[Bug c/57180] Structures with a flexible arrray member have wrong size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57180 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-05-06 08:53:37 UTC --- This testcase fails on armv5tel-linux-gnueabi with (at least) gcc 4.4, 4.6, 4.7, and 4.8.
[Bug c/57133] false const qualifier warning typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57133
--- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-05-01
11:37:56 UTC ---
(In reply to comment #0)
typedef char *type;
void f(const type t)
{
This doesn't do what you think it does. t is now a const variable of type
char*, not a variable of type const char*. Observe:
cat pr57133.c
typedef char *type;
void f(const type t) { t = 0; }
void g(const type t) { *t = 0; }
gcc -Wall -S pr57133.c
pr57133.c: In function 'f':
pr57133.c:2:1: error: assignment of read-only parameter 't'
The warning in your main() is correct.
[Bug libgcc/57085] Segmentation Fault when building a c file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085 --- Comment #11 from Mikael Pettersson mikpe at it dot uu.se 2013-04-29 19:30:35 UTC --- I can't reproduce the ICE with a cross to arm-linux-androideabi either.
[Bug libgcc/57085] Segmentation Fault when building a c file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-04-28 09:11:03 UTC --- (In reply to comment #2) Created attachment 29954 [details] Affected code Attached is contents.c that I mentioned in the initial post. This is from system/extras/ext4_utils/ in jb-mr1.1-release of Android. That's the original C code, not the _preprocessed_ C code. It still depends on numerous headers files to compile. Please just do your android arm gcc your compile options -E -o contents.i contents.c and attach contents.i.
[Bug libgcc/57085] Segmentation Fault when building a c file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2013-04-28 13:41:53 UTC --- I can't reproduce the ICE with 4.9 r198366 configured as a cross to armv7l-unknown-linux-gnueabi, on either x86_64-linux or i686-linux, or natively on armv5tel-unknown-linux-gnueabi with 4.9-20130421 (r198117).
[Bug libgcc/57085] Segmentation Fault when building a c file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085 --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se 2013-04-28 18:08:02 UTC --- (In reply to comment #8) Any suggestions for troubleshooting this bug on my end? I've done a few toolchain builds and always run into this segfault as do others. Tell us more about the host and target system: 1. What's the complete target triplet? 2. What's the host system's triplet? You only wrote i686, but the OS part may be relevant (Linux, *BSD, MacOS, Cygwin, MinGW, ...). 3. Are the gcc sources completely vanilla, or do you have local modifications?
[Bug libgcc/57085] Segmentation Fault when building a c file
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-04-27 10:00:13 UTC --- Please attach _preprocessed_ source for the test case, and tell us what options gcc was invoked when compiling the test case.
[Bug c/57080] Invalid optimization (-O2) when doing double - int conversion (on big endian archs(?))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57080 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-04-26 11:49:44 UTC --- Created attachment 29946 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29946 test case I can reproduce the issue on m68k: with the attached test case I get 4 on m68k-linux (big-endian), but 5 on x86_64-linux (little-endian). I don't see any conversions to char or unsigned, so I don't think PR27394 is related. The issue goes away with -ffloat-store on m68k. I haven't analyzed it further. On the big-endian armv5teb-linux-gnueabi I get 5, but it's soft-fp.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2013-04-25 09:16:12 UTC --- (In reply to comment #4) Patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01464.html . The patch doesn't work. With 4.9-20130421 + the patch I get: /tmp/objdir/./prev-gcc/xg++ -B/tmp/objdir/./prev-gcc/ -B/tmp/install49/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/tmp/gcc-4.9-20130421/libstdc++-v3/libsupc++ -L/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/objdir/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -Ifortran -I/tmp/gcc-4.9-20130421/gcc -I/tmp/gcc-4.9-20130421/gcc/fortran -I/tmp/gcc-4.9-20130421/gcc/../include -I/tmp/gcc-4.9-20130421/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-x86_64/gmp-5.1.1/include -I/home/mikpe/pkgs/linux-x86_64/mpfr-3.1.2/include -I/home/mikpe/pkgs/linux-x86_64/mpc-1.0.1/include -I/tmp/gcc-4.9-20130421/gcc/../libdecnumber -I/tmp/gcc-4.9-20130421/gcc/../libdecnumber/bid -I../libdecnumber -I/tmp/gcc-4.9-20130421/gcc/../libbacktrace /tmp/gcc-4.9-20130421/gcc/fortran/module.c -o fortran/module.o /tmp/gcc-4.9-20130421/gcc/fortran/module.c:78:18: fatal error: zlib.h: No such file or directory #include zlib.h Note the absence of any -I directive to pick up the internal zlib. Zlib was built however, and e.g. lto-compress managed to pick it up: /tmp/objdir/./prev-gcc/xg++ -B/tmp/objdir/./prev-gcc/ ...-I/tmp/gcc-4.9-20130421/gcc/../zlib ... /tmp/gcc-4.9-20130421/gcc/lto-compress.c -o lto-compress.o
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2013-04-25 13:50:47 UTC --- (In reply to comment #6) Updated patch at http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01517.html This one works. Thanks.
[Bug bootstrap/57028] [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-04-24 16:54:41 UTC --- As far as I understand it, there are two issues: 1. zlib isn't built unless some explicitly enabled component demands it; in my case (on x86_64) zlib was built since I had java enabled, but nothing in Fortran appears to declare a dependency on zlib. Maybe gcc/fortran/config-lang.in is the place to declare that? 2. The in-tree zlib isn't added automatically to include and library paths, components need to check for with_system_zlib and adjust their paths accordingly, c.f. libjava/configure.ac.
[Bug c/57046] wrong code generated by gcc 4.8.0 on i686
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57046 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-04-23 11:31:06 UTC --- Created attachment 29918 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29918 Single-file test case. I can reproduce the wrong-code on x86_64-linux with gcc 4.9-20130421 and 4.8-20130418, using -m32 -O2 -Wall. gcc 4.7 and 4.6 generate correct code.
[Bug bootstrap/57028] New: [4.9 regression] Fortran bootstrap fails due to missing zlib.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57028 Bug #: 57028 Summary: [4.9 regression] Fortran bootstrap fails due to missing zlib.h Classification: Unclassified Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Attempting to bootstrap gcc-4.9-20130421 on x86_64-linux (Fedora 17) w/ Fortran enabled but no zlib-devel package installed results in: /mnt/scratch/objdir49/./prev-gcc/xg++ -B/mnt/scratch/objdir49/./prev-gcc/ -B/mnt/scratch/install49/x86_64-unknown-linux-gnu/bin/ -nostdinc++ -B/mnt/scratch/objdir49/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/mnt/scratch/objdir49/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/mnt/scratch/objdir49/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/mnt/scratch/objdir49/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include -I/mnt/scratch/gcc-4.9-20130421/libstdc++-v3/libsupc++ -L/mnt/scratch/objdir49/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/mnt/scratch/objdir49/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -c -DIN_GCC_FRONTEND -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -I. -Ifortran -I/mnt/scratch/gcc-4.9-20130421/gcc -I/mnt/scratch/gcc-4.9-20130421/gcc/fortran -I/mnt/scratch/gcc-4.9-20130421/gcc/../include -I/mnt/scratch/gcc-4.9-20130421/gcc/../libcpp/include -I/home/mikpe/pkgs/linux-x86_64/gmp-5.1.1/include -I/home/mikpe/pkgs/linux-x86_64/mpfr-3.1.2/include -I/home/mikpe/pkgs/linux-x86_64/mpc-1.0.1/include -I/mnt/scratch/gcc-4.9-20130421/gcc/../libdecnumber -I/mnt/scratch/gcc-4.9-20130421/gcc/../libdecnumber/bid -I../libdecnumber -I/mnt/scratch/gcc-4.9-20130421/gcc/../libbacktrace /mnt/scratch/gcc-4.9-20130421/gcc/fortran/module.c -o fortran/module.o /mnt/scratch/gcc-4.9-20130421/gcc/fortran/module.c:78:18: fatal error: zlib.h: No such file or directory #include zlib.h ^ compilation terminated. make[3]: *** [fortran/module.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcj-dbtool.pod gcj.pod jcf-dump.pod jv-convert.pod grmic.pod gc-analyze.pod gfortran.pod gfdl.pod gij.pod gcc.pod gcov.pod cpp.pod fsf-funding.pod make[3]: Leaving directory `/mnt/scratch/objdir49/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir49' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir49' make: *** [bootstrap] Error 2 The previous weekly snapshot, 4.9-20130414, bootstrapped fine on the same system with the same configuration options.
[Bug target/57018] Miscompilation of bison 2.7.1 under -Os -fomit-frame-pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se, ||vmakarov at gcc dot gnu.org --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-04-21 11:58:54 UTC --- I can reproduce the wrong-code on x86_64-linux with gcc 4.9 and 4.8, using -m32 -march=i686 -Os -fomit-frame-pointer -fno-asynchronous-unwind-tables. It started with r195095, a fix for an LRA ICE (PR55672).
[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2013-04-17 20:15:47 UTC --- (In reply to comment #9) How to proceed? Derive a stand-alone test case from the failing glibc module and whatever glibc code it requires, then minimize it.
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC|mikpe at it dot uu.se |
--- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2013-04-14
08:56:47 UTC ---
The error is in the test case. It overrides the libc memmove() with its own
implementation, but that implementation fails to follow the specification. In
particular, it returns NULL rather than memmove()'s first parameter.
GCC now optimizes based on this aspect of the specification, so things go wrong
at runtime.
Correcting the test case as follows allows it to work with gcc 4.8 and 4.9:
--- unix.c.~1~ 2013-03-06 23:17:26.0 +0100
+++ unix.c 2013-04-14 10:45:24.651407693 +0200
@@ -110,7 +110,7 @@ memmove(void *dp, const void *sp, size_t
unsigned char *cdp, *csp;
if (n=0)
- return 0;
+ return dp;
cdp = dp;
csp = (unsigned char *)sp;
if (cdp csp) {
@@ -124,6 +124,6 @@ memmove(void *dp, const void *sp, size_t
*--cdp = *--csp;
} while (--n);
}
- return 0;
+ return dp;
}
#endif
Not a bug in GCC. Please close as INVALID.
[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2013-04-14 15:55:32 UTC --- OK, I can confirm that compiling glibc-2.17 with gcc-4.7.3 -O3 -march=bdver1 causes the sha512 test to fail, but without -march=bdver1 it doesn't fail. I also saw regressions in math/test-float.out, math/test-double.out, math/test-ifloat.out, math/test-idouble.out, nptl/tst-cond25.out, and rt/tst-cpuclock2.out.
[Bug target/56940] internal compiler error: unrecognizable insn:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56940 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-04-13 10:55:21 UTC --- I can reproduce the ICE with gcc 4.6.4, but not with 4.7.3 or 4.8.0, all built as crosses to arm-linux-gnueabi from unmodified FSF releases.
[Bug target/48576] wrong code when accessing variables in a large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48576 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2013-04-13 12:26:24 UTC --- This bug still occurs with gcc 4.9-20130407, 4.8-20130411, and 4.7-20130406.
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-04-13 17:53:30 UTC --- Thanks for the complete test case. I can reproduce the apparent wrong-code (runtime SEGV) on x86_64-linux w/ glibc-2.15 with gcc 4.9-20130407 and 4.8-20130411, but not with 4.7-20130406 or 4.6-20130405.
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 --- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2013-04-13 20:39:03 UTC --- Started with Bernd Schmidt's Optimize calls to functions that return one of their arguments patch in http://gcc.gnu.org/r187459, originally proposed in http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01817.html.
[Bug target/56866] gcc 4.7.x/gcc-4.8.x with '-O3 -march=bdver2' misscompiles glibc-2.17/crypt/sha512.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56866
Mikael Pettersson mikpe at it dot uu.se changed:
What|Removed |Added
CC||mikpe at it dot uu.se
--- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-04-12
12:42:26 UTC ---
I've bootstrapped and regtested gcc-4.7.3 on an Opteron 6278, with and without
--with-arch=bdver1. With --with-arch=bdver1 there were numerous regressions in
gcc.dg/vect/ and gcc.target/i386/{,l-}fma*, and one in
gcc.target/i386/pr42542-4a.c. I don't know if these indicate wrong-code or
missed-optimization.
I'd be willing to run specific wrong-code test cases on this machine, if
they're completely standalone (not depending on recent glibc).
[Bug bootstrap/56813] [4.9 regression] invalid assembly code for libiberty/cp-demangle.c on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56813 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-04-10 07:24:50 UTC --- The error is gone in gcc-4.9-20130407. Don't know exactly which rev fixed it.
[Bug tree-optimization/56899] Wrong constant folding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56899 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-04-10 07:45:20 UTC --- What's the target? I can't reproduce on x86_64, armv5tel, or m68k.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-04-09 07:52:07 UTC --- I can reproduce the problem on x86-64 Linux with 4.8-20130404. This issue would be fatal for one of my projects which includes an embedded libc.
[Bug middle-end/56888] memcpy implementation optimized as a call to memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56888 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-04-09 09:59:20 UTC --- Started with Richard Biener's http://gcc.gnu.org/r188261 aka PR53081 fix, which added or improved memcpy recognition. I'm guess the new code fails to check for whatever option is supposed to disable this sort of transformation.
[Bug other/56881] Miscompilation (optimisation failure?) causing NULL dereference and segfault at runtime
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56881 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-04-09 14:45:33 UTC --- The test case is incomplete, as it lacks both main() and domalloc(). Please add those (in a separate file if you like) so that the test case can be compiled to an executable, and the presence or absence of a runtime failure can be observed.
[Bug c/52773] internal error: in replace_pseudos_in, at reload1.c:577
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52773 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-04-08 17:11:50 UTC --- The ICE still occurs with gcc 4.6-20130405, 4.7-20130406, 4.8-20130404, and 4.9-20130407.
[Bug c/56851] Segmentation Error using -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56851 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-04-06 09:58:19 UTC --- Some important information was hidden in that attached zip file. First, the target is arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb, with the host being mingw32. Second, the version is wrong; it's not 4.7.0 but ARM/embedded-4_7-branch revision 196615 (I can't tell if it's vanilla or patched). However, I can reproduce the cc1 SEGV in a cross from x86_64-linux to arm-linux-gnueabi with gcc-4.7-20130330: /tmp/objdir/gcc/xgcc -B/tmp/objdir/gcc -mcpu=cortex-m3 -mthumb -O3 -S sensors.i C:\Radio Control\OpenAero32\src\sensors.c: In function 'ACC_getADC': C:\Radio Control\OpenAero32\src\sensors.c:251:6: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Re-running under gdb shows: Program received signal SIGSEGV, Segmentation fault. 0x007f5baf in rename_use_op (op_p=0x77611330) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:55 55if (TREE_CODE (USE_FROM_PTR (op_p)) != SSA_NAME) Missing separate debuginfos, use: debuginfo-install glibc-2.15-58.fc17.x86_64 (gdb) bt #0 0x007f5baf in rename_use_op (op_p=0x77611330) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:55 #1 rename_variables_in_bb (bb=0x776103a8) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:95 #2 0x007f5bee in rename_variables_in_loop (loop=0x77551440) at /tmp/gcc-4.7-20130330/gcc/tree-vect-loop-manip.c:111 #3 0x007155aa in copy_loop_before (loop=0x77551330) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:182 #4 generate_loops_for_partition (copy_p=1 '\001', partition=0x12c4e30, loop=0x77551330) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:216 #5 generate_code_for_partition (copy_p=1 '\001', partition=0x12c4e30, loop=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:446 #6 ldist_gen (starting_vertices=0x12da6d0, rdg=0x1288840, loop=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1142 #7 distribute_loop (stmts=optimized out, loop=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1228 #8 distribute_loop (loop=optimized out, stmts=optimized out) at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1170 #9 0x00715b8d in tree_loop_distribution () at /tmp/gcc-4.7-20130330/gcc/tree-loop-distribution.c:1284 #10 0x00646f53 in execute_one_pass (pass=0x108ee20) at /tmp/gcc-4.7-20130330/gcc/passes.c:2084 #11 0x00647265 in execute_pass_list (pass=0x108ee20) at /tmp/gcc-4.7-20130330/gcc/passes.c:2139 #12 0x00647277 in execute_pass_list (pass=0x108ff00) at /tmp/gcc-4.7-20130330/gcc/passes.c:2140 #13 0x00647277 in execute_pass_list (pass=0x108f180) at /tmp/gcc-4.7-20130330/gcc/passes.c:2140 #14 0x0071cd16 in tree_rest_of_compilation (fndecl=0x7749c300) at /tmp/gcc-4.7-20130330/gcc/tree-optimize.c:422 #15 0x004d1aba in cgraph_expand_function (node=0x777a26c0) at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:1837 #16 0x004d320a in cgraph_expand_all_functions () at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:1904 #17 cgraph_optimize () at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:2218 #18 0x004d371a in cgraph_finalize_compilation_unit () at /tmp/gcc-4.7-20130330/gcc/cgraphunit.c:1344 #19 0x004195a0 in c_write_global_declarations () at /tmp/gcc-4.7-20130330/gcc/c-decl.c:10032 #20 0x006d73a1 in compile_file () at /tmp/gcc-4.7-20130330/gcc/toplev.c:573 #21 do_compile () at /tmp/gcc-4.7-20130330/gcc/toplev.c:1929 #22 toplev_main (argc=15, argv=0x7fffdae8) at /tmp/gcc-4.7-20130330/gcc/toplev.c:2005 #23 0x77a47735 in __libc_start_main () from /lib64/libc.so.6 #24 0x00408861 in _start () gcc 4.8-20130404 and 4.6-20130405 both successfully compile this test case.
[Bug c/56851] Segmentation Error using -O3 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56851 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-04-06 11:57:13 UTC --- The SEGV stopped on trunk with r195239 aka PR55964 fix.
[Bug bootstrap/56813] [4.9 regression] invalid assembly code for libiberty/cp-demangle.c on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56813 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-04-03 13:10:22 UTC --- Started with Steven Bosscher's http://gcc.gnu.org/r197266, still occurs at r197407, reproducible with a cross.
[Bug bootstrap/56813] New: [4.9 regression] invalid assembly code for libiberty/cp-demangle.c on armv5tel-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56813
Bug #: 56813
Summary: [4.9 regression] invalid assembly code for
libiberty/cp-demangle.c on armv5tel-linux-gnueabi
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mi...@it.uu.se
Created attachment 29776
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29776
preprocessed source and generated assembly code
Attempting to bootstrap gcc-4.9-20130331 on armv5tel-linux-gnueabi fails with:
ln -s /mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty/cp-demangle.c
cp-demangle.c
/bin/sh ../libtool --tag CC --tag disable-shared --mode=compile
/mnt/scratch/objdir49/./gcc/xgcc -B/mnt/scratch/objdir49/./gcc/
-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/
-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/lib/ -isystem
/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/include -isystem
/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/sys-include
-DHAVE_CONFIG_H -I.. -I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty
-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../include -prefer-pic
-D_GLIBCXX_SHARED
-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi
-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include
-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/libsupc++ -g -O2 -DIN_GLIBCPP_V3
-Wno-error -c cp-demangle.c
libtool: compile: /mnt/scratch/objdir49/./gcc/xgcc
-B/mnt/scratch/objdir49/./gcc/
-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/bin/
-B/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/lib/ -isystem
/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/include -isystem
/mnt/scratch/install49/armv5tel-unknown-linux-gnueabi/sys-include
-DHAVE_CONFIG_H -I.. -I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../libiberty
-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/../include -D_GLIBCXX_SHARED
-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi
-I/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/include
-I/mnt/scratch/gcc-4.9-20130331/libstdc++-v3/libsupc++ -g -O2 -DIN_GLIBCPP_V3
-Wno-error -c cp-demangle.c -fPIC -DPIC -o cp-demangle.o
/tmp/ccdHzBmd.s: Assembler messages:
/tmp/ccdHzBmd.s:13290: Error: bad immediate value for offset (4104)
make[5]: *** [cp-demangle.lo] Error 1
make[5]: Leaving directory
`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/mnt/scratch/objdir49/armv5tel-unknown-linux-gnueabi/libstdc++-v3'
make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
make[2]: Leaving directory `/mnt/scratch/objdir49'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir49'
make: *** [bootstrap] Error 2
This is a recent regression as the previous weekly snapshot, 4.9-20130324,
bootstrapped fine.
The preprocessed code for cp-demangle.c also compiles fine with current 4.8,
4.7, and 4.6 branches.
Binutils is based on 2.22.52.0.1 20120131.
Configuration options:
/mnt/scratch/gcc-4.9-20130331/configure --prefix=/mnt/scratch/install49
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-languages=c,c++,fortran,ada
--disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --disable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--disable-sjlj-exceptions --with-arch=armv5te --with-tune=xscale
--build=armv5tel-unknown-linux-gnueabi --disable-plugin --disable-lto
--disable-libmudflap
I'll attach cp-demangle.{i,s}.
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-03-30 11:59:19 UTC --- I can reproduce the initial bug with gcc 4.4.7, 4.5.3, 4.6.3, and 4.7.0, but not with 4.5.4, 4.6-20130322, 4.7.1, or 4.7.2.
[Bug target/48326] Target attribute leaks from function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-03-30 12:31:38 UTC --- The initial bug was fixed by r187169 on 4.7 branch, I'd say it's clearly a dup of PR53228.
[Bug rtl-optimization/56745] [4.8/4.9 Regression] ICE in merge_if_block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56745 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-27 11:20:58 UTC --- Started with http://gcc.gnu.org/r193098.
[Bug c++/56734] Even simple exceptions cause a segmentation fault in my build of gcc on Solaris 10.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56734 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 09:09:18 UTC --- Works for me on Solaris 2.10/SPARC, gcc-4.7.2 configured w/ Sun not GNU binutils: g++ -O -c Core.ii g++ -O -c CoreTest.ii g++ Core.o CoreTest.o ./a.out Exception int caught For completeness: g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/home/mikpe/pkgs/sol2-sparc64/gcc-4.7.2/libexec/gcc/sparc-sun-solaris2.10/4.7.2/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /tmp/mikpe/gcc-4.7.2/configure --prefix=/home/mikpe/pkgs/sol2-sparc64/gcc-4.7.2 --with-gmp=/home/mikpe/pkgs/sol2-sparc64/gmp-5.0.5 --with-mpfr=/home/mikpe/pkgs/sol2-sparc64/mpfr-3.1.1 --with-mpc=/home/mikpe/pkgs/sol2-sparc64/mpc-1.0.1 --disable-build-poststage1-with-cxx --disable-libquadmath --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-libgomp --enable-threads --enable-checking=release --enable-version-specific-runtime-libs --with-system-zlib --enable-languages=c,c++,ada --with-cpu=ultrasparc --without-cloog --without-ppl Thread model: posix gcc version 4.7.2 (GCC)
[Bug rtl-optimization/56732] ICE in advance_target_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 09:40:52 UTC --- Also reproducible for arm-linux-gnueabi: 4.8.0 ICEs, 4.7.2 and 4.6.3 don't.
[Bug middle-end/56712] [4.6 Regression] constructor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 10:24:08 UTC --- (In reply to comment #5) Created attachment 29724 [details] backport of the above mentioned fix Don't base your backport on the original patch submission, base it on the actual commit, r180700. There are differences between the two.
[Bug rtl-optimization/56732] ICE in advance_target_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56732 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-26 13:35:30 UTC --- Started with http://gcc.gnu.org/r188742 or http://gcc.gnu.org/r188743. With r188742 I get: In file included from ploaderhook.c:25:0: /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h: In function 'sprintf': /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h:304:1: error: unrecognizable insn: (jump_insn 23 22 24 2 (simple_return) /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h:304 -1 (nil) - simple_return) /home/rajiv/ndless/ndless/Ndless-SDK/ndless/bin/../include/os.h:304:1: internal compiler error: in extract_insn, at recog.c:2130 Starting with r188743 I get: ploaderhook.c: In function 'plh_hook': ploaderhook.c:156:1: internal compiler error: in advance_target_bb, at sched-rgn.c:3466 r188741 was OK.
[Bug middle-end/56712] constructor function is called twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56712 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-24 22:21:28 UTC --- Works for me with 4.7/4.8/4.9, and 4.5 and older, but fails with 4.6. The bug was fixed for 4.7.0 by r180700; that change has no BZ PR entry, but the patch submission (http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02486.html) described a scenario involving cloned constructor functions much like this one.
[Bug ada/48835] porting GNAT to m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #55 from Mikael Pettersson mikpe at it dot uu.se 2013-03-22
14:30:23 UTC ---
(In reply to comment #54)
This ICE started with r180192, an ICE fix (PR50780). I don't see anything in
that patch that seems m68k or cc0 related
Actually, r180192 is HIGHLY CC0-related, see PR49847#c16.
Here's an annotated gdb session:
sh-4.2$ gdb /mnt/scratch/objdir47/./gcc/gnat1
GNU gdb (GDB) Brewer Linux (7.4.50.20120120-52.bl17.bl.1)
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as m68k-brewer-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /mnt/scratch/objdir47/gcc/gnat1...done.
(gdb) run -gnatwa -quiet -nostdinc -dumpbase a-calfor.adb -auxbase-strip
a-calfor.o -O2 -Wextra -Wall -fpic -g -mcpu=68060 -gnatpg -mcpu=68060 -gnatO
a-calfor.o a-calfor.adb -o /tmp/ccudsaKf.s
Starting program: /mnt/scratch/objdir47/gcc/gnat1 -gnatwa -quiet -nostdinc
-dumpbase a-calfor.adb -auxbase-strip a-calfor.o -O2 -Wextra -Wall -fpic -g
-mcpu=68060 -gnatpg -mcpu=68060 -gnatO a-calfor.o a-calfor.adb -o
/tmp/ccudsaKf.s
Program received signal SIGSEGV, Segmentation fault.
0x806f7016 in find_comparison_args (code=GE, parg1=0xe218,
parg2=0xe21c, pmode1=0xe220, pmode2=0xe224) at
/mnt/scratch/gcc-4.7-r180192/gcc/cse.c:2975
2975 while (arg2 == CONST0_RTX (GET_MODE (arg1)))
Missing separate debuginfos, use: debuginfo-install
glibc-2.15-58.bl17.bl.1.m68k gmp-5.0.4-1.bl15.bl.2.m68k
libmpc-1.0.1-1.bl17.bl.1.m68k mpfr-3.1.1-1.bl17.bl.1.m68k
zlib-1.2.5-7.bl17.m68k
(gdb) bt
#0 0x806f7016 in find_comparison_args (code=GE, parg1=0xe218,
parg2=0xe21c, pmode1=0xe220, pmode2=0xe224) at
/mnt/scratch/gcc-4.7-r180192/gcc/cse.c:2975
#1 0x806fe620 in record_jump_equiv (taken=optimized out, insn=0xc0a07440) at
/mnt/scratch/gcc-4.7-r180192/gcc/cse.c:3920
#2 cse_extended_basic_block (ebb_data=optimized out) at
/mnt/scratch/gcc-4.7-r180192/gcc/cse.c:6432
#3 cse_main (f=0xc09e3f80, nregs=185) at
/mnt/scratch/gcc-4.7-r180192/gcc/cse.c:6527
#4 0x806fe720 in rest_of_handle_cse () at
/mnt/scratch/gcc-4.7-r180192/gcc/cse.c:7379
#5 0x804ba474 in execute_one_pass (pass=0x8088bc8c) at
/mnt/scratch/gcc-4.7-r180192/gcc/passes.c:2064
#6 0x804ba780 in execute_pass_list (pass=0x8088bc8c) at
/mnt/scratch/gcc-4.7-r180192/gcc/passes.c:2119
#7 0x804ba790 in execute_pass_list (pass=0x80889834) at
/mnt/scratch/gcc-4.7-r180192/gcc/passes.c:2120
#8 0x8057b212 in tree_rest_of_compilation (fndecl=0xc0547600) at
/mnt/scratch/gcc-4.7-r180192/gcc/tree-optimize.c:420
#9 0x8035bb5a in cgraph_expand_function (node=0xc04d3d10) at
/mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:1804
#10 0x8035d3f2 in cgraph_expand_all_functions () at
/mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:1871
#11 cgraph_optimize () at /mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:2168
#12 0x8035d57e in cgraph_finalize_compilation_unit () at
/mnt/scratch/gcc-4.7-r180192/gcc/cgraphunit.c:1312
#13 0x80049b26 in gnat_write_global_declarations () at
/mnt/scratch/gcc-4.7-r180192/gcc/ada/gcc-interface/utils.c:4920
#14 0x8053e70a in compile_file () at
/mnt/scratch/gcc-4.7-r180192/gcc/toplev.c:581
#15 do_compile () at /mnt/scratch/gcc-4.7-r180192/gcc/toplev.c:1930
#16 toplev_main (argc=21, argv=0xe444) at
/mnt/scratch/gcc-4.7-r180192/gcc/toplev.c:2006
#17 0xc012dee8 in __libc_start_main () from /lib/libc.so.6
#18 0x800279a2 in _start ()
(gdb) list
2970
2971 arg1 = *parg1, arg2 = *parg2;
2972
2973 /* If ARG2 is const0_rtx, see what ARG1 is equivalent to. */
2974
2975 while (arg2 == CONST0_RTX (GET_MODE (arg1)))
2976{
2977 /* Set nonzero when we find something of interest. */
2978 rtx x = 0;
2979 int reverse_code = 0;
(gdb) print *parg1
$1 = (rtx) 0x0
We're at the start of find_comparison_args, and *parg1 is NULL. No wonder we
SEGV then at line 2975.
(gdb) up
#1 0x806fe620 in record_jump_equiv (taken=optimized out, insn=0xc0a07440) at
/mnt/scratch/gcc-4.7-r180192/gcc/cse.c:3920
3920 code = find_comparison_args (code, op0, op1, mode0, mode1);
(gdb) list
3915 know that it isn't valid for floating-point. */
3916 code = GET_CODE (XEXP (SET_SRC (set), 0));
3917 op0 = fold_rtx (XEXP (XEXP (SET_SRC (set), 0), 0), insn);
3918 op1 = fold_rtx (XEXP (XEXP (SET_SRC (set), 0), 1), insn);
3919
3920 code = find_comparison_args (code, op0, op1, mode0, mode1);
3921 if (! cond_known_true)
3922{
3923 code = reversed_comparison_code_parts (code, op0, op1, insn);
3924
[Bug middle-end/56657] [GCC 4.6/4.7] ICE - error: unrecognizable insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56657 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-03-20 08:43:05 UTC --- The non-preprocessed test case doesn't ICE for me with gcc-4.7.2 targeting x86_64-w64-mingw32 (so not the same mingw as the reporter is using), with either -m64 or -m32. The preprocessed test case does ICE that compiler with -m32, but not with -m64.
[Bug middle-end/56657] [GCC 4.6/4.7] ICE - error: unrecognizable insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56657 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2013-03-20 09:07:28 UTC --- Created attachment 29698 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29698 reduced test case
[Bug ada/48835] porting GNAT to m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #54 from Mikael Pettersson mikpe at it dot uu.se 2013-03-20 11:05:58 UTC --- Status update: Although gnat is solid enough to rebuild itself with (patched) gcc-4.6 on m68k, there is a regression with (similarly patched) 4.7 that breaks bootstrap: /mnt/scratch/objdir47/./gcc/xgcc -B/mnt/scratch/objdir47/./gcc/ -B/usr/m68k-brewer-linux/bin/ -B/usr/m68k-brewer-linux/lib/ -isystem /usr/m68k-brewer-linux/include -isystem /usr/m68k-brewer-linux/sys-include -c -g -O2 -mcpu=68060 -fpic -W -Wall -gnatpg -nostdinc -mcpu=68060 a-calfor.adb -o a-calfor.o xgcc: internal compiler error: Segmentation fault (program gnat1) Please submit a full bug report, with preprocessed source if appropriate. make[9]: *** [a-calfor.o] Error 4 make[9]: Leaving directory `/mnt/scratch/objdir47/gcc/ada/rts_m68060' make[8]: *** [gnatlib] Error 2 make[8]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[7]: *** [gnatlib-shared-default] Error 2 make[7]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[6]: *** [gnatlib-shared-dual] Error 2 make[6]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[5]: *** [gnatlib-shared] Error 2 make[5]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[4]: *** [gnatlib-shared] Error 2 make[4]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/m68060/libada' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/libada' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir47' make: *** [bootstrap] Error 2 This only occurs when compiling the 68060 variant of the libraries. With multilibs disabled 4.7.3 bootstraps fine w/ Ada. This ICE started with r180192, an ICE fix (PR50780). I don't see anything in that patch that seems m68k or cc0 related, so I suspect it just exposed some latent issue.
[Bug c/56584] _int_free assertion failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56584 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-10 10:14:46 UTC --- I can't reproduce the error with vanilla gcc-4.7.2 running on Fedora 17/x86_64, either natively or in a cross to ARM Cortex-M3.
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-03-08 08:23:31 UTC --- Created attachment 29613 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29613 backport of r183512/PR48308 to 4.6 branch This is the backport I've been using since early June 2012. The original patch required adjustments related to how LOG_LINKS are stored. Tested extensively on x86_64, sparc64, powerpc64, armv5te, and m68k.
[Bug c/56569] When compiling the source insn does not satisfy its constraints:with CFlags as -mcfv4e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56569 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-08 09:25:58 UTC --- gcc-3.4.0 is ancient and hasn't been supported by upstream for years. Please try again with a supported release, e.g. 4.7.2 or 4.6.3. Also, you failed to provide a test case.
[Bug c/56569] When compiling the source insn does not satisfy its constraints:with CFlags as -mcfv4e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56569 --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-03-08 12:19:15 UTC --- The please close this bug report.
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-07 13:37:51 UTC --- I can reproduce the runtime failure on armv5tel-linux-gnueabi with vanilla gcc-4.6.3. Trunk works, as does my heavily patched 4.6-based system compiler. I'll investigate some more later today.
[Bug target/56561] Miscompilation with -Os -arm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56561 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-07 18:14:17 UTC --- The wrong-code on 4.6 branch is stopped by backporting r183512 aka PR48308 fix.
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-03-04 13:24:04 UTC --- The wrong-code with -O3 -fno-tree-coalesce-vars stopped occurring at r190284, Richard Biener's large Allow anonymous SSA names patch. The patch description mentions minor code generation differences, but it doesn't appear to contain actual wrong code fixes so the underlying issue may still be latent on trunk.
[Bug tree-optimization/56501] gcc 4.6 ICE on noreturn function at -Os and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56501 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-03 11:06:24 UTC --- The original ICE stopped occurring for 4.7 in r171450, which added an FRE pass after early SRA. From that point on it reproduces with -Os -fno-tree-free. It then stopped again for 4.8 in r186901, Steven Bosscher's Simplify tree-switch-conversion.c a bit - prep work for gimple switch lowering patch. The ICE in 4.7 occurs because tree-switch-conversion.c:check_process_case calls single_succ on a bb that has NULL succs, leading to a SEGV in VEC_edge_base_index. The patch in r186901 doesn't apply at all to 4.7, and I don't see any obvious bug fix in it that could be cherry-picked and applied to 4.7.
[Bug c/56512] Memory corruption when compiling code with -O on PowerPC when using setjmp/longjmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56512 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-03-03 14:43:40 UTC --- This test case is full of undefined behaviour: - you longjmp out of a frame to an older frame, and then expect to be able to longjmp back into the younger frame; that doesn't work in general - your counter variable isn't volatile (read the C standard on restrictions of auto variables in functions invoking setjmp) Your call_with_cushion() won't do what you think as the auto buffer is dead at the point of the tailcall. Is this a flawed attempt to implement coroutines?
[Bug tree-optimization/56270] loop over array of struct float causes compiler error: segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56270 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-03-03 19:43:14 UTC --- This was fixed for 4.8 by Jan Hubicka's r193175, which rewrote finite_loop_p in tree-ssa-loop-niter.c. That patch doesn't work as-is in 4.7.2 (it applies but uses other things which aren't in 4.7.2.) The SEGV in 4.7.2 occurs in tree-vect-stmts.c:3938 3938 gcc_assert (useless_type_conversion_p (vectype, 3939 TREE_TYPE (vec_oprnd))); because vec_oprnd is NULL at that point.
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-03-03 20:11:08 UTC --- I can reproduce the wrong-code on armv5tel-linux-gnueabi with gcc-4.7-20130302 and gcc-4.6-20121109, but not with gcc-4.8-20130224. I can't reproduce on x86_64, sparc64, aarch64, or m68k.
[Bug target/56513] Wrong code generation with -O3 on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56513 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2013-03-03 23:26:49 UTC --- The wrong-code stopped for 4.8 with r188526, the introduction and enabling of -ftree-coalesce-vars. At that point the wrong-code reappears with -O3 -fno-tree-coalesce-vars, however with current trunk those options give correct code. I'll investigate some more tomorrow.
[Bug libstdc++/56332] libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-02-15 08:39:20 UTC --- For mingw-w64 isn't the triplet supposed to be 'x86_64-w64-mingw32'? Or has the 'old mingw' now grown its own 64-bit support?
[Bug libstdc++/56332] libstdc++-v3 does not support x86_64-pc-mingw64: No support for this host/target combination
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56332 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-02-15 14:09:35 UTC --- Confusing or not, the triplet is as I stated, see e.g.: http://sourceforge.net/apps/trac/mingw-w64/wiki/Answer%20Multilib%20Toolchain And the 32-bit target is 'i686-w64-mingw32' for mingw-w64's 32-bit mode, 'i386-pc-mingw32' is old mingw which is an entirely different entity.
[Bug c/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-02-15 14:19:28 UTC --- The test case causes alignment exceptions for me on armv5tel-linux-gnueabi, when compiled with any one of gcc 4.8, 4.7, or 4.6. Was Sandra's patch ever applied?
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #17 from Mikael Pettersson mikpe at it dot uu.se 2013-02-06
23:23:58 UTC ---
Created attachment 29376
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29376
reduced test case
Please disregard my last two comments, I misread the insn dump and mistook a
note for the invalid concurrent modification of a register.
Thorsten's initial xslt test case, attachment 27325, ICEs 4.6 and 4.7 -with -O2
-fPIC, and 4.8 with just -O2. This new test case is substantially reduced from
the initial one, but it only ICEs 4.8. The ICE occurs when cselib processes
insn 67.
IRA produced
(insn 67 66 69 10 (set (reg/f:SI 52 [ D.1521 ])
(mem/f:SI (post_inc:SI (reg:SI 59 [ ivtmp.11 ])) [3 MEM[base: 0B,
index: ivtmp.11_66, offset: 0B]+0 S4 A16])) pr52306-4.c:44 38 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 59 [ ivtmp.11 ])
(nil)))
with, if I read the dump correctly, reg 52 mapped to %a1 and reg 59 spilled.
Reload then sees fit to reload reg 59 into %a1, resulting in
(insn 67 253 69 10 (set (reg:SI 9 %a1)
(mem/f:SI (post_inc:SI (reg:SI 9 %a1)) [3 MEM[base: 0B, index:
ivtmp.11_66, offset: 0B]+0 S4 A16])) pr52306-4.c:44 38 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 9 %a1)
(nil)))
which uses %a1 both as an auto-inc source pointer and as the dest of the load,
causing the assertion failure in cselib.
The post_inc of reg 59 (%a1) is actually dead, reload added insns to load %a1
from reg 59's spill slot and to increment that memory cell directly. I'm
guessing either reload should not have coalesced reg 59 with reg 52 (due to the
post_inc on reg 59), or it should have cancelled the post_inc when it added the
new insn to increment the spill slot directly.
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se 2013-02-04 15:39:09 UTC --- (In reply to comment #8) Mikael, I tested this on x86_64-linux and sparc64-linux. On x86_64 there were no test suite changes, Thanks for testing this patch. Was the run on x86_64 a bootstrap-and-test? If not, I'll start one now. Both of them were full bootstrap-and-test runs.
[Bug testsuite/56206] New: [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56206 Bug #: 56206 Summary: [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Running the test suite from recent gcc-4.7 snapshots on armv5tel-linux-gnueabi shows the following new test suite failures: ERROR: gcc.target/arm/aapcs/neon-vect1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect2.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect2.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect3.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect3.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect4.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect4.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect5.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect5.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect6.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect6.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect7.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect7.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/neon-vect8.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/neon-vect8.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp1.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp10.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp10.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp11.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp11.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp12.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp12.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp13.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp13.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR: gcc.target/arm/aapcs/vfp14.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok UNRESOLVED: gcc.target/arm/aapcs/vfp14.c: wrong # args: extra words after else clause in if command for dg-require-effective-target 4 arm_hard_vfp_ok ERROR:
[Bug testsuite/56206] [4.7.3 regression] dg-require-effective-target arm_hard_vfp_ok triggers many test suite errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56206 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-02-04 18:33:05 UTC --- Thanks, my test machine is busy currently but I'll check this on Wednesday.
[Bug target/55108] bad compile-time evaluation of members of initialized union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55108 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-02-03 23:24:37 UTC --- On armv5tel-linux-gnueabi this bug is reproducible with gcc-4.6 but not with gcc-4.7 or 4.8. The wrong-code was made latent for 4.7.0 by r179556 aka PR38885, a missed-optimization fix. Bisecting with that fix disabled (a simple #if 0 / #endif wrapper around the new code) showed that the wrong-code was fixed properly for 4.8 by r187648 aka PR53352, a fix for incorrect CSE of unions on ARM. Backporting r187648 to 4.6 fixes this PR's test case with 4.6 on armv5tel. Anyone backporting r187648 to 4.7 or 4.6 should also backport the test case fixup in r187654.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #18 from Mikael Pettersson mikpe at it dot uu.se 2013-01-30 08:53:31 UTC --- gmp-5.0.5 builds and tests Ok on m68k-linux when configured with -ffloat-store in CFLAGS. There is one fcmp;fblt and three fcmp;fbne sequences in the previously failing test case (just the .o file, so excluding libgmp.a). There are 24 fcmps in libgmp.a, but they are all followed by relational conditional jumps, none is followed by an equality/inequality conditional jump. Should I close this as a duplicate of PR323?
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #15 from Mikael Pettersson mikpe at it dot uu.se 2013-01-30
17:34:11 UTC ---
(In reply to comment #1)
The bug, duplicated by compiling attachment 26150 [details], from bug 43437
comment 16,
with a cross-compiler to m68k-elf with -O -c, exposes a reload problem.
Before
reload, we have this insn:
(insn 288 287 290 40 (set (reg/f:SI 124 [ D.1788 ])
(mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.76 ])) [5 MEM[base:
D.1889_285, offset: 0B]+0 S4 A16])) pr52306.c:278 37 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 145 [ ivtmp.76 ])
(nil)))
But isn't this already invalid, as it has both a post_inc and a REG_INC of the
same (reg:SI 145 [ ivtmp.76 ]) operand?
This is produced by the auto_inc_dec pass. Before that we have (175r.fwprop2):
(insn 188 187 190 22 (set (reg/v:SI 76 [ i ])
(plus:SI (reg/v:SI 76 [ i ])
(const_int 1 [0x1]))) pr43437-2.c:222 132 {*addsi3_internal}
(nil))
(insn 190 188 191 22 (set (cc0)
(compare (reg/v:SI 76 [ i ])
(reg/v:SI 68 [ n ]))) pr43437-2.c:222 14 {*m68k.md:486}
(nil))
which auto_inc_dec turns into (176r.auto_inc_dec):
289 r145:SI=r145:SI+0x4
288 r124:SI=[r145:SI]
288 r124:SI=[r145:SI]
found mem(288) *(r[145]+0)
289 r145:SI=r145:SI+0x4
found post inc(289) r[145]+=4
trying SIMPLE_POST_INC
rescanning insn with uid = 288.
deleting insn with uid = 288.
deleting insn with uid = 289.
success 288 r124:SI=[r145:SI++]
REG_INC: r145:SI
...
288 r124:SI=[r145:SI++]
REG_INC: r145:SI
...
(insn 288 287 290 41 (set (reg/f:SI 124 [ D.1812 ])
(mem/f:SI (post_inc:SI (reg:SI 145 [ ivtmp.80 ])) [5 MEM[base:
D.1914_291, offset: 0B]+0 S4 A16])) pr43437-2.c:278 37 {*movsi_m68k2}
(expr_list:REG_INC (reg:SI 145 [ ivtmp.80 ])
(nil)))
Is this valid?
[Bug middle-end/52306] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306
--- Comment #16 from Mikael Pettersson mikpe at it dot uu.se 2013-01-30
17:50:07 UTC ---
Sorry I quoted the wrong fragment from 175r.fwprop, the correct fragment is:
(insn 288 287 289 41 (set (reg/f:SI 124 [ D.1812 ])
(mem/f:SI (reg:SI 145 [ ivtmp.80 ]) [5 MEM[base: D.1914_291, offset:
0B]+0 S4 A16])) pr43437-2.c:278 37 {*movsi_m68k2}
(nil))
(insn 289 288 290 41 (set (reg:SI 145 [ ivtmp.80 ])
(plus:SI (reg:SI 145 [ ivtmp.80 ])
(const_int 4 [0x4]))) pr43437-2.c:278 132 {*addsi3_internal}
(nil))
[Bug rtl-optimization/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-01-30 22:20:19 UTC --- (In reply to comment #5) A more structured version of the patch: After fixing the obvious syntax error + If the label is not marked with a bb, assume it's the same bb. */ + */ I tested this on x86_64-linux and sparc64-linux. On x86_64 there were no test suite changes, on sparc64 I got -FAIL: gcc.dg/pr56035.c (internal compiler error) -FAIL: gcc.dg/pr56035.c (test for excess errors) which is good, but I also got +FAIL: g++.old-deja/g++.pt/memtemp52.C -std=c++11 (test for excess errors) g++.log shows it failed due to an exit 1 from xg++, without diagnostic. Re-running that one test manually doesn't fail so I guess it was just a fluke.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #14 from Mikael Pettersson mikpe at it dot uu.se 2013-01-29 18:03:04 UTC --- The wrong-code occurs in the test wrapper rather than in gmp proper, and the test wrapper does contain a helper function (my_ldexp) which computes and returns 'double'. So the problem might simply be caused by excess precision.
[Bug regression/56131] New: [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 Bug #: 56131 Summary: [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se The recently added gcc.dg/pr56035.c test case fails on sparc-linux: +FAIL: gcc.dg/pr56035.c (internal compiler error) +FAIL: gcc.dg/pr56035.c (test for excess errors) Compiling it with an x86_64-linux to sparc-linux cross-compiler shows: /tmp/objdir/gcc/xgcc -B/tmp/objdir/gcc/ -O1 -ftree-vectorize -fcse-follow-jumps -fstrict-overflow -S pr56035.c pr56035.c: In function 'f': pr56035.c:35:1: internal compiler error: Segmentation fault } ^ 0x70fa9f crash_signal /tmp/gcc-4.8-20130127/gcc/toplev.c:332 0x4cdc96 delete_insn(rtx_def*) /tmp/gcc-4.8-20130127/gcc/cfgrtl.c:151 0x6210a8 delete_related_insns(rtx_def*) /tmp/gcc-4.8-20130127/gcc/jump.c:1243 0x6215e7 redirect_jump_2(rtx_def*, rtx_def*, rtx_def*, int, int) /tmp/gcc-4.8-20130127/gcc/jump.c:1574 0x6216b2 redirect_jump(rtx_def*, rtx_def*, int) /tmp/gcc-4.8-20130127/gcc/jump.c:1533 0x6c4464 dbr_schedule(rtx_def*) /tmp/gcc-4.8-20130127/gcc/reorg.c:3722 0x6c52bf rest_of_handle_delay_slots /tmp/gcc-4.8-20130127/gcc/reorg.c:3891 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. This ICE is different from the one in PR56035. Reverting the PR56035 fix in r195462 makes no difference. gcc-4.7 does not ICE on this test case.
[Bug regression/56131] [4.8 regression] gcc.dg/pr56035.c ICEs gcc on sparc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56131 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-01-28 21:58:49 UTC --- Started with Tom de Vries' Remove dead labels to increase superblock scope patch in r186451: http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00875.html http://gcc.gnu.org/ml/gcc-cvs/2012-04/msg00402.html
[Bug middle-end/56098] conditional write through volatile pointer produces unintended read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56098 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-01-25 08:42:56 UTC --- gcc 3.3.6 to 4.2.4 generate: problem: .LFB2: movqptr(%rip), %rax testl %edi, %edi movl$1, (%rax) je .L4 movl$2, (%rax) .L4: rep ; ret which looks Ok to me. From 4.3.6 up to 4.7.2 we get the broken code Werner showed. 3.2.3 generates different broken code: problem: .LFB1: xorl%eax, %eax movqptr(%rip), %rdx testl %edi, %edi setne %al movl$1, (%rdx) incl%eax movl%eax, (%rdx) ret
[Bug target/56096] Bad code generated for conditional shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56096 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-01-24 08:54:44 UTC --- Bad is ambiguous, it could mean sub-optimal or it could mean incorrect or wrong. In this case it means sub-optimal, please change the PR summary to reflect that.
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-01-24 09:31:20 UTC --- I've checked and gcc-4.6 does miscompile this test case, but gets it right with the PR52573 fix applied. Vanilla gcc-4.7 doesn't seem to miscompile this particular test case, but it still miscompiles the original PR52573 test case. Anyway, I'm certain this PR is a dup of PR52573 so please close it as such.
[Bug target/56087] [m68k] gcc miscompiles pari (multiplication)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56087 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-23 21:15:40 UTC --- (In reply to comment #0) Using the same register twice in muls.l is not permitted. This sounds a lot like PR52573, a patch was proposed in July 2012 and finally approved and committed a few days ago in r195288, see http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00936.html. Can you confirm that Debian's gcc 4.6 lacks the PR52573 fix but its 4.7 does have the fix? If that's not the case, then this must be a different bug that just happens to have symptoms similar to PR52573.
[Bug bootstrap/56001] [4.7 Regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2013-01-22 22:03:13 UTC --- Works now, with gcc-4.7-20130119 on a partially updated system (newer glibc, binutils, system gcc, tcl, expect, dejagnu). Closing.
[Bug target/52911] [4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2013-01-21 17:28:19 UTC --- I can reproduce with a gcc-4.7-20130119 cross from x86_64-linux to ppc-linux, but not with gcc-4.8-20130120. So possibly fixed on trunk.
[Bug target/52911] [4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2013-01-21 18:00:06 UTC --- Let me run a bisection first...
[Bug target/52911] [4.6/4.7/4.8 Regression] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 --- Comment #11 from Mikael Pettersson mikpe at it dot uu.se 2013-01-21 22:52:18 UTC --- This ICE was fixed for 4.8 by Alan Modra's PR53914, rs6000 constraints and reload queries fix in r189801. The ICE described in http://gcc.gnu.org/ml/gcc/2012-07/msg00142.html and the linked-to Red Hat bugzilla entry looks exactly like this PR's ICE. The patch is localized to the rs6000 backend, but it's quite big so I would not be comfortable backporting it en masse to 4.7 branch.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2013-01-21 23:18:34 UTC --- I'm using the ARAnym full-system m68040 emulator -- that's the only realistic option for testing gcc on Linux/m68k at the moment. I maintain my own small Fedora-based distro, so if you like I can supply a disk image with that, plus the scripts and ARAnym parameter files I use. Otherwise you can probably find HOWTOs and pointers to images on the Debian/m68k wiki.
[Bug middle-end/56051] Wrong expression evaluation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56051 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-20 14:11:20 UTC --- Technically the test case should use CHAR_BIT not 8. The bug is present in every release back to at least 2.95.3.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2013-01-17 23:20:26 UTC --- Created attachment 29198 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29198 standalone test case Here's a standalone test case, extracted from gmp's t-get_d.c. It's largish (444 lines) but most of that are support functions needed for the program logic but otherwise unrelated to the wrong-code issue. The wrong-code occurs in check_random() as a side-effect of the inlining of my_ldexp().
[Bug bootstrap/56001] New: [4.7.3 regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001 Bug #: 56001 Summary: [4.7.3 regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Attempting to bootstrap gcc-4.7-20130112 on powepc64-linux fails for me with: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -o cc1 c-lang.o c-family/stub-objc.o attribs.o c-errors.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-objc-common.o c-parser.o tree-mudflap.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o default-c.o rs6000-c.o \ cc1-checksum.o main.o libbackend.a libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/home/mikpe/pkgs/linux-ppc64/gmp-5.0.5/lib -L/home/mikpe/pkgs/linux-ppc64/mpfr-3.1.1/lib -L/home/mikpe/pkgs/linux-ppc64/mpc-1.0.1/lib -lmpc -lmpfr -lgmp -L../zlib -lz libbackend.a(except.o): In function `VEC_uchar_base_splice': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x9238): relocation truncated to fit: R_PPC_REL24 against symbol `memcpy@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o libbackend.a(except.o): In function `VEC_uchar_base_quick_insert': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x92f0): relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o libbackend.a(except.o): In function `VEC_uchar_base_ordered_remove': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x934c): relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o libbackend.a(except.o): In function `VEC_uchar_base_block_remove': /mnt/archive/gcc-4.7-20130112/gcc/vecprim.h:27:(.text+0x93c0): relocation truncated to fit: R_PPC_REL24 against symbol `memmove@@GLIBC_2.0' defined in .plt section in /usr/lib/../lib/crt1.o collect2: ld returned 1 exit status make[3]: *** [cc1] Error 1 make[3]: Leaving directory `/mnt/archive/objdir47/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/mnt/archive/objdir47' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/mnt/archive/objdir47' make: *** [bootstrap] Error 2 On the same machine with the same system toolchain (gcc-4.6.3, binutils-2.22), both the previous 4.7 snapshot (4.7-20130105) and the current 4.8 snapshot (4.8-20130113) bootstrapped fine.
[Bug bootstrap/56001] [4.7 Regression] relocation truncated to fit: R_PPC_REL24 breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56001 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-16 19:47:20 UTC --- (In reply to comment #1) Is your toolchain using BSS PLT? I don't know, it's fairly vanilla. Do you have some test I could run?
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-01-16 20:46:19 UTC --- (In reply to comment #3) Mikael -- can you try adding -fno-rename-registers to the cflags used to compile gmp and see if that changes anything? It'd be greatly appreciated. Done, -fno-rename-registers made no difference with any of 4.6/4.7/4.8.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-12 16:23:55 UTC --- The regression started with Jan Hubicka's Pretty-ipa merge: Inliner heruistics reorg patch in r147852: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00812.html http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00829.html However, that just changed inlining heuristics so most likely it exposed a latent problem. I'll start working on a reduced test case now.
[Bug target/55939] New: [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 Bug #: 55939 Summary: [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Building gmp-5.0.5 for m68k (configure for --host=m68020-unknown-linux), with gcc 4.6, 4.7, or 4.8, and then running gmp's test suite results in: make[4]: Entering directory `/home/mikpe/objdir-gmp/tests/mpq' ... ERROR (check_random test 1): bad mpq_set_d results 3.098073531878046e-120 3.098073531878046e-120 ... 1 of 11 tests failed The failure is 100% repeatable. Building with gcc-4.5.4 instead eliminates the failure, so this is a regression. I don't have a reduced test case yet. I'm going to start a bisection on gcc trunk to hopefully identify when this regression started.
[Bug target/55939] [4.6/4.7/4.8 regression] gcc miscompiles gmp-5.0.5 on m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55939 --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-01-11 20:06:03 UTC --- I cut out one line too many in the build log, it's tests/mpq/t-get_d that fails. On the surface the problem started with Jan Hubicka's Inline heuristic 4/4 patch in r166657: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01305.html http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00546.html However, all that did was to bump the default value of early-inlining-insns from 8 to 10. Compiling gmp with gcc-4.5.4 --param early-inlining-insns=10 also causes tests/mpq/t-get_d to fail, so the real problem is older.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #16 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 10:13:02 UTC --- Something is seriously broken in Philip's environment or his gcc-4.7 build. I get fairly clean g++/libstdc++ test suite results with vanilla 4.7 on Fedora 15/sparc64 + kernel 3.8-rc2, see e.g. http://gcc.gnu.org/ml/gcc-testresults/2013-01/msg00571.html. One thing that differs is that my gcc is configured for 32-bit code by default with the ability to generate 64-bit code when requested (--target=sparc-unknown-linux --with-cpu=ultrasparc --enable-targets=all), whereas I assume that Philip's sparc64 rpms are 64-bit binaries generating 64-bit code by default. I could do a pure 64-bit bootstrap + regtest in a day or two, just to check.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #18 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 10:32:35 UTC --- Yes, the snippet in Comment #14 works fine for me, with both -m32 and -m64.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #26 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 12:42:13 UTC --- (In reply to comment #19) Mikael, could you compare against the versions of packages that I'm using? Well, my environment is Fedora 15 so all system components are older. glibc is 2.13.90-4.1 for instance. The other things that matter for gcc are newer and compiled and installed privately by myself: gmp-5.0.5, mpfr-3.1.1, mpc-1.0.1, binutils-2.22, all compiled by my own gcc-4.6.3. Hurm,.. your build of gcc-4.7.?, was that unmodified or with the slew of RHT patches that the fc* packages normally gets added, applied? That was with unmodified FSF sources (a weekly svn snapshot tarball). Note that RH's gcc src rpms are usually (always?) based on RH's own gcc branches (see http://gcc.gnu.org/viewcvs/branches/redhat/) rather than vanilla upstream releases or snapshots, so the amount of modifications are much larger than what the explicit set of patches indicate.
[Bug target/55909] libtool test exposes what I think is some alignment issue in libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55909 --- Comment #27 from Mikael Pettersson mikpe at it dot uu.se 2013-01-09 12:46:11 UTC --- (In reply to comment #25) Mikael, as reference was your version of 4.7.3 compiled without --enable-initfini-array ? Yes.
[Bug rtl-optimization/52714] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #6 from Mikael Pettersson mikpe at it dot uu.se 2013-01-05 11:57:52 UTC --- Created attachment 29086 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29086 revert gcc 4.6 to gcc 4.5 version of PR45695 fix The ICE is caused by the gcc-4.6 version of the PR45695 fix. That fix was applied in different form to gcc-4.5, and there it doesn't cause any ICE. This patch reverts gcc-4.6 to the gcc-4.5 version of the PR45695 fix, which fixes the ICE with gcc-4.6. Bootstrapped and regression-tested on x86_64, m68k, arm, sparc64, and powerpc64. I still don't know why the 4.6 version of PR45695 causes the ICE, so I don't intend to submit this patch at this time, but at least it could help other m68k users.
[Bug tree-optimization/55883] with -fwrapv, (x 0 -x 0) is assumed to be false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55883 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2013-01-05 20:06:29 UTC --- Fails all the way back to gcc-3.4.6, older releases don't have -fwrapv. Fixed for 4.8 by r193591 == PR55236 fix: http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00538.html http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00707.html The test cases are very very similar so I'd say this is a duplicate of PR55236. Applying r193591 to 4.7 and 4.6 fixes this test case there too.
[Bug target/43961] [ARM thumb] branch out of range with thumb1_output_casesi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43961 --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se 2013-01-03 08:54:35 UTC --- (In reply to comment #8) Mikael, ping on this patch from June 2010 ... what happened in testing? I've included this patch in my local 4.6-based branch since June 2010, and it's tested w/o regressions on armv5te ever since (configured w/o --disable-multilib, so I assume the test suite will also test Thumb-1 not just ARM mode). The patch apparently didn't work in a 4.5-based compiler, but I don't have any notes explaining what the issue was. 4.5 is EOL anyway. Somehow I forgot to forward-port it to 4.7 so I haven't tested it yet in my 4.7-based branch. Will do that asap.
[Bug rtl-optimization/55838] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #2 from Mikael Pettersson mikpe at it dot uu.se 2013-01-01 11:21:05 UTC --- ICEs 4.7.2 and 4.6.3 as described in comment #1. ICEs 4.5.4 down to 4.0.4 with: pr55838.c: In function 'f': pr55838.c:8:1: internal compiler error: in do_SUBST, at combine.c:681 Older releases (3.4.6, 3.3.6, 3.2.3, 2.95.3) don't ICE.
[Bug c/55771] Negation and type conversion incorrectly exchanged
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55771 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2012-12-21 08:59:47 UTC --- With gcc-3.2.3 or 3.3.6 it prints 1.84467e+19 1.84467e+19 on x86_64-linux, with 3.4.6 up to 4.7.2 it prints -3 1.84467e+19 Optimization level doesn't seem to make any difference.
[Bug c/55771] Negation and type conversion incorrectly exchanged
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55771 --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-12-21 10:06:50 UTC --- I'm beginning to think the test case is invalid. The operands of the multiplication in f1 are unsigned long and float, but they are not converted to double. Instead the unsigned long is converted to float (C1x, N1494, 6.3.1.8, 1st paragraph, 2nd Otherwise sub-paragraph), but -3UL is outside the range of a 32-bit float, so the result is undefined (C1x, N1494, 6.3.1.4, 2nd paragraph, last sentence).
[Bug target/54062] extraneous move due to register allocation issue on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54062 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Mikael Pettersson mikpe at it dot uu.se 2012-12-09 10:18:04 UTC --- A recent trunk (r194325) generates identical object code for both functions. I'm assuming the switch to LRA for x86_64 resolved the issue. Closing as fixed.
[Bug rtl-optimization/52714] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2012-12-09 20:22:53 UTC --- Thorsten's test case also ICEs gcc-4.7-20121208 and gcc-4.8 r194325.
