[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #20 from mikpe at it dot uu dot se 2010-09-21 11:30 --- (In reply to comment #19) > Can you provide a .i file for which this is reproducible with a cross > compiler? > > Before/after -fdump-rtl-ira dumps and assembly files could also be helpful. I'm leaving in a couple of minutes on work-related travelling. I'll resume my attempts to convert the miscompiled code to a minimized and standalone test case on thursday. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #18 from mikpe at it dot uu dot se 2010-09-20 22:05 --- It's the 17 line if-for-return block headed by /* Check whether its cheaper to implement a left shift by a constant bit count by a sequence of additions. */ that gets miscompiled by stage1, which makes sense given the observed effects. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #16 from mikpe at it dot uu dot se 2010-09-20 16:37 --- FWIW, exposed on trunk by r160462 (PR44423 fix), backported to 4.5 in r160775. But clearly the issue was latent since the movt patterns were added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #17 from mikpe at it dot uu dot se 2010-09-20 12:40 --- expmed.c:expand_shift () is miscompiled: breaking that function out to a separate source file, compiling it with stage1/xgcc, and relinking stage2/cc1 I get 'lsls', compiling it with the bootstrap gcc and relinking stage2/cc1 I get 'adds'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #8 from mikpe at it dot uu dot se 2010-09-20 12:02 --- r139881 is good. I'll start a bisection. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #6 from mikpe at it dot uu dot se 2010-09-20 10:29 --- Can you do a bisection to identify the exact commit responsible? Looking at the original commit that introduced the movt md pattern (139881) I see a TARGET_USE_MOVT guard in the C code that _should_ prevent it from being selected on non Thumb2-capable CPUs. If these guards are now broken then they need to be fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #15 from mikpe at it dot uu dot se 2010-09-19 16:29 --- The code generation difference originates from `expmed.o'. Using stage1's expmed.o with stage2's other .o files I get 'adds', using stage2's expmed.o with stage1's other .o files I get 'lsls'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #14 from mikpe at it dot uu dot se 2010-09-19 15:30 ---
On the trivial sreal.c test case the dumps (-fdump-rtl-all -fdump-tree-all)
from stage1 and stage2 start to diverge at `150r.expand':
diff -ru dumps1/sreal.c.150r.expand dumps2/sreal.c.150r.expand
--- dumps1/sreal.c.150r.expand 2010-09-19 17:20:07.0 +0200
+++ dumps2/sreal.c.150r.expand 2010-09-19 17:20:36.0 +0200
@@ -26,8 +26,8 @@
(insn 7 6 8 3 (parallel [
(set (reg:DI 137)
-(plus:DI (reg:DI 136)
-(reg:DI 136)))
+(ashift:DI (reg:DI 136)
+(const_int 1 [0x1])))
(clobber (reg:CC 24 cc))
]) sreal.c:3 -1
(nil))
The immediately preceeding dump (149t.optimized) is as follows for both stages:
;; Function normalize (normalize)
normalize (long long unsigned int * sreal_sig)
{
long long unsigned int D.2004;
long long unsigned int D.2003;
:
D.2003_2 = *sreal_sig_1(D);
D.2004_3 = D.2003_2 << 1;
*sreal_sig_1(D) = D.2004_3;
return;
}
I'll try mixing stage1 and stage2 .o files next.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug c/45726] Thumb2 instruction emitted for incompatible CPU
--- Comment #1 from mikpe at it dot uu dot se 2010-09-19 11:15 --- I see the same on arm-linux-gnueabi with 4.6-20100907 and 4.5-20100916. It happens regardless of whether I pass -mcpu=arm9tdmi, -mcpu=armv5tel, or no -mcpu= at all. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #9 from mikpe at it dot uu dot se 2010-09-14 19:40 --- (In reply to comment #8) > With 4.4.2 as base on gcc57 (and your PR45444 patch) I don't see the > comparison > failure: > > http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg01282.html Please try --with-arch=armv5te --with-tune=xscale in the configure options. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)
--- Comment #6 from mikpe at it dot uu dot se 2010-09-09 15:57 --- This ICE stopped to appear on trunk with r162019: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00373.html http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00827.html Applying the generic bits of that to current 4.5 stops the ICE there too. I can't say if r162019 is a genuine bug fix or merely improves things a bit so that this test case no longer triggers the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664
[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)
--- Comment #5 from mikpe at it dot uu dot se 2010-09-09 12:41 --- (In reply to comment #4) > This ICEs for me with 4.4-20100907 and the 4.5.1 release (-m32 -mno-fpu), but > not with 4.5-20100902 or 4.6-20100904. Oops, that was with a locally modified 4.5-20100902. A vanilla 4.5-20100902 still ICEs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664
[Bug target/35664] unable to find a register to spill in class 'FP_REGS' (sparc-linux)
--- Comment #4 from mikpe at it dot uu dot se 2010-09-09 12:06 --- This ICEs for me with 4.4-20100907 and the 4.5.1 release (-m32 -mno-fpu), but not with 4.5-20100902 or 4.6-20100904. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #7 from mikpe at it dot uu dot se 2010-09-09 10:21 ---
It's not a stage2/stage3 debug difference as far as I can tell. I've
recompiled every differing .o file with the stage 1/2/3 xgccs -fcompare-debug
without complaints.
The test case showing the different code generation is trivial (this is in the
objdir for a native bootstrap of r163951):
> cat sreal.c
void normalize(unsigned long long *sreal_sig)
{
*sreal_sig <<= 1;
}
> stage1-gcc/xgcc -Bstage1-gcc -O2 -c sreal.c; objdump -d sreal.o
sreal.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e1c020d0ldrdr2, [r0]
4: e0922002addsr2, r2, r2
8: e0a33003adc r3, r3, r3
c: e1c020f0strdr2, [r0]
10: e12fff1ebx lr
> stage2-gcc/xgcc -Bstage2-gcc -O2 -c sreal.c ; objdump -d sreal.o
sreal.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e1c020d0ldrdr2, [r0]
4: e1b02082lslsr2, r2, #1
8: e0a33003adc r3, r3, r3
c: e1c020f0strdr2, [r0]
10: e12fff1ebx lr
> stage3-gcc/xgcc -Bstage3-gcc -O2 -c sreal.c ; objdump -d sreal.o
sreal.o: file format elf32-littlearm
Disassembly of section .text:
:
0: e1c020d0ldrdr2, [r0]
4: e1b02082lslsr2, r2, #1
8: e0a33003adc r3, r3, r3
c: e1c020f0strdr2, [r0]
10: e12fff1ebx lr
So stage1 chooses adds but stage2 and stage3 choose lsls for << of the lower
half of a long long. Since the behaviour of a stageN xgcc depends on both the
gcc source code and the compiler used to build it, I have to suspect a source
code ambiguity (e.g. evaluation order dependence) that the bootstrap compiler
(gcc-4.4.4 in my case) resolves differently from post-r162417 4.6.
I've so far not been able to reproduce this difference in a cross from i686;
those cross compilers always seem to choose the adds form regardless of the
version of gcc I'm building with.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45482] Bootstrap fails on PPC error: conflicting types for 'malloc'
--- Comment #11 from mikpe at it dot uu dot se 2010-09-08 16:00 --- (In reply to comment #10) > (In reply to comment #9) > > > I have found a cure. > > The original configuration had GMP, MPFR and MPC built and installed under the > user home directory (there were neither mpfr nor mpc system-wide, and gmp was > a > bit old); somehow this is the root cause of the problem, despite --with-gmp > and > friends. > > Building the three packages from source in the GCC source tree gets the > bootstrap process beyond the previous stopping point (currently in middle of > stage 3). > > Maybe this should be added to the platform-specific notes? How did you configure those prebuilt gmp/mpfr/mpc libraries installed under your home directory? In particular, did you configure them all with --disable-shared? If not, then you have to be extremely careful to avoid unintended mismatches, and in some cases incorrectly duplicated state. I know for a fact that prebuilt gmp/mpfr/mpc installed in a private location works fine on powerpc64-linux when all are configured with --disable-shared. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45482
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #6 from mikpe at it dot uu dot se 2010-09-08 12:24 --- The smallest .o file that differs between stage2 and stage3 is sreal.o. Diffing the objdump -d output shows: @@ -1,5 +1,5 @@ -stage2-gcc/sreal.o: file format elf32-littlearm +stage3-gcc/sreal.o: file format elf32-littlearm Disassembly of section .text: @@ -19,7 +19,7 @@ 2c: 01520004cmpeq r2, r4 30: 3a11bcc 7c 34: e5911000ldr r1, [r1] - 38: e0944004addsr4, r4, r4 + 38: e1b04084lslsr4, r4, #1 3c: e0a55005adc r5, r5, r5 40: e1530005cmp r3, r5 44: 01520004cmpeq r2, r4 That is, a single adds became an lsls instead. cfgloopanal.o and tree-ssa-loop-ivcanon.o show the exact same one-instruction adds-became-lsls difference. double-int.o has more elaborate differences: @@ -1,5 +1,5 @@ -stage2-gcc/double-int.o: file format elf32-littlearm +stage3-gcc/double-int.o: file format elf32-littlearm Disassembly of section .text: @@ -427,13 +427,13 @@ 674: e1a0c33clsr ip, ip, r3 678: e58d4018str r4, [sp, #24] 67c: e58d2020str r2, [sp, #32] - 680: e1cd21d8ldrdr2, [sp, #24] - 684: e0922002addsr2, r2, r2 - 688: e58d5024str r5, [sp, #36] ; 0x24 + 680: e58d5024str r5, [sp, #36] ; 0x24 + 684: e1cd21d8ldrdr2, [sp, #24] + 688: e1b02082lslsr2, r2, #1 68c: e0a33003adc r3, r3, r3 - 690: e1cd02d0ldrdr0, [sp, #32] - 694: e1822000orr r2, r2, r0 - 698: e1833001orr r3, r3, r1 + 690: e1cd42d0ldrdr4, [sp, #32] + 694: e1822004orr r2, r2, r4 + 698: e1833005orr r3, r3, r5 69c: e58ab000str fp, [sl] 6a0: e58ac004str ip, [sl, #4] 6a4: e1c820f0strdr2, [r8] I'll try to extract a test case from one of these. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
--- Comment #6 from mikpe at it dot uu dot se 2010-09-08 10:16 --- (In reply to comment #5) > I can't get this to ICE with latest version of 4.4, 4.5 or 4.6 branches. The default_secondary_reload ICE is on a gcc_assert() so you must configure with --enable-checking; --enable-checking=release is sufficient. You also need to target Thumb-1 not Thumb-2; -march=armv5te suffices. The gen_thumb_movhi_clobber ICE is a gcc_unreachable() in a pattern guarded by TARGET_THUMB1, so you must target Thumb-1 not Thumb-2; -march=armv5te suffices. I just reproduced the first with 4.4-20100907 and 4.5-20100902, and the second with 4.5-20100902. I didn't check 4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[Bug rtl-optimization/45593] ICE on Sparc with -Os
--- Comment #2 from mikpe at it dot uu dot se 2010-09-08 09:30 --- I can reproduce the ICE on sparc64-linux with 4.5-20100902 and 4.6-20100904 -Os -m32. With -m64 or -O1/O2/O3 it doesn't ICE. 4.4-20100817 doesn't ICE. -- mikpe at it dot uu dot se changed: What|Removed |Added CC| |mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45593
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #5 from mikpe at it dot uu dot se 2010-09-07 22:26 --- (In reply to comment #3) > I'm currently checking if latest trunk (r163951) is still broken. It is. I'll try to come up with a cross-compiler friendly test case tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #3 from mikpe at it dot uu dot se 2010-09-07 14:25 --- This set of bootstrap comparison failures were introduced by r162418: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00772.html It's been a pain to bisect because pretty much every week between then and now there's been some other bootstrap-breaking bug masking this one. I'm currently checking if latest trunk (r163951) is still broken. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug target/45559] [4.4 regression] wrong conversion from unsigned int/long to float
--- Comment #3 from mikpe at it dot uu dot se 2010-09-07 10:15 --- Well then, the bug is not in gcc but in the Linux kernel's math emulation code. You need to update your kernel to one that includes the fix. The fix is commit f8324e20f8289dffc646d64366332e05eaacab25 in Linus' tree, and there is a link to the original patch in PR44631. It should also be in the official stable 2.6 kernels by now, but I wouldn't know how those relate to Debian's kernels. Could the original bug reporter please close this PR as a dupe of PR44631. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
--- Comment #7 from mikpe at it dot uu dot se 2010-09-06 21:05 --- (In reply to comment #5) > /mnt/scratch/objdir/./gcc/xgcc -B/mnt/scratch/objdir/./gcc/ > -B/mnt/scratch/install/sparc64-unknown-linux-gnu/bin/ > -B/mnt/scratch/install/sparc64-unknown-linux-gnu/lib/ -isystem > /mnt/scratch/install/sparc64-unknown-linux-gnu/include -isystem > /mnt/scratch/install/sparc64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2 > -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes > -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g > -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. > -I../../.././gcc -I/mnt/scratch/gcc-4.6-r163858/libgcc > -I/mnt/scratch/gcc-4.6-r163858/libgcc/. > -I/mnt/scratch/gcc-4.6-r163858/libgcc/../gcc > -I/mnt/scratch/gcc-4.6-r163858/libgcc/../include > -I/mnt/scratch/gcc-4.6-r163858/libgcc/../libdecnumber/dpd > -I/mnt/scratch/gcc-4.6-r163858/libgcc/../libdecnumber -DHAVE_CC_TLS -o > _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c > /mnt/scratch/gcc-4.6-r163858/libgcc/../gcc/libgcc2.c \ > -fvisibility=hidden -DHIDE_EXPORTS > /mnt/scratch/gcc-4.6-r163858/libgcc/../gcc/libgcc2.c: In function '__muldi3': > /mnt/scratch/gcc-4.6-r163858/libgcc/../gcc/libgcc2.c:558:1: internal compiler > error: in find_mem_expr_in_1pdv, at var-tracking.c:4120 > > I haven't attempted to bisect this yet. Bisection identified r163383, Bernd's 4-insn combine patch, as the cause for this regression. However, it got fixed today by r163917, Andreas Krebbel's fix for an s390x regression from r163383. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug target/45559] [4.4 regression] wrong conversion from unsigned int/long to float
--- Comment #1 from mikpe at it dot uu dot se 2010-09-06 17:15 --- Dupe of PR44631? -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45559
[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
--- Comment #5 from mikpe at it dot uu dot se 2010-09-05 10:07 ---
(In reply to comment #4)
> Subject: Re: [4.6 regression] bootstrap failure on
> sparc64-unknown-linux-gnu
>
> On Sat, Sep 04, 2010 at 01:38:34PM -0000, mikpe at it dot uu dot se wrote:
> > Can you show us the complete configure options you used?
>
> gcc63 is down at the moment for scheduled maintenance, so I can't quote
> exactly. As best I can recall, it was:
>
> CC='gcc -m64' /path/to/configure --disable-lib{mudflap,ssp,gomp} \
> --enable-languages=c --disable-nls --enable-threads=posix \
> --with-mpfr=/opt/cfarm/mpfr-2.4.1-64 \
> --with-gmp=/opt/cfarm/gmp-4.2.4-64 --with-mpc=/opt/cfarm/mpc-0.8-64
This is similar (modulo paths) to what I tried unsuccessfully to do. The
problem was the "CC='gcc -m64'" override; somehow that caused the stage2
attempt to configure 32-bit zlib to fail because it passed a completely bogus
path to prev-gcc as CC. The same error occurred when trying to build a pure
64-bit gcc-4.5.1, but it did work for building a 64-bit gcc-4.4.4.
I then used my 64-bit 4.4.4 to build a 64-bit 4.5.1 (just setting PATH, not
CC), and then the 64-bit 4.5.1 to build a 64-bit 4.6-r163858. The last build
ICEd in stage2 when trying to build a 32-bit _muldi3 for libgcc:
/mnt/scratch/objdir/./gcc/xgcc -B/mnt/scratch/objdir/./gcc/
-B/mnt/scratch/install/sparc64-unknown-linux-gnu/bin/
-B/mnt/scratch/install/sparc64-unknown-linux-gnu/lib/ -isystem
/mnt/scratch/install/sparc64-unknown-linux-gnu/include -isystem
/mnt/scratch/install/sparc64-unknown-linux-gnu/sys-include-g -O2 -m32 -O2
-g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I.
-I../../.././gcc -I/mnt/scratch/gcc-4.6-r163858/libgcc
-I/mnt/scratch/gcc-4.6-r163858/libgcc/.
-I/mnt/scratch/gcc-4.6-r163858/libgcc/../gcc
-I/mnt/scratch/gcc-4.6-r163858/libgcc/../include
-I/mnt/scratch/gcc-4.6-r163858/libgcc/../libdecnumber/dpd
-I/mnt/scratch/gcc-4.6-r163858/libgcc/../libdecnumber -DHAVE_CC_TLS -o
_muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c
/mnt/scratch/gcc-4.6-r163858/libgcc/../gcc/libgcc2.c \
-fvisibility=hidden -DHIDE_EXPORTS
/mnt/scratch/gcc-4.6-r163858/libgcc/../gcc/libgcc2.c: In function '__muldi3':
/mnt/scratch/gcc-4.6-r163858/libgcc/../gcc/libgcc2.c:558:1: internal compiler
error: in find_mem_expr_in_1pdv, at var-tracking.c:4120
I haven't attempted to bisect this yet.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #13 from mikpe at it dot uu dot se 2010-09-04 16:19 --- For the record, the original ICE in this PR was fixed by r162784: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01138.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug bootstrap/45518] [4.6 regression] bootstrap failure on sparc64-unknown-linux-gnu
--- Comment #3 from mikpe at it dot uu dot se 2010-09-04 13:38 --- Can you show us the complete configure options you used? I'm trying to build gcc-4.6 for sparc64-linux w/o --with-cpu=v8 (so it defaults to 64-bit mode) and I can't get past an error after stage1 where it tries to configure a 32-bit zlib but passes the wrong path to prev-gcc. -- mikpe at it dot uu dot se changed: What|Removed |Added CC| |mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45518
[Bug bootstrap/45445] [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
--- Comment #2 from mikpe at it dot uu dot se 2010-09-02 20:55 --- (In reply to comment #1) > With r163667 and fixes for PR45444 applied I don't see issues with a v7-a > bootstrap. Can we see if a later version works for you ? With r163777 and the proposed PR45444 fix applied I still get the same bootstrap comparison failures after stage3 as before. Your v7-a build probably triggers different code generation paths than my armv5te with xscale tuning build. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #5 from mikpe at it dot uu dot se 2010-09-02 12:00 --- Patch has been posted: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00048.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #31 from mikpe at it dot uu dot se 2010-08-30 18:59 --- (In reply to comment #30) > A regression but no known-to-work version? 4.2.4 is known to work. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091#c5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug debug/45447] ICE with `-g -femit-struct-debug-baseonly'
--- Comment #1 from mikpe at it dot uu dot se 2010-08-30 11:12 --- It also ICEs current gcc-4.4 and gcc-4.6. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45447
[Bug bootstrap/45445] New: [4.6 regression] ARM bootstrap failure: comparison failures after stage 3
Attempting to bootstrap gcc-4.6-20100828 on armv5tel-linux-gnueabi, after
applying the preliminary fixes for PR45444, fails with comparison failures
after stage 3:
make[3]: Leaving directory `/home/mikpe/objdir46'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/lto-cgraph.o differs
gcc/value-prof.o differs
gcc/expr.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/lto-streamer-out.o differs
gcc/stor-layout.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/loop-iv.o differs
gcc/double-int.o differs
gcc/expmed.o differs
gcc/dbxout.o differs
gcc/tree.o differs
gcc/sreal.o differs
gcc/cfgloopanal.o differs
gcc/explow.o differs
libcpp/expr.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/mikpe/objdir46'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/mikpe/objdir46'
make: *** [bootstrap] Error 2
This looks almost identical to the failure in the presumed-fixed PR45162.
Configured with:
/home/mikpe/gcc-4.6-20100828/configure --enable-bootstrap --enable-shared
--enable-threads=posix --enable-checking=release --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c
--enable-java-awt=gtk --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-brewer-linux-gnueabi
--with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin
--disable-lto --disable-libmudflap
--
Summary: [4.6 regression] ARM bootstrap failure: comparison
failures after stage 3
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
[Bug bootstrap/45444] [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
--- Comment #1 from mikpe at it dot uu dot se 2010-08-29 16:26 --- Created an attachment (id=21586) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21586&action=view) preliminary fixes for arm.c stage2 errors This gets me past the arm.c stage2 errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug bootstrap/45444] New: [4.6 regression] ARM bootstrap failure: uninitialized const member in 'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
Attempting to bootstrap gcc-4.6-20100828 on armv5tel-linux-gnueabi fails in
stage 2 with:
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c: In function
'arm_get_pcs_model':
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:3725:7: error: passing
argument 1 of 'stdarg_p' discards 'const' qualifier from pointer target type
[-Werror]
/home/mikpe/gcc-4.6-20100828/gcc/tree.h:4851:13: note: expected 'tree' but
argument is of type 'const_tree'
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c: In function
'locate_neon_builtin_icode':
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error:
uninitialized const member in 'neon_builtin_datum' is invalid in C++
[-Werror=c++-compat]
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17969:20: note: 'itype'
should be initialized
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error: in
'neon_builtin_datum' is invalid in C++ [-Werror=c++-compat]
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17970:13: note: 'bits' should
be initialized
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error:
uninitialized const member in 'neon_builtin_datum' is invalid in C++
[-Werror=c++-compat]
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17971:24: note: 'codes'
should be initialized
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:18913:22: error:
uninitialized const member in 'neon_builtin_datum' is invalid in C++
[-Werror=c++-compat]
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:17972:22: note: 'num_vars'
should be initialized
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c: In function
'arm_output_asm_insn':
/home/mikpe/gcc-4.6-20100828/gcc/config/arm/arm.c:22649:3: error: function
might be possible candidate for 'gnu_printf' format attribute
[-Werror=missing-format-attribute]
cc1: all warnings being treated as errors
make[3]: *** [arm.o] Error 1
make[3]: Leaving directory `/home/mikpe/objdir46/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/home/mikpe/objdir46'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/mikpe/objdir46'
make: *** [bootstrap] Error 2
The first error in arm_ge_pcs_model () was reported 11 days ago as PR45321.
The other 'uninitialized const member' warnings/errors are new since then. I
can't see any obvious recent changes in arm.c that would explain them, so I
suspect they're caused by some C front-end change.
--
Summary: [4.6 regression] ARM bootstrap failure: uninitialized
const member in 'neon_builtin_datum' is invalid in C++
[-Werror=c++-compat]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45444
[Bug rtl-optimization/45416] Code size regression between 4.6(4.5) and 4.4 for ARM
--- Comment #5 from mikpe at it dot uu dot se 2010-08-26 21:13 --- The code size regression on ARM is caused by r146817, Matz' expand from SSA patch: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html Here's the diff in the assembly code generated by a cross to armv5tel-linux-gnueabi, with -Os -S, for r146816 and r146817: --- pr45316.s-r146816 2010-08-26 23:00:18.0 +0200 +++ pr45316.s-r146817 2010-08-26 23:03:24.0 +0200 @@ -17,8 +17,13 @@ @ args = 0, pretend = 0, frame = 0 @ frame_needed = 0, uses_anonymous_args = 0 @ link register save eliminated. - mov r0, r0, lsr #10 - and r0, r0, #1 + mov r2, #1024 + mov r3, #0 + and r2, r2, r0 + and r3, r3, r1 + orrsr1, r2, r3 + moveq r0, #0 + movne r0, #1 bx lr .size foo, .-foo .ident "GCC: (GNU) 4.5.0 20090426 (experimental)" My cross was configured: ../gcc-4.5-r146817/configure --target=armv5tel-unknown-linux-gnueabi --with-arch=armv5te --with-tune=xscale --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-multilib --enable-threads=posix --enable-checking=release --enable-languages=c -- mikpe at it dot uu dot se changed: What|Removed |Added CC||matz at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416
[Bug c/45416] Code size regression between 4.6(4.5) and 4.4 for ARM
--- Comment #4 from mikpe at it dot uu dot se 2010-08-26 14:01 --- (In reply to comment #3) > I found I can reproduce the bug with ARM I see this too on armv5tel-linux-gnueabi. gcc-4.4.4 -Os generates 3 instructions for the body of foo(), 4.5.1 and 4.6.0 generate 8 instructions. -- mikpe at it dot uu dot se changed: What|Removed |Added CC| |mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45416
[Bug target/44999] "and r0, r0, #255" can be replace with uxtb in thumb2
--- Comment #3 from mikpe at it dot uu dot se 2010-08-21 17:28 --- Didn't Carrot's r163184 fix this PR and its dupe PR43461? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44999
[Bug middle-end/45364] Compiling wine's directx.c with -O1 -g takes a very long time
--- Comment #5 from mikpe at it dot uu dot se 2010-08-21 15:44 --- (In reply to comment #4) > Well something in -g processing is a CPU hog. On my Turion X2 Ultra ZM-82 > laptop (2.2GHz x 2 cores) with 32-bit kernel and vanilla gcc-4.5.1 > (--enable-checking=release) I get: Same machine, but running a 64-bit kernel and using a 64-bit gcc-4.5.1: > time gcc -m32 -O0 -c pr45364.i 1.390u 0.090s 0:01.49 99.3% 0+0k 0+0io 0pf+0w > time gcc -m32 -O0 -g -c pr45364.i 1.630u 0.060s 0:01.71 98.8% 0+0k 0+0io 0pf+0w > time gcc -m32 -O1 -c pr45364.i 3.690u 0.090s 0:03.80 99.4% 0+0k 0+0io 0pf+0w > time gcc -m32 -O1 -g -c pr45364.i 26.740u 0.230s 0:27.00 99.8%0+0k 0+0io 0pf+0w > time gcc -m32 -O2 -c pr45364.i 10.960u 0.220s 0:11.52 97.0%0+0k 0+0io 0pf+0w > time gcc -m32 -O2 -g -c pr45364.i 291.430u 0.540s 4:52.15 99.9% 0+0k 0+0io 0pf+0w In the last -O2 -g run cc1 used about 344MB of address space. So it doesn't take forever but -g is definitely a CPU hog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45364
[Bug middle-end/45364] Compiling wine's directx.c with -O1 -g takes a very long time
--- Comment #4 from mikpe at it dot uu dot se 2010-08-21 14:36 --- Well something in -g processing is a CPU hog. On my Turion X2 Ultra ZM-82 laptop (2.2GHz x 2 cores) with 32-bit kernel and vanilla gcc-4.5.1 (--enable-checking=release) I get: > time gcc -m32 -O0 -c pr45364.i 1.220u 0.120s 0:01.35 99.2% 0+0k 0+0io 0pf+0w > time gcc -m32 -O0 -g -c pr45364.i 1.500u 0.060s 0:01.57 99.3% 0+0k 0+0io 0pf+0w > time gcc -m32 -O1 -c pr45364.i 3.100u 0.100s 0:03.21 99.6% 0+0k 0+0io 0pf+0w > time gcc -m32 -O1 -g -c pr45364.i 22.590u 0.190s 0:22.81 99.8%0+0k 0+0io 0pf+0w > time gcc -m32 -O2 -c pr45364.i 8.680u 0.210s 0:08.93 99.5% 0+0k 0+0io 0pf+0w > time gcc -m32 -O2 -g -c pr45364.i 238.490u 0.340s 3:58.97 99.9% 0+0k 0+0io 0pf+0w During the last -O2 -g run I ran top and cc1 only used about 200MB, so swapping is not the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45364
[Bug bootstrap/45321] [4.6 regression] ARM bootstrap failure due to stdarg_p change
--- Comment #1 from mikpe at it dot uu dot se 2010-08-18 15:43 --- Created an attachment (id=21511) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21511&action=view) proposed fix The issue is that stdarg_p has a non-const parameter but the call site in the ARM backend has a const value it wants to pass. The right solution seems to be to make stdarg_p accept a const parameter, but then the problem is that the parameter is stored in the iterator's fntype field. Nothing uses that field, so removing it and then making the parameter const fixes the issue. ARM bootstrap still fails for me with comparison failures, however. (I'm in an email black hole at the moment so can't easily submit this to gcc-patches.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug bootstrap/45321] New: [4.6 regression] ARM bootstrap failure due to stdarg_p change
Attempting to bootstrap gcc-4.6-20100814 (r163252) on arm-linux-gnueabi fails due to a warning in stage2 and the default use of -Werror there: /home/mikpe/gcc-4.6-20100814/gcc/config/arm/arm.c: In function 'arm_get_pcs_model': /home/mikpe/gcc-4.6-20100814/gcc/config/arm/arm.c:3720:7: error: passing argument 1 of 'stdarg_p' discards 'const' qualifier from pointer target type [-Werror] /home/mikpe/gcc-4.6-20100814/gcc/tree.h:4829:13: note: expected 'tree' but argument is of type 'const_tree' cc1: all warnings being treated as errors make[3]: *** [arm.o] Error 1 make[3]: Leaving directory `/home/mikpe/objdir46/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/mikpe/objdir46' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/mikpe/objdir46' make: *** [bootstrap] Error 2 Presumably caused by r163033: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00244.html -- Summary: [4.6 regression] ARM bootstrap failure due to stdarg_p change Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC host triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45321
[Bug libstdc++/45300] in cstdio/cstdlib keyword restrict is used instead of __restrict
--- Comment #11 from mikpe at it dot uu dot se 2010-08-17 13:01 ---
Should libstdc++-v3/include/{c_global,c_std}/cwchar also get the restrict ->
__restrict treatment?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45300
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #9 from mikpe at it dot uu dot se 2010-08-07 11:59 --- (In reply to comment #8) > As of r162787 bootstrap goes a bit further then fails on compare in > stage3-bubble: > > Comparing stages 2 and 3 > warning: gcc/cc1-checksum.o differs > Bootstrap comparison failure! > gcc/tree-vect-data-refs.o differs > make[2]: *** [compare] Error 1 > make[2]: Leaving directory `/home/guerby/build' > make[1]: *** [stage3-bubble] Error 2 > make[1]: Leaving directory `/home/guerby/build' > make: *** [bootstrap] Error 2 > > Let me know if I should open a new report. That's the now fixed PR45162. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler
--- Comment #5 from mikpe at it dot uu dot se 2010-08-04 22:15 --- Created an attachment (id=21398) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21398&action=view) preprocessed source for _udivmoddi4 In non-parallel builds _udivmoddi4 is always the first module to make cc1 run out of memory. I get the error on both i686 and x86_64 hosts, and with both gcc-4.4.4 and gcc-4.3.5 as bootstrap compilers (only tried 4.3.5 on i686 though). I did use --with-arch=armv5te --with-tune=xscale when configuring my compiler, which may be relevant as it changes instruction selection defaults. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45177
[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3
--- Comment #10 from mikpe at it dot uu dot se 2010-08-04 20:13 --- Bernd's patch fixes the -fcompare-debug failures in my arm cross-compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler
--- Comment #3 from mikpe at it dot uu dot se 2010-08-04 20:06 --- It's caused by r162815: http://gcc.gnu.org/ml/gcc-cvs/2010-08/msg00026.html The build failure still occurs with r162878. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45177
[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3
--- Comment #6 from mikpe at it dot uu dot se 2010-08-04 12:27 --- The -O2 -fcompare-debug failure on ARM is caused by r162678: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg01032.html Both the original large testcase and the reduced one compile fine with gcc-4.6-r162677 -O2 -fcompare-debug, but fail with r162678. I haven't checked more recent revisions yet due to PR45177. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||bernds at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
[Bug bootstrap/45177] [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler
--- Comment #2 from mikpe at it dot uu dot se 2010-08-04 10:01 ---
Attaching gdb after cc1 just passed 2.5 G virtual:
0x080c0c93 in pool_alloc (pool=0xa45d708) at
/tmp/gcc-4.6-r162856/gcc/alloc-pool.c:252
252 {
Missing separate debuginfos, use: debuginfo-install glibc-2.10.2-1.i686
(gdb) bt
#0 0x080c0c93 in pool_alloc (pool=0xa45d708) at
/tmp/gcc-4.6-r162856/gcc/alloc-pool.c:252
#1 0x0812091e in df_ref_create_structure (cl=DF_REF_REGULAR,
collection_rec=,
reg=0xb757a1c0, loc=0xb734d814, bb=0xb7534400, info=0xa46b930,
ref_type=DF_REF_REG_MEM_STORE,
ref_flags=0, width=-1, offset=-1, mode=VOIDmode) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:2802
#2 0x08120a8c in df_ref_record (cl=,
collection_rec=,
reg=, loc=0xb734d814, bb=0xb7534400,
insn_info=0xa46b930,
ref_type=DF_REF_REG_MEM_STORE, ref_flags=0, width=-1, offset=-1,
mode=VOIDmode)
at /tmp/gcc-4.6-r162856/gcc/df-scan.c:2928
#3 0x081210d7 in df_uses_record (cl=,
collection_rec=,
loc=, ref_type=DF_REF_REG_MEM_STORE, bb=0xb7534400,
insn_info=0xa46b930,
flags=0, width=-1, offset=-1, mode=VOIDmode) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:3159
#4 0x081219d7 in df_insn_refs_collect (collection_rec=,
bb=, insn_info=0x1f68fb8) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:3571
#5 0x08121f3a in df_insn_refs_verify (collection_rec=0xbfb95d50, bb=0x7,
insn=,
abort_if_fail=0 '\0') at /tmp/gcc-4.6-r162856/gcc/df-scan.c:4466
#6 0x081222b6 in df_insn_rescan (insn=0x13e97828) at
/tmp/gcc-4.6-r162856/gcc/df-scan.c:1260
#7 0x0826d4f3 in peep2_update_life (prev=, last=,
match_len=, bb=) at
/tmp/gcc-4.6-r162856/gcc/recog.c:3313
#8 peephole2_optimize (prev=, last=,
match_len=, bb=) at
/tmp/gcc-4.6-r162856/gcc/recog.c:3441
#9 rest_of_handle_peephole2 (prev=, last=,
match_len=, bb=) at
/tmp/gcc-4.6-r162856/gcc/recog.c:3619
#10 0x082534cb in execute_one_pass (pass=0x8863640) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1564
#11 0x0825374d in execute_pass_list (pass=0x8863640) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1619
#12 0x08253760 in execute_pass_list (pass=0x88634e0) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1620
#13 0x08253760 in execute_pass_list (pass=0x88634a0) at
/tmp/gcc-4.6-r162856/gcc/passes.c:1620
#14 0x0831f87a in tree_rest_of_compilation (fndecl=0xb74dc400)
at /tmp/gcc-4.6-r162856/gcc/tree-optimize.c:452
#15 0x0844c02f in cgraph_expand_function (node=)
at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1643
#16 0x0844d201 in cgraph_expand_all_functions () at
/tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1722
#17 cgraph_optimize () at /tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1978
#18 0x0844da15 in cgraph_finalize_compilation_unit () at
/tmp/gcc-4.6-r162856/gcc/cgraphunit.c:1185
#19 0x08056f9c in c_write_global_declarations () at
/tmp/gcc-4.6-r162856/gcc/c-decl.c:9698
#20 0x082e2324 in compile_file () at /tmp/gcc-4.6-r162856/gcc/toplev.c:957
#21 do_compile () at /tmp/gcc-4.6-r162856/gcc/toplev.c:2295
#22 toplev_main () at /tmp/gcc-4.6-r162856/gcc/toplev.c:2336
#23 0x080baeeb in main (argc=62, argv=0xbfb96134) at
/tmp/gcc-4.6-r162856/gcc/main.c:36
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45177
[Bug bootstrap/45177] New: [4.6 regression] cc1 runs out of memory building libgcc in ARM cross-compiler
Attempting to build gcc-4.6 r162856 (head as of a few minutes ago) on
i686-linux as a cross to armv5tel-linux-gnueabi fails with cc1 running out of
memory:
/tmp/objdir/./gcc/xgcc -B/tmp/objdir/./gcc/
-B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/bin/
-B/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/lib/
-isystem
/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/include
-isystem
/home/mikpe/pkgs/linux-x86/cross-armv5tel/armv5tel-unknown-linux-gnueabi/sys-include
-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fPIC -Wno-missing-prototypes -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I. -I../.././gcc -I/tmp/gcc-4.6-r162856/libgcc -I/tmp/gcc-4.6-r162856/libgcc/.
-I/tmp/gcc-4.6-r162856/libgcc/../gcc -I/tmp/gcc-4.6-r162856/libgcc/../include
-DHAVE_CC_TLS -o _udivmoddi4.o -MT _udivmoddi4.o -MD -MP -MF _udivmoddi4.dep
-DL_udivmoddi4 -c /tmp/gcc-4.6-r162856/libgcc/../gcc/libgcc2.c \
-fexceptions -fnon-call-exceptions
cc1: out of memory allocating 171803424 bytes after a total of 46485504 bytes
make[2]: *** [_udivmoddi4.o] Error 1
make[2]: Leaving directory `/tmp/objdir/armv5tel-unknown-linux-gnueabi/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/tmp/objdir'
make: *** [all] Error 2
This happend twice in a row now. Repeating it a third time and watching the
process with 'top' I see that cc1 grows to somewhere over 2.5 GB virtual before
dying. The machine has 6 GB of RAM and 4 GB of swap, but it didn't start
swapping before cc1 died.
4.6-20100731 (r162788) did not have this problem.
Full configuration line:
/tmp/gcc-4.6-r162856/configure --target=armv5tel-unknown-linux-gnueabi
--with-arch=armv5te --with-tune=xscale
--prefix=/home/mikpe/pkgs/linux-x86/cross-armv5tel
--with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.8.2 --disable-plugin --disable-lto
--disable-nls --disable-shared --disable-libmudflap --disable-multilib
--enable-threads=posix --enable-checking=release --enable-languages=c
--
Summary: [4.6 regression] cc1 runs out of memory building libgcc
in ARM cross-compiler
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45177
[Bug rtl-optimization/45162] [4.6 regression] ARM bootstrap comparison failures after stage 3
--- Comment #4 from mikpe at it dot uu dot se 2010-08-03 21:12 --- Created an attachment (id=21381) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21381&action=view) reduced test case Here is a 66-line test case, reduced from Ramana's preprocessed source, that reliably fails -fcompare-debug when compiled by a gcc-4.6-20100731 cross to armv5tel-linux-gnueabi hosted on i686-linux. Diffing the disassembled object code for -g0 and -g shows: @@ -1,5 +1,5 @@ -pr45162.o.g0: file format elf32-littlearm +pr45162.o.g: file format elf32-littlearm Disassembly of section .text: @@ -57,6 +57,7 @@ c4: e1943005orrsr3, r4, r5 c8: e1a7mov r0, r7 cc: 01a04008moveq r4, r8 - d0: ebfebl 0 - d4: e5804004str r4, [r0, #4] - d8: ead0b 20 + d0: 03a05000moveq r5, #0 ; 0x0 + d4: ebfebl 0 + d8: e5804004str r4, [r0, #4] + dc: eacfb 20 My cross was configured: /tmp/gcc-4.6-20100731/configure --target=armv5tel-unknown-linux-gnueabi --with-arch=armv5te --with-tune=xscale --prefix=/home/mikpe/pkgs/linux-x86/cross-armv5tel --with-gmp=/home/mikpe/pkgs/linux-x86/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-x86/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-x86/mpc-0.8.2 --disable-plugin --disable-lto --disable-nls --disable-shared --disable-libmudflap --disable-multilib --enable-threads=posix --enable-checking=release --enable-languages=c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
[Bug bootstrap/45162] New: [4.6 regression] ARM bootstrap comparison failures after stage 3
Attempting to bootstrap gcc-4.6-20100731 (r162788) on armv5tel-linux-gnueabi
fails due to bootstrap comparison failures after stage 3:
make[3]: Leaving directory `/home/mikpe/objdir46'
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/lto-cgraph.o differs
gcc/value-prof.o differs
gcc/tree-vect-data-refs.o differs
gcc/expr.o differs
gcc/tree-ssa-loop-ivopts.o differs
gcc/lto-streamer-out.o differs
gcc/stor-layout.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/loop-iv.o differs
gcc/double-int.o differs
gcc/expmed.o differs
gcc/dbxout.o differs
gcc/tree.o differs
gcc/sreal.o differs
gcc/cfgloopanal.o differs
gcc/explow.o differs
libcpp/expr.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/mikpe/objdir46'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/mikpe/objdir46'
make: *** [bootstrap] Error 2
Target: armv5tel-brewer-linux-gnueabi
Configured with: /home/mikpe/gcc-4.6-20100731/configure --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk
--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-brewer-linux-gnueabi
--with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin
--disable-lto --disable-libmudflap
--
Summary: [4.6 regression] ARM bootstrap comparison failures after
stage 3
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: armv5tel-unknown-linux-gnueabi
GCC host triplet: armv5tel-unknown-linux-gnueabi
GCC target triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45162
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code
--- Comment #15 from mikpe at it dot uu dot se 2010-07-28 23:31 --- Richard's proposed fix appears to need the PR44284 fix to avoid regressing vect-20.c, much like PR44828 also needed PR44284 to not regress vectorization tests. Current 4.5 has PR44284 backported, so the PR45034 fix works there. I did a preliminary backport of the first PR44284 fix to 4.4, and that solved the vect-20.c regression but caused a couple of regressions of its own. I'll try backporting the followup fixes too, but I suspect the rational conclusion will be to not backport the PR45034 fix, or to backport it with an adjustment to vect-20.c to expect the reduced vectorization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug tree-optimization/45109] ICE: in get_constraint_for_component_ref, at tree-ssa-structalias.c:2932
--- Comment #2 from mikpe at it dot uu dot se 2010-07-28 19:05 --- Not just MIPS, I get this ICE with gcc-4.4 on arm, powerpc64, and sparc64. On i686 a native gcc-4.4 doesn't ICE but a cross to arm does. gcc-4.5 doesn't ICE. -- mikpe at it dot uu dot se changed: What|Removed |Added CC| |mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45109
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code
--- Comment #14 from mikpe at it dot uu dot se 2010-07-28 15:38 --- If I apply Richard's patch to gcc-4.4-20100727 and bootstrap/regtest the new test case works but I get a single regression in the old ones: FAIL: gcc.dg/vect/vect-22.c scan-tree-dump-times vect "vectorized 4 loops" 1 Looking in vect-22.c.101t.vect reveals: ... .../gcc/testsuite/gcc.dg/vect/vect-22.c:87: note: not vectorized: relevant stmt not supported: D.2174_43 = (short unsigned int) D.2173_42; ... .../gcc-4.4-20100727/gcc/testsuite/gcc.dg/vect/vect-22.c:73: note: not vectorized: relevant stmt not supported: D.2164_26 = (unsigned char) D.2163_25; ... .../gcc-4.4-20100727/gcc/testsuite/gcc.dg/vect/vect-22.c:54: note: vectorized 2 loops in function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code
--- Comment #13 from mikpe at it dot uu dot se 2010-07-28 14:13 --- I've bootstrapped and regtested Richard's proposed fix (http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02161.html) on top of a recent 4.5 snapshot, and it fixed the test case (and the original code it was based on) with no testsuite regressions. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #10 from mikpe at it dot uu dot se 2010-07-28 09:45 --- (In reply to comment #8) > I just realized that this is a packed structure and probably need to look up > the semantics of this in the AAPCS. IIRC the AAPCS states that it doesn't > support packed structures or bitfields at exported interfaces. In the C test case the function returning a packed struct is `static' and called only by name from within the same translation unit. Surely that's not an "exported interface". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code
--- Comment #8 from mikpe at it dot uu dot se 2010-07-27 22:18 ---
(In reply to comment #7)
> In fact, it seems that the error is already there at the very
> beginning: the .original dump shows
>
> fixnum_neg
> {
> ux = (unsigned char) x;
> uy = (unsigned char) -(signed char) ux;
> ...
> }
>
> That is, the negation of unsigned char value is implemented by casting it to
> signed char, which introduces signed overflow if the value of x is -128. As
> far as I understand the C standard, this seems incorrect.
It depends on how GCC interprets that cast and negation:
- if the cast has C semantics, then (signed char)ux causes overflow
- if the cast wraps, then it is fine and yields (signed char)-128
- if the negation has C semantics, then (signed char)-128 is widened to int and
then negated to 128
- if the negation maps signed char to signed char, then it causes overflow
IMO, a serious problem with the C standard is that
signed char x = -1;
signed char y = (signed char)(unsigned char)x;
triggers signed overflow causing undefined behaviour.
This comes from an asymmetry between cast to unsigned and cast to signed:
- cast from signed to unsigned is a total and injective function
- cast from unsigned to signed is a partial function with range from 0 to the
maximum of the signed type (inclusive), which excludes values converted from
negative signed values
(I'd be happy to be proven wrong about this, if anyone can cite relevant
sections from n1124 (C99 TC2) or n1494 (C1x draft) to the contrary.)
Personally I think GCC should treat source-level casts as wrapping, regardless
of -fstrict-overflow and -fno-wrapv. Perhaps it intends to, and we're just
seeing the effects of bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug target/44834] pr44707.c FAILs on sparc -m32: asm operand requires impossible reload
--- Comment #2 from mikpe at it dot uu dot se 2010-07-26 17:10 --- Fixed by Eric's patch for PR44707. -- mikpe at it dot uu dot se changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44834
[Bug c++/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #3 from mikpe at it dot uu dot se 2010-07-26 09:33 --- Created an attachment (id=21312) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21312&action=view) reduced test case in C You don't need C++ to trigger the bug. Proper C with a function that may recurse before returning a packed struct suffices. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug c++/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #2 from mikpe at it dot uu dot se 2010-07-26 08:49 --- With -Os on armv5tel I see a random number repeated 16 times, with -O2 I see the expected output. gcc-4.4 and gcc-4.5 are affected. (Can't test 4.6 or 4.3 right now.) -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #3 from mikpe at it dot uu dot se 2010-07-25 19:24 --- It's caused by r162431: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00785.html -- mikpe at it dot uu dot se changed: What|Removed |Added CC||rsandifo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #13 from mikpe at it dot uu dot se 2010-07-25 17:15 --- is non-standard. For instance, Solaris 10 doesn't have it. Does the test case really require explicit bit fields? Does it work (as in show the miscompile before the fix) with shift & mask operations instead? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug middle-end/45017] miscompile with bitfield and optimization
--- Comment #10 from mikpe at it dot uu dot se 2010-07-25 16:45 --- This test fails on powerpc64-linux and sparc64-linux. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45017
[Bug testsuite/45068] g++.dg/debug/dwarf2/nested-2.C failed on Linux/ia64
--- Comment #2 from mikpe at it dot uu dot se 2010-07-25 16:44 --- Also fails on sparc64-linux, which uses "!' (bang) as comment character. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45068
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #2 from mikpe at it dot uu dot se 2010-07-25 16:14 --- Created an attachment (id=21307) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21307&action=view) reduced test case Attaching reduced 9-line test case. The ICE reproduces with a 4.6 cross hosted on i686-linux: > gcc/xgcc -Bgcc/ -O2 -S /tmp/pr45067.c /tmp/pr45067.c: In function 'decDivideOp': /tmp/pr45067.c:6:6: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug bootstrap/45067] [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
--- Comment #1 from mikpe at it dot uu dot se 2010-07-25 13:02 --- Created an attachment (id=21306) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21306&action=view) preprocessed source for decNumber.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug bootstrap/45067] New: [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522
4.6-20100724 (r162503) fails to bootstrap on arm-linux-gnueabi in stage 2: make[3]: Entering directory `/home/mikpe/objdir46/libdecnumber' source='/home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c' object='decNumber.o' libtool=no /home/mikpe/objdir46/./prev-gcc/xgcc -B/home/mikpe/objdir46/./prev-gcc/ -B/home/mikpe/temp/armv5tel-brewer-linux-gnueabi/bin/ -B/home/mikpe/temp/armv5tel-brewer-linux-gnueabi/bin/ -B/home/mikpe/temp/armv5tel-brewer-linux-gnueabi/lib/ -isystem /home/mikpe/temp/armv5tel-brewer-linux-gnueabi/include -isystem /home/mikpe/temp/armv5tel-brewer-linux-gnueabi/sys-include -I/home/mikpe/gcc-4.6-20100724/libdecnumber -I. -g -O2 -gtoggle -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -Wcast-qual -pedantic -Wno-long-long -Werror -I/home/mikpe/gcc-4.6-20100724/libdecnumber -I. -c /home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c /home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c: In function 'decDivideOp': /home/mikpe/gcc-4.6-20100724/libdecnumber/decNumber.c:4456:15: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [decNumber.o] Error 1 make[3]: Leaving directory `/home/mikpe/objdir46/libdecnumber' make[2]: *** [all-stage2-libdecnumber] Error 2 make[2]: Leaving directory `/home/mikpe/objdir46' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/mikpe/objdir46' make: *** [bootstrap] Error 2 The previous weekly snapshot (4.6-20100717) did bootstrap Ok (with r162270 reverted). gcc-4.6 was configured: /home/mikpe/gcc-4.6-20100724/configure --prefix=/home/mikpe/temp --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran --enable-java-awt=gtk --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-brewer-linux-gnueabi --with-gmp=/home/mikpe/pkgs/linux-armv5l/gmp-4.3.2 --with-mpfr=/home/mikpe/pkgs/linux-armv5l/mpfr-2.4.2 --with-mpc=/home/mikpe/pkgs/linux-armv5l/mpc-0.8.2 --disable-plugin --disable-lto --disable-libmudflap -- Summary: [4.6 regression] ARM bootstrap failure: internal compiler error: in expand_widen_pattern_expr, at optabs.c:522 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC build triplet: armv5tel-unknown-linux-gnueabi GCC host triplet: armv5tel-unknown-linux-gnueabi GCC target triplet: armv5tel-unknown-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code
--- Comment #6 from mikpe at it dot uu dot se 2010-07-25 10:56 --- My bisection identified r114057 as the cause or trigger for this bug: http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00661.html The assembly code diff for the test case with r114056 and r114057 is: --- char-neg.s-r114056 2010-07-25 12:22:25.0 +0200 +++ char-neg.s-r114057 2010-07-25 12:22:31.0 +0200 @@ -57,9 +57,10 @@ movl%edi, %eax xorl%ebx, %ebx cmpb$-128, %al + movl%edi, %eax sete%bl negl%eax - movsbl %al,%eax + subl$256, %eax movl%ebx, 8(%esp) movl%eax, 4(%esp) movl%edi, (%esp) which looks completely broken. (This is the inlined code for foo() in the loop in test_neg().) r114057 was backported to 4.1.2, but for some reason the bug doesn't trigger there. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Known to fail|4.3.2 |4.3.2 4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug bootstrap/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
--- Comment #4 from mikpe at it dot uu dot se 2010-07-24 19:36 --- Attempting to bootstrap 4.5.1-RC on powerpc-linux with --enable-target-optspace fails near the end of stage1 while configuring libgomp: configure:3658: checking for C compiler default output file name configure:3680: /home/mikpe/objdir/./gcc/xgcc -B/home/mikpe/objdir/./gcc/ -B/tmp/install/powerpc-unknown-linux-gnu/bin/ -B/tmp/install/powerpc-unknown-linux-gnu/lib/ -isystem /tmp/install/powerpc-unknown-linux-gnu/include -isystem /tmp/install/powerpc-unknown-linux-gnu/sys-include-g -Os conftest.c >&5 /home/mikpe/objdir/./gcc/crtend.o: In function `__do_global_ctors_aux': crtstuff.c:(.text+0xc): undefined reference to `_savegpr_31' collect2: ld returned 1 exit status libgcc.a was built and does define _savegpr_31, and libgcc_s.so is the expected linker script, and both files are available in the build directory. So yes, --enable-target-optspace appears broken. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code
--- Comment #5 from mikpe at it dot uu dot se 2010-07-24 18:47 --- (In reply to comment #3) > It is triggered by revision 121254: > > http://gcc.gnu.org/ml/gcc-cvs/2007-01/msg00960.html I don't think that's correct. I definitely see the error with both gcc trunk r121253 (pre 4.3.0) and 4.2.4 on i686-linux. I'll try to bisect it myself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug bootstrap/45053] libgcc_s link command misses crtsavgpr_s and crtresgpr_s for powerpc
--- Comment #2 from mikpe at it dot uu dot se 2010-07-24 13:22 --- The build on some targets including powerpc is supposed to create libgcc_s.so as a linker script that inputs BOTH the real shared libgcc_s.so and the static libgcc.a, as some symbols are only defined in the static libgcc. Please make sure that you're preserving this linker script when installing gcc. If you want to backport PR41175 to 4.4 then you also need to backport config.gcc changes related to the powerpc linker script from r151568. (ARM has the same issue. No I'm not responsible for this misdesign.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45053
[Bug target/44631] [sparc] long long to double conversion error
--- Comment #10 from mikpe at it dot uu dot se 2010-07-24 08:45 --- The lkml post is: http://marc.info/?l=linux-kernel&m=127957675305013&w=2 I did look briefly at glibc's soft-fp, but (a) it was substantially updated in February 2006, and (b) none of my systems seemed to enable it (i.e., gcc -msoft-float appeared to generate calls to libgcc rather than libc) so I didn't know how to test it short of building a custom glibc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug target/44631] [sparc] long long to double conversion error
--- Comment #7 from mikpe at it dot uu dot se 2010-07-23 16:44 --- The Linux kernel math-emu fix is included in kernel 2.6.35-rc6. I've re-checked that the test cases work correctly on USIIIi with -mcpu=v9 and this kernel. The fix is scheduled for backporting to the official stable kernels, and should be trivial to backport to just about any 2.6-based kernel. Matthias, can you please close this bug now? (It wasn't even a gcc bug.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug testsuite/44701] [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c
--- Comment #8 from mikpe at it dot uu dot se 2010-07-23 12:22 --- (In reply to comment #7) > Fixed? No, the test case itself needs a fix too. Jakub posted it to gcc-patches, but it was never approved AFAIK and is still not applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44701
[Bug c/45034] "safe" conversion from unsigned to signed char gives broken code
--- Comment #1 from mikpe at it dot uu dot se 2010-07-22 21:13 --- Created an attachment (id=21290) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21290&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug c/45034] New: "safe" conversion from unsigned to signed char gives broken code
The following program (which I'll also attach later) gives unexpected results,
where signed char values are passed as non properly sign-extended ints:
> cat char-neg.c
#include
#include
#include
static void fixnum_neg(signed char x, signed char *py, int *pv)
{
unsigned char ux, uy;
ux = (unsigned char)x;
uy = -ux;
*py = (uy <= 127) ? (signed char)uy : (-(signed char)(255 - uy) - 1);
*pv = (x == -128) ? 1 : 0;
}
void __attribute__((noinline)) foo(int x, int y, int v)
{
printf("test_neg: -(%d) => (%d, %d)\n", x, y, v);
if (y < -128 || y > 127)
abort();
}
int test_neg(void)
{
signed char x, y;
int v, err;
err = 0;
x = -128;
for (;;) {
fixnum_neg(x, &y, &v);
foo((int)x, (int)y, v);
if ((v && x != -128) || (!v && x == -128))
++err;
if (x == 127)
break;
++x;
}
return err;
}
int main(void)
{
if (CHAR_BIT != 8
|| SCHAR_MIN != -128 || SCHAR_MAX != 127
|| UCHAR_MAX != 255)
abort();
if (test_neg() != 0)
abort();
return 0;
}
> gcc -O2 -Wall -Wextra char-neg.c ; ./a.out
test_neg: -(-128) => (-128, 1)
test_neg: -(-127) => (-129, 0)
Abort
The abort shows that the `signed char' variable y is incorrectly extended to
int when passed to foo().
Passing -fwrapv eliminates the failure. Maybe I've been staring at this for
too long, but I can't see any signed overflow in this code.
The problem occurs with gcc 4.6/4.5/4.4/4.3/4.2, but not with 4.1 or older.
The program comes from some code which attempts to emulate machine-level
integer arithmetic and condition code settings. To validate the condition code
logic I used exhaustive testing on a smaller integer type (signed char), but
that broke as shown above. The assignment to *py in fixnum_neg() is one of
several attempts to cast from unsigned to signed char without (apparently)
triggering undefined behaviour due to signed overflow; other failed attempts
have included plain casts, assignment via a union, and memcpy() via a local
signed char temporary.
gcc was configured --with-gmp=... --with-mpfr=... --with-mpc=...
--disable-plugin --disable-lto --disable-nls --enable-threads=posix
--enable-checking=release --disable-libmudflap --enable-languages=c
--
Summary: "safe" conversion from unsigned to signed char gives
broken code
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #11 from mikpe at it dot uu dot se 2010-07-20 09:37 --- Patch posted: http://gcc.gnu.org/ml/libstdc++/2010-07/msg00067.html http://gcc.gnu.org/ml/gcc/2010-07/msg00293.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug bootstrap/44335] [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
--- Comment #7 from mikpe at it dot uu dot se 2010-07-20 08:53 --- (In reply to comment #5) > Here is my patch: > http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00085.html > bootstrap & regtest finished successfully on i686-pc-linuc-gnu in trunk > revision 161664. I've bootstrapped and regtested current 4.6 w/ java on arm-linux-gnueabi with this patch applied, and it solved the bootstrap failure with no regressions. I also included it in bootstraps w/ java on powerpc64 and sparc64, again with no regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #9 from mikpe at it dot uu dot se 2010-07-20 08:48 --- I just finished a native bootstrap and libstdc++-only regtest on arm-linux-gnueabi with the proposed fix for PR44902. The build-time warning is gone, there were no test suite regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug bootstrap/44993] [4.6 regression] sparc64-linux bootstrap broken
--- Comment #1 from mikpe at it dot uu dot se 2010-07-19 21:04 --- The second failure is PR44970. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44993
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #7 from mikpe at it dot uu dot se 2010-07-19 09:48 --- I had planned to include this patch in my native ARM bootstrap+regtest of the next 4.6 weekly snapshot (4.6-20100717) and then submit it properly, but with the bootstrap-breaking r162270 mess it slipped my mind. If people are Ok with it w/o native testing, I'll gladly submit it right now or have someone else apply it directly under the obvious rule. Otherwise I'll do an incremental re-build and libstd++-only test run with it once my current test cycle completes, and then submit it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug target/44631] [sparc] long long to double conversion error
--- Comment #6 from mikpe at it dot uu dot se 2010-07-18 20:58 --- Created an attachment (id=21244) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21244&action=view) fix Linux kernel math emulation FP_FROM_INT macro The bug is in the Linux kernel math-emu code. The _FP_FROM_INT macro which converts integers to raw floats is supposed to produce normalized floats, but due to an error in a boundary condition, it fails to do so for a range of numbers, resulting in very incorrect floats for those numbers. The fix is syntactically trivial (s/http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug middle-end/44974] [4.6 Regression] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #4 from mikpe at it dot uu dot se 2010-07-18 19:59 --- It's caused by r160051: http://gcc.gnu.org/ml/gcc-cvs/2010-05/msg01110.html -- mikpe at it dot uu dot se changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #22 from mikpe at it dot uu dot se 2010-07-18 19:53 --- And on armv5tel-linux-gnueabi with gcc-4.6 r162277: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa.o differs gcc/sel-sched-ir.o differs make[2]: *** [compare] Error 1 Configured just with --enable-languages=c --with-arch=armv5te --with-tune=xscale -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug target/44974] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #2 from mikpe at it dot uu dot se 2010-07-18 16:07 --- Not ARM-specific. The same failure occurs for i686/powerpc64/sparc64-linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #16 from mikpe at it dot uu dot se 2010-07-18 12:31 --- And on sparc64-linux with gcc-4.6 r162277: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! libdecnumber/decimal32.o differs libdecnumber/decimal64.o differs libdecnumber/decimal128.o differs make[2]: *** [compare] Error 1 Configured just --with-cpu=v8 --enable-languages=c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #15 from mikpe at it dot uu dot se 2010-07-18 11:55 --- And on powerpc64-linux with gcc-4.6 r162277: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-ssa.o differs libiberty/regex.o differs make[2]: *** [compare] Error 1 Configured just with --with-cpu=default32 --enable-languages=c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #14 from mikpe at it dot uu dot se 2010-07-18 09:57 --- gcc-4.6 r162277 bootstrap failure on i686-linux: Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/dwarf2out.o differs gcc/reg-stack.o differs gcc/reload.o differs gcc/recog.o differs gcc/i386.o differs libiberty/hashtab.o differs make[2]: *** [compare] Error 1 Configured just with --enable-languages=c and --with-gmp/mpfr/mpc paths. Reverting r162270 fixes it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug target/44974] Function with attribute noreturn omits a call to another function with noreturn
--- Comment #1 from mikpe at it dot uu dot se 2010-07-18 09:09 --- I see the same with gcc-4.6 -O1 built natively on armv5tel-linux-gnueabi. With -O0/-O2/-Os or 4.5/4.4 -O1 foo1() calls _Exit() as it should. Thus a regression. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44974
[Bug target/44631] [sparc] long long to double conversion error
--- Comment #5 from mikpe at it dot uu dot se 2010-07-15 21:30 --- Created an attachment (id=21219) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21219&action=view) updated long long to double conversion test I've updated the test case to try conversions of a larger range of values, and to convert them back to calculate the diffs due to precision loss. When testing this on a couple of machines I noticed that the -mcpu=v9 code (fxtod) behaves differently depending on processor generation and OS kernel. On a USIIIi (Sun Blade 2500 Red) with Linux kernel 2.6.35-rc5 I get: > ./pr44631v2-v9 0x015c181b6dc019dc -> 2.47804e+17 (0x438b83036db8033c) -> 0x0370606db7006780, diff 149824205863538084 0x0100 -> 1.44115e+17 (0x4380) -> 0x0200, diff 72057594037927936 0x00ff -> 7.20576e+16 (0x4370) -> 0x0100, diff 1 0x0021 -> 9.00720e+15 (0x4340) -> 0x0020, diff -1 0x0020 -> 9.00720e+15 (0x4340) -> 0x0020, diff 0 0x001f -> 9.00720e+15 (0x433f) -> 0x001f, diff 0 That is, going from 0x00ff to the next higher integer results in a huge difference in the resulting double. On a USIIi (Ultra5) with Linux kernel 2.6.35-rc5 the same binary gives: > ./pr44631v2-v9 0x015c181b6dc019dc -> 9.79798e+16 (0x4375c181b6dc019e) -> 0x015c181b6dc019e0, diff 4 0x0100 -> 7.20576e+16 (0x4370) -> 0x0100, diff 0 0x00ff -> 7.20576e+16 (0x4370) -> 0x0100, diff 1 0x0021 -> 9.00720e+15 (0x4340) -> 0x0020, diff -1 0x0020 -> 9.00720e+15 (0x4340) -> 0x0020, diff 0 0x001f -> 9.00720e+15 (0x433f) -> 0x001f, diff 0 That is, while rounding occurs there are no huge jumps in the intermediate double representation. In fact, the output exactly matches the output for the -mcpu=v8 case which uses pure SW conversions instead of fxtod. So USIIIi and USIIi behave differently. On another USIIIi (Sun Fire V240) running Solaris 10, a gcc-4.4.4 -mcpu=v9 binary again gives the exact same results as -mcpu=v8 or USIIi runs. So Linux and Solaris behave differently on USIIIi. Both the Linux and Solaris kernels for SPARC contain FP emulation support for various cases the HW doesn't like to handle. According to comments in the Linux kernel one of the changes in USIII from earlier generations was that fxtod started to trap for certain cases. According to debugging code I added to the Linux kernel, fxtod does trap and get emulated on USIIIi for many (all?) cases where the conversion is inexact, including the test cases where fxtod produced very wrong values. So it appears the Linux kernel's emulation of fxtod is broken. My Linux kernel on the USIIIi was compiled by gcc-4.4.4. As a final test I recompiled it with gcc-3.4.6, but that made no difference. So I suspect a kernel logic error, not a miscompilation. BTW, in an interim version of the test case I did log the value of FSR, but all three systems (Linux USIIi, Linux USIIIi, and Solaris USIIIi) did run with the same rounding and exception control settings so that's not the issue. -- mikpe at it dot uu dot se changed: What|Removed |Added Attachment #20986|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug libstdc++/44902] eh_arm.cc:42:23: error: declaration of '__cxxabiv1::__cxa_type_match_result __cxa_type_match(_Unwind_Control_Block*, const std::type_info*, bool, void**)' with C language linkage
--- Comment #4 from mikpe at it dot uu dot se 2010-07-13 23:51 --- Created an attachment (id=21195) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21195&action=view) fix __cxa_type_match and __cxa_begin_cleanup prototypes Looks like long-standing confusion about the return types of __cxa_type_match and __cxa_begin_cleanup. I see the warnings with 4.5 and 4.6, but strangely enough not with 4.4 even though the same mismatch exists there. Fixed by making the prototypes match the function definitions. Tested so far with a 4.6 cross to arm-linux-gnueabi. There's also a mismatching extern declaration for __cxa_begin_cleanup in libjava/exception.cc, but it seems harmless so I excluded the patch to correct it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44902
[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
--- Comment #14 from mikpe at it dot uu dot se 2010-07-13 17:40 --- Also fails on sparc64-linux, with SIGBUS due to misaligned load in bar(). On armv5tel-unknown-linux-gnueabi it triggers an alignment exception, which the Linux kernel may emulate/fixup (there's a kernel tunable for that). -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #4 from mikpe at it dot uu dot se 2010-07-10 21:10 --- This is fixed on trunk since r161797. However, this is now a 4.5 regression. A patch to backport the fix to 4.5 has been posted: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00877.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug objc/41848] Extra Objective C test failures because of section anchors.
--- Comment #4 from mikpe at it dot uu dot se 2010-07-10 18:49 --- The issue is still very much there with 4.[456] on arm-linux-gnueabi, see e.g. the test results I post. In my 4.4 production compiler I apply Ramana's fix, and it eliminates all objc test failures for me. Haven't checked how it fares with 4.5 yet (I forgot that it was only a proposed fix and not a backport from trunk). -- mikpe at it dot uu dot se changed: What|Removed |Added CC| |mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41848
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #3 from mikpe at it dot uu dot se 2010-07-10 10:30 ---
It now also fails with 4.5 branch on sparc64-linux, with identical
-fdump-tree-vect-details as for powerpc64. With 4.6 it fails on ARM with
identical reason since 20100529.
I'm thinking this hunk in the PR44284 fix is to blame:
--- trunk/gcc/testsuite/gcc.dg/vect/vect-109.c 2010/05/27 12:08:51 159919
+++ trunk/gcc/testsuite/gcc.dg/vect/vect-109.c 2010/05/27 13:23:45 159920
@@ -72,7 +72,7 @@
return 0;
}
-/* { dg-final { scan-tree-dump-times "vectorized 0 loops" 2 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 2 "vect" } } */
/* { dg-final { scan-tree-dump-times "not vectorized: unsupported unaligned
store" 2 "vect" { xfail vect_hw_misalign } } } */
/* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 10
"vect" { target vect_hw_misalign } } } */
/* { dg-final { cleanup-tree-dump "vect" } } */
That is, the changed expectation that vectorization now will succeed should
probably depend on target vect_hw_misalign.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug testsuite/44325] [4.6 regression] FAIL: gcc.dg/vect/vect-109.c
--- Comment #2 from mikpe at it dot uu dot se 2010-07-10 10:06 --- This test now also fails with 4.5 branch on powerpc64. It's a recent regression, introduced somewhere between 20100701 and 20100708. The -fdump-tree-vect-details file shows: > fgrep vectorized vect-109.c.110t.vect vect-109.c:33: note: not vectorized: control flow in loop. vect-109.c:26: note: === vect_mark_stmts_to_be_vectorized === vect-109.c:26: note: not vectorized: unsupported unaligned store. vect-109.c:20: note: vectorized 0 loops in function. vect-109.c:55: note: not vectorized: control flow in loop. vect-109.c:48: note: === vect_mark_stmts_to_be_vectorized === vect-109.c:48: note: not vectorized: unsupported unaligned store. vect-109.c:42: note: vectorized 0 loops in function. so it's not the common problem with too many vectorized loops. I'll try reverting the PR44284 backport. -- mikpe at it dot uu dot se changed: What|Removed |Added CC| |mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44325
[Bug objc/44887] [4.6 regression] All Objective-C execution tests fail on Solaris 2/SPARC
--- Comment #3 from mikpe at it dot uu dot se 2010-07-09 18:27 --- These new objc failures are also seen on sparc64-linux btw. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44887
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #11 from mikpe at it dot uu dot se 2010-07-08 14:12 --- (In reply to comment #9) > Still the alternative is probably correct more often. So if that fixes the > issue for you we can go with that until I manage to finish the alignment > tracking. The alternative does fix this test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug middle-end/44843] [4.6 regression] All 32-bit fortran execution tests SEGV on SPARC: unaligned access
--- Comment #6 from mikpe at it dot uu dot se 2010-07-08 12:18 ---
With this short test case:
struct s {
double for_alignment;
struct { int x, y, z; } a[16];
};
void f(struct s *s)
{
unsigned int i;
for (i = 0; i < 16; ++i) {
s->a[i].x = 0;
s->a[i].y = 0;
s->a[i].z = 0;
}
}
revision 161840 changes the generated code as follows:
--- pr44843.s-r161839 2010-07-08 14:00:06.0 +0200
+++ pr44843.s-r161840 2010-07-08 14:00:26.0 +0200
@@ -6,10 +6,9 @@
.proc 020
f:
mov 16, %g1
.LL2:
- st %g0, [%o0+8]
- st %g0, [%o0+12]
+ stx %g0, [%o0+8]
st %g0, [%o0+16]
addcc %g1, -1, %g1
bne,pt %icc, .LL2
add%o0, 12, %o0
which will fail at runtime due to misalignment in the 2nd loop iteration.
Removing the double which is there to align the struct and the start of the
array eliminates the bug.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
CC| |mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44843
[Bug c++/44810] [4.6 Regression] FAIL: g++.dg/torture/pr36745.C
--- Comment #2 from mikpe at it dot uu dot se 2010-07-06 16:17 --- This new FAIL of pr36745.C since r161655 is also seen on sparc64, ia64, arm, and alpha. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44810
[Bug target/44834] New: pr44707.c FAILs on sparc -m32: asm operand requires impossible reload
The recently added gcc/testsuite/gcc.c-torture/compile/pr44707.c fails on sparc64 with -m32 -O1/-O2/-O3/-Os: gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload gcc/testsuite/gcc.c-torture/compile/pr44707.c:12:3: error: 'asm' operand requires impossible reload This shows as new FAILs in recent test results, but the test case is new and actually fails with every gcc 4.x/3.x release back to gcc-3.2.3. Both Linux and Solaris fail. It does not fail with -O0 or with -m64. -- Summary: pr44707.c FAILs on sparc -m32: asm operand requires impossible reload Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44834
