--- Comment #38 from bergner at gcc dot gnu dot org 2007-06-09 04:08
---
Created an attachment (id=13671)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13671&action=view)
Updated patch to address x86_64 performance issues.
This updated patch reverts the swap_commutative_operands_
--- Comment #6 from rob1weld at aol dot com 2007-06-09 03:52 ---
Changing From / To:
"Known to work: (Blank)" and "Known to fail: 4.2.0 4.2.1 4.3.0"
"Known to work: 4.3.0" and "Known to fail: 4.2.0 4.2.1"
Since 4.3.0 works on i686-pc-linux-gnu perfectly - No reason to believe 4.3.0
wo
--- Comment #2 from rob1weld at aol dot com 2007-06-09 03:45 ---
Tried running "make -i check" on a just-built version of gcc while compiling a
newer revision of gcc in a different X-Window. The load was enough to give a
number of timeouts in various places.
It is inconvenient to be una
--- Comment #4 from rob1weld at aol dot com 2007-06-09 03:27 ---
One enhancement I did try was adding this to the end of contrib/test_summary.
It does nothing for _me_ since I have the new assembler but for others it would
catch the failures and report them.
print "";
print "---";
--- Comment #2 from rob1weld at aol dot com 2007-06-09 03:17 ---
>> From [EMAIL PROTECTED]
> I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
> the most recent patches. My version is 2.2.1-p5.
>> What does p4 do?
They only offer the patches mixed together, int
+++ This bug was initially created as a clone of Bug #21291 +++
works with -O0, fails with -O[123].
gcc-4.0.0 + patches for pr20973,21173.
I could not reopen http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21291 so I
thought I'd try clicking on clone this bug since it has re-emerged in 4.2.0 and
4.3.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-09 02:10 ---
This is related to (or a dup of) bug 19590.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from rob1weld at aol dot com 2007-06-09 00:57 ---
Here is a related failure this time for gcc.c-torture/execute/20050604-1.c :
# grep --color=always -B16 -A6 20050604-1.c gcc/testsuite/gcc/gcc.log | tail -n
26
Executing on host: /opt/gcc-4_3-build-2/gcc/xgcc -B/opt/gcc-4
--- Comment #5 from pcarlini at suse dot de 2007-06-09 00:26 ---
Ok, that is it. That locale must be installed because old glibcs had a bug
which showed up clearly with "de_DE" and we must check against it. The docs
explain that, anyway:
http://gcc.gnu.org/onlinedocs/libstdc++/install
--- Comment #4 from thanate at asu dot edu 2007-06-09 00:22 ---
localedef --list-archive gave me only one line:
en_US.utf8
I think that's how I set up my system, with only one locale.
Now I'm not sure why should I have to have de_DE installed
for locale("") to work. But if you want, I
--- Comment #3 from pcarlini at suse dot de 2007-06-09 00:11 ---
See this line in the Log:
> checking for C locale to use... generic
That means the configure-time tests for the gnu locale model are not ok and the
generic locale model is selected instead, as a fallback. Can you investig
--- Comment #2 from thanate at asu dot edu 2007-06-08 23:40 ---
umm... I don't know how to check for that.
But I ran configure with --enable-clocale=gnu.
I posted my build log at
http://mathpost.asu.edu/~thanate/build.log
I'll keep the build dir for a while in case
you need some more l
--- Comment #2 from jsberg04+computing dot bugs dot gcc at ftml dot net
2007-06-08 23:38 ---
Created an attachment (id=13670)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13670&action=view)
Preprocessed, bzip2 compressed example.
>From Xorg 7.2.0, if anyone cares...
--
http
--- Comment #32 from pinskia at gcc dot gnu dot org 2007-06-08 23:38
---
*** Bug 32266 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 23:38 ---
*** This bug has been marked as a duplicate of 30052 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
I will attach the example in a subsequent comment. If I execute:
gcc -O1 -c xf86ScanPci.c
it sucks up 805M of virtual memory. No optimization, no problem.
gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.0/configure --prefix=/opt/gcc-4.2.0
--enable-threads --w
--- Comment #7 from rob1weld at aol dot com 2007-06-08 23:34 ---
I tried this on i686-pc-linux-gnu using gcc-3.4 (from Debian), gcc-4.1 (from
Debian), gcc version 4.2.0 20070501 (prerelease) (from SVN), and gcc version
4.3.0 20070607 (experimental) (from SVN):
I modified as follows:
/*
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 22:14 ---
> --never_inline prevents all inlining, even when called for in source code
-fno-inline
(Or do you mean even with attribute always_inline?)
> --no_automatic_inline prevents automatic inlining, i.e. inlining by the
No matter how high the optimzation level,
--never_inline prevents all inlining, even when called for in source code
--no_automatic_inline prevents automatic inlining, i.e. inlining by the
compiler when not specifically called for in the source code
--
Summary: --never_inline and --
--- Comment #10 from mueller at gcc dot gnu dot org 2007-06-08 21:48
---
Subject: Bug 31809
Author: mueller
Date: Fri Jun 8 21:48:34 2007
New Revision: 125580
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125580
Log:
2007-06-08 Dirk Mueller <[EMAIL PROTECTED]>
PR c+
--- Comment #9 from mueller at gcc dot gnu dot org 2007-06-08 21:48 ---
Subject: Bug 31806
Author: mueller
Date: Fri Jun 8 21:48:34 2007
New Revision: 125580
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125580
Log:
2007-06-08 Dirk Mueller <[EMAIL PROTECTED]>
PR c++/
--- Comment #3 from axel at freakout dot de 2007-06-08 20:25 ---
Subject: Re: 03.5: gcc 4.2.0 compiled vanilla
kernel 2.4.34.5 crashes when VIA C3 optimized -march=c3
According to pinskia at gcc dot gnu dot org:
>
> --- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 2
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:19 ---
Testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32264
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-08 20:18 ---
I think we need more information from you about what issues you are running
into.
I also use glibc 2.3.2 with many different versions of GCC too. I still don't
see what regressions you are talking about anyways.
-
When Linux vanilla kernel 2.4.34.5 is compiled with -march=c3 (VIA C3)
- kernel crashes after boot on a VIA C3
.config: CONFIG_MCYRIXIII=y
Environment:
System: Linux bongo 2.4.34.5-ARXc3 COHERENT #9-ARX (Build 3359) Fri Jun 8
16:41:33 CEST 2007 i686 i686 i386 GNU/Linux
Architectur
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 20:16 ---
HUH? I had never had any problems with older versions of GCC with newer
versions of binutils. If you do then either it is a bug in the older version
of GCC (which is likely) or a bug in the newer binutils (which is
Document the required versions of glibc and binutils.
Typically only a couple versions of glibc and binutils are compatible with each
version of gcc, and finding out which ones are compatible is often quite
time-consuming. While "gcc/doc/gccinstall.info" does document some minimum
versions, it sh
I have configure gcc like this:
/n/08/rask/src/gcc/configure --target=m68hc11-none --disable-multilib
--disable-nls --with-newlib --enable-sim
Building libgfortran fails with this message:
libtool: compile: /home/rask/build/gcc-m68hc11-none/./gcc/gfortran
-B/home/rask/build/gcc-m68hc11-none/./g
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-06-08 19:50 ---
>It is also fixed in 3.4.6.
Well then it is fixed as 3.3.x is no longer being maintained and has not been
for over a year (or two).
--
pinskia at gcc dot gnu dot org changed:
What|Removed
Compiling with:
g++ -g -O3 gccbug.cpp -pthread -o gccbug -s
Note that removing the -s eliminates the segfault, as does removing
optimizations with -O0.
This occurs with gcc 3.3 and 3.3.6 but does not occur with the gcc 3.2.3
delivered as part of RedHat ES3.0u5. It is also fixed in 3.4.6.
#inclu
--- Comment #2 from goeran at uddeborg dot se 2007-06-08 19:25 ---
Ok. I've found a few more in parse.y, but I won't bother to report them then.
So far nothing outside this time around, but I have a few hundred messages to
go ... :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
--- Comment #12 from anhvofrcaus at gmail dot com 2007-06-08 19:11 ---
You are right Constraint_Error is raised when checking for validity through
Item.all'Valid if Item is null. Therefore, using Laurent's to check Item for
null is the only way. Either one of these methods verifies that
--- Comment #11 from baldrick at gcc dot gnu dot org 2007-06-08 18:46
---
> Thank you both for your explanation to a newbie having no experience with
> valgrind tool. I have come up with a simpler version which similar to
> Laurent's. Here it goes.
Thanks - but how is it supposed to wo
The following code, compiled with -O2 -Wall (g++ 4.3 as of 20070607),
produces the following unexpected/annoying warning:
test_typeinfo.cpp: In function 'int main()':
test_typeinfo.cpp:5: warning: dereferencing type-punned pointer will break
strict-aliasing rules
test_typeinfo.cpp:5: warning: unus
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:36 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org changed:
--- Comment #1 from tromey at gcc dot gnu dot org 2007-06-08 18:35 ---
I'm closing this, because parse.y no longer exists on svn trunk.
If you find instances of this bug in the remaining parts of gcj,
please file a new PR. Thanks.
--
tromey at gcc dot gnu dot org changed:
--- Comment #4 from simartin at gcc dot gnu dot org 2007-06-08 18:27
---
Fixed on the mainline.
--
simartin at gcc dot gnu dot org changed:
What|Removed |Added
I checked http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16104 which is for
gcc.c-torture/execute/20050316-1.c and this is not related.
In this test optimization levels "-O0", "-O1" and "-O2" are broken, levels
"-O3" and "-Os" are OK. I am using rtl and rtlflag checking.
# gcc/xgcc -v
Using built-i
--- Comment #4 from ian at airs dot com 2007-06-08 17:57 ---
I'm testing this patch.
Index: tree-vrp.c
===
--- tree-vrp.c (revision 125521)
+++ tree-vrp.c (working copy)
@@ -2208,6 +2208,8 @@ extract_range_from_unary_expr
--- Comment #7 from rask at sygehus dot dk 2007-06-08 17:35 ---
Created an attachment (id=13669)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13669&action=view)
Patch v3 to add -L and -B as necessary
This patch should fix the mep* case that I accidentally deleted.
--
rask at
Hi,
maybe someone of the gcc bugs group can help you, this bug is
unrelated to the video4linux/em28xx project.
Maybe retrying to compile the code might fix it, (I would try to run
memcheck and checking for faulty memory)
Markus
On 6/8/07, Romain Fluttaz <[EMAIL PROTECTED]> wrote:
Hi, i'm unde
--- Comment #1 from kargl at gcc dot gnu dot org 2007-06-08 17:14 ---
(In reply to comment #0)
> I installed http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2 and applied
> the
> most recent patches. My version is 2.2.1-p5.
What does p4 do?
--
kargl at gcc dot gnu dot org changed
--- Comment #1 from pcarlini at suse dot de 2007-06-08 16:53 ---
In fact, the problem is of the same type of that in C++/30500: in C++ only when
execute_warn_function_return begins in_system_header is zero (in C is 1 and all
the warnings are suppressed because diagnostic_report_warnings_
--- Comment #6 from pinskia at gcc dot gnu dot org 2007-06-08 16:51 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
org/ml/gcc-testresults/2007-05/msg01083.html
Here are some other people's results - some used the --with-mpfr option:
Compiled using "--with-mpfr=/remote/atg5/jbuck/mpfr-linux" :
Results for 4.3.0 20070608 (experimental) testsuite on i686-pc-linux-gnu
http://gcc.gnu.org/ml/gcc-testresu
--- Comment #8 from brolley at redhat dot com 2007-06-08 15:47 ---
Created an attachment (id=13668)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13668&action=view)
Improvement on previous patch
--
brolley at redhat dot com changed:
What|Removed
--- Comment #7 from brolley at redhat dot com 2007-06-08 15:46 ---
Small optimization. We need only call complete_type_or_else once we know it's
an array type.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
--- Comment #6 from brolley at redhat dot com 2007-06-08 15:42 ---
Created an attachment (id=13667)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13667&action=view)
New proposed patch
--
brolley at redhat dot com changed:
What|Removed |Added
--- Comment #5 from brolley at redhat dot com 2007-06-08 15:41 ---
OK, I've looked into this a bit more. For inspiration I looked into where the
error is generated when an incomplete struct is used instead of an unsized
array. I found it in:
cxx_incomplete_type_diagnostic called by
comp
The following program exposes a problem with the scoping of the loop variable
in the IO statement:
program test
implicit none
character(len=100) :: value
integer, dimension(100) :: intvalues
integer i
i = 2
intvalues = 42
value = "2 5 69"
write(*,*) len(trim(value))
rea
--- Comment #4 from dominiq at lps dot ens dot fr 2007-06-08 15:35 ---
You may also have a look to PR30572.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32255
--- Comment #3 from dir at lanl dot gov 2007-06-08 15:32 ---
It is something new for me. My last build from 4 days ago did not have the
problem -
[dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f
[dranta:~/tests/gfortran-D] dir% gfortran --v
Using built-in
Hi, this header (header.h):
#pragma GCC system_header
int noreturn() { }
included by (file.cc):
#include "header.h"
void ok() { }
Leads to:
paolo:~/Work> g++ -Wall -c file.cc
header.h: In function 'int noreturn()':
header.h:2: warning: control reaches end of non-void function
Note, this probl
--- Comment #2 from dominiq at lps dot ens dot fr 2007-06-08 15:13 ---
> /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib referenced
I have seen this problem while regetesting g++. I am not sure, but I think I
have reported the problem to the gcc list without answer (
--- Comment #1 from dir at lanl dot gov 2007-06-08 14:59 ---
I just noticed that programs work anyway -
[dranta:~/tests/gfortran-D] dir% rm testioBackspace
[dranta:~/tests/gfortran-D] dir% gfortran -o testioBackspace testioBackspace.f
/usr/bin/ld: warning can't open dynamic library: /li
posix
gcc version 4.3.0 20070608 (experimental)
--
Summary: warning can't open dynamic library
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: una
--- Comment #4 from r dot f dot arduini at larc dot nasa dot gov
2007-06-08 14:15 ---
Subject: Re: internal compiler error: in gfc_assign_data_value, at
fortran/data.c:288
Can you please tell me why the compiler flags "tauaero.f:1517" while
the problem seems to be associated with th
--- Comment #172 from rguenther at suse dot de 2007-06-08 13:47 ---
Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement
new does not change the dynamic type as it should
On Fri, 8 Jun 2007, ian at airs dot com wrote:
>
>
> --- Comment #171 from ian at airs dot com 2007-06-08 0
--- Comment #3 from pault at gcc dot gnu dot org 2007-06-08 12:56 ---
(In reply to comment #2)
> Also breaks 465.tonto in SPEC2006.
> I'd say it's
> 2007-06-04 Lee Millward <[EMAIL PROTECTED]>
Gentlemen, you will see that this patch was reverted this morning because it
caused PRs3,
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-06-08 12:27 ---
Also breaks 465.tonto in SPEC2006.
I'd say it's
2007-06-04 Lee Millward <[EMAIL PROTECTED]>
* trans-intrinsic.c (gfc_conv_intrinsic_function_args): Adjust
to operate on a stack allocated array for
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:39 ---
works for me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UN
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:36 ---
Confirmed.
{
struct foo x = {.mem1=0, .mem2=-1};
<>;
<).mem2) >>>
>>;
return = 0;
}
2.95 used zero for .mem2 initialization.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:28 ---
Confirmed. We are wrongly expanding
;; D.2027 = D.2026 << 32
(insn 18 17 0 (parallel [
(set (reg:DI 59 [ D.2027 ])
(ashift:DI (reg:DI 60 [ D.2026 ])
(const_int 32 [0x
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-06-08 10:16 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-06-08 10:11 ---
Confirmed. Instead of calls to _gfortran_pow_r4_i4, gfortran should use
__builtin_powi in this case. __builtin_powi is either expanded inline or
implemented by the libgcc powi function which looks like
TYPE
NAME (
--- Comment #5 from ubizjak at gmail dot com 2007-06-08 09:14 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|ubizjak at gmail dot
--- Comment #4 from uros at gcc dot gnu dot org 2007-06-08 09:06 ---
Subject: Bug 32243
Author: uros
Date: Fri Jun 8 09:06:46 2007
New Revision: 125567
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125567
Log:
PR tree-optimization/32243
* tree-vect-transform.c
--- Comment #5 from dorit at gcc dot gnu dot org 2007-06-08 08:58 ---
Subject: Bug 32224
Author: dorit
Date: Fri Jun 8 08:57:54 2007
New Revision: 125566
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125566
Log:
PR tree-optimization/32224
* tree-vect-analyze.c
--- Comment #1 from pcarlini at suse dot de 2007-06-08 08:38 ---
The only possible explanation is that, at build time, the configury didn't find
the required localedata (at least "de_DE") or other tests failed, and the
generic (instead of gnu) locale model has been selected. In that case
--- Comment #8 from chrbr at gcc dot gnu dot org 2007-06-08 08:18 ---
doloop_optimize does the iv inversion with the doloop_end insn support in the
machine description.
--
chrbr at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06
---
Patch reverted until Lee comes back, PR assigned to him.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:06
---
Patch reverted until Lee comes back, and bug assigned to him so that he takes
care of it in the next round.
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2007-06-08 08:04
---
(In reply to comment #1)
> r125316 | fxcoudert | 2007-06-04 22:59:49 +0200 (Mo, 04 Jun 2007) | 31 lines
> 2007-06-04 Lee Millward <[EMAIL PROTECTED]>
> http://gcc.gnu.org/ml/gcc-cvs/2007-06/msg00072.html
Patch re
--- Comment #3 from ubizjak at gmail dot com 2007-06-08 08:02 ---
Patch in testing.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #7 from chrbr at gcc dot gnu dot org 2007-06-08 07:58 ---
Subject: Bug 29953
Author: chrbr
Date: Fri Jun 8 07:58:41 2007
New Revision: 125564
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125564
Log:
PR target/29953
* config/sh/sh.md (doloop_end): New pattern and s
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-08 07:52 ---
(In reply to comment #1)
> no, this is OK (whether it is a good design choice is another thing, I will
> think about that).
I actually have a fix for this issue (the MEM with just index: and offset:) but
it is goin
--- Comment #171 from ian at airs dot com 2007-06-08 07:49 ---
Created an attachment (id=13666)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13666&action=view)
Patch
This variant of the previous patch does better on at least some of the tramp3d
functions. Here we eliminate the C
--- Comment #12 from rakdver at gcc dot gnu dot org 2007-06-08 07:29
---
Subject: Bug 32209
Author: rakdver
Date: Fri Jun 8 07:28:50 2007
New Revision: 125563
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125563
Log:
PR middle-end/32209
* dominance.c (debug_do
--- Comment #2 from ubizjak at gmail dot com 2007-06-08 07:20 ---
Confirmed, fails also on i686 (-O3 -msse2 -ftree-vectorize).
Backtrace:
#1 0x08686e6e in vectorizable_type_promotion (stmt=0xb7d0624c, bsi=0x0,
vec_stmt=0x0) at ../../gcc-svn/trunk/gcc/tree-vect-transform.c:2891
#2 0x0
The following code compiles and run find using my system's
g++-4.1.3 but when compiled with g++-4.2.1 from SVN,
I get
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
//-
#include
#include
in
80 matches
Mail list logo
