[Bug fortran/32331] New: Better error message for variable bond of DATA implied do
subroutine test(n) character(len=20), dimension(n) :: string data ( string(i) ,i=1,n ) / 'A', 'B', 'C', 'D', 'E' / end subroutine gives currently: data ( string(i) ,i=1,n ) / 1 Error: iterator end at (1) does not simplify which is unclear, how about something like: ifort: Error: x.f90, line 3: This symbol must be a defined parameter or an argument of an inquiry function that evaluates to a compile-time constant. [N] or NAG f95: Error: Static array STRING cannot have variable bounds -- Summary: Better error message for variable bond of DATA implied do Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32331
[Bug fortran/32315] DATA with implied-do: Bounds checks missing
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-14 06:43 --- Using data ( string(i) ,i=-3,1 ) / 'A', 'B', 'C', 'D', 'E' / gives even an ICE. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-invalid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32315
[Bug middle-end/32258] Testsuite reports - FAIL: gcc.dg/torture/builtin-pow-mpfr-1.c
--- Comment #16 from rob1weld at aol dot com 2007-06-14 07:41 --- Created an attachment (id=13702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13702action=view) Patch main configure script to detect mpfr library and header version mismatch I have made best efforts to make a compatable patch by reading several configure files and attempted to ensure this will work on as many systems as possible. Would a few people who are expert on scripting and maintaining GCC coding standards review this patch and make any repairs they deem neccesary. It should work as-is but I've been trying do do a few things at once today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32258
[Bug target/32332] New: libobjc build failure on arm-unknown-eabi (__gnu_objc_personality_v0)
I configured gcc (revision 125688) like this in a combined tree: /n/08/rask/src/gcc/configure --target=arm-unknown-eabi --disable-multilib --disable-nls --disable-gdb --with-newlib --enable-sim The build ends with this: libtool: compile: /home/rask/build/gcc-arm-unknown-eabi/./gcc/xgcc -B/home/rask/build/gcc-arm-unknown-eabi/./gcc/ -nostdinc -B/home/rask/build/gcc-arm-unknown-eabi/arm-unknown-eabi/newlib/ -isystem /home/rask/build/gcc-arm-unknown-eabi/arm-unknown-eabi/newlib/targ-include -isystem /n/08/rask/src/gcc/newlib/libc/include -B/home/rask/build/gcc-arm-unknown-eabi/arm-unknown-eabi/libgloss/arm -L/home/rask/build/gcc-arm-unknown-eabi/arm-unknown-eabi/libgloss/libnosys -L/n/08/rask/src/gcc/libgloss/arm -B/usr/local/arm-unknown-eabi/bin/ -B/usr/local/arm-unknown-eabi/lib/ -isystem /usr/local/arm-unknown-eabi/include -isystem /usr/local/arm-unknown-eabi/sys-include -L/home/rask/build/gcc-arm-unknown-eabi/./ld -c -I. -I/n/08/rask/src/gcc/libobjc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -DIN_GCC -DIN_TARGET_LIBS -fno-strict-aliasing -fexceptions -fexceptions -I/n/08/rask/src/gcc/libobjc/objc -I/n/08/rask/src/gcc/libobjc/../gcc -I/n/08/rask/src/gcc/libobjc/../gcc/config -I../.././gcc -I/n/08/rask/src/gcc/libobjc/../include /n/08/rask/src/gcc/libobjc/exception.c -o exception.o /n/08/rask/src/gcc/libobjc/exception.c: In function 'parse_lsda_header': /n/08/rask/src/gcc/libobjc/exception.c:94: warning: passing argument 2 of 'read_uleb128' from incompatible pointer type /n/08/rask/src/gcc/libobjc/exception.c:103: warning: passing argument 2 of 'read_uleb128' from incompatible pointer type /n/08/rask/src/gcc/libobjc/exception.c: In function '__gnu_objc_personality_v0': /n/08/rask/src/gcc/libobjc/exception.c:173: error: '_URC_FATAL_PHASE1_ERROR' undeclared (first use in this function) /n/08/rask/src/gcc/libobjc/exception.c:173: error: (Each undeclared identifier is reported only once /n/08/rask/src/gcc/libobjc/exception.c:173: error: for each function it appears in.) /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:177: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:234: warning: passing argument 2 of 'read_uleb128' from incompatible pointer type /n/08/rask/src/gcc/libobjc/exception.c:279: warning: passing argument 2 of 'read_sleb128' from incompatible pointer type /n/08/rask/src/gcc/libobjc/exception.c:280: warning: passing argument 2 of 'read_sleb128' from incompatible pointer type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:291: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:329: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c: In function 'objc_exception_throw': /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type /n/08/rask/src/gcc/libobjc/exception.c:364: error: cast specifies array type make[2]: *** [exception.lo] Error 1 make[2]: Leaving directory
[Bug middle-end/32285] [4.1 Regression] Miscompilation with pure _Complex returning call inside another fn's argument list
--- Comment #8 from jakub at gcc dot gnu dot org 2007-06-14 08:03 --- Yes, I mean performance and size regressions. But your changes to tree-nrv never mentioned you found bugs in it and therefore are making NRV more strict, on the contrary, PR25505 was fixing a performance/size issue where NRV was too strict and your patch was meant to make it less strict, at least that's what I understood from the gcc-patches thread. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32285
[Bug target/32180] Paranoia UCB GSL TestFloat libm tests fail - accuracy of recent gcc math poor
--- Comment #19 from rob1weld at aol dot com 2007-06-14 08:14 --- You've shown nothing to validate that crlibm is more accurate than mpfr. So how did you do this measurement? Read 1st section of http://www.mpfr.org/faq.html and either crlibm-0.18beta1.pdf or better still crlibm-1.01beta1.pdf (build from the CVS). I've done some tweaking which further doubles the speed in some cases by playing with the gcc 4.3.0 command line options. If all you want is _one_ ulp then the speed increase alone should be enough to prefer it over mpfr; for such a low standard a difference can not be found (except in speed and proof, of which mpfr has none). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32180
[Bug libstdc++/32261] Thread race segfault in std::string::append with -O and -s
--- Comment #8 from pcarlini at suse dot de 2007-06-14 08:15 --- Note, however, that startiing with 3.4.x (vs 3.3.x) the empty string representation is not not reference counted anymore. First blush, the *specific* code snippet in this PR should be safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32261
[Bug c/32329] Use of option -fwhole-program needs to exclude option -c in spec file
--- Comment #2 from rob1weld at aol dot com 2007-06-14 08:26 --- Agreed. After a 20 hour day the proximity of the word `-fwhole-program' to the attribute `externally_visible' while juggling three things at once did not work out so good. Perhaps a compiler warning message could be created that when -c and -fwhole-program are used together without using externally_visible in the file the result is essentially an un-linkable object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32329
[Bug middle-end/31723] Use reciprocal and reciprocal square root with -ffast-math
--- Comment #26 from ubizjak at gmail dot com 2007-06-14 09:18 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00944.html -- ubizjak at gmail dot com changed: What|Removed |Added CC|ubizjak at gmail dot com| AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2007- ||06/msg00944.html Status|NEW |ASSIGNED Keywords||patch Last reconfirmed|2007-04-27 10:45:36 |2007-06-14 09:18:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31723
[Bug ada/32333] New: Ada gnatbind should utilize gcc's path and also check -B path
I installed gcc version 4.3.0 20070609 but did NOT put it on my path. I typed: export CC=/usr/test/bin/gcc to use the install but off path gcc. I compiled gcc version 4.3.0 20070613 and everything was fine until here: /usr/test/bin/gcc -c -g -fkeep-inline-functions -gnatpg -gnata -nostdinc -I- -I. -Iada -I/root/downloads/gcc-4_3-trunk/gcc/ada /root/downloads/gcc-4_3-trunk/gcc/ada/back_end.adb -o ada/back_end.o /usr/test/bin/gcc -c -g -fkeep-inline-functions -gnatpg -gnata -nostdinc -I- -I. -Iada -I/root/downloads/gcc-4_3-trunk/gcc/ada /root/downloads/gcc-4_3-trunk/gcc/ada/gnat1drv.adb -o ada/gnat1drv.o gnatbind -C -nostdinc -I- -I. -Iada -I/root/downloads/gcc-4_3-trunk/gcc/ada -o ada/b_gnat1.c -n ada/gnat1drv.ali fatal error: file gnat1drv.ali is incorrectly formatted make sure you are using consistent versions of gcc/gnatbind 12. R nnnvnnnvvnvvnvnvn | make[3]: *** [ada/b_gnat1.c] Error 4 make[3]: Leaving directory `/opt/gcc-4_3-build-libcrlibm/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/opt/gcc-4_3-build-libcrlibm' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/opt/gcc-4_3-build-libcrlibm' make: *** [all] Error 2 # head -1 /opt/gcc-4_3-build-libcrlibm/gcc/ada/gnat1drv.ali V GNAT Lib v4.3 # gnatbind -v | head -2 GNATBIND 4.2.0 20070501 (prerelease) My complaint is this: 1): Since I am using /usr/test/bin/gcc why can't gcc simply call /usr/test/bin/gnatbind instead of gnatbind (that searches the OS path). 2): The main configure script _does_ seem to look at environment variables for GNATBIND and GNATMAKE but typing configure --help does not show this feature - though --help mentions near every other environment variable supported. 3): You can't simply toss a GNATBIND=/usr/test/bin/gnatbind line at the top of the offending Makefile when the build break as shown above. If anyone else gets stuck like this you can put your un-pathed gcc 4.3.0 directory at the head of an export PATH=... statement (making it pathed) and then type make. Ada will now build successfully - since the 'un-pathed' gnatbind is fetched from the first path in your export PATH=... statement. Gcc should use it's own path (argv[0]) and any -B's to look for any drivers it calls (cc1, f77, pascal, gnat etc.). Surely it is wrong to call gnatbind bare-pathed. What if your PATH environment was PATH=/dir1:/dir2:/dir3 and you wanted to use /dir3/bin/gcc-3.4 to compile an Ada file - would you rather hope to find something in /dir3/bin instead of looking in /dir1 and then /dir2 first for gnatbind ? Which leavs another issue. If we use /dir3/bin/gcc-3.4 would we want to use /dir3/bin/gnatbind-3.4 prior to looking for /dir3/bin/gnatbind. -- Summary: Ada gnatbind should utilize gcc's path and also check - B path Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rob1weld at aol dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32333
[Bug ada/32333] Ada gnatbind should utilize gcc's path and also check -B path
--- Comment #1 from charlet at gcc dot gnu dot org 2007-06-14 09:31 --- You're using non standard build procedure which are not supported. When using GNAT (as opposed to building), things are different, and you can call gnatmake with full path, it will then pick up the right gcc, gnatbind, etc... -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32333
[Bug target/32274] FAIL: gcc.dg/vect/pr32224.c
--- Comment #5 from dorit at gcc dot gnu dot org 2007-06-14 09:39 --- Subject: Bug 32274 Author: dorit Date: Thu Jun 14 09:39:31 2007 New Revision: 125703 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125703 Log: PR target/32274 * gcc.dg/vect/pr32224.c: Fix. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/pr32224.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
[Bug c/32324] unsigned long long operator and integer literals
--- Comment #3 from schwab at suse dot de 2007-06-14 09:45 --- This is still undefined. Use 1U31 instead. -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32324
[Bug bootstrap/32334] New: Bootstrap comparison failure when comparing stage 2 and 3
I installed the gcc-4.2.0 on Intel(R) Xeon(TM) in a clean directory which is different from the source one with the following configuration: ../gcc-4.2.0/configure --prefix=$prefix --enable-language=c,c++ --with-gnu-as --with-gnu-ld And then I got the following error: Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/compiler/redriver/project3/gcc/gcc-install' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/compiler/redriver/project3/gcc/gcc-install' make: *** [all] Error 2 Could you please tell me what problem with it? What does the bootstrap comparison mean? Whether any of my prerequisite tool/packet didn't fit with GCC-4.2.0. Because I installed the gcc-4.1.2 version in the same machine, with the same configuration but it was ok. Thanks very much . -- Summary: Bootstrap comparison failure when comparing stage 2 and 3 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: redriver at korea dot ac dot kr GCC host triplet: Intel(R) Xeon(TM) CPU GCC target triplet: Intel(R) Xeon(TM) CPU http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32334
[Bug target/32335] New: libgcc build failure, ICE in cselib_record_set, at cselib.c:1508
Here's how I configure gcc: /n/08/rask/src/gcc/configure --target=m32c-unknown-elf --disable-libgfortran --disable-multilib --disable-nls --with-newlib --enable-sim --disable-gdb The error message: /home/rask/build/gcc-m32c-unknown-elf/./gcc/xgcc -B/home/rask/build/gcc-m32c-unknown-elf/./gcc/ -nostdinc -B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/ -isystem /home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/newlib/targ-include -isystem /n/08/rask/src/gcc/newlib/libc/include -B/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/m32c -L/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgloss/libnosys -L/n/08/rask/src/gcc/libgloss/m32c -B/usr/local/m32c-unknown-elf/bin/ -B/usr/local/m32c-unknown-elf/lib/ -isystem /usr/local/m32c-unknown-elf/include -isystem /usr/local/m32c-unknown-elf/sys-include -L/home/rask/build/gcc-m32c-unknown-elf/./ld -O2 -g -O2 -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I/n/08/rask/src/gcc/libgcc -I/n/08/rask/src/gcc/libgcc/. -I/n/08/rask/src/gcc/libgcc/../gcc -I/n/08/rask/src/gcc/libgcc/../include -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c \ /n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c: In function '__muldi3': /n/08/rask/src/gcc/libgcc/../gcc/libgcc2.c:566: internal compiler error: in cselib_record_set, at cselib.c:1508 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_muldi3.o] Error 1 make[2]: Leaving directory `/home/rask/build/gcc-m32c-unknown-elf/m32c-unknown-elf/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/home/rask/build/gcc-m32c-unknown-elf' make: *** [all] Error 2 -- Summary: libgcc build failure, ICE in cselib_record_set, at cselib.c:1508 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: m32c-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32335
[Bug libfortran/32336] New: matmul: flag runtime- instead of assertation error
$ gfortran-svn -g -pg -O0 -Wall -Wimplicit-interface -Wunderflow -Wsurprising -fbounds-check -fimplicit-none -ffpe-trap=invalid,zero -fbacktrace ... [list-of-objects] a.out: ../../../../svn/gcc/libgfortran/generated/matmul_r8.c:172: matmul_r8: Assertion `count == b-dim[0].ubound + 1 - b-dim[0].lbound' failed. Aborted The call to MATMUL obviously is erroneous, but a runtime error instead of an assertation would be preferable in this case. -- Summary: matmul: flag runtime- instead of assertation error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32336
[Bug libfortran/21185] libgfortran unusable for cross-testing for newlib targets
--- Comment #7 from rask at sygehus dot dk 2007-06-14 10:36 --- I've thought about adding ENOSYS stubs for the missing functions to libgloss. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21185
[Bug target/32337] New: [4.3 Regression] Error: Register number out of range 0..1
I'm getting the following assembler error with current gcc 4.3. This
worked with 20070604 and is probably due to the dataflow merge.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O1 ccmalloc-callchain.c
ccmalloc-callchain.c: In function 'backtrace':
ccmalloc-callchain.c:14: warning: unsupported argument to
'__builtin_return_address'
/tmp/ccMB3CzF.s: Assembler messages:
/tmp/ccMB3CzF.s:10: Warning: Second operand of .save contradicts .prologue
/tmp/ccMB3CzF.s:17: Error: Register number out of range 0..1
/tmp/ccMB3CzF.s:17: Warning: Use of 'mov' violates WAW dependency 'GR%, % in 1
- 127' (impliedf), specific resource number is 33
/tmp/ccMB3CzF.s:17: Warning: Only the first path encountering the conflict is
reported
/tmp/ccMB3CzF.s:14: Warning: This is the location of the conflicting usage
/tmp/ccMB3CzF.s:39: Error: Register number out of range 0..1
/tmp/ccMB3CzF.s:60: Error: Register number out of range 0..1
Testcase:
typedef struct __jmp_buf_tag
{
}
jmp_buf[1];
static jmp_buf backtrace_jump;
static char *
return_address (unsigned i)
{
switch (i)
{
case 0:
return (char *) __builtin_return_address (0);
case 1:
return (char *) __builtin_return_address (1);
}
}
backtrace (int skip)
{
if (_setjmp (backtrace_jump) == 0)
{
int i = ++skip;
while (1)
{
char *pc = return_address (i++);
if (!pc)
break;
}
}
}
--
Summary: [4.3 Regression] Error: Register number out of range
0..1
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32337
[Bug target/32338] New: [4.3 Regression] Error: .prologue within prologue
I'm getting the following assembler error with current gcc 4.3. This
worked with 20070604 and is probably due to the dataflow merge. This is
possible the same as, or related to, PR32337, but I cannot tell for sure.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2
-fno-omit-frame-pointer
skalibs-dns_transmit.c
/tmp/cc1yk7fL.s: Assembler messages:
/tmp/cc1yk7fL.s:93: Warning: .restore outside of body region
/tmp/cc1yk7fL.s:101: Error: .prologue within prologue
Testcase:
struct dns_transmit
{
};
firstudp (struct dns_transmit *d)
{
}
firsttcp (struct dns_transmit *d)
{
}
dns_transmit_start (struct dns_transmit *d, char const *q)
{
unsigned int len;
len = dns_domain_length (q);
if (len 512)
return firsttcp (d);
return firstudp (d);
}
--
Summary: [4.3 Regression] Error: .prologue within prologue
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
GCC target triplet: ia64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32338
[Bug rtl-optimization/32339] New: [4.3 Regression] ICE in insert_save, at caller-save.c:726
I'm getting the following ICE with current gcc 4.3. This worked with
20070604 and is probably due to the dataflow merge. Note that PR31025
contains a similar ICE, but the description is quite different to what
I'm seeing. Note that my testcase shows an ICE on ia64 but works on
x86_64.
[EMAIL PROTECTED]:~$ /usr/lib/gcc-snapshot/bin/gcc -c -O2 freeciv-citydlg.c
freeciv-citydlg.c: In function 'change_callback':
freeciv-citydlg.c:15: internal compiler error: in insert_save, at
caller-save.c:726
Please submit a full bug report,
Testcase:
struct city_dialog
{
struct city *pcity;
char change_list_names[200][200];
int change_list_ids[200];
};
change_callback (void)
{
struct city_dialog *pdialog;
int n;
int i;
get_city_dialog_production_full (pdialog-change_list_names[n],
pdialog-pcity);
pdialog-change_list_ids[n++] = i;
}
--
Summary: [4.3 Regression] ICE in insert_save, at caller-
save.c:726
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
[Bug target/32340] New: libjava build failure due to missing thread synchronization primitives
I have configured gcc like this: /n/08/rask/src/gcc/configure --target=arm-unknown-elf --disable-multilib --disable-nls --disable-gdb --with-newlib --enable-sim Building libjava fails with this message: libtool: compile: /home/rask/build/gcc-arm-unknown-elf/./gcc/xgcc -shared-libgcc -B/home/rask/build/gcc-arm-unknown-elf/./gcc -nostdinc++ -L/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libstdc++-v3/src -L/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libstdc++-v3/src/.libs -nostdinc -B/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/newlib/ -isystem /home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/newlib/targ-include -isystem /n/08/rask/src/gcc/newlib/libc/include -B/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libgloss/arm -L/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libgloss/libnosys -L/n/08/rask/src/gcc/libgloss/arm -B/usr/local/arm-unknown-elf/bin/ -B/usr/local/arm-unknown-elf/lib/ -isystem /usr/local/arm-unknown-elf/include -isystem /usr/local/arm-unknown-elf/sys-include -L/home/rask/build/gcc-arm-unknown-elf/./ld -DHAVE_CONFIG_H -I. -I/n/08/rask/src/gcc/libjava -I./include -I./gcj -I/n/08/rask/src/gcc/libjava -Iinclude -I/n/08/rask/src/gcc/libjava/include -I/n/08/rask/src/gcc/libjava/classpath/include -Iclasspath/include -I/n/08/rask/src/gcc/libjava/classpath/native/fdlibm -I/n/08/rask/src/gcc/libjava/../boehm-gc/include -I../boehm-gc/include -I/n/08/rask/src/gcc/libjava/.././libjava/../gcc -I/n/08/rask/src/gcc/libjava/../zlib -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/local\ -DTOOLEXECLIBDIR=\/usr/local/arm-unknown-elf/lib\ -DJAVA_HOME=\/usr/local\ -DBOOT_CLASS_PATH=\/usr/local/share/java/libgcj-4.3.0.jar\ -DJAVA_EXT_DIRS=\/usr/local/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/local/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/usr/local/lib/gcj-4.3.0\ -DPATH_SEPARATOR=\:\ -DECJ_JAR_FILE=\\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/local/lib/gcj-4.3.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.3.0/classmap.db\ -MT jni-libjvm.lo -MD -MP -MF .deps/jni-libjvm.Tpo -c /n/08/rask/src/gcc/libjava/jni-libjvm.cc -o jni-libjvm.o In file included from /n/08/rask/src/gcc/libjava/include/jvm.h:35, from /n/08/rask/src/gcc/libjava/jni-libjvm.cc:14: ./sysdep/locks.h:11:2: error: #error Thread synchronization primitives not implemented for this platform. In file included from /n/08/rask/src/gcc/libjava/jni-libjvm.cc:14: /n/08/rask/src/gcc/libjava/include/jvm.h:754: error: 'obj_addr_t' does not name a type /n/08/rask/src/gcc/libjava/include/jvm.h:763: error: 'ParkHelper' does not name a type make[3]: *** [jni-libjvm.lo] Error 1 make[3]: Leaving directory `/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libjava' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/rask/build/gcc-arm-unknown-elf/arm-unknown-elf/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/rask/build/gcc-arm-unknown-elf' make: *** [all] Error 2 -- Summary: libjava build failure due to missing thread synchronization primitives Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32340
[Bug target/32341] New: undefined reference to `df_set_regs_ever_live_p'
Here's how I configured gcc: /n/08/rask/src/gcc/configure --target=v850-unknown-elf --disable-multilib --disable-nls --disable-gdb --with-newlib --enable-sim GCC fails to build with this: gcc -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-incpath.o cppdefault.o c-ppoutput.o c-cppbuiltin.o prefix.o c-objc-common.o c-dump.o c-pch.o c-parser.o v850-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp libbackend.a(v850.o): In function `substitute_ep_register': /n/08/rask/src/gcc/gcc/config/v850/v850.c:1137: undefined reference to `df_set_regs_ever_live_p' collect2: ld returned 1 exit status make[2]: *** [cc1-dummy] Error 1 make[2]: Leaving directory `/home/rask/build/gcc-v850-unknown-elf/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/rask/build/gcc-v850-unknown-elf' make: *** [all] Error 2 -- Summary: undefined reference to `df_set_regs_ever_live_p' Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rask at sygehus dot dk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: v850-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32341
[Bug target/32341] undefined reference to `df_set_regs_ever_live_p'
--- Comment #1 from patchapp at dberlin dot org 2007-06-14 11:31 --- Subject: Bug number PR target/32341 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-06/msg00953.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32341
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #11 from patchapp at dberlin dot org 2007-06-14 12:00 --- Subject: Bug number PR32302 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-06/msg00954.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug fortran/32289] mips version of gfortran produces internal compiler error
--- Comment #11 from tbm at cyrius dot com 2007-06-14 12:00 --- Note that gcc-4.2 exists on MIPS in Debian testing and 4.3 in the form of the gcc-snapshot package in Debian unstable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32289
[Bug gcov-profile/32316] internal compiler error: Segmentation fault
--- Comment #3 from tbm at cyrius dot com 2007-06-14 12:02 --- (In reply to comment #2) I am really sorry. But I think there is no possiblity to upload a preprocessed source here Why not? Just click the Create a New Attachment link. You can save the preprocessed source with --save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32316
[Bug rtl-optimization/31025] [dataflow] Crash in caller-save.c due to x87 math
--- Comment #4 from zadeck at naturalbridge dot com 2007-06-14 12:05 --- This bug was fixed a long time ago, i did not realize there was a bugzilla opened on it. -- zadeck at naturalbridge dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31025
[Bug other/31400] enable static linking of support libraries through -static-libXY
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-06-14 12:13 --- Still pinging for someone to review my one-line patch to gcc.c... maybe we can get this feature into trunk before GCC 12.0 ;-) -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- |http://gcc.gnu.org/ml/gcc- |patches/2007- |patches/2007- |05/msg00394.html|06/msg00956.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31400
[Bug fortran/31218] ICE on valid code with gfortran
--- Comment #7 from pault at gcc dot gnu dot org 2007-06-14 12:13 --- As reported in comment#6, this cleared itself. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31218
[Bug fortran/32302] [4.2 Regression] Incorrect result with -O2
--- Comment #13 from pault at gcc dot gnu dot org 2007-06-14 13:05 --- Fixed on trunk. Thanks, Dale Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.2/4.3 Regression]|[4.2 Regression] Incorrect |Incorrect result with -O2 |result with -O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug fortran/32302] [4.2/4.3 Regression] Incorrect result with -O2
--- Comment #12 from pault at gcc dot gnu dot org 2007-06-14 13:04 --- Subject: Bug 32302 Author: pault Date: Thu Jun 14 13:04:05 2007 New Revision: 125708 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125708 Log: 2007-06-14 Paul Thomas [EMAIL PROTECTED] PR fortran/32302 * trans-common.c (build_common_decl): If resizing of common decl is needed, update the TREE_TYPE. 2007-06-14 Paul Thomas [EMAIL PROTECTED] PR fortran/32302 * gfortran.dg/common_resize_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/common_resize_1.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-common.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32302
[Bug target/32342] New: [4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:396
I'm getting the following ICE on x86_64 with trunk. I don't see this on
IA64. It also worked with 4.3 20070604.
(sid)26226:[EMAIL PROTECTED]: ~] /usr/lib/gcc-snapshot//bin/gcc -c -O3
~/filezilla-sshsh512.c
/home/tbm/filezilla-sshsh512.c: In function 'SHA512_Simple':
/home/tbm/filezilla-sshsh512.c:25: error: insn does not satisfy its
constraints:
(insn 38 35 6 2 (set (reg/f:DI 53 virtual-incoming-args)
(reg:DI 1 dx)) 82 {*movdi_1_rex64} (nil))
/home/tbm/filezilla-sshsh512.c:25: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
Testcase:
typedef struct
{
unsigned long hi, lo;
}
uint64;
typedef struct
{
uint64 h[4];
}
SHA512_State;
SHA512_Core_Init (SHA512_State *s)
{
static const uint64 iv[] = {
{0x6a09e667, 0xf3bcc908},
{0xbb67ae85, 0x84caa73b}
};
int i;
for (i = 0; i 4; i++)
s-h[i] = iv[i];
}
SHA512_Simple (SHA512_State s)
{
SHA512_Core_Init (s);
SHA512_Bytes (s);
}
--
Summary: [4.3 Regression] ICE in reload_cse_simplify_operands, at
postreload.c:396
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32342
[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726
--- Comment #1 from spark at gcc dot gnu dot org 2007-06-14 14:10 --- What's the target tripe ? I presume thi sis ia64-unknown-linux ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726
--- Comment #2 from tbm at cyrius dot com 2007-06-14 14:16 --- (In reply to comment #1) What's the target tripe ? I presume thi sis ia64-unknown-linux ? Yes. -- tbm at cyrius dot com changed: What|Removed |Added GCC host triplet|[EMAIL PROTECTED]| GCC target triplet||ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
[Bug target/32341] undefined reference to `df_set_regs_ever_live_p'
--- Comment #2 from spark at gcc dot gnu dot org 2007-06-14 14:33 --- Subject: Bug 32341 Author: spark Date: Thu Jun 14 14:33:21 2007 New Revision: 125715 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125715 Log: 2007-06-14 Rask Ingemann Lambertsen [EMAIL PROTECTED] PR target/32341 * config/v850/v850.c: Include dataflow header file. (substitute_ep_register): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/config/v850/v850.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32341
[Bug testsuite/32274] FAIL: gcc.dg/vect/pr32224.c
--- Comment #6 from ubizjak at gmail dot com 2007-06-14 14:33 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|target |testsuite Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32274
[Bug fortran/32343] New: ICE with arrays and vector valued functions from a used module
[EMAIL PROTECTED] cat radiimod.f90 module SortedRadii implicit none integer::Nr real(kind=8),dimension(5)::aux2 contains function GetEpsR(i) result (x) integer,intent(in)::i real(kind=8),dimension(Nr)::x x=1 end function GetEpsR end module SortedRadii [EMAIL PROTECTED] gfortran -c radiimod.f90 [EMAIL PROTECTED] cat acmod.f90 module AC use SortedRadii implicit none contains function Emax(Jtot,j,omega) result (Em) integer,intent(in)::Jtot,j,omega real(kind=8)::Em integer::n,ri n=5 aux2(1:n)=GetEpsR(j)+(/(ri,ri=1,n)/) end function Emax end module [EMAIL PROTECTED] gfortran -v -c acmod.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --disable-multilib --enable-languages=fortran Thread model: posix gcc version 4.2.0 20070501 (prerelease) /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.2.0/f951 acmod.f90 -quiet -dumpbase acmod.f90 -mtune=generic -auxbase acmod -version -I /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.2.0/finclude -o /tmp/ccDqZ5yW.s GNU F95 version 4.2.0 20070501 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.2.0 20070501 (prerelease). GGC heuristics: --param ggc-min-expand=89 --param ggc-min-heapsize=112193 acmod.f90: In function emax: acmod.f90:11: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:863 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. I suspect the problem comes from the fact that the size of the vector returned by GetEpsR is comes from Nr in SortedRadii while the others come from n in AC. (It's up to the caller to make sure these are the same before Emax is called.) The ICE goes away if the 'n's in the aux2 assignment line are changed to 5s or 'Nr's. -- Summary: ICE with arrays and vector valued functions from a used module Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: terry at chem dot gu dot se GCC host triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32343
[Bug fortran/32343] ICE with arrays and vector valued functions from a used module
--- Comment #1 from terry at chem dot gu dot se 2007-06-14 15:24 --- Or maybe not. If x is explicitly 5-element in GetEpsR (no reference to Nr) the ICE still occurs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32343
[Bug target/32341] undefined reference to `df_set_regs_ever_live_p'
--- Comment #3 from rask at sygehus dot dk 2007-06-14 15:43 --- Finally, I can close a bug as fixed. :-) -- rask at sygehus dot dk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32341
[Bug c++/32344] New: Exception handling crash on multi-threaded Solaris/Sparc
On multiprocessor Solaris Sparc machines, if multiple threads are concurrently throwing exceptions, and another thread is calling exit() or returning from main(), there are messages such as: terminate called recursively terminate called after throwing an instance of ' And sometimes core is dumped with an abort signal. I have been able to reproduce this on a number of different gcc versions (4.2.0, 4.1.2, 2.95.2). You can find the code I use to reproduce it at: http://www.csug.rochester.edu/users/ugrads/asveikau/exception_bug.cc Note that running it once without incident does not mean the system is unaffected by the bug; keep running it until it dumps core. The code runs file on: SunPRO C++ on the affected systems, gcc 4.1.1 on i386 linux, and gcc 3.2.3 on i386 linux. This is why I concluded that the issue is specific to either gcc on Solaris or gcc on Sparc. Since it works fine on Sun's compiler, I don't think it is Solaris's fault. I don't have access to sparc linux or x86 solaris, so I couldn't narrow it down beyond that. -- Summary: Exception handling crash on multi-threaded Solaris/Sparc Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: a dot l dot sveikauskas at gmail dot com GCC build triplet: sparc-sun-solaris2.10, sparc-sun-solaris2.9, sparc-sun- solaris2. GCC host triplet: sparc-sun-solaris2.10, sparc-sun-solaris2.9, sparc-sun- solaris2. GCC target triplet: sparc-sun-solaris2.10, sparc-sun-solaris2.9, sparc-sun- solaris2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32344
[Bug c++/32344] Exception handling crash on multi-threaded Solaris/Sparc
--- Comment #1 from a dot l dot sveikauskas at gmail dot com 2007-06-14 16:25 --- Created an attachment (id=13703) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13703action=view) Code that reproduces the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32344
[Bug libfortran/32345] New: Unconditional snprintf use breaks all gfortran exec tests on Tru64 UNIX V4.0F
All gfortran execute tests fail on alpha-dec-osf4.0f since snprintf is missing in libc, but used in libgfortran. Environment: System: OSF1 hindemith V4.0 1229 alpha Machine: alpha host: alpha-dec-osf4.0f build: alpha-dec-osf4.0f target: alpha-dec-osf4.0f configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf4.0f --build alpha-dec-osf4.0f --target alpha-dec-osf4.0f --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap How-To-Repeat: Bootstrap and test on alpha-dec-osf4.0f. --- Comment #1 from ro at techfak dot uni-bielefeld dot de 2007-06-14 16:40 --- Fix: The reference is from runtime/backtrace.c (show_backtrace) and can easily be changed to use sprintf() is snprintf() is unavailable. -- Summary: Unconditional snprintf use breaks all gfortran exec tests on Tru64 UNIX V4.0F Product: gcc Version: 3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at techfak dot uni-bielefeld dot de GCC build triplet: alpha-dec-osf4.0f GCC host triplet: alpha-dec-osf4.0f GCC target triplet: alpha-dec-osf4.0f http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32345
[Bug c++/32346] New: long long bitfield passed to int argument incorrectly
A long long bitfield of size 32 is passed to a function taking an int argument
using two argument slots. Adding an explicit cast solves the problem.
Testcase:
#include stdio.h
typedef struct {
long long item : 32;
} tester;
void dosomething(int i, int j)
{
printf(i = %#x, j = %#x\n, i, j);
}
void foo(tester bar)
{
dosomething(bar.item, 0);
}
int main(void)
{
tester test;
test.item = 0xabcdef01;
foo(test);
return(0);
}
Asm:
.align 2
.globl _Z3foo6tester
.type _Z3foo6tester, @function
_Z3foo6tester:
.LFB3:
pushl %ebp
.LCFI3:
movl%esp, %ebp
.LCFI4:
subl$24, %esp
.LCFI5:
movl8(%ebp), %eax
movl%eax, %edx
sarl$31, %edx
movl$0, 8(%esp)
movl%eax, (%esp)
movl%edx, 4(%esp)
call_Z11dosomethingii
leave
ret
.LFE3:
.size _Z3foo6tester, .-_Z3foo6tester
Output:
i = 0xabcdef01, j = 0x
With explicit cast:
void foo(tester bar)
{
dosomething((int)bar.item, 0);
}
Asm:
.align 2
.globl _Z3foo6tester
.type _Z3foo6tester, @function
_Z3foo6tester:
.LFB3:
pushl %ebp
.LCFI3:
movl%esp, %ebp
.LCFI4:
subl$8, %esp
.LCFI5:
movl8(%ebp), %eax
movl$0, 4(%esp)
movl%eax, (%esp)
call_Z11dosomethingii
leave
ret
.LFE3:
.size _Z3foo6tester, .-_Z3foo6tester
Output:
i = 0xabcdef01, j = 0
--
Summary: long long bitfield passed to int argument incorrectly
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greened at obbligato dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726
--- Comment #3 from spark at gcc dot gnu dot org 2007-06-14 17:52 --- This is a bug in df-scan.c, marking regs unnecessarily as read-write, which lead to unnecessarily stretched live ranges for regs involved in pre/post modify insn. I'm working on it. -- spark at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-14 17:52:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #19 from ian at airs dot com 2007-06-14 17:57 --- Adding Richard in case he has any comment. I don't agree with comment #17 from Doug. In the code in comment #16, if f saves c, there is no way that it could validly use it after the block scope exits. In general if we expand the scope of a variable outside of its block scope, then the stack sharing code in cfgexpand.c will do the wrong thing. There is normally no reason for the tree code to expand the scope of a variable. But there is also nothing specifically to stop it from doing so. In this particular case store sinking is extending the life of a variable. This is a meaningless move, as there is no valid way for the stored value to be accessed. It is happening because alias analysis thinks that the function call can refer to the stored variable, although this actually can not happen. Part of the reason alias analysis is wrong is that we retain the list of addressable variables in a statement when we shouldn't. Interestingly, if I apply the tree-ssa-operands.c patch from http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01807.html then the problem goes away. But there are a few complex issues here: 1) Alias analysis thinks that a function can refer to a variable in a different block scope. 2) Nothing systematically prevents the tree code from referencing or setting variables outside of their block scope. 3) The stack sharing code in cfgexpand assumes that variables are only referenced or set within their block scope. This is going to require more investigation. I think we are mainly lucky because the tree optimizers tend to not move variables outside of their block scope. This test case just happens to show a way in which that can happen. -- ian at airs dot com changed: What|Removed |Added CC||rth at gcc dot gnu dot org, ||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #20 from dougkwan at google dot com 2007-06-14 18:05 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code That was my initial opinion too but Diego and Danny told me there is only one scope in the tree SSA form. So it is okay. About your comment of us being lucky, I believe our luck is running out. As we do more and more things in the tree passes, we will be likely to see this problem more often. 14 Jun 2007 17:58:01 -, ian at airs dot com [EMAIL PROTECTED]: --- Comment #19 from ian at airs dot com 2007-06-14 17:57 --- I don't agree with comment #17 from Doug. In the code in comment #16, if f saves c, there is no way that it could validly use it after the block scope exits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug middle-end/32327] [4.2 Regression] Incorrect stack sharing causing removal of live code
--- Comment #21 from rguenther at suse dot de 2007-06-14 18:12 --- Subject: Re: [4.2 Regression] Incorrect stack sharing causing removal of live code On Thu, 14 Jun 2007, ian at airs dot com wrote: --- Comment #19 from ian at airs dot com 2007-06-14 17:57 --- This is going to require more investigation. I think we are mainly lucky because the tree optimizers tend to not move variables outside of their block scope. This test case just happens to show a way in which that can happen. We may finally need to compute life for on-stack variables instead of relying on something not happening that is not explicitly forbidden in our IL (placement new anyone? ;)) (the other) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32327
[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726
--- Comment #4 from spark at gcc dot gnu dot org 2007-06-14 18:31 --- diff -r 8522653fd69d gcc/df-scan.c --- a/gcc/df-scan.c Thu Jun 14 00:17:05 2007 + +++ b/gcc/df-scan.c Thu Jun 14 11:29:46 2007 -0700 @@ -2982,9 +2982,9 @@ df_uses_record (struct df_collection_rec case PRE_MODIFY: case POST_MODIFY: /* Catch the def of the register being modified. */ - flags |= DF_REF_READ_WRITE | DF_REF_PRE_POST_MODIFY; df_ref_record (collection_rec, XEXP (x, 0), XEXP (x, 0), bb, insn, -DF_REF_REG_DEF, flags); +DF_REF_REG_DEF, + flags | DF_REF_READ_WRITE | DF_REF_PRE_POST_MODIFY); /* ... Fall through to handle uses ... */ This patch fixes the problem. I'm starting the testing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339
[Bug target/32201] Can not allocate %xmm0 register for variable blend insn
--- Comment #6 from ubizjak at gmail dot com 2007-06-14 19:11 --- Fixed in mainline. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32201
[Bug c/32347] New: ICE on gcc/testsuite/gcc-dg/vmx/ops.c
Reading specs from /var/tmp/gcc_r43/build-25/gcc/specs
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,c++,fortran --disable-altivec --disable-checking
--disable-nls --disable-decimal-float --disable-werror --disable-multilib
--with-ibmlongdouble --with-cpu=7450 --enable-clocale=gnu --with-system-zlib
Thread model: posix
gcc version 4.3.0 20070614 (experimental)
/var/tmp/gcc_r43/build-25/gcc/cc1 -E -quiet -v -iprefix
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/
-isystem /var/tmp/gcc_r43/build-25/gcc/include -isystem
/var/tmp/gcc_r43/build-25/gcc/include-fixed -D__unix__ -D__gnu_linux__
-D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix
-Asystem=posix ops.c -maltivec -mabi=altivec -mcpu=7450 -std=gnu99
-fno-show-column -Os -fpch-preprocess -o ops.i
ignoring nonexistent directory
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
ignoring nonexistent directory
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
ignoring nonexistent directory
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include
ignoring nonexistent directory
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
ignoring nonexistent directory
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
ignoring nonexistent directory
/var/tmp/gcc_r43/build-25/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/libffi
/var/tmp/gcc_r43/build-25/gcc/include
/var/tmp/gcc_r43/build-25/gcc/include-fixed
/usr/local/include
/usr/include
End of search list.
/var/tmp/gcc_r43/build-25/gcc/cc1 -fpreprocessed ops.i -quiet -dumpbase ops.c
-maltivec -mabi=altivec -mcpu=7450 -auxbase-strip ops.s -Os -std=gnu99 -version
-fno-show-column -o ops.s
GNU C version 4.3.0 20070614 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070614 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96544
Compiler executable checksum: 8c94e74aa22d7e7d522ab31740502ad9
ops.c: In function 'f6':
ops.c:761: error: insn does not satisfy its constraints:
(insn 1187 1186 32 2 ops.c:663 (set (reg:V4SI 78 1)
(mem:V4SI (plus:SI (reg:SI 11 11)
(const_int 16 [0x10])) [7 S16 A128])) 515 {altivec_lvx_v4si}
(nil))
ops.c:761: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE on gcc/testsuite/gcc-dg/vmx/ops.c
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: malitzke at metronets dot com
GCC build triplet: powerpc-unknown-linux-gnu
GCC host triplet: powerpc-unknown-linux-gnu
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #1 from malitzke at metronets dot com 2007-06-14 19:30 --- Created an attachment (id=13704) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13704action=view) standard preprocessed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm
--- Comment #2 from spark at gcc dot gnu dot org 2007-06-14 19:49 ---
The problem is reproducible also on x86-64.
The following patch seems to fix the ICE.
I'll start a bootstrap/testing.
*** /tmp/gcse.c 2007-06-14 19:46:27.0 +
--- gcc/gcse.c 2007-06-14 19:44:19.0 +
*** replace_store_insn (rtx reg, rtx del, ba
*** 6341,6357
mem = smexpr-pattern;
insn = gen_move_insn (reg, SET_SRC (single_set (del)));
- insn = emit_insn_after (insn, del);
-
- if (dump_file)
- {
- fprintf (dump_file,
- STORE_MOTION delete insn in BB %d:\n , bb-index);
- print_inline_rtx (dump_file, del, 6);
- fprintf (dump_file, \nSTORE MOTION replaced with insn:\n );
- print_inline_rtx (dump_file, insn, 6);
- fprintf (dump_file, \n);
- }
for (ptr = ANTIC_STORE_LIST (smexpr); ptr; ptr = XEXP (ptr, 1))
if (XEXP (ptr, 0) == del)
--- 6341,6346
*** replace_store_insn (rtx reg, rtx del, ba
*** 6379,6384
--- 6368,6385
XEXP (note, 0) = insn;
}
+ insn = emit_insn_after (insn, del);
+
+ if (dump_file)
+ {
+ fprintf (dump_file,
+ STORE_MOTION delete insn in BB %d:\n , bb-index);
+ print_inline_rtx (dump_file, del, 6);
+ fprintf (dump_file, \nSTORE MOTION replaced with insn:\n );
+ print_inline_rtx (dump_file, insn, 6);
+ fprintf (dump_file, \n);
+ }
+
delete_insn (del);
/* Now we must handle REG_EQUAL notes whose contents is equal to the mem;
--
spark at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |spark at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-06-14 19:49:10
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321
[Bug target/32341] [4.3 Regression] undefined reference to `df_set_regs_ever_live_p'
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Summary|undefined reference to |[4.3 Regression] undefined |`df_set_regs_ever_live_p' |reference to ||`df_set_regs_ever_live_p' Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32341
[Bug c/32348] New: ICE on valid code
Gcc version 4.2.0 configured for e500v2, i.e.: --target=powerpc-unknown-linux-gnuspe --enable-e500_double ICE occurs during build of eglic-2.5. Here is the command with -v, attached is e_expl.i /_TOOLS_/dist/gnu_toolchain/gnu-gcc-4.2.0-binutils-2.17-eglibc-2.5-e500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/libexec/gcc/powerpc-unknown-linux-gnuspe/4.2.0/cc1 -E -quiet -nostdinc -v -I../include -I/tmp/edmar/gcc_420/build/obj_glibc/math -I/tmp/edmar/gcc_420/build/obj_glibc -I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf -I../ports/sysdeps/unix/sysv/linux/powerpc/powerpc32/e500/fpu -I../ports/sysdeps/powerpc/powerpc32/e500/fpu -I../ports/sysdeps/unix/sysv/linux/powerpc/powerpc32/e500 -I../sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu -I../sysdeps/powerpc/powerpc32/fpu -I../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../ports/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../nptl/sysdeps/unix/sysv/linux/powerpc -I../ports/sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/ieee754/ldbl-128ibm -I../sysdeps/ieee754/ldbl-opt -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../ports/sysdeps/unix/sysv/linux -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../nptl/sysdeps/unix/sysv -I../ports/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc -I../nptl/sysdeps/unix -I../ports/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/powerpc/powerpc32/e500 -I../ports/sysdeps/powerpc/powerpc32 -I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/fpu -I../nptl/sysdeps/powerpc -I../ports/sysdeps/powerpc -I../sysdeps/powerpc -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../nptl -I../ports -I.. -I../libio -I. -MD /tmp/edmar/gcc_420/build/obj_glibc/math/e_expl.d -MF /tmp/edmar/gcc_420/build/obj_glibc/math/e_expl.o.dt -MP -MT /tmp/edmar/gcc_420/build/obj_glibc/math/e_expl.o -MQ /tmp/edmar/gcc_420/build/obj_glibc/math/e_expl.o -D__unix__ -D__gnu_linux__ -D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix -Asystem=posix -D__NO_MATH_INLINES -D__LIBC_INTERNAL_MATH_INLINES -D_LIBC_REENTRANT -DNOT_IN_libc=1 -DIS_IN_libm=1 -isystem /_TOOLS_/dist/gnu_toolchain/gnu-gcc-4.2.0-binutils-2.17-eglibc-2.5-e500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include -isystem /_TOOLS_/dist/gnu_toolchain/gnu-gcc-4.2.0-binutils-2.17-eglibc-2.5-e500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include-fixed -isystem /_TOOLS_/dist/gnu_toolchain/gnu-gcc-4.2.0-binutils-2.17-eglibc-2.5-e500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/sysroot/usr/include -include ../include/libc-symbols.h ../sysdeps/ieee754/ldbl-128ibm/e_expl.c -mnew-mnemonics -mlong-double-128 -std=gnu99 -Wall -Winline -Wwrite-strings -Wstrict-prototypes -Wno-uninitialized -fmerge-all-constants -fworking-directory -O2 -fpch-preprocess -o e_expl.i ignoring nonexistent directory /_TOOLS_/dist/gnu_toolchain/gnu-gcc-4.2.0-binutils-2.17-eglibc-2.5-e500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/lib/gcc/powerpc-unknown-linux-gnuspe/4.2.0/include-fixed #include ... search starts here: #include ... search starts here: ../include /tmp/edmar/gcc_420/build/obj_glibc/math /tmp/edmar/gcc_420/build/obj_glibc ../sysdeps/powerpc/powerpc32/elf ../sysdeps/powerpc/elf ../ports/sysdeps/unix/sysv/linux/powerpc/powerpc32/e500/fpu ../ports/sysdeps/powerpc/powerpc32/e500/fpu ../ports/sysdeps/unix/sysv/linux/powerpc/powerpc32/e500 ../sysdeps/unix/sysv/linux/powerpc/powerpc32/fpu ../sysdeps/powerpc/powerpc32/fpu ../nptl/sysdeps/unix/sysv/linux/powerpc/powerpc32 ../ports/sysdeps/unix/sysv/linux/powerpc/powerpc32 ../sysdeps/unix/sysv/linux/powerpc/powerpc32 ../nptl/sysdeps/unix/sysv/linux/powerpc ../ports/sysdeps/unix/sysv/linux/powerpc ../sysdeps/unix/sysv/linux/powerpc ../sysdeps/ieee754/ldbl-128ibm ../sysdeps/ieee754/ldbl-opt ../nptl/sysdeps/unix/sysv/linux ../nptl/sysdeps/pthread ../sysdeps/pthread ../ports/sysdeps/unix/sysv/linux ../sysdeps/unix/sysv/linux ../sysdeps/gnu ../sysdeps/unix/common ../sysdeps/unix/mman ../sysdeps/unix/inet ../nptl/sysdeps/unix/sysv ../ports/sysdeps/unix/sysv ../sysdeps/unix/sysv ../sysdeps/unix/powerpc ../nptl/sysdeps/unix ../ports/sysdeps/unix ../sysdeps/unix ../sysdeps/posix ../ports/sysdeps/powerpc/powerpc32/e500 ../ports/sysdeps/powerpc/powerpc32 ../sysdeps/powerpc/powerpc32 ../sysdeps/wordsize-32 ../sysdeps/powerpc/fpu ../nptl/sysdeps/powerpc ../ports/sysdeps/powerpc ../sysdeps/powerpc ../sysdeps/ieee754/dbl-64 ../sysdeps/ieee754/flt-32 ../sysdeps/ieee754 ../sysdeps/generic/elf ../sysdeps/generic ../nptl ../ports .. ../libio .
[Bug target/32268] Wrong comparison results for __float128 operands
--- Comment #2 from uros at gcc dot gnu dot org 2007-06-14 20:15 --- Subject: Bug 32268 Author: uros Date: Thu Jun 14 20:15:13 2007 New Revision: 125720 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125720 Log: PR target/32268 * config/i386/sfp-machine.c (CMPtype): New define. (mach stubs): Use CMPtype instead of int as a return type. testsuite/ChangeLog: PR target/32268 * gcc.target/i386/pr32268.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr32268.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sfp-machine.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32268
[Bug target/32268] Wrong comparison results for __float128 operands
--- Comment #3 from ubizjak at gmail dot com 2007-06-14 20:42 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32268
[Bug c++/32346] long long bitfield passed to int argument incorrectly
--- Comment #1 from greened at obbligato dot org 2007-06-14 20:48 --- Created an attachment (id=13705) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13705action=view) Preprocessed testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
[Bug c++/32346] long long bitfield passed to int argument incorrectly
--- Comment #2 from greened at obbligato dot org 2007-06-14 20:50 --- Configuration: g++ -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /tools/gcc-4.2.0/configure --prefix=/tools/i686-pc-linux-gnu --disable-shared --with-gnu-as --with-gnu-ld --with-build-time-tools=/tools/i686-pc-linux-gnu/bin --with-mpfr=/tools/i686-pc-linux-gnu --with-gmp=/tools/i686-pc-linux-gnu --enable-targets=all Thread model: posix gcc version 4.2.0 This only fails with g++. gcc compiles it fine. -- greened at obbligato dot org changed: What|Removed |Added CC||greened at obbligato dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32346
[Bug rtl-optimization/32283] Missed induction variable optimization
--- Comment #7 from pranav dot bhandarkar at gmail dot com 2007-06-14 20:50 --- I guess strength reduction should then be implemented at the RTL level ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32283
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-06-14 20:53 --- Why did you remove me? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug libgcj/31093] Multicast PromiscuousTraffic
--- Comment #3 from geoffk at gcc dot gnu dot org 2007-06-14 20:56 --- Subject: Bug 31093 Author: geoffk Date: Thu Jun 14 20:56:25 2007 New Revision: 125721 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125721 Log: PR 31093 * decl2.c (determine_visibility): Remove duplicate code for handling type info. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/anon4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31093
[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
--- Comment #12 from dave at hiauly1 dot hia dot nrc dot ca 2007-06-14
21:05 ---
Subject: Re: [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
Sounds like the following patch would work:
diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
{
return (reload_completed
(compute_frame_size (get_frame_size (), 0) ? 0 : 1)
- df_hard_reg_used_count (2) == 1
+ DF_REG_DEF_COUNT (2) == 0
! frame_pointer_needed);
}
This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).
Thanks, I'll give it a try.
I had tried using current_function_is_leaf. However, it's not working.
It seems to work for some simple test cases but a trivial return is still
being generated in at least one situation where a non trivial return
is needed. I haven't had time to debug what's wrong.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296
[Bug middle-end/32349] New: ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
Multiple tests in SPEC CPU2000 ICE when compiled with -O2 -fmodulo-sched on
powerpc64-linux with either -m32 or -m64; there are more failures with -m64.
Here's a cut-down testcase, which I'm sure someone will be able to minimize
even more:
extern long *x1, *x2, *x3;
int
foo ()
{
/* Switching the following two lines prevents the ICE. */
long *p1, *p2;
long m, n, i;
p1 = x1;
p2 = x2;
n = 0;
for (i = *x3; 0 i; i--)
{
m = (*p1++) ^ (*p2++);
m = (m 0x) + ((m 1) 0x);
m = (m 0x) + ((m 2) 0x);
m = (m + (m 4)) 0x0f0f0f0f;
m = (m + (m 8));
n += m;
}
return n;
}
Output when compiled with trunk revision 125693 (default is -m32):
elm3b145% /opt/gcc-nightly/trunk-20070614/bin/gcc -O2 -fmodulo-sched -c
bug0614-1.c
bug0614-1.c: In function foo:
bug0614-1.c:23: internal compiler error: in df_refs_verify, at df-scan.c:4066
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
--
Summary: ICE in df_refs_verify with -O2 -fmodulo-sched for spec
tests
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janis at gcc dot gnu dot org
GCC target triplet: powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #3 from spark at gcc dot gnu dot org 2007-06-14 21:10 --- Adding our bugmaster to CC. -- spark at gcc dot gnu dot org changed: What|Removed |Added CC||spark at gcc dot gnu dot ||org, pinskia at gcc dot gnu ||dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c++/31903] [4.3 Regression] typeinfo of classes in anon namespace isn't being marked static
--- Comment #11 from geoffk at gcc dot gnu dot org 2007-06-14 21:11 --- Should be fixed with this change: r125721 | geoffk | 2007-06-14 13:56:25 -0700 (Thu, 14 Jun 2007) | 4 lines PR 31093 * decl2.c (determine_visibility): Remove duplicate code for handling type info. -- geoffk at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31903
[Bug middle-end/32349] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
--- Comment #1 from spark at gcc dot gnu dot org 2007-06-14 21:12 --- Kenny, can you take a look ? -- spark at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-06-14 21:19 --- (In reply to comment #3) Adding our bugmaster to CC. Well in this case, I am more of a PPC guy and not the bugmaster. I think I know what the issue is already, but since you did --disable-altivec which does not make sense as you did --with-cpu=7450 also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c++/31923] g++ accepts a storage-class-specifier on a template explicit specialization
--- Comment #2 from simon_baldwin at yahoo dot com 2007-06-14 21:29 --- Note: there's also a C++ language defect report relating to this issue, with recommendation from the CWG: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#605 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31923
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #5 from malitzke at metronets dot com 2007-06-14 21:42 ---
Smart comment, unfortunately it is wrong. I spotted this myself and quickly
rebootstrapped gcc the results are:
Reading specs from /var/tmp/gcc_r43/build-26/gcc/specs
Target: powerpc-unknown-linux-gnu
Configured with: ../gcc-4.3.0/configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --host=powerpc-unknown-linux-gnu
--build=powerpc-unknown-linux-gnu --enable-__cxa_atexit --enable-threads=posix
--enable-shared --enable-clocale=gnu --enable-bootstrap
--enable-languages=c,c++,fortran --enable-altivec --disable-checking
--disable-nls --disable-decimal-float --disable-werror --disable-multilib
--with-ibmlongdouble --with-cpu=7450 --enable-clocale=gnu --with-system-zlib
Thread model: posix
gcc version 4.3.0 20070614 (experimental)
/var/tmp/gcc_r43/build-26/gcc/cc1 -E -quiet -v -iprefix
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/
-isystem /var/tmp/gcc_r43/build-26/gcc/include -isystem
/var/tmp/gcc_r43/build-26/gcc/include-fixed -D__unix__ -D__gnu_linux__
-D__linux__ -Dunix -D__unix -Dlinux -D__linux -Asystem=linux -Asystem=unix
-Asystem=posix ops.c -maltivec -mabi=altivec -mcpu=7450 -std=gnu99
-fno-show-column -Os -fpch-preprocess -o ops.i
ignoring nonexistent directory
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
ignoring nonexistent directory
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
ignoring nonexistent directory
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include
ignoring nonexistent directory
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include
ignoring nonexistent directory
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/include-fixed
ignoring nonexistent directory
/var/tmp/gcc_r43/build-26/gcc/../lib/gcc/../../lib/gcc/powerpc-unknown-linux-gnu/4.3.0/../../../../powerpc-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/libffi
/var/tmp/gcc_r43/build-26/gcc/include
/var/tmp/gcc_r43/build-26/gcc/include-fixed
/usr/local/include
/usr/include
End of search list.
/var/tmp/gcc_r43/build-26/gcc/cc1 -fpreprocessed ops.i -quiet -dumpbase ops.c
-maltivec -mabi=altivec -mcpu=7450 -auxbase-strip ops.s -Os -std=gnu99 -version
-fno-show-column -o ops.s
GNU C version 4.3.0 20070614 (experimental) (powerpc-unknown-linux-gnu)
compiled by GNU C version 4.3.0 20070614 (experimental), GMP version
4.2.1, MPFR version 2.2.1-p5.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=96544
Compiler executable checksum: e4f92d229bfbaed546370fd132d96102
ops.c: In function 'f6':
ops.c:761: error: insn does not satisfy its constraints:
(insn 1187 1186 32 2 ops.c:663 (set (reg:V4SI 78 1)
(mem:V4SI (plus:SI (reg:SI 11 11)
(const_int 16 [0x10])) [7 S16 A128])) 515 {altivec_lvx_v4si}
(nil))
ops.c:761: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
the ops.i files compare identical but I could add and waste bandwidt
--
malitzke at metronets dot com changed:
What|Removed |Added
CC||dje at watson dot ibm dot
||com, geoffk at geoffk dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #6 from malitzke at metronets dot com 2007-06-14 21:50 --- This is just a more conspicuous case as evidenced looking at the data below. The almost 2:1 worse results for the powerpc show up day after day, month after month. Powerpc G4 gcc-4.3.0-20070613 check results === g++ Summary === # of expected passes16031 # of unexpected failures10 # of expected failures 86 # of unsupported tests 108 === libmudflap Summary === # of expected passes1817 # of unexpected failures9 === libstdc++ Summary === # of expected passes # of unexpected failures1 # of unexpected successes 1 # of expected failures 42 # of unsupported tests 316 === libgomp Summary === # of expected passes1566 === gfortran Summary === # of expected passes18252 # of unexpected failures24 # of expected failures 8 # of unsupported tests 36 === gcc Summary === # of expected passes45473 # of unexpected failures5 # of unexpected successes 2 # of expected failures 138 # of untested testcases 35 # of unsupported tests 434 i686 pentium3 gcc-4.3.0-20070613 check results === libmudflap Summary === # of expected passes1821 # of unexpected failures5 === libgomp Summary === # of expected passes1566 === g++ Summary === # of expected passes16165 # of unexpected failures6 # of unexpected successes 2 # of expected failures 86 # of unsupported tests 81 === gfortran Summary === # of expected passes18308 # of unexpected failures8 # of expected failures 8 # of unsupported tests 16 === libstdc++ Summary === # of expected passes4445 # of unexpected successes 1 # of expected failures 42 # of unsupported tests 316 === gcc Summary === # of expected passes45210 # of unexpected failures1 # of unexpected successes 2 # of expected failures 135 # of untested testcases 35 # of unsupported tests 318 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-06-14 21:56 --- These are the results I get from a couple of (3) days old on powerpc64-linux: === gcc Summary for unix//-m32 === # of expected passes46391 # of unexpected failures16 # of unexpected successes 2 # of expected failures 138 # of unresolved testcases 2 # of untested testcases 35 # of unsupported tests 416 === gcc Summary for unix//-m64 === # of expected passes46238 # of unexpected failures13 # of unexpected successes 3 # of expected failures 138 # of unresolved testcases 2 # of untested testcases 35 # of unsupported tests 484 === gcc Summary === # of expected passes92629 # of unexpected failures29 # of unexpected successes 5 # of expected failures 276 # of unresolved testcases 4 # of untested testcases 70 # of unsupported tests 900 /home/apinski/src/ptrplus/gcc/objdir/gcc/xgcc version 4.3.0 20070611 (experimental) And yes I know the unexpected failures look high, all of the problems related to what I am running with really and nothing else. Also by the way you should look into the changelog and you will notice I started my GCC work with PPC :). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug c++/32350] New: Very high compile times for template code
The attached code takes 1m29s to compile on my machine with 4.2.0 in 64-bit mode, and takes 0.5s on 4.0.3 Using built-in specs. Target: x86_64-suse-linux Configured with: ../../gcc-4.2.0/configure --enable-languages=c,c++,fortran --prefix=/usr/local/products/gcc/4.2.0-pa-64 --with-gnu-as --with-as=/usr/local/products/gcc/binutils-2.17-64/bin/as --with-gnu-ld --with-ld=/usr/local/products/gcc/binutils-2.17-64/bin/ld --enable-threads=posix --enable-shared --enable-__cxa_atexit --with-gmp=/usr/local/products/gcc/gmp-4.2-64 --with-mpfr=/usr/local/products/gcc/mpfr-2.2.1-64 --enable-libstdcxx-allocator=pool x86_64-suse-linux Thread model: posix gcc version 4.2.0 monsterd09:/work/nova/2300 time /usr/local/products/gcc/4.2.0-pa-64/bin/g++ -O0 -I/work/nova/sts5/beta/src -I/work/ren/ren/src -I/work/ren/ren.ext/src -D_LARGEFILE64_SOURCE -ftemplate-depth-64 -pedantic-errors -Wall -Wno-unknown-pragmas -W -Woverloaded-virtual -fno-strict-aliasing -fsigned-char -Wno-long-long test_fixedpoint_case.C real1m29.184s user1m28.338s sys 0m0.204s -- Summary: Very high compile times for template code Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: georgeh at rentec dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32350
[Bug c++/32350] Very high compile times for template code
--- Comment #1 from georgeh at rentec dot com 2007-06-14 22:02 --- Created an attachment (id=13706) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13706action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32350
[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c
--- Comment #8 from janis at gcc dot gnu dot org 2007-06-14 22:10 --- I get the same failure with my nightly build compiler for powerpc64-linux with -m32 -Os -mcpu=7450. I'll minimize the testcase and perhaps that nice young man Andrew Pinski will fix the bug for us. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347
[Bug middle-end/31979] ICE compiling openssl-0.9.8e/apps/ocsp.c
--- Comment #3 from roederja at cs dot washington dot edu 2007-06-14 22:19 --- I get the same error (internal compiler error: in move_insn, at haifa-sched.c:1963) when trying to compile EiffelStudio on Mac OS X PPC, also GCC 4.2 . However it's hard to tell where it fails exactly because the error is in some generated c-byte-code... However compilation works with Apple's GCC 4.0.1 -- roederja at cs dot washington dot edu changed: What|Removed |Added CC||roederja at cs dot ||washington dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31979
[Bug c++/11247] -frepo fails to instantiate typeinfo
--- Comment #6 from aaw at gcc dot gnu dot org 2007-06-14 22:32 --- I've just run into this problem trying to test an unrelated change. Here's a puzzler, though. If I run the g++.dg/rtti/repo1.C test, it compiles successfully. If I copy the command line for the compilation but modify the output filename, I get an object file with `function11::function1()' removed. For some reason, the behavior of the -frepo option is dependent on the -o option. -- aaw at gcc dot gnu dot org changed: What|Removed |Added CC||aaw at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11247
[Bug c++/31806] [4.1 Regression] miscompilation with -fschedule-insns2 -fno-threadsafe-statics
--- Comment #10 from mueller at gcc dot gnu dot org 2007-06-14 23:12 --- Subject: Bug 31806 Author: mueller Date: Thu Jun 14 23:12:25 2007 New Revision: 125726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125726 Log: 2007-06-14 Dirk Mueller [EMAIL PROTECTED] PR c++/31806 * g++.dg/opt/static6.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/opt/static6.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31806
[Bug target/32348] ICE on valid code
--- Comment #1 from joseph at codesourcery dot com 2007-06-14 23:26 --- Subject: Re: New: ICE on valid code On Thu, 14 Jun 2007, edmar at freescale dot com wrote: Gcc version 4.2.0 configured for e500v2, i.e.: --target=powerpc-unknown-linux-gnuspe --enable-e500_double ICE occurs during build of eglic-2.5. glibc for Power requires IBM long double, and IBM long double for E500 is not supported by unmodified FSF GCC 4.2 (since my patch to add the support was large and depended on changes to target-independent RTL parts of the compiler that were potentially risky to other targets - and indeed did need followup patches to fix problems with other targets that showed up when those changes went on mainline). If you are using a compiler with all the relevant changes backported, then GCC Bugzilla isn't the right place to report bugs in it. Of course, if the bug still applies when building glibc (2.6 or later in order to work with newer GCC) with current unmodified GCC trunk, then report it here as a bug against trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32348
[Bug other/32351] New: Wrong DFP format is used in libdecnumber
libdecnumber is a build library which is used by compiler internaly to support DFP. configure.ac in libdecnumber has case $target in powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*) enable_decimal_float=yes ;; *) enable_decimal_float=no ;; esac ... case $target in i?86*-*-linux* | x86_64*-*-linux*) enable_decimal_float=bid ;; *) enable_decimal_float=dpd ;; esac When gcc is configured as i686-linux or x86_64-linux, the target won't match i?86*-*-linux* | x86_64*-*-linux*. As the result, libdecnumber will be wrongly configured to use DPD by default. A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01015.html -- Summary: Wrong DFP format is used in libdecnumber Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: patch Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32351
[Bug middle-end/32349] [4.3 Regression] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Summary|ICE in df_refs_verify with -|[4.3 Regression] ICE in |O2 -fmodulo-sched for spec |df_refs_verify with -O2 - |tests |fmodulo-sched for spec tests Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349
[Bug target/32342] [4.3 Regression] ICE in reload_cse_simplify_operands, at postreload.c:396
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32342
[Bug fortran/32343] ICE with arrays and vector valued functions from a used module
--- Comment #2 from burnus at gcc dot gnu dot org 2007-06-15 05:59 --- I can reproduce this with 4.1.3 and 4.2, but not with 4.3. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.0 4.1.3 Known to work||4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32343
