--- 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
--- 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
--- 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
--- 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
--- 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
--- 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=20979action=view)
proposed fix for PR43961
Update ARM's ADDR_VEC_ALIGN to correctly describe that its
ASM_OUTPUT_CASE_LABEL will add
--- 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
--- 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=20982action=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
--- 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=20986action=view)
test long long to double runtime conversions
Making the constant signed rather than unsigned makes no difference.
I
/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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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=21089action=view)
delete unused ut set variable regno
This obvious patch gets me past this point in the bootstrap.
--
http
--- 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
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
--- 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
--- 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 #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 #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 #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 #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 #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 #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
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 #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
--- 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 #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 #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 #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 #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
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 #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
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 #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
--- 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
: 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 #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
--- 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
: 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 #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
--- 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 #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-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 #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 #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
301 - 400 of 422 matches
Mail list logo
