[Bug fortran/31251] Non-integer character length leads to segfault

--- Comment #10 from jvdelisle at gcc dot gnu dot org 2007-05-04 07:39 --- Comment #9 is a red herring. Using gdb and looking at this at line 2143: mpz_set (result->value.integer, e->ts.cl->length->value.integer); (gdb) p *e->ts.cl->length $9 = {expr_type = EXPR_CONSTANT, ts = {

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #40 from ian at airs dot com 2007-05-04 07:37 --- Created an attachment (id=13506) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13506&action=view) Patch Here is yet another patch, an improvement over the previous one. It finally dawned on me that we can use an asm to

[Bug fortran/31692] Wrong code when passing function name as result to procedures

--- Comment #3 from pault at gcc dot gnu dot org 2007-05-04 07:29 --- This fixes it but needs some cleaning up: Index: gcc/fortran/trans-expr.c === *** gcc/fortran/trans-expr.c(revision 124354) --- gcc/fortran/trans-exp

[Bug fortran/31251] Non-integer character length leads to segfault

--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-05-04 06:42 --- I think the problem may be in arith.c (gfc_constant_result). We are passing a type real into this and so we do not mpz_init (result->value.integer); Which we later try to set at simplify.c: 2143 mpz_set

[Bug target/31797] gcc-4.2.0 racing

--- Comment #4 from ralf_corsepius at rtems dot org 2007-05-04 06:36 --- Using GT64260eth.c from attachment 13505, I am able to reproduce the race with gcc-4.2.0-20070430 for arm-rtems, bfin-rtems, powerpc-rtems, i386-rtems. => I assume this issue to be target independent and to affect

[Bug target/31797] powerpc: race

--- Comment #3 from ralf_corsepius at rtems dot org 2007-05-04 06:29 --- Created an attachment (id=13505) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13505&action=view) Stripped down example to expose the issue on all targets -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3

[Bug ada/31800] ACATS c46051a fails

--- Comment #5 from ebotcazou at gcc dot gnu dot org 2007-05-04 06:26 --- Spurious. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|W

[Bug fortran/31251] Non-integer character length leads to segfault

--- Comment #8 from kargl at gcc dot gnu dot org 2007-05-04 06:16 --- This appears to be an alignment issue. On x86_64-*-FreeBSD, I do not see the segfault. On i386-*-FreeBSD, I see the segfault. Here's is the backtrace Starting program: /usr/home/kargl/work/4x/libexec/gcc/i386-unknow

[Bug c++/10179] alignment attributes are not inherited correctly with empty classes

--- Comment #4 from jadamcze at utas dot edu dot au 2007-05-04 05:58 --- Also present in mainline as of 20070406. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10179

[Bug c++/10179] alignment attributes are not inherited correctly with empty classes

--- Comment #3 from jadamcze at utas dot edu dot au 2007-05-04 05:10 --- Bitten and confirmed. gcc-4.1.1 (from cellsdk-2.0). -- jadamcze at utas dot edu dot au changed: What|Removed |Added -

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #39 from bangerth at dealii dot org 2007-05-04 04:54 --- >From my perspective as a user, I wouldn't find a memory clobber in front of every placement new all that terrible. People don't do that in tight loops, and even if they did all that would happen is that the clobber pre

[Bug c/31804] gcc segfaults on very long pointer chains

--- Comment #3 from bangerth at dealii dot org 2007-05-04 04:50 --- (In reply to comment #0) > $ perl -wle 'print "int", "*" x 99, "p;"' >try.c && gcc try.c > gcc: Internal error: Segmentation fault (program cc1) Yo, dude, that would take a seriously long program to even initialize

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #38 from mark at codesourcery dot com 2007-05-04 03:47 --- Subject: Re: [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should rguenth at gcc dot gnu dot org wrote: > --- Comment #36 from rguenth at gcc dot gnu dot org 2007-05-03 21:5

[Bug c/31804] gcc segfaults on very long pointer chains

--- Comment #2 from fang at csl dot cornell dot edu 2007-05-04 03:40 --- adding to personal favorite list :) -- fang at csl dot cornell dot edu changed: What|Removed |Added --

[Bug fortran/31251] Non-integer character length leads to segfault

--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-05-04 03:27 --- Very odd. On rev 124344 on my old i686 FC5 box I did a bootstrap. This is unmodified source from the svn and I get no segfault and just the double error. This is what I see on x86-64 as reported above. --

[Bug fortran/31218] ICE on valid code with gfortran

--- Comment #4 from jvdelisle at gcc dot gnu dot org 2007-05-04 02:47 --- The ice is happening here: /* Create an array constructor from an initialization expression. We assume the frontend already did any expansions and conversions. */ tree gfc_conv_array_initializer (tree type,

[Bug gcov-profile/31810] gcov returns wrong results

--- Comment #2 from echristo at apple dot com 2007-05-04 02:38 --- Yeah, probably. Bah. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31810

[Bug c++/12076] gcov misreports coverage of return statement [NRV]

--- Comment #14 from pinskia at gcc dot gnu dot org 2007-05-04 02:34 --- *** Bug 31810 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug gcov-profile/31810] gcov returns wrong results

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-04 02:34 --- And this is why people should not confirm their own bugs :). *** This bug has been marked as a duplicate of 12076 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |

[Bug gcov-profile/31810] gcov returns wrong results

-- echristo at apple dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|

[Bug gcov-profile/31810] New: gcov returns wrong results

#include // this global string causes gcov to think there's executable lines // beyond the end of the file, and that they have not been executed std::string globalVar = ""; std::string doSomething() { // instantiating this string and calling a method on it causes the // 'return' line to

[Bug c++/20912] C++ FE emitting assignments to read-only global symbols

--- Comment #19 from pinskia at gcc dot gnu dot org 2007-05-04 01:30 --- One more case where C++ front-end is doing this still is located in PR 31809. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/31809] [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.0.2 4.1.1 4.2.0 4.3.0 Known to work|

[Bug c++/31809] New: [4.1/4.2/4.3 Regression] sometimes TREE_READONLY is still set for non read only variables causing wrong code

Testcase which should not abort but does currently at -O1 and above because SRA thinks the decl is constant so it using its DECL_INITIAL but that is NULL so we get a zero instead of the corect value: struct sc { unsigned v; static inline sc f(unsigned a); }; inline sc sc::f(unsigned a) { static

[Bug ada/31808] New: cross-built gnattools installs vxaddr2line regardless of target triplet

When building an ada-enabled compiler in a cross-environment, the gnattools directory will install "vxaddr2line", even if the target is not *-*-vxworks*. It should only install vxaddr2line when the target matches *-*-vxworks*. -- Summary: cross-built gnattools installs vxaddr2line re

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

--- Comment #4 from daney at gcc dot gnu dot org 2007-05-04 00:01 --- Sorry for the noise. After unpacking the tarball with gnu tar, the bootstrap proceeds past the previous point of failure. -- daney at gcc dot gnu dot org changed: What|Removed |

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-03 23:30 --- The tar file which is created has the GNU tar extensions in it as file names are long. If you see anywhere @long_file (I think that is the name of the file) file, then you know it did not exact it correctly. --

[Bug ada/31800] ACATS c46051a fails

--- Comment #4 from anhvofrcaus at gmail dot com 2007-05-03 23:28 --- On the second ACATS run, c46051a test passes. You are correct it exhibits a spurious behavior. Therefore, this report is withdrawn (closed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31800

[Bug fortran/31781] fortran regressions on trunk if you --disable-checking

--- Comment #4 from fxcoudert at gcc dot gnu dot org 2007-05-03 23:11 --- Stupid mistake, trivial patch: Index: simplify.c === --- simplify.c (revision 124285) +++ simplify.c (working copy) @@ -2919,7 +2919,10 @@ gfc_sim

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

--- Comment #2 from daney at gcc dot gnu dot org 2007-05-03 23:09 --- Dang. I am using busybox tar. It seems to have failed while unpacking the tarfile. I am building gnu tar now. Perhaps that will solve this problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31807

[Bug ada/31800] ACATS c46051a fails

--- Comment #3 from ebotcazou at gcc dot gnu dot org 2007-05-03 23:04 --- > Is there a spurious failure catatory in ACATS? They are spurious failures on Linux, because of the harness. Just look at the log file and post the error message. -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug libstdc++/31807] bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

--- Comment #1 from daney at gcc dot gnu dot org 2007-05-03 23:02 --- I am investigating why ext/pb_ds/detail/unordered_iterator/const_point_iterator.hpp is missing from my source directory when it appears to be in the tarball. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31807

[Bug fortran/31781] fortran regressions on trunk if you --disable-checking

--- Comment #3 from dfranke at gcc dot gnu dot org 2007-05-03 22:57 --- With "--enable-checking", the same dump as shown in comment #3 looks like: $> cat repeat.f90.003t.original MAIN__ () { _gfortran_set_std (68, 127, 0, 0, 0); { struct __st_parameter_dt dt_parm.0; dt_parm

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

--- Comment #4 from dj at redhat dot com 2007-05-03 22:55 --- Gak, the grep didn't show it earlier today, but does now. Sigh. Lesson: never buy quantum computers! We still have the problem that almost half the targets (on trunk) don't have gen_blockage(). Will updating all the target

[Bug libstdc++/31807] New: bootstrap failure in 4.2.0 RC3. const_point_iterator.hpp not found

I was trying to bootstrap from the 4.2.0 RC3 tarball. Configured as: ../gcc-4.2.0-20070501/configure --with-arch=mips32 --with-float=soft --disable-java-awt --without-x --disable-tls --enable-__cxa_atexit --disable-jvmpi --disable-static --disable-libmudflap --enable-languages=c,c++,java A simila

[Bug ada/31800] ACATS c46051a fails

--- Comment #2 from anhvofrcaus at gmail dot com 2007-05-03 22:48 --- Is there a spurious failure catatory in ACATS? If true, how many are there? Are they documented in the ACATS test procedure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31800

[Bug fortran/31781] fortran regressions on trunk if you --disable-checking

--- Comment #2 from dfranke at gcc dot gnu dot org 2007-05-03 22:46 --- Confirmed. Testcase: $> cat repeat.f90 character(len=1), parameter :: s1 = "a" print *, "aa: ", repeat(s1, 2) end $> gfortran-svn -g -Wall -fdump-tree-original repeat.f90 $> cat repeat.f90.003t.original MAIN_

[Bug ada/31669] GNAT blows up during compilation

--- Comment #2 from anhvofrcaus at gmail dot com 2007-05-03 22:42 --- Just use a normal command as shown below: gcc -c re_not_available.ads It is true that gnatdist is part of GLADE. However, it should reject the codes rather raising exception and terminated. -- http://gcc.gnu.org

[Bug rtl-optimization/31806] New: miscompilation with -fschedule-insns2 -fthreadsafe-statics and static variables

Hi, the testcase below aborts with gcc 4.1.3 compiled with: g++ -O2 -fno-threadsafe-statics === Cut === extern "C" void abort(void); struct A { void *d; }; static const A& staticA() { static A s_static; return s_static; } void assert_failed() { abort(); } A testMethod() {

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #37 from pcarlini at suse dot de 2007-05-03 22:24 --- By the way, would it be possible to have a look at the assembly of competitors? I'm under the impression that a quick look would more than enough to understand whether we are optimizing "enough"... -- http://gcc.gnu.o

[Bug middle-end/31095] [4.3 Regression] ICE in expand_expr_real_1, at expr.c:8786

--- Comment #7 from pinskia at gcc dot gnu dot org 2007-05-03 22:06 --- *** Bug 31805 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug fortran/31805] [4.3 only] regression of st_function.f90

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-03 22:06 --- *** This bug has been marked as a duplicate of 31095 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug fortran/31805] New: [4.3 only] regression of st_function.f90

Since May 1st, gfortran.fortran-torture/execute/st_function.f90 fails to compile with optimization enabled. $> gfortran-svn -g -O1 st_function.f90 && ./a.out st_function.f90: In function 'MAIN__': st_function.f90:63: internal compiler error: in expand_expr_real_1, at expr.c:8833 (gdb) bt #0 fanc

[Bug c/31804] gcc segfaults on very long pointer chains

--- Comment #1 from rguenth at gcc dot gnu dot org 2007-05-03 22:02 --- you must be kidding. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added St

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

--- Comment #3 from pinskia at gcc dot gnu dot org 2007-05-03 22:00 --- (In reply to comment #2) > there's no mention of "blockage" in the trunk documentation. HUH? @cindex @code{blockage} instruction pattern @item @samp{blockage} This pattern defines a pseudo insn that prevents the i

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #36 from rguenth at gcc dot gnu dot org 2007-05-03 21:59 --- Well, the patch in comment #33 really does what I did with the patch to libstdc++. If we take the first patch (from comment #29) and change its effects on the alias machinery so that for q = ALIAS_CONVERT_EXPR (

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #35 from pinskia at gcc dot gnu dot org 2007-05-03 21:48 --- (In reply to comment #34) > "*intentionally* (emphasis mine) performs no other action". There is no other action taken, it is just a barrior, not even really an action in my mind. -- http://gcc.gnu.org/bugzil

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #34 from pcarlini at suse dot de 2007-05-03 21:45 --- First blush, I'm not enthusiastic about this last proposal. Seems to me just a concealed way to do what Richard suggested at the beginning of this thread. As such, I'm still finding it, in spirit at least, against the lett

[Bug middle-end/31802] SSE2 performance is deteriorating when __m128 is placed in union

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-03 21:44 --- This is because the union does not get the correct mode (it gets BLK or TImode) so GCC stores the union to the stack all the time. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug c/31804] New: gcc segfaults on very long pointer chains

$ perl -wle 'print "int", "*" x 99, "p;"' >try.c && gcc try.c gcc: Internal error: Segmentation fault (program cc1) ... $ gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.1.1-r3/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/i686-pc

[Bug fortran/25071] dummy argument larger than actual argument

--- Comment #3 from patchapp at dberlin dot org 2007-05-03 20:50 --- Subject: Bug number PR25071 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00186.html -- http://gcc.gnu.org/bugzilla/sh

[Bug libstdc++/29286] [4.0/4.1/4.2/4.3 Regression] placement new does not change the dynamic type as it should

--- Comment #33 from ian at airs dot com 2007-05-03 20:33 --- Created an attachment (id=13504) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13504&action=view) Patch Here is a much simpler patch which also fixes the problem. This simply inserts a memory clobber before each placem

[Bug c/31537] duplicate weakref emitted with IMA

--- Comment #4 from geoffk at gcc dot gnu dot org 2007-05-03 20:14 --- The following testcase should be equivalent to the original one but not involve IMA: void f1() { static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once"))); } void f2() { static __gthrw_pthread_

[Bug ada/31800] ACATS c46051a fails

--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-05-03 20:01 --- Please try again, it may be spurious. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

--- Comment #2 from dj at redhat dot com 2007-05-03 20:01 --- Note that only 19 out of 33 target directories (trunk) even mention the word "blockage" and there's no mention of "blockage" in the trunk documentation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31801

[Bug ada/31669] GNAT blows up during compilation

--- Comment #1 from ludovic at ludovic-brenta dot org 2007-05-03 19:47 --- Please specify how you invoked the compiler, and understand that you need gnatdist for distributed programs. gnatdist is part of GLADE which is separate from GNAT. -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug ada/30618] [4.1 regression] Infinite loop in sem_ch8.end_use_clauses

--- Comment #3 from ludovic at ludovic-brenta dot org 2007-05-03 19:45 --- Since when are regressions priority P5? I understand Ada is never release-critical (what a shame) but P2 would be appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30618

[Bug fortran/31803] ICE when for character pointer => target(range)

--- Comment #1 from burnus at gcc dot gnu dot org 2007-05-03 19:43 --- ==11966== Invalid read of size 8 ==11966==at 0x41BF0C: gfc_check_pointer_assign (expr.c:2555) ==11966==by 0x4519D0: resolve_code (resolve.c:5225) ==11966==by 0x452D3D: resolve_codes (resolve.c:7386) Bette

[Bug fortran/31803] New: ICE when for character pointer => target(range)

character (len = 70), target :: textt character (len = 70), pointer :: textp character (len = 50), pointer :: textp2 a = 42 textp => textt textp2 => textt(1:50) end -- Summary: ICE when for character pointer => target(range) Product: gcc Version: 4.3.

[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)

--- Comment #8 from sje at cup dot hp dot com 2007-05-03 19:36 --- I went back to r124216 and added a print to see what the next instruction was, since it wasn't a barrier. What I found was a "NOTE_INSN_DELETED_LABEL", followed by a barrier. I am guessing we want to ignore that (and an

[Bug c++/31802] New: SSE2 performance is deteriorating when __m128 is placed in union

When I compile the following testcase with '-O3 -msse3' options it runs in 22.562sec, without 'union' clause it runs in 0.280sec. And should be the same time. -- begin testcase -- typedef float __v2df __attribute__ ((__vector_size__ (16))); typedef __v2df __m128; static __inline __m128 _mm_sub_p

[Bug ada/16086] Legal program rejected, procedure of protected object should be visible

--- Comment #5 from ludovic at ludovic-brenta dot org 2007-05-03 19:27 --- I disagree. Per RM 9.5.1(1), "a protected subprogram IS a subprogram..." (emphasis mine). Furthermore, the last sentence of 12.6(9) says: "The view is a function or procedure, never an entry". Both of these se

[Bug target/31801] [dataflow] undefined reference to `gen_blockage'

--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-03 19:24 --- This is all target issues, they should be including a pattern for blockage. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug ada/15606] Legal program rejected, RM 8.2(22)

--- Comment #3 from ludovic at ludovic-brenta dot org 2007-05-03 19:15 --- I disagree. As highlighted at the beginning of this PR, per 8.2(2), the instance becomes visibleonly _after_ its declaration, i.e. at the semicolon. Before the semicolon, the two "Foo"s are NOT ambiguous becaus

[Bug middle-end/31801] New: [dataflow] undefined reference to `gen_blockage'

Hello, the targets avr, cris, h8300, m32c and v850 show the same error when build in the dataflow-branch: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold

[Bug fortran/31399] Wrong code for do loop with large interation count

--- Comment #3 from patchapp at dberlin dot org 2007-05-03 18:37 --- Subject: Bug number PR31399 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00121.html -- http://gcc.gnu.org/bugzilla/sh

[Bug fortran/31630] [4.3 regression] ICE on nasty derived types code

--- Comment #5 from patchapp at dberlin dot org 2007-05-03 18:37 --- Subject: Bug number PR31630 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00116.html -- http://gcc.gnu.org/bugzilla/sh

[Bug target/31768] Invalid code or ICE for %z constraint

--- Comment #4 from ubizjak at gmail dot com 2007-05-03 17:38 --- (In reply to comment #3) > Is there any chance of this problem being fixed in 4.1 and 4.2 as well? If so, > should I open new bugs for those? The %z modifier is IMO not intended for general use, so I don't think the backp

[Bug rtl-optimization/31799] Failed to optimize out test instruction

--- Comment #2 from ubizjak at gmail dot com 2007-05-03 17:22 --- Ah, for some reason insn 13 does not have the insn link pointing to insn 10. Probably dataflow should/could fix this? -- ubizjak at gmail dot com changed: What|Removed |Added ---

[Bug rtl-optimization/31799] Failed to optimize out test instruction

--- Comment #1 from ubizjak at gmail dot com 2007-05-03 17:08 --- (In reply to comment #0) > foo: > addl$1, %edi > testl %edi, %edi > movl%edi, (%rdx) > je .L3 > movl$1, (%rsi) > .L3: > rep ; ret This is just an unfortu

[Bug target/30243] avr-gcc 4.1.1: signbit() causes an internal compiler error

--- Comment #1 from eweddington at cso dot atmel dot com 2007-05-03 17:06 --- Confirmed. Also fails for 4.1.2. -- eweddington at cso dot atmel dot com changed: What|Removed |Added ---

[Bug target/31644] [avr] can't find a register in class 'BASE_POINTER_REGS' while reloading 'asm'

--- Comment #2 from eweddington at cso dot atmel dot com 2007-05-03 16:56 --- Confirmed on GCC 4.1.2. -- eweddington at cso dot atmel dot com changed: What|Removed |Added

[Bug c/18624] GCC does not detect local variable set but never used

--- Comment #9 from pinskia at gcc dot gnu dot org 2007-05-03 16:52 --- *** Bug 31795 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/31795] -Wunused should warn about variables set but never read

--- Comment #2 from pinskia at gcc dot gnu dot org 2007-05-03 16:52 --- *** This bug has been marked as a duplicate of 18624 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

--- Comment #8 from eweddington at cso dot atmel dot com 2007-05-03 16:40 --- Confirmed. Code snippet fails for 4.1.2 when compiling for -O2 and -O3. Note that compiling with -O[0,1,s] is successful. Changing target to all avr. -- eweddington at cso dot atmel dot com changed:

[Bug target/31768] Invalid code or ICE for %z constraint

--- Comment #3 from us15 at os dot inf dot tu-dresden dot de 2007-05-03 16:22 --- Is there any chance of this problem being fixed in 4.1 and 4.2 as well? If so, should I open new bugs for those? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31768

[Bug fortran/31251] Non-integer character length leads to segfault

--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-05-03 15:49 --- (In reply to comment #5) > I am not able to reproduce a segfault. However, this patch eliminates the > double error message. Could someone verify that they still get a segfault > without this patch and then try w

[Bug ada/31800] New: ACATS c46051a fails

test -d testsuite/ada/acats || mkdir -p testsuite/ada/acats testdir=`cd ../../gcc-4.2.0-20070501/gcc/testsuite/ada/acats; ${PWDCMD-pwd}`;\ export testdir; cd testsuite/ada/acats; /bin/sh ${testdir}/run_acats === acats configuration === target gcc is /home/voax/build-4.2.0/gcc/xgcc -

[Bug target/31768] Invalid code or ICE for %z constraint

--- Comment #2 from ubizjak at gmail dot com 2007-05-03 15:41 --- (In reply to comment #0) > unsigned long c; Fixed in mainline. But don't use long types on "out" insn, as you will generate "outll" on x86_64. -- ubizjak at gmail dot com changed: What|Removed

[Bug inline-asm/31768] Invalid code or ICE for %z constraint

--- Comment #1 from uros at gcc dot gnu dot org 2007-05-03 15:32 --- Subject: Bug 31768 Author: uros Date: Thu May 3 14:32:25 2007 New Revision: 124379 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124379 Log: PR target/31768 * config/i386/i386.c (print_operand

[Bug rtl-optimization/31799] New: Failed to optimize out test instruction

For void foo (int x, int *y, int *z) { *z = ++x; if (x != 0) *y = 1; } gcc 4.3 generates foo: .LFB2: addl$1, %edi testl %edi, %edi movl%edi, (%rdx) je .L3 movl$1, (%rsi) .L3: rep ; ret But "testl %edi, %edi" isn't needed

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

--- Comment #7 from ralf_corsepius at rtems dot org 2007-05-03 15:20 --- FYI: Vanilla gcc-4.1.2 without newlib also exposes this issue with the code fragment from comment #6: ./avr-gcc -o tmp.o -c init.c -O2 init.c: In function 'init_array': init.c:12: error: unable to find a register

[Bug tree-optimization/30565] ICE with -O1 -ftree-pre -ftree-loop-linear

--- Comment #5 from rakdver at gcc dot gnu dot org 2007-05-03 14:27 --- Subject: Bug 30565 Author: rakdver Date: Thu May 3 13:27:26 2007 New Revision: 124378 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124378 Log: PR tree-optimization/30565 * lambda-code.c (p

[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code

--- Comment #9 from burnus at gcc dot gnu dot org 2007-05-03 14:18 --- As the fix has been checked in and it works (at least here ;-), mark as FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code

--- Comment #8 from burnus at gcc dot gnu dot org 2007-05-03 14:16 --- *** Bug 31697 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699

[Bug middle-end/31697] [4.3 Regression] Crash of gen. prog. when using -funroll-loops -march=opteron

--- Comment #7 from burnus at gcc dot gnu dot org 2007-05-03 14:16 --- Mark as duplicate as the fix in PR 31699 fixes this bug. *** This bug has been marked as a duplicate of 31699 *** -- burnus at gcc dot gnu dot org changed: What|Removed |Added

[Bug target/31733] [4.3 Regression] ICE in rtl_verify_flow_info, at cfgrtl.c:2050: {return_internal} (nil)

--- Comment #7 from tbm at cyrius dot com 2007-05-03 14:12 --- It's hard to say when this was introduced. The problem is that starting with r123363, gcc won't accept this preprocessed code. I used preprocessed code generated by 4.3 20070326 to test older revisions, but there the bug do

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

--- Comment #6 from ralf_corsepius at rtems dot org 2007-05-03 14:07 --- This is the minimised *.c having been extracted from newlib's file exposing the bug: -- snip -- extern void (*array_start []) (void); extern void (*array_end []) (void); void init_array (void) { int count; int

[Bug middle-end/31699] [4.3 Regression] -march=opteron -ftree-vectorize generates wrong code

--- Comment #7 from dorit at gcc dot gnu dot org 2007-05-03 13:55 --- Subject: Bug 31699 Author: dorit Date: Thu May 3 12:54:45 2007 New Revision: 124375 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124375 Log: PR tree-optimization/31699 * tree-vect-analyze.c

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

--- Comment #5 from ralf dot corsepius at rtems dot org 2007-05-03 13:12 --- Subject: RE: error: unable to find a register to spill in class 'BASE_POINTER_REGS' On Thu, 2007-05-03 at 06:05 -0600, Eric Weddington wrote: > > > --- Comment #2 from ralf_corsepius at rtems do

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

--- Comment #4 from eweddington at cso dot atmel dot com 2007-05-03 13:05 --- Subject: RE: error: unable to find a register to spill in class 'BASE_POINTER_REGS' > --- Comment #2 from ralf_corsepius at rtems dot org > 2007-05-03 10:27 --- > I can also reproduce the bug wi

[Bug c++/29365] Unnecessary anonymous namespace warnings

--- Comment #20 from aaronavay62 at aaronwl dot com 2007-05-03 13:00 --- It looks like this will not be backported to 4.2 as its not strictly a regression. See . If you use this sort of pimpl and anonymous namespaces or similar, and you

[Bug ada/31744] Ada has way TOO MANY "may be used uninitialized" warnings.

--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-05-03 12:44 --- > I also did compile for my other platform (i686-pc-linux-gnu) and did not > notice > if these warnings occurred when make was running. They are only present on platforms that do not use DWARF-2 EH. -- ebotc

[Bug ada/31744] Ada has way TOO MANY "may be used uninitialized" warnings.

--- Comment #3 from charlet at gcc dot gnu dot org 2007-05-03 12:08 --- Thanks for the feedback. Closing this PR then. -- charlet at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/31795] -Wunused should warn about variables set but never read

--- Comment #1 from aldot at gcc dot gnu dot org 2007-05-03 11:16 --- Maybe related to 30438, 18624 I started to do Index: gcc/tree.h === --- gcc/tree.h (revision 124373) +++ gcc/tree.h (working copy) @@ -364,7 +364,7 @@

[Bug target/31787] bfin: Dreg expected for CLI. Input text was P0.

--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:47 --- Created an attachment (id=13503) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13503&action=view) *.i of the breakdown above -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31787

[Bug target/31797] powerpc: race

--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:45 --- Created an attachment (id=13502) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13502&action=view) *.i of the breakdown above -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31797

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

--- Comment #3 from ralf_corsepius at rtems dot org 2007-05-03 10:43 --- Created an attachment (id=13501) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13501&action=view) *.i of the breakdown above -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31786

[Bug target/31786] error: unable to find a register to spill in class 'BASE_POINTER_REGS'

--- Comment #2 from ralf_corsepius at rtems dot org 2007-05-03 10:27 --- I can also reproduce the bug with 4.2.0-20070501. It also is related to optimization levels. Newlib is being compiled with -O2, which triggers this breakdown. Using -O1 or -Os to build init.c lets the breakdown va

[Bug ada/31744] Ada has way TOO MANY "may be used uninitialized" warnings.

--- Comment #2 from rob1weld at aol dot com 2007-05-03 10:09 --- Confirmed. My Linux system has gcc 4.2.0 installed and I do NOT get that many warnings, only a couple. I _do_ have the _newest_ possible version of all programs for Cygwin. In any event, on _any_ platform, it is actually

  1   2   >