--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 -, mikpe at it dot uu dot se wrote:
Can you show us
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
: 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
--- 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=21586action=view)
preliminary fixes for arm.c stage2 errors
This gets me past the arm.c stage2 errors.
--
http://gcc.gnu.org
: mikpe at it dot uu dot se
GCC host triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45445
--- 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
--- 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
--- 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
--- 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
--- 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
: 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
--- 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=21511action=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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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=21398action=view)
preprocessed source for _udivmoddi4
In non-parallel builds _udivmoddi4 is always the first module to make cc1 run
out
--- 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=21381action=view)
reduced test case
Here is a 66-line test case, reduced from Ramana's preprocessed source, that
reliably fails
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=21312action=view)
reduced test case in C
You don't need C++ to trigger the bug. Proper C with a function that may
recurse before
--- 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
--- 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
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
--- 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=21306action=view)
preprocessed source for decNumber.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45067
--- 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=21307action=view)
reduced test case
Attaching reduced 9-line test case. The ICE reproduces with a 4.6 cross hosted
on i686-linux
--- 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
--- 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
--- Comment #13 from mikpe at it dot uu dot se 2010-07-25 17:15 ---
endian.h 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
--- 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
--- Comment #10 from mikpe at it dot uu dot se 2010-07-24 08:45 ---
The lkml post is:
http://marc.info/?l=linux-kernelm=127957675305013w=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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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=21290action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=21244action=view)
fix Linux kernel math emulation FP_FROM_INT macro
The bug is in the Linux kernel math-emu code. The _FP_FROM_INT
--- 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=21219action=view)
updated long long to double conversion test
I've updated the test case to try conversions of a larger range of values
--- 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
--- 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=21195action=view)
fix __cxa_type_match and __cxa_begin_cleanup prototypes
Looks like long-standing confusion about the return types
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
1 - 100 of 422 matches
Mail list logo
