[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 #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/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 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 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 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 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 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 #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 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 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 #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 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 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 #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 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 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 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 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 #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 #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 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 c/43961] [ARM thumb] "branch out of range" with thumb1_output_casesi
--- Comment #3 from mikpe at it dot uu dot se 2010-05-02 19:37 --- Also breaks on armv5tel-unknown-linux-gnueabi with gcc-4.5-20100429 and gcc-4.6-20100501. It works with gcc-4.4-20100427 and gcc-4.3-20100103. -- 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=43961
[Bug bootstrap/43964] New: 4.6-20100501 (r158965) bootstrap failure on ARM, ira-color.c triggers -Werror
make bootstrap of gcc-4.6-20100501 snapshot on armv5tel-unknown-linux-gnueabi
fails in stage 2 as follows:
/home/mikpe/gcc-4.6-20100501/gcc/ira-color.c: In function 'assign_hard_reg':
/home/mikpe/gcc-4.6-20100501/gcc/ira-color.c:447:31: error: unused variable
'rclass' [-Werror=unused-variable]
/home/mikpe/gcc-4.6-20100501/gcc/ira-color.c:444:59: error: unused variable
'add_cost' [-Werror=unused-variable]
cc1: all warnings being treated as errors
I suspect r158911 (PR42895 patch) is responsible, I'll try reverting that one
now.
--
Summary: 4.6-20100501 (r158965) bootstrap failure on ARM, ira-
color.c triggers -Werror
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=43964
[Bug bootstrap/43964] [4.6 Regression] 4.6-20100501 (r158965) bootstrap failure on ARM, ira-color.c triggers -Werror
--- Comment #1 from mikpe at it dot uu dot se 2010-05-03 10:43 --- Created an attachment (id=20545) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20545&action=view) suggested fix for PR43964 Confirmed r158911 to be the cause of this bootstrap failure. Attached patch should fix it. So far tested with bootstrap on i686-linux and cross to arm. I'm now running a full bootstrap (all languages except ada) on arm, expect 12 hours or so for it to complete. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43964
[Bug bootstrap/43964] [4.6 Regression] 4.6-20100501 (r158965) bootstrap failure on ARM, ira-color.c triggers -Werror
--- Comment #2 from mikpe at it dot uu dot se 2010-05-04 00:56 --- Bootstrap with the patch succeeded on ARM. Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00187.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43964
[Bug bootstrap/43964] [4.6 Regression] 4.6-20100501 (r158965) bootstrap failure on ARM, ira-color.c triggers -Werror
--- Comment #4 from mikpe at it dot uu dot se 2010-05-04 11:23 --- Thanks Bernd for committing this. Closing as fixed. -- 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=43964
[Bug c++/43911] [4.4/4.5 Regression] g++ can't compile any even trivial c++ source: undefined reference to `_Unwind_GetIPInfo'
--- Comment #24 from mikpe at it dot uu dot se 2010-05-11 06:51 --- Your gcc appears confused about whether to use the newer _Unwind_GetIPInfo() or the older _Unwind_GetIP(). Most likely it's because you're building for uclibc rather than glibc. I think you need to bisect between the last working gcc and the first broken one to identify the responsible commit. Once that's done the fix may be apparent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43911
[Bug java/44095] New: [4.5/4.6 regression] massive java failures due to -findirect-dispatch breakage on sparc64-linux
Java is severely broken on sparc64-linux with gcc 4.5/4.6, which is a major regression from 4.4: http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00853.html (4.6 broken) http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00681.html (4.5 broken) http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00472.html (4.4 works) The detailed test suite logs show that _every_ -findirect-dispatch test case SEGFAULTs shortly after startup. I've bisected trunk and identified r155622 as the cause: Author: jakub Date: Mon Jan 4 16:02:41 2010 New Revision: 155622 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155622 Log: PR driver/42442 * gcc.c (SWITCH_IGNORE_PERMANENTLY): Define. (do_self_spec): For switches with SWITCH_IGNORE set set also SWITCH_IGNORE_PERMANENTLY. (check_live_switch): Check SWITCH_IGNORE_PERMANENTLY instead of SWITCH_IGNORE. Let's compare installations of r155621 and r155622: > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: > /mnt/scratch/install-r155621/bin/gcj -v -findirect-dispatch > --main=ArrayStore2 ArrayStore2.jar ... /mnt/scratch/install-r155621/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jc1 ArrayStore2.jar -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fPIC -fkeep-inline-functions -quiet -dumpbase ArrayStore2.jar -mcpu=v8 -auxbase ArrayStore2 -g1 -version -findirect-dispatch -fbootclasspath=./:/mnt/scratch/install-r155621/share/java/libgcj-4.5.0.jar -o /tmp/ccCkBmCp.s ... as -V -Qy -s -K PIC -32 -relax -o /tmp/ccgzZvpI.o /tmp/ccCkBmCp.s ... /mnt/scratch/install-r155621/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jvgenmain -findirect-dispatch ArrayStore2main /tmp/ccwLkVQ4.i ... /mnt/scratch/install-r155621/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/cc1 /tmp/ccwLkVQ4.i -quiet -dumpbase ArrayStore2main.c -mcpu=v8 -g1 -version -fdollars-in-identifiers -o /tmp/ccCkBmCp.s ... as -V -Qy -s -32 -relax -o /tmp/cc8Sx4xt.o /tmp/ccCkBmCp.s ... > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: ./a.out index rhs java.lang.ArrayIndexOutOfBoundsException > LD_LIBRARY_PATH=/mnt/scratch/install-r155622/lib: > /mnt/scratch/install-r155622/bin/gcj -v -findirect-dispatch > --main=ArrayStore2 ArrayStore2.jar ... /mnt/scratch/install-r155622/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jc1 ArrayStore2.jar -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fPIC -fkeep-inline-functions -quiet -dumpbase ArrayStore2.jar -mcpu=v8 -auxbase ArrayStore2 -g1 -version -findirect-dispatch -fbootclasspath=./:/mnt/scratch/install-r155622/share/java/libgcj-4.5.0.jar -o /tmp/cc5XY9sD.s ... as -V -Qy -s -K PIC -32 -relax -o /tmp/cc626Pob.o /tmp/cc5XY9sD.s ... /mnt/scratch/install-r155622/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jvgenmain -findirect-dispatch ArrayStore2main /tmp/ccLsDapM.i ... /mnt/scratch/install-r155622/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/cc1 /tmp/ccLsDapM.i -quiet -dumpbase ArrayStore2main.c -mcpu=v8 -g1 -version -fdollars-in-identifiers -o /tmp/cc5XY9sD.s ... as -V -Qy -s -K PIC -32 -relax -o /tmp/ccw9Ke7n.o /tmp/cc5XY9sD.s ... > LD_LIBRARY_PATH=/mnt/scratch/install-r155622/lib:. ./a.out Segmentation fault The main difference is that in the working compiler, the java classes are assembled with -K PIC but the generated main() is not, while in the broken compiler both the java classes and the generated main() are assembled with -K PIC. If I force -K PIC with the working compiler it too fails: > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: > /mnt/scratch/install-r155621/bin/gcj -findirect-dispatch --main=ArrayStore2 > -Wa,-K,PIC ArrayStore2.jar > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: ./a.out Segmentation fault I note that gcc/java/jvspec.c has %http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44095
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #9 from mikpe at it dot uu dot se 2010-05-12 16:34 --- Confirmed with cross to armv5tel-unknown-linux-gnueabi. 4.3/4.4/4.5/4.6 all generate the signal-unsafe epilogue. -- 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=44091
[Bug target/44099] ICE in g++.dg/debug/nullptr01.C test on Solaris 2/SPARC
--- Comment #3 from mikpe at it dot uu dot se 2010-05-12 19:15 --- I get the same errors with nullptr01.C on sparc64-unknown-linux-gnu. My build has c++ as an enabled language, and most other c++ and libstdc++ tests work, so I don't think this is a dupe of PR44048. -- 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=44099
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #12 from mikpe at it dot uu dot se 2010-05-13 10:28 --- r130052 is a generic scheduling tweak originally described here: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #6 from mikpe at it dot uu dot se 2010-05-19 11:43 --- This bug also affects 4.5 and 4.4, but not 4.3, making it a regression from 4.3. The fix for 4.6 backports cleanly to 4.5 and with minor fuzz to 4.4, and has been verified to fix the problem on those branches too with no new testsuite regressions (bootstrapped + regtested on i686-linux). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #8 from mikpe at it dot uu dot se 2010-05-19 11:57 --- I just compiled the original test case with 4.5, 4.4, and 4.3, and the assert didn't trigger when compiled with 4.3. I didn't investigate any further. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug libstdc++/44190] Debug vector resize does not update capacity
--- Comment #12 from mikpe at it dot uu dot se 2010-05-19 12:29 --- (In reply to comment #10) > Let's apply the patch to 4.5 too. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44190
[Bug tree-optimization/44183] Vectorizer may generate invalid memory access
--- Comment #4 from mikpe at it dot uu dot se 2010-05-20 10:18 --- (In reply to comment #3) > I am curious what is the problem with that? These elements are not used, they > are just loaded... An out-of-bounds read can result in a SEGV if the memory is unmapped. Worse things can happen if the memory is "special" (think kernels and MMIO). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
[Bug tree-optimization/44183] Vectorizer may generate invalid memory access
--- Comment #6 from mikpe at it dot uu dot se 2010-05-20 11:05 --- It depends on the specific values of (a) array end alignment and (b) the number of bytes read. As long as the array end + number of bytes read can cross a page boundary, you're potentially causing SEGV or other errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
[Bug bootstrap/44255] New: [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64
4.6-20100515 (r159445) bootstrapped fine on my sparc64-linux machine.
4.6-20100522 (r159746) gets a bootstrap comparison failure in stage 3:
...
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
libiberty/cp-demangle.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/mnt/scratch/objdir46'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/mnt/scratch/objdir46'
make: *** [bootstrap] Error 2
Configuration parameters:
/mnt/scratch/gcc-4.6-20100522/configure
--with-gmp=/home/mikpe/pkgs/linux-sparc64/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-sparc64/mpfr-2.4.2
--with-mpc=/home/mikpe/pkgs/linux-sparc64/mpc-0.8.1 --with-cpu=v8
--enable-multilib --disable-plugin --disable-lto --disable-nls
--enable-threads=posix --enable-checking=release --disable-libmudflap
--enable-languages=c
I'll try to bisect it.
--
Summary: [4.6 regression] gcc-4.6-20100522 bootstrap comparison
failure on sparc64
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: sparc64-unknown-linux-gnu
GCC host triplet: sparc64-unknown-linux-gnu
GCC target triplet: sparc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #1 from mikpe at it dot uu dot se 2010-05-23 21:09 --- The exact same bootstrap comparison failure now also showed up in my attempt to build gcc-4.6-20100522 on armv5tel-unknown-linux-gnueabi. And like sparc64 the previous 4.6 weekly snapshot bootstrapped fine. -- mikpe at it dot uu dot se changed: What|Removed |Added GCC build triplet|sparc64-unknown-linux-gnu |sparc64-unknown-linux-gnu, ||armv5tel-unknown-linux- ||gnueabi GCC host triplet|sparc64-unknown-linux-gnu |sparc64-unknown-linux-gnu, ||armv5tel-unknown-linux- ||gnueabi GCC target triplet|sparc64-unknown-linux-gnu |sparc64-unknown-linux-gnu, ||armv5tel-unknown-linux- ||gnueabi Summary|[4.6 regression] gcc-4.6- |[4.6 regression] gcc-4.6- |20100522 bootstrap |20100522 bootstrap |comparison failure on |comparison failure on |sparc64 |sparc64 and arm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #2 from mikpe at it dot uu dot se 2010-05-24 09:31 --- Bisection identified r159600 as the source of the failure on sparc64: Author: rsandifo Date: Wed May 19 21:08:53 2010 New Revision: 159600 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159600 Log: gcc/ * combine.c (propagate_for_debug): Call make_compound_operation on the source value. (try_combine): When implementing a split chosen by find_split_point, either copy i2src or set it to null. Assert that i2src is not null before substituting into CALL_INSN_FUNCTION_USAGE. Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c The corresponding gcc-patches thread started here: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01296.html My ARM box is currently busy running another test, but as soon as that finishes I'll check if r159600 is also responsible for the ARM bootstrap failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #4 from mikpe at it dot uu dot se 2010-05-24 16:16 --- (In reply to comment #3) > most likely this is a duplicate of: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44229 > > and potentially an LE/BE issue given that it's not reported on *x86* However: 1. I see the failure on both BE (sparc64) and LE (armv5tel). 2. Both BE (powerpc64-linux) and LE (x86) don't see the failure. So I doubt it's an endianess issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #5 from mikpe at it dot uu dot se 2010-05-24 16:21 --- Comparing stage2-libiberty/cp-demangle.o with stage3-libiberty/cp-demangle.o shows that one instruction has had it's source operands swapped: > objdump -d stage2-libiberty/cp-demangle.o > a > objdump -d stage3-libiberty/cp-demangle.o > b > diff -u a b --- a 2010-05-24 17:59:49.0 +0200 +++ b 2010-05-24 17:59:54.0 +0200 @@ -1,5 +1,5 @@ -stage2-libiberty/cp-demangle.o: file format elf32-sparc +stage3-libiberty/cp-demangle.o: file format elf32-sparc Disassembly of section .text: @@ -4702,7 +4702,7 @@ 5078: 89 29 20 04 sll %g4, 4, %g4 507c: 84 00 80 04 add %g2, %g4, %g2 5080: 84 00 b8 6c add %g2, -1940, %g2 -5084: 84 80 80 03 addcc %g2, %g3, %g2 +5084: 84 80 c0 02 addcc %g3, %g2, %g2 5088: 22 80 02 11 be,a 58cc 508c: c4 00 a0 04 ld [ %g2 + 4 ], %g2 5090: c6 06 20 14 ld [ %i0 + 0x14 ], %g3 Now, the code is still correct, but gcc shouldn't arbitrarily change it's mind like this in stage3. Hence I suspect r159600 introduces some non-determinism, or exposes latent non-determinism. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #6 from mikpe at it dot uu dot se 2010-05-24 22:24 --- The stage 3 comparison failure on ARM is as follows: ... Bootstrap comparison failure! libiberty/pic/cp-demangle.o differs Comparing the disassembly listings of prev-libiberty/pic/cp-demangle.o and libiberty/pic/cp-demangle.o yields: @@ -1,5 +1,5 @@ -prev-libiberty/pic/cp-demangle.o: file format elf32-littlearm +libiberty/pic/cp-demangle.o: file format elf32-littlearm Disassembly of section .text: @@ -4751,12 +4751,12 @@ 4954: e58d0004str r0, [sp, #4] 4958: eae7b 48fc 495c: e3a01014mov r1, #20 ; 0x14 -4960: e0010193mul r1, r3, r1 -4964: e59f38e8ldr r3, [pc, #2280] ; 5254 -4968: e2411e79sub r1, r1, #1936 ; 0x790 -496c: e2411004sub r1, r1, #4 ; 0x4 -4970: e7923003ldr r3, [r2, r3] -4974: e0913003addsr3, r1, r3 +4960: e0030391mul r3, r1, r3 +4964: e59f18e8ldr r1, [pc, #2280] ; 5254 +4968: e2433e79sub r3, r3, #1936 ; 0x790 +496c: e2433004sub r3, r3, #4 ; 0x4 +4970: e7922001ldr r2, [r2, r1] +4974: e0923003addsr3, r2, r3 4978: 0a000215beq 51d4 497c: e5942014ldr r2, [r4, #20] 4980: e5941018ldr r1, [r4, #24] So it's not just two swapped source operands in an arithmetic instruction as on sparc, but also different (still valid) register assignment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #15 from mikpe at it dot uu dot se 2010-05-26 12:44 --- Created an attachment (id=20749) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20749&action=view) proposed 4.6 fix for PR38644 PR38644 and its dupes are very similar to PowerPC PR44199 and PR30282. PR44199 was recently fixed by conditionally emitting stack ties in epilogues. I first intended to simply clone that approach for Thumb1, but it turns out there's already a conditional barrier in thumb1_expand_epilogue (). So for now I simply extended that condition to also trigger whenever there's stack pointer adjustment in the epilogue. I've confirmed that this fixes the test cases in PR38644, PR42155, and PR44091. I know that Richard Earnshaw has stated that he considers this a middle-end rather than a back-end bug, and I agree with that. However, given that this wrong-code bug has been known for so long with no middle-end fix in sight, I think solving it in the back-end is appropriate for now, at least for 4.4/4.5. The current patch is a little too heavy in that it also blocks non memory accesses from being scheduled past the stack pointer adjustment -- I saw an example of that in the large PR44091 test case. Using a stack tie instead of a full barrier should hopefully fix that. So far only tested with 4.4/4.5/4.6 crosses to armv5tel-unknown-linux-gnueabi. I'll try this in a 4.5 native bootstrap soonish (4.6 bootstraps are currently broken on ARM, see PR44255). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #10 from mikpe at it dot uu dot se 2010-05-26 15:16 --- (In reply to comment #2) > My ARM box is currently busy running another test, but as soon as that > finishes > I'll check if r159600 is also responsible for the ARM bootstrap failure. It is, r159599 bootstraps on ARM, r159600 does not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #11 from mikpe at it dot uu dot se 2010-05-27 21:35 --- Created an attachment (id=20763) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20763&action=view) preprocessed source for libiberty/cp-demangle.c Here's the preprocessed source for libiberty/cp-demangle.c as generated by gcc-4.6-20100522 on sparc64-unknown-linux. The same 4.6 snapshot built on x86 as a cross to sparc64-unknown-linux also fails with -m32 -g -fcompare-debug -O2: > sparc64-unknown-linux-gcc -m32 -g -fcompare-debug -O2 -c cp-demangle.i sparc64-unknown-linux-gcc: cp-demangle.i: -fcompare-debug failure If you compile cp-demangle.i to .o first with -g0 and then with -g and compare the objdump -d output from those two object files, you'll find a single instruction difference at or near address 0x5080 in function cplus_demangle_type (). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #6 from mikpe at it dot uu dot se 2010-05-28 11:49 --- Confirmed. A linux-2.6.34 kernel configured for ARM and compiled with gcc-4.5-20100520 crashes during boot with a NULL pointer dereference in its copy_user_highpage() exactly at the point where it tries to start /sbin/init. HIGHMEM enabled or not makes no difference. The same kernel compiled with gcc-4.4.4 boots fine. Both gcc's were configured for armv5tel-unknown-linux-gnu --with-arch=armv5te --with-tune=xscale. The linux kernels were built for mach-iop32x/n2100 (XScale IOP80219). I note that copypage-xscale.c:xscale_mc_copy_user_highpage() calls a __naked function to do the bulk copy. Converting that to a plain inline function (changing 'pc' to 'lr' in the final instruction that restores the scrach regs), does not prevent the crash. So I suspect a plain C code miscompilation. I'll try to bisect it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #13 from mikpe at it dot uu dot se 2010-05-28 16:02 --- Jakub's patch fixed 4.6 bootstrap on my sparc64 machine. My ARM is testing other branches currently, but I should have 4.6 bootstrap results for it on Sunday or Monday, at which time I'll close this PR if things went well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44255
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #7 from mikpe at it dot uu dot se 2010-05-28 22:02 --- Bisection identified r148981 as the cause of this regression: Author: rth Date: Fri Jun 26 18:23:32 2009 New Revision: 148981 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148981 Log: * function.h (struct function): Add cannot_be_copied_reason, and cannot_be_copied_set. * tree-inline.c (has_label_address_in_static_1): Rename from inline_forbidden_p_2; don't set inline_forbidden_reason here. (cannot_copy_type_1): Rename from inline_forbidden_p_op; likewise don't set inline_forbidden_reason. (copy_forbidden): New function, split out of inline_forbidden_p. (inline_forbidden_p_stmt): Don't check for nonlocal labels here. (inline_forbidden_p): Use copy_forbidden. (tree_versionable_function_p): Likewise. (inlinable_function_p): Merge into tree_inlinable_function_p. (tree_function_versioning): Remap cfun->nonlocal_goto_save_area. * ipa-cp.c (ipcp_versionable_function_p): New function. (ipcp_cloning_candidate_p): Use it. (ipcp_node_modifiable_p): Likewise. I'll try to extract a smaller test case tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug tree-optimization/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra
--- Comment #8 from mikpe at it dot uu dot se 2010-05-29 11:35 --- (In reply to comment #6) > I note that copypage-xscale.c:xscale_mc_copy_user_highpage() calls a __naked > function to do the bulk copy. Converting that to a plain inline function > (changing 'pc' to 'lr' in the final instruction that restores the scrach > regs), > does not prevent the crash. So I suspect a plain C code miscompilation. Actually that conversion away from __naked may have been flawed. What I'm seeing is that r148981 causes gcc to clone the __naked function and change its calling conventions in ways that don't match the proper function call ABI. This breaks the body of the __naked function which is just a big asm() statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug target/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra, __naked attribute is broken
--- Comment #13 from mikpe at it dot uu dot se 2010-05-29 14:27 ---
(In reply to comment #10)
> Or rather, if you have
>
> void __attribute__((naked)) foo (int i)
> {
> asm("use i");
> }
>
> without any inputs refering to i that is invalid.
Not according to gcc/doc/extend.texi:
> @item naked
> @cindex function without a prologue/epilogue code
> Use this attribute on the ARM, AVR, IP2K, RX and SPU ports to indicate that
> the specified function does not need prologue/epilogue sequences generated by
> the compiler. It is up to the programmer to provide these sequences. The
> only statements that can be safely included in naked functions are
> @code{asm} statements that do not have operands.
Note: "do not have operands". Thus the only way such an asm() can refer to
parameters is by assuming a standard function call sequence and hardcoding
corresponding register numbers or stack frame offsets.
However, even if the asm() refers to those parameters via "r"(...) inputs,
gcc-4.5 changes the register assignment to not agree with the standard call
sequence, I'll attach a small test case showing that in a moment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug target/44290] [4.5 Regression] arm linux kernel crahes when built with -fipa-sra, __naked attribute is broken
--- Comment #14 from mikpe at it dot uu dot se 2010-05-29 14:39 --- (In reply to comment #11) > (it seems quite stupid to have naked functions with only an asm inside in the > first place - you can equally well use plain assembly) Except that with plain asm() for an entire function definition you'd also have to include boring preamble/postamble stuff like .align/.type/.size if you want it to appear as a proper function, and you still have to declarate a prototype. And the reason for making it a separate function rather than an inline asm() is probably related to register assignment: a separate function can (could) make assumptions about parameter registers and scratch registers. With inline asm() you have to be much more elaborate, esp. if you have constraints that gcc cannot express, like even/odd register pairs on ARM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug target/44290] [4.5 Regression] __naked attribute is broken
--- Comment #17 from mikpe at it dot uu dot se 2010-05-29 14:47 --- Created an attachment (id=20772) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20772&action=view) test case from copypage-xscale.c This is distilled from the kernel's copypage-xscale.c file and illustrates the issue. With gcc-4.4 the __naked__ function foo() is called with the standard call sequence register assignment, so the asm() body of foo() works. With gcc-4.5 foo() is cloned and gets its second parameter `to' in r0 (not r1 as expected), and the body of foo() is modified to set up the actual first parameter (&fie[0]) in r1 (not r0 as expected). Obviously the asm() then breaks. Compiling with -fno-ipa-cp avoids this problem, as does adding __noclone__ and __noinline__ to foo()'s function definition. I don't immediately see how to enforce __noclone__ and __noinline__ in the ARM backend when it sees __naked__. Any ideas? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug target/44290] [4.5 Regression] __naked attribute is broken
--- Comment #18 from mikpe at it dot uu dot se 2010-05-29 18:00 --- Created an attachment (id=20773) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20773&action=view) linux kernel workaround for attribute naked breakage This patch makes the Linux kernel add noinline and noclone attributes to functions declared __naked. This allows gcc-4.5 to build a working 2.6.34 Linux kernel for my mach-iop32x/n2100 ARM box. Khem: can you check if this kernel-side workaround fixes your problem? Eventually I'd like the kernel to not use __naked, but that is non-trivial. This fix should work now and be easily backportable to older kernels. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44290
[Bug c++/44328] switch/case optimization produces an invalid jump table index
--- Comment #2 from mikpe at it dot uu dot se 2010-05-30 14:50 --- I can confirm this wrong-code when gcc 4.4/4.5 targets arm-unknown-eabi. However, a 4.4/4.5 running natively on arm-unknown-linux-gnueabi does not exhibit this behaviour. There there's no 'comparison always true' warning, and the generated code contains conditional instructions where the arm-unknown-eabi gcc emitted unconditional instructions. This is what 4.5-20100527 generates for me on arm-unknown-linux-gnueabi: sub r1, r1, #1 cmp r1, #2 ldrls r3, .L4 movhi r1, #1 ldrls r1, [r3, r1, asl #2] b open .L5: .align 2 .L4: .word .LANCHOR0 .size _Z9open_filePKc8OpenMode, .-_Z9open_filePKc8OpenMode .section.rodata .align 2 .LANCHOR0 = . + 0 .type CSWTCH.2, %object .size CSWTCH.2, 12 CSWTCH.2: .word 74 .word 3 .word 75 My guess is that the subtract+compare is done in a too narrow mode, resulting in the warning and subsequent omission of the conditionals. Also, it's not a jump table but a lookup table. -- 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=44328
[Bug bootstrap/44335] New: [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
Attempting to bootstrap gcc-4.6-20100529 on armv5tel-unknown-linux-gnueabi with
java enabled fails:
...
In file included from /home/mikpe/gcc-4.6-20100529/gcc/java/except.c:33:0:
/home/mikpe/gcc-4.6-20100529/gcc/except.h:322:6: error: #error
"EH_RETURN_DATA_REGNO required"
/home/mikpe/gcc-4.6-20100529/gcc/except.h:325:6: error: #error
"{DWARF2,TARGET}_UNWIND_INFO required"
/home/mikpe/gcc-4.6-20100529/gcc/except.h:329:6: error: #error
"EH_RETURN_HANDLER_RTX or eh_return required"
/home/mikpe/gcc-4.6-20100529/gcc/except.h:335:6: error: #error "Must use SJLJ
exceptions but configured not to"
make[3]: *** [java/except.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
Configured with: /home/mikpe/gcc-4.6-20100529/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.1 --disable-plugin
--disable-lto --disable-libmudflap
The gcc-4.6-20100515 weekly snapshot bootstrapped fine with the same
configuration options.
--
Summary: [4.6 regression] gcc-4.6-20100529 java bootstrap failure
on arm-linux-gnueabi
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=44335
[Bug bootstrap/44255] [4.6 regression] gcc-4.6-20100522 bootstrap comparison failure on sparc64 and arm
--- Comment #14 from mikpe at it dot uu dot se 2010-05-31 07:20 --- The bootstrap comparison failure is gone on armv5tel-unknown-linux-gnueabi with gcc-4.6-20100529. Thus closing as fixed. -- 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=44255
[Bug bootstrap/44335] [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
--- Comment #2 from mikpe at it dot uu dot se 2010-05-31 16:20 --- Steven's patch in r160039 did get me a past the error in java/except.c, however then the bootstrap dies a few files later with: /home/mikpe/gcc-4.6-20100529/gcc/java/jcf-parse.c: In function 'handle_constant': /home/mikpe/gcc-4.6-20100529/gcc/java/jcf-parse.c:565:9: error: implicit declaration of function 'arm_float_words_big_endian' [-Werror=implicit-function-declaration] cc1: all warnings being treated as errors make[3]: *** [java/jcf-parse.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 -- mikpe at it dot uu dot se changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
[Bug middle-end/44291] [4.6 regression] ICE in set_user_assembler_libfunc
--- Comment #2 from mikpe at it dot uu dot se 2010-06-02 15:33 ---
I see this error too, it's causing gcc.c-torture/execute/builtins/memops-asm.c
and gcc.dg/pr39443.c to regress on arm-linux-gnueabi due to ICEs. I didn't see
the problem in 4.6-20100515 (r159445), but do see it in 4.6-20100522 (r159746)
and current head (r160155). I'll try to bisect this.
An even simpler test case is:
extern void abort (void)
__asm__ ("foo_abort")
;
Commenting out the __asm__ bit cures the 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=44291
[Bug middle-end/44291] [4.6 regression] ICE in set_user_assembler_libfunc
--- Comment #3 from mikpe at it dot uu dot se 2010-06-02 20:36 --- It's caused by r159455: Author: rguenth Date: Sun May 16 14:47:38 2010 New Revision: 159455 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159455 Log: 2010-05-16 Richard Guenther * lto-symtab.c (lto_symtab_entry_hash): Use IDENTIFIER_HASH_VALUE. * optabs.c (libfunc_decl_hash): Likewise. * varasm.c (emutls_decl): Likewise. fortran/ * trans-decl.c (module_htab_decls_hash): Use IDENTIFIER_HASH_VALUE. Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/lto-symtab.c trunk/gcc/optabs.c trunk/gcc/varasm.c See also http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01167.html Reverting just the change to optabs.c eliminates the ICE. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44291
[Bug bootstrap/44335] [4.6 regression] gcc-4.6-20100529 java bootstrap failure on arm-linux-gnueabi
--- Comment #3 from mikpe at it dot uu dot se 2010-06-06 15:42 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00472.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44335
[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code
--- Comment #16 from mikpe at it dot uu dot se 2010-06-06 19:16 --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00481.html I tried to use the existing stack tie instead of a full barrier, but it had no effect at all, causing the mis-schedules to reappear. I also tried to port over the PowerPC version of the stack tie, but that ICEd the compiler; I'm not yet good enough at .md hackery to resolve that one. So I went back to the initial patch, and bootstrapped and regtested it in native builds of 4.6, 4.5, and 4.4 on armv5tel-linux-gnueabi. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644
[Bug target/44392] [4.5/4.6 Regression] libgcc compile with --enable-target-optspace (-Os) causes recursion in __bswapsi2
--- Comment #3 from mikpe at it dot uu dot se 2010-06-06 19:54 --- I've looked at this, and as far as I can tell it's caused by two separate improvements in 4.5 that are Ok individually but cause libgcc's __bswapsi2 to call itself when combined (and certain build options are selected). 1. The middle-end now recognises C idioms for bswap and represents them as calls to the builtin bswap. 2. The ARM backend now generates much better code for the builtin bswap, but for archs prior to ARMv6 when -Os is enabled the .md expander arranges to have a libcall emitted instead. Consequently, then building for (say) ARMv5 with --enable-target-optspace: a) the middle-end represents the C bswap idiom in libgcc2.c:__bswapsi2 () as a call to the builtin b) the ARM backend (not knowing it's compiling libgcc) emits a libcall c) hence __bswapsi2 () calls itself The only way I see around this is to add a compiler option (-fin-libgcc say), set it when compiling libgcc routines (similar to -DIN_LIBGCC2), check for it in the ARM bswap expander, and if set ignore -Os in the arch < v6 case. -- 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=44392
[Bug bootstrap/44458] Bootstrap fails on arm_float_words_big_endian implicit declaration when Ada on arm-linux
--- Comment #2 from mikpe at it dot uu dot se 2010-06-08 08:19 --- The same error occurs for java on ARM, see PR44335. I posted a patch to fix that one (must include both tm.h and tm_p.h in jcf-parse.c) that but so far has gotten no response to it. -- 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=44458
[Bug rtl-optimization/44484] New: [4.6 regression] revision 160260 caused sparc64 testsuite failures
Between gcc-4.6-20100529 and gcc-4.6-20100605 a number of new testsuite FAILs appeared on sparc64-linux: === gfortran tests === FAIL: gfortran.fortran-torture/execute/forall_7.f90 execution, -O2 -fomit-frame-pointer -finline-functions -funroll-loops FAIL: gfortran.fortran-torture/execute/forall_7.f90 execution, -O3 -g === libgomp tests === FAIL: libgomp.c/nestedfn-3.c (test for excess errors) WARNING: libgomp.c/nestedfn-3.c compilation failed to produce executable FAIL: libgomp.c/nestedfn-4.c (test for excess errors) WARNING: libgomp.c/nestedfn-4.c compilation failed to produce executable FAIL: libgomp.c/task-2.c (test for excess errors) WARNING: libgomp.c/task-2.c compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O1 (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O1 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O2 (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O2 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -O3 -g (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -O3 -g compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic1.f90 -Os (test for excess errors) WARNING: libgomp.fortran/omp_atomic1.f90 -Os compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O1 (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O1 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O2 (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O2 compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -O3 -g (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -O3 -g compilation failed to produce executable FAIL: libgomp.fortran/omp_atomic2.f90 -Os (test for excess errors) WARNING: libgomp.fortran/omp_atomic2.f90 -Os compilation failed to produce executable I've traced this to r160260 (fix PR39871, PR40615, PR42500, PR42502). Some intermediate revisions cause bootstrap breakage making a bisection difficult, but reverting r160260 from gcc-4.6-20100605 eliminates the FAILs above. Although most FAILs are for Fortran, there are also three C-only libgomp tests that now FAIL. Compare also http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00316.html (r160217, libgomp) http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg02923.html (r160038, fortran and libgomp) with http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00454.html (r160287, libgomp) http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00590.html (r160330, fortran and libgomp) I'll check tomorrow if any of these are reproducible with a cross-compiler. -- Summary: [4.6 regression] revision 160260 caused sparc64 testsuite failures Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikpe at it dot uu dot se GCC build triplet: sparc64-unknown-linux-gnu GCC host triplet: sparc64-unknown-linux-gnu GCC target triplet: sparc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug rtl-optimization/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #1 from mikpe at it dot uu dot se 2010-06-11 21:07 --- Created an attachment (id=20896) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20896&action=view) task-2.c test case from libgomp's test suite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug rtl-optimization/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #2 from mikpe at it dot uu dot se 2010-06-11 21:09 --- Created an attachment (id=20897) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20897&action=view) broken -S output from gcc-4.6-20100605 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug rtl-optimization/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #3 from mikpe at it dot uu dot se 2010-06-11 21:10 --- Created an attachment (id=20898) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20898&action=view) working -S output from gcc-4.6-20100605 with r160260 reverted -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug rtl-optimization/44484] [4.6 regression] revision 160260 caused sparc64 testsuite failures
--- Comment #4 from mikpe at it dot uu dot se 2010-06-11 21:27 --- The bug is easily observed with a cross to sparc64-linux, using e.g. the task-2.c test case in libgomp's libgomp.c test suite. Diffing the -S output of 4.6-20100605 vanilla (bad) with the same where r160260 has been reverted (ok), we see: --- task-2.s-bad2010-06-11 22:45:02.0 +0200 +++ task-2.s-ok 2010-06-11 22:51:56.0 +0200 @@ -5,20 +5,21 @@ .proc 020 f2._omp_fn.1: .register %g2, #scratch + .register %g3, #scratch add %sp, -192, %sp lduw[%o0+12], %g1 st %g1, [%sp+2235] lduw[%o0+8], %g2 cmp %g2, 10 bne,pt %icc, .LL7 -nop +add%sp, 2235, %g3 ba,pt %xcc, .LL9 sub%sp, -192, %sp .LL5: .LL7: membar 15 add %g1, 1, %g2 - cas [%sp+2235], %g1, %g2 + cas [%g3], %g1, %g2 cmp %g1, %g2 bne,pt %icc, .LL5 mov%g2, %g1 So what r160260 did was to replace [%g3] in the cas instruction with [%sp+2235], which doesn't work because cas cannot use [reg+offset] addressing modes, it only accepts [reg] addressing modes. Attempting to assemble these files confirms: > sparc64-unknown-linux-as task-2.s-ok > sparc64-unknown-linux-as task-2.s-bad task-2.s-bad: Assembler messages: task-2.s-bad:21: Error: Illegal operands task-2.s-bad:48: Error: Illegal operands To compile task-2.c I used sparc64-unknown-linux-gcc -mcpu=v9 -fmessage-length=0 -fopenmp -O2 -S task-2.c (the -mcpu=v9 may be redundant, but that's what the libgomp test suite did on the actual sparc64 box). My sparc64 cross is configured simply with --target=sparc64-unknown-linux --enable-languages=c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44484
[Bug bootstrap/44458] [4.6 Regression] Bootstrap fails on arm_float_words_big_endian implicit declaration when Ada on arm-linux
--- Comment #4 from mikpe at it dot uu dot se 2010-06-12 21:26 ---
(In reply to comment #3)
> Fixing by reverting Steven patch is not enough to regain bootstrap on arm,
> here
> is the error during stage2:
This is a new unrelated error caused by r160458. You should IMO have opened a
new PR for it. Anyway, the patch below should fix it. Tested in a cross so
far, I'll do a native bootstrap of 4.6 head + this tomorrow. The declaration
bug for 'vec' is obvious. The fact that 'op1' is extracted but unused makes me
a bit nervous.
--- gcc-4.6-r160458/gcc/config/arm/arm.c.~1~
+++ gcc-4.6-r160458/gcc/config/arm/arm.c
@@ -11457,13 +11457,12 @@ thumb2_reorg (void)
rtx dst = XEXP (pat, 0);
rtx src = XEXP (pat, 1);
rtx op0 = XEXP (src, 0);
- rtx op1 = XEXP (src, 1);
if (rtx_equal_p (dst, op0)
|| GET_CODE (src) == PLUS || GET_CODE (src) == MINUS)
{
rtx ccreg = gen_rtx_REG (CCmode, CC_REGNUM);
rtx clobber = gen_rtx_CLOBBER (VOIDmode, ccreg);
- rtx vec = gen_rtvec (2, pat, clobber);
+ rtvec vec = gen_rtvec (2, pat, clobber);
PATTERN (insn) = gen_rtx_PARALLEL (VOIDmode, vec);
INSN_CODE (insn) = -1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44458
[Bug objc++/44518] New: [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
On 4_5-branch, the objc++ encode-2.mm and encode-3.mm tests started to fail
recently on several platforms:
FAIL: obj-c++.dg/encode-2.mm scan-assembler
{?={Vec=ddi}{Vec=ffi}fd{Vec=cci}i}
FAIL: obj-c++.dg/encode-3.mm -fgnu-runtime execution test
Compare e.g.
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00958.html (s390x, r160516)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00567.html (arm, r160235)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00364.html (powerpc64,
r160235)
with
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01078.html (s390x, r160582)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01249.html (arm, r160582)
http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg01118.html (powerpc64,
r160582)
I suspect the PR32052 backport in r160541.
Testsuite results before and after the corresponding trunk commit (r158958)
show a similar regression. Compare e.g.
http://gcc.gnu.org/ml/gcc-testresults/2010-04/msg02848.html (powerpc64,
r158910)
with
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00161.html (powerpc64,
r158969)
--
Summary: [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm
fail on several platforms
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #4 from mikpe at it dot uu dot se 2010-06-13 16:42 --- (In reply to comment #3) > powerpc*-darwin9 passes and, apparently, *86*-linux-gnu (I checked Lu's > output) I've scanned the gcc-testresults list archive for May and June quite carefully, and I don't think anyone is testing obj-c++ on i686 or x86_64 linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #5 from mikpe at it dot uu dot se 2010-06-13 16:49 ---
Created an attachment (id=20903)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20903&action=view)
correction to encode-2.mm
On powerpc64 encode-2.mm fails because the test case scans the assembly output
for the string "{?={Vec=ddi}{Vec=ffi}fd{Vec=cci}i}", but
on
powerpc64 it is "{?={Vec=ddi}{Vec=ffi}fd{Vec=CCi}i}".
Note the different case for the "CC" part. That's because the test case
instantiates a Vec with plain char and expects it to mangle to "c". However,
plain char maps to either signed or unsigned char depending on the machine, and
those two types mangle differently. Apparently "c" corresponds to signed char.
Adjusting the test case to explicitly say "signed char" fixes it on powerpc64.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #8 from mikpe at it dot uu dot se 2010-06-13 17:15 ---
On ARM encode-2.mm fails in part for the same "plain char mangles differently"
reason as on powerpc64, but also due to a backend oddity. Here's how the
string is output in the assembly file on ARM:
.ascii "{?={Vec=ddi}{Vec=ffi}fd{Vec=CC"
.ascii "i}i}\000"
For some reason the ARM backend breaks not very long string literals into
chunks. That's ok in principle because the data is correct in the object file,
but it means that testsuite "scan-assembler" operations become unreliable.
Ideally the test should scan the object file for the string instead, but there
doesn't seem to be a way to do that.
It seems gcc on i686 will also break up long string literals, but it allows for
much much longer strings before doing that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44518] [4.5/4.6 regression] objc++ encode-2.mm and encode-3.mm fail on several platforms
--- Comment #10 from mikpe at it dot uu dot se 2010-06-13 17:42 --- Created an attachment (id=20904) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20904&action=view) correction to encode-3.mm The powerpc64 failure in encode-3.mm was also caused by a plain char mangling difference. This patch fixes it by explicitly using 'signed char'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44518
[Bug testsuite/44538] New: [4.5/4.6 regression] PR43949 fix caused gcc.dg/vect/slp-perm-{5,6}.c to fail
Since the PR43949 fix was backported to 4_5-branch I'm seeing
FAIL: gcc.dg/vect/slp-perm-5.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-perm-6.c scan-tree-dump-times vect "vectorized 1 loops" 1
in testsuite results on powerpc64-linux. They also fail on trunk since PR43949
was fixed there.
Before the PR43949 fix we had one "vectorized 1 loops" message in slp-perm-5:
> fgrep 'vectorized 1 loops' slp-perm-5.c.110t.vect
slp-perm-5.c:24: note: vectorized 1 loops in function.
but after the fix we have two:
> fgrep 'vectorized 1 loops' slp-perm-5.c.110t.vect
slp-perm-5.c:24: note: vectorized 1 loops in function.
slp-perm-5.c:47: note: vectorized 1 loops in function.
Since scan-tree-dump-times .. 1 .. expects exactly one such message, the test
case is now considered to have failed.
Perhaps artificially prevent the other loop from ever being vectorized?
--
Summary: [4.5/4.6 regression] PR43949 fix caused gcc.dg/vect/slp-
perm-{5,6}.c to fail
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44538
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
--- Comment #2 from mikpe at it dot uu dot se 2010-06-16 21:25 --- With crosses to armv5tel-unknown-linux-gnueabi, gcc-4.3 and 4.4 work but a recent 4.5 ICEs as described here. This stopped ICEing in 4.6 with r160260, an ira/reload patch. However, that was just an improvement fixing a number of missed-optimization PRs (PR39871, R40615, PR42500, PR42502) with no ARM backend changes, so I suspect there's a bug here still latent on trunk. I'll try a bisect next to see which revision introduced the ICE. -- mikpe at it dot uu dot se changed: What|Removed |Added CC| |mikpe at it dot uu dot se Summary|internal compiler error: in |internal compiler error: in |gen_thumb_movhi_clobber, at |gen_thumb_movhi_clobber, at |config/arm/arm.md:5811 |config/arm/arm.md:5811 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
--- Comment #3 from mikpe at it dot uu dot se 2010-06-17 13:51 --- The ICE was introduced in 4.5 by r146904, an ira tweak for a missed optimization (PR39914) with no ARM specific bits. That change was then applied to 4.4 in r147081, and indeed that caused 4.4 branch to ICE too. I'll bisect 4.4 next to see what stopped the ICE between r147081 and now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[Bug target/44557] internal compiler error: in gen_thumb_movhi_clobber, at config/arm/arm.md:5811
--- Comment #4 from mikpe at it dot uu dot se 2010-06-19 17:56 ---
I my earlier tests I failed to notice that this test case triggers one of two
different ICEs, depending on options and compiler version. I also mistakenly
tested with a locally modified gcc-4.4.
The ICE in this PR, in gen_thumb_movhi_clobber, is triggered by r147270 +
r147274, updates to loop-invariant.c part of PR33928 fixes with no ARM specific
bits. Another ICE, in default_secondary_reload, is triggered by r146904.
Which ICE you get depends on -f{no-,}forward-propagate. Both ICEs disappear if
r146904 is reverted. gcc-4.4.4 includes a backport or r146904 and does trigger
the default_secondary_reload ICE. gcc-4.3.4 does not ICE.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44557
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #18 from mikpe at it dot uu dot se 2010-06-20 18:26 --- (In reply to comment #5) > Unfortunately I don't see this happening on the x86_64-linux -> > arm-linux-gnueabi cross compiler I built for myself. You need to build a cross to arm-eabi not arm-linux-gnueabi to see the bug. The two ABIs apparently have different data layout rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #2 from mikpe at it dot uu dot se 2010-06-21 09:47 --- Seen also with 4.6 and 4.5 arm-unknown-linux-gnueabi toolchains at -O0, 4.4 and 4.3 don't trigger it. I'm pretty sure I've seen another thumb out of range branch PR not too long ago. -- 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=44603
[Bug target/44603] out of range branch generated in thumb code.
--- Comment #3 from mikpe at it dot uu dot se 2010-06-21 10:09 --- Dupe of PR43961? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44603
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #20 from mikpe at it dot uu dot se 2010-06-21 10:44 --- (In reply to comment #19) > Configuration options for i386-linux and x86_64-linux hosts for both > binutils and gcc would be very much appreciated. I don't know if you can build the c++ frontend without libstdc++, but the latter seem to require a libc, so I had to do a 4-step build with newlib: Common options for binutils, gcc, and newlib: --target=arm-unknown-eabi --prefix=/../cross-arm-eabi Initial C-only gcc: --enable-languages=c --disable-libssp Use that to build and install newlib. Final gcc with c++: --enable-languages=c,c++ --with-newlib -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug c++/44328] switch/case optimization produces an invalid lookup table index
--- Comment #21 from mikpe at it dot uu dot se 2010-06-21 11:18 --- (In reply to comment #20) > (In reply to comment #19) > > Configuration options for i386-linux and x86_64-linux hosts for both > > binutils and gcc would be very much appreciated. > > I don't know if you can build the c++ frontend without libstdc++, ... You can. Just build gcc with --target=arm-unknown-eabi --enable-languages=c,c++ --disable-libstdc++-v3 --disable-libssp. No newlib needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
[Bug target/43961] [ARM thumb] "branch out of range" with thumb1_output_casesi
--- Comment #5 from mikpe at it dot uu dot se 2010-06-22 12:22 --- It's caused by r148770, which is when Richard Earnshaw added compressed switch table support for Thumb-1. See also: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01698.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43961
[Bug target/43961] [ARM thumb] "branch out of range" with thumb1_output_casesi
--- Comment #6 from mikpe at it dot uu dot se 2010-06-22 12:28 --- Created an attachment (id=20979) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20979&action=view) proposed fix for PR43961 Update ARM's ADDR_VEC_ALIGN to correctly describe that its ASM_OUTPUT_CASE_LABEL will add a 2-byte alignment directive for Thumb-1 compressed switch tables. This fixes the test cases (both the PR43961 and the PR44603 one) for me. Untested beyond that, will include in full bootstraps and regtests shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43961
[Bug target/44634] [4.4 regression] ICE in change_address_1, at emit-rtl.c:1954
--- Comment #2 from mikpe at it dot uu dot se 2010-06-22 14:51 --- Dupe of PR42868. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44634
[Bug target/44626] [4.4 regression] ICE in output_operand: invalid expression as operand
--- Comment #2 from mikpe at it dot uu dot se 2010-06-22 18:14 --- Created an attachment (id=20982) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20982&action=view) backport Nathan Sidwell's movw fix to 4.4 This ICE was fixed for 4.5 by r148788, Nathan Sidwell's "[ARM] movw fix", see http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01358.html. The attached patch backports that fix to current 4.4, which fixes the ICE. I've had this in my 4.4 tree since July 2009, so I'm confident it's solid. Matthias, does this patch work for you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44626
[Bug target/44631] [sparc] long long to double conversion error
--- Comment #4 from mikpe at it dot uu dot se 2010-06-23 12:12 --- Created an attachment (id=20986) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20986&action=view) test long long to double runtime conversions Making the constant signed rather than unsigned makes no difference. I converted the test case to do the conversions at runtime and to print the hex representations of the long long and double values. Here's some results: > gcc -O2 -m32 -mcpu=v8 pr44631.c ; ./a.out 97979797979797980 (0x015c181b6dc019dc) -> 9.79798e+16 (0x4375c181b6dc019e) 72057594037927936 (0x0100) -> 7.20576e+16 (0x4370) 72057594037927935 (0x00ff) -> 7.20576e+16 (0x4370) This looks fine, but the topmost two values have been rounded. > gcc -O2 -m32 -mcpu=v9 pr44631.c ; ./a.out 97979797979797980 (0x015c181b6dc019dc) -> 2.47804e+17 (0x438b83036db8033c) 72057594037927936 (0x0100) -> 1.44115e+17 (0x4380) 72057594037927935 (0x00ff) -> 7.20576e+16 (0x4370) Note the discontinuity. Looks to me like fxtod fails to round and instead produces a large jump in the exponent. Does gcc assume some specific setting in FSR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug testsuite/44701] New: [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c
PR44492 was fixed in r161328. This revision changed the generated code for
asm-es-2.c as follows:
--- asm-es-2.s-ok
+++ asm-es-2.s-bad
@@ -23,9 +23,10 @@
f2:
.p2align 4,,15
.L3:
+ addi 3,3,16
#APP
# 14 "gcc-4.6-20100626/gcc/testsuite/gcc.target/powerpc/asm-es-2.c" 1
- asm2u 16(3)
+ asm2 0(3)
# 0 "" 2
#NO_APP
b .L3
Since asm-es-2.c contains
/* { dg-final { scan-assembler "asm2u 16\\(3\\)" } } */
the code doesn't match causing the test case to now FAIL.
--
Summary: [4.6 regression] PR44492 fix broke
gcc.target/powerpc/asm-es-2.c
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44701
[Bug testsuite/44701] [4.6 regression] PR44492 fix broke gcc.target/powerpc/asm-es-2.c
--- Comment #2 from mikpe at it dot uu dot se 2010-06-29 11:00 ---
(In reply to comment #1)
> - asm ("asm2%U0 %0" : "=m" (*p));
> + asm ("asm2%U0 %0" : "=m<>" (*p));
That fixed the test case. Thanks. I didn't know about the PowerPC-specific %U
thing, but now I see that the compiler did the right thing.
Seems like the descriptions of "m" and "es" in the PowerPC-specific part of
md.texi are now a bit stale: "es" should be equivalent to "m", and "m" should
be safe (free of side-effects) unless accompanied by "<" or ">".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44701
[Bug target/44626] [4.4 regression] ICE in output_operand: invalid expression as operand
--- Comment #5 from mikpe at it dot uu dot se 2010-07-03 19:53 --- (In reply to comment #4) > Can this patch be submitted to gcc-patc...@gcc.gnu.org after due testing ? Yes. Although I've tested this many times it's always been together with many other patches. I'm now running a 4.4 bootstrap+regtest with only this one applied. Will submit the patch once that succeeds, which should be less than 24 hours from now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44626
[Bug c/44806] 4.5.0 i686 code generation regression with -O2
--- Comment #1 from mikpe at it dot uu dot se 2010-07-03 20:44 --- This test case works for me on i686-linux with gcc-4.5-20100701, but fails with gcc-4.5.0. So it should be fixed in 4.5.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44806
[Bug target/44626] [4.4 regression] ICE in output_operand: invalid expression as operand
--- Comment #6 from mikpe at it dot uu dot se 2010-07-04 19:54 --- Patch posted after successful (re)testing: http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00331.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44626
[Bug middle-end/44738] c-c++-common/uninit-17.c failed
--- Comment #3 from mikpe at it dot uu dot se 2010-07-04 20:10 ---
Also seen on {powerpc64,sparc64}-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44738
[Bug bootstrap/44820] New: [4.6 regression] ARM bootstrap failure: regno set but unused in arm_attr_length_move_neon
gcc-4.6-20100703 fails during stage 2 of bootstrap on ARM: /home/mikpe/gcc-4.6-20100703/gcc/config/arm/arm.c: In function 'arm_attr_length_move_neon': /home/mikpe/gcc-4.6-20100703/gcc/config/arm/arm.c:12868:7: error: variable 'regno' set but not used [-Werror=unused-but-set-variable] 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 Given the location of the error the cause is obviously Jie Zhang's recent patch which added arm_attr_length_move_neon, namely r161776. I'll attach a preliminary patch momentarily. -- Summary: [4.6 regression] ARM bootstrap failure: regno set but unused in arm_attr_length_move_neon 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=44820
[Bug bootstrap/44820] [4.6 regression] ARM bootstrap failure: regno set but unused in arm_attr_length_move_neon
--- Comment #1 from mikpe at it dot uu dot se 2010-07-05 08:57 --- Created an attachment (id=21089) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21089&action=view) delete unused ut set variable regno This obvious patch gets me past this point in the bootstrap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44820
[Bug bootstrap/44820] [4.6 regression] ARM bootstrap failure: regno set but unused in arm_attr_length_move_neon
--- Comment #4 from mikpe at it dot uu dot se 2010-07-05 10:00 --- Thank you Jie for the swift action. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44820
[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
[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
