[Bug target/38090] [4.4 Regression] Internal compiler error: in extract_insn while building linux-kernel from git with -Os or -O1 and higher
--- Comment #3 from ubizjak at gmail dot com 2008-11-12 16:30 --- The testcase compiles OK with GNU C (GCC) version 4.4.0 20081112 (experimental) [trunk revision 141785] (x86_64-unknown-linux-gnu) -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38090
[Bug c/38096] optimization regression
--- Comment #1 from ubizjak at gmail dot com 2008-11-12 21:29 --- The paste of the ICE itself would be nice indeed: pr38096.c: In function foo: pr38096.c:13: internal compiler error: in vectorizable_store, at tree-vect-transform.c:5447 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38096
[Bug c/38096] optimization regression
--- Comment #2 from ubizjak at gmail dot com 2008-11-12 21:31 --- *** This bug has been marked as a duplicate of 37955 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38096
[Bug tree-optimization/37955] [4.4 Regression] internal compiler error: in vectorizable_store, at tree-vect-transform.c:5447
--- Comment #12 from ubizjak at gmail dot com 2008-11-12 21:31 --- *** Bug 38096 has been marked as a duplicate of this bug. *** -- ubizjak at gmail dot com changed: What|Removed |Added CC||mariah dot lenox at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37955
[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused
--- Comment #27 from ubizjak at gmail dot com 2008-11-13 14:58 --- I wouldn't call this problem an enhancement. Matrix computations are affected by this problem. -- ubizjak at gmail dot com changed: What|Removed |Added Severity|enhancement |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug target/27855] [4.3/4.4 regression] reassociation causes the RA to be confused
--- Comment #26 from ubizjak at gmail dot com 2008-11-13 14:52 --- (In reply to comment #25) > Now that we have a new RA, is this still an issue? Yes. TYPE=double: gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc: atlasmm 60 1000 0.196 2203.95 gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math atlasmm 60 1000 0.276 1565.12 TYPE=float: gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math -fno-tree-reassoc atlasmm 60 1000 0.160 2699.83 gcc -DREPS=1000 -msse3 -O2 -mfpmath=sse -ffast-math atlasmm 60 1000 0.232 1861.96 gcc version 4.4.0 20081113 (experimental) [trunk revision 141819] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug testsuite/37517] gcc.target/i386/quad-sse.c fails with -fPIC
--- Comment #5 from ubizjak at gmail dot com 2008-11-13 18:07 ---
We are checking for certain function calls, so following should work too:
Index: quad-sse.c
===
--- quad-sse.c (revision 141824)
+++ quad-sse.c (working copy)
@@ -18,4 +18,4 @@
return __builtin_copysignq (x, y);
}
-/* { dg-final { scan-assembler-not "call" } } */
+/* { dg-final { scan-assembler-not "call.*(neg|fabs|copysign)" } } */
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-13 18:07:22
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37517
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #11 from ubizjak at gmail dot com 2008-11-14 07:16 --- (In reply to comment #9) > This patch: > > http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00593.html Oh, I forgot to manually merge struct-layout-1.h part. Fill fix ASAP. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #12 from ubizjak at gmail dot com 2008-11-14 07:40 --- (In reply to comment #8) > Let me know if I need to provide anything else to debug this. Again, this test > case passes completely if I delete the second line of t027_test.h. The problem is, that %mm0 register is accessed in check2601(), as can be seen from t027_y.s assembler dump. This access blocks stack registers in check2601va(), so the check fails at this point. My patch disables all access to MMX registers, so V1DImode should be handled by generic moves. However, IIRC darwin doesn't use MMX registers to pass function args/return values. From t027_y.s dump that you provided, it is evident that check2601() returns its structure with only v1di member in %mm0. Is this OK? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #13 from ubizjak at gmail dot com 2008-11-14 09:00 ---
Oh, I see the problem.
We generate:
/* { dg-options " -mno-mmx" { target i?86-*-* x86_64-*-* } } */
/* { dg-options " -fno-common { target ... *-*-darwin *-*-mingw32*
*-*-cygwin* } } */
However, x86 darwin, mingw32 and cygwin* matches both lines. Since dg-options
don't concatenate, latest match simply overwrites all previous matches.
So, these targets simply overwrite -mno-mmx option.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #14 from ubizjak at gmail dot com 2008-11-14 09:49 --- The problem from Comment #9 is now fixed in mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug testsuite/37517] gcc.target/i386/quad-sse.c fails with -fPIC
--- Comment #8 from ubizjak at gmail dot com 2008-11-14 11:18 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37517
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #16 from ubizjak at gmail dot com 2008-11-14 14:46 ---
(In reply to comment #15)
> I do recall that I tried...
>
> * { dg-options " -mno-mmx" { target i?86-*-* x86_64-*-* } } */
> /* { dg-options " -fno-common -mno-mmx { target ... *-*-darwin
> *-*-mingw32*
> *-*-cygwin* } } */
>
> and that causes many more tests in struct-layout-1 to fail.
This should work now. You have to remove inclusion of mmintrin.h and
xmmintrin.h for -mno-mmx, otherwise you will get the same problem as shown in
Comment #9 on targets where -msse2 is the default (this includes x86 darwin).
Fortunatelly, this is pure testsuite problem, see Comment #13.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug testsuite/38099] tmpdir-gcc.dg-struct-layout-1/t027 c_compat_x_tst.o-c_compat_y_tst.o execute failure
--- Comment #19 from ubizjak at gmail dot com 2008-11-15 10:59 --- (In reply to comment #17) > Current gcc trunk, r141877, still fails... Please read Comment #13 why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38099
[Bug c/38134] gcc-4.4 speed regression with sse code
--- Comment #2 from ubizjak at gmail dot com 2008-11-15 16:46 --- Can you try with -fno-ira? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug target/38120] missing space in x86 assembly code for some mov instructions
--- Comment #1 from ubizjak at gmail dot com 2008-11-16 14:16 --- Can you send us a patch? -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|translation |target Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu|x86-unknown-linux-gnu Last reconfirmed|-00-00 00:00:00 |2008-11-16 14:16:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38120
[Bug testsuite/38151] tmpdir-gcc.dg-struct-layout-1/t028 failure at -m64 on i686-apple-darwin9
--- Comment #9 from ubizjak at gmail dot com 2008-11-16 20:28 ---
(In reply to comment #8)
> This failing testcase produces the following in gdb...
> #0 0x7fff83829ee6 in __kill ()
> #1 0x7fff8389af4d in abort ()
> #2 0x00010f6f in main ()
> (gdb)
>
> Is there anything else I can provide to debug this?
Yes: compile all three testfiles with -g flag added, put a watchpoint on
"fails" variable (watch fails) and see where it triggers.
It looks to me that something is wrong with s2848 argument that is passed to
check2848 function. At calling site (in test2848 function), we have:
(gdb) print s2848
$10 = {a = 4027477739, b = -936922831153888968, c = 0x601720}
and in check2848 we receive:
(gdb) print arg0
$11 = {a = 4195077, b = 3221252723567493120, c = 0x7fffde0e11a0}
The structure is defined as:
struct S2848
{
unsigned int a;
_Complex int __attribute__ ((aligned (1))) b;
struct
{
} __attribute__ ((packed, aligned)) c[1];
};
Hm, looks like a real bug to me.
This also fails on linux, I'll try to create a testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug testsuite/38151] structures with _Complex arguments are not passed correctly
--- Comment #10 from ubizjak at gmail dot com 2008-11-16 20:58 ---
Real bug with argument passing. Confirmed on x86_64-linux-gnu with the
testcase:
--cut here--
struct S2848
{
unsigned int a;
_Complex int b;
};
struct S2848 s2848;
void __attribute__((noinline))
check2848 (struct S2848 arg0)
{
if (arg0.b != s2848.b)
abort ();
}
int main()
{
s2848.a = 4027477739U;
s2848.b = (723419448 + -218144346 * __extension__ 1i);
check2848 (s2848);
return 0;
}
--cut here--
> gcc -O2 t.c
> ./a.out
Aborted
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC||hjl at gcc dot gnu dot org,
||hubicka at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC host triplet|i686-apple-darwin9 |
GCC target triplet|i686-apple-darwin9 |x86_64
Keywords||ABI, wrong-code
Known to fail||4.3.0 4.4.0
Last reconfirmed|-00-00 00:00:00 |2008-11-16 20:58:10
date||
Summary|tmpdir-gcc.dg-struct-layout-|structures with _Complex
|1/t028 failure at -m64 on |arguments are not passed
|i686-apple-darwin9 |correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug testsuite/38151] structures with _Complex arguments are not passed correctly
--- Comment #11 from ubizjak at gmail dot com 2008-11-16 21:09 ---
Also fails in return from function:
--cut here--
struct S2848
{
unsigned int a;
_Complex int b;
};
struct S2848 s2848;
struct S2848 __attribute__((noinline))
check2848 (struct S2848 arg0)
{
s2848.a = 4027477739U;
s2848.b = (723419448 + -218144346 * __extension__ 1i);
return s2848;
}
int main()
{
struct S2848 ret;
ret = check2848 (s2848);
if (ret.b != s2848.b)
abort ();
return 0;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/37033] [4.4 Regression] Revision 138733 breaks -g vs -g0 for PCH
--- Comment #9 from ubizjak at gmail dot com 2008-11-17 12:27 --- We can add -fno-dwarf2-cfi-asm to gcc.dg/pch/valid-1b.hs to suppress definition of __GCC_HAVE_DWARF2_CFI_ASM in -g case. Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00807.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00807.html Status|UNCONFIRMED |NEW Component|debug |target Ever Confirmed|0 |1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2008-11-17 12:27:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37033
[Bug target/38134] [4.4 Regression] speed regression with inline-asm sse code
--- Comment #6 from ubizjak at gmail dot com 2008-11-17 18:11 --- I think that addps .LC10(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC11(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC12(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC13(%rip), %xmm0 mulps %xmm1, %xmm0 addps .LC14(%rip), %xmm0 mulps %xmm1, %xmm0 is the bottleneck. Perhaps we should split impilicit memory operands out of the insn by some generic peephole (if the register is available) and schedule loads appropriately. OTOH, loop optimizer should detect invariant loads and move them out of the loop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38134
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #5 from ubizjak at gmail dot com 2008-11-18 00:11 --- (In reply to comment #4) > Using top-of-stack GCC and Binutils from Nov 17, issue still present; Applied > the below patch and re-tried, no change in behavior. Fails the same way... This one is tested with a cross and works for me: Index: mips.md === --- mips.md (revision 141951) +++ mips.md (working copy) @@ -4537,7 +4537,7 @@ rtx low = mips_subword (operands[0], 0); rtx high = mips_subword (operands[0], 1); emit_insn (gen_store_word (low, operands[1], const0_rtx)); - if (ISA_HAS_MXHC1) + if (register_operand (high, mode) && ISA_HAS_MXHC1) emit_insn (gen_mfhc1 (high, operands[1])); else emit_insn (gen_store_word (high, operands[1], const1_rtx)); -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-18 00:11:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #7 from ubizjak at gmail dot com 2008-11-18 08:09 --- Created an attachment (id=16716) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16716&action=view) Patch with a testcase This patch solves all issues with mthc1 and mfhc1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug target/37362] [4.4 Regression] Bootstrap broken on mipsisa64r2-linux-gcc
--- Comment #10 from ubizjak at gmail dot com 2008-11-18 22:06 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg00920.html Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37362
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #12 from ubizjak at gmail dot com 2008-11-19 19:32 --- Created an attachment (id=16723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16723&action=view) Da patch. Jack, can you try attached patch? -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #13 from ubizjak at gmail dot com 2008-11-19 21:17 --- (In reply to comment #12) > Created an attachment (id=16723) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16723&action=view) [edit] > Da patch. > > Jack, can you try attached patch? Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01010.html It looks we still fail va_arg cases. But number of failures with the original testcase drops from 10 to 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #16 from ubizjak at gmail dot com 2008-11-20 19:50 ---
Problems from Comment #10 and Comment #11 are fixed by the patch from Comment
#13, but following test still fails, even with a patched compiler:
--cut here--
void abort (void);
struct S2848
{
unsigned int a;
_Complex int b;
struct
{
} __attribute__ ((aligned)) c;
};
struct S2848 s2848;
int fails;
void __attribute__((noinline))
check2848va (int z, ...)
{
struct S2848 arg;
__builtin_va_list ap;
__builtin_va_start (ap, z);
arg = __builtin_va_arg (ap, struct S2848);
if (s2848.a != arg.a)
++fails;
if (s2848.b != arg.b)
++fails;
__builtin_va_end (ap);
}
int main (void)
{
s2848.a = 4027477739U;
s2848.b = (723419448 + -218144346 * __extension__ 1i);
check2848va (1, s2848);
if (fails)
abort ();
return 0;
}
--cut here--
> gcc -O2 t1.c
> ./a.out
Aborted
> gdb ./a.out
[...]
(gdb) watch fails
Hardware watchpoint 1: fails
(gdb) run
Starting program: /home/uros/test/compat/a.out
Hardware watchpoint 1: fails
Old value = 0
New value = 1
0x0040051d in check2848va (z=1) at t1.c:29
29 ++fails;
Missing separate debuginfos, use: debuginfo-install glibc.x86_64
(gdb) p /x arg.b
$2 = 0x004005802b1e8138
(gdb) p /x s2848.b
$3 = 0xf2ff61a62b1e8138
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #18 from ubizjak at gmail dot com 2008-11-20 21:13 --- va_arg problem from Comment #16 remains unfixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #19 from ubizjak at gmail dot com 2008-11-20 21:37 --- Hm, rdx gets corrupted: check2848va: .LFB0: .cfi_startproc movq%rsi, %rcx # tmp73, leaq8(%rsp), %rax #, (+) movq%rdx, -40(%rsp) #, shrq$32, %rcx #, cmpl%esi, s2848(%rip) # tmp73, s2848.a >>> movq-80(%rsp), %rdx #, tmp74 movq%rax, -112(%rsp)#, .overflow_arg_area leaq-56(%rsp), %rax #, movq%rsi, -48(%rsp) #, movl$8, -120(%rsp) #, .gp_offset movq%rsi, -88(%rsp) # tmp70, movq%rax, -104(%rsp)#, .reg_save_area movq%rsi, -72(%rsp) # tmp73, arg movq%rdx, -64(%rsp) # tmp74, arg je .L4 #, addl$1, fails(%rip) #, fails .L4: cmpl%ecx, s2848+4(%rip) # arg$b$real, s2848.b setne %cl #, tmp79 (++)cmpl%edx, s2848+8(%rip) # arg$b$imag, s2848.b setne %al #, tmp82 orb %al, %cl# tmp82, tmp79 je .L6 #, addl$1, fails(%rip) #, fails rdx is saved at the point of (+), corrupted at ">>>" and this corrupted value is used at (++). The insn at ">>>" just falls in the insn stream from the sky, it is not present if "a" is changed to "unsigned long" in S2848 structure. In case when "a" is changed to "unsigned long", testcase works OK. The testcase also works when insn at ">>>" is removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #2 from ubizjak at gmail dot com 2008-11-21 17:22 --- H.J. can probably confirm this. -- ubizjak at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, ubizjak at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug c/38217] gcc.dg/sync-2.c and gcc.dg/sync-3.c fail execution test on powerpc-apple-darwin9
--- Comment #5 from ubizjak at gmail dot com 2008-11-21 17:23 --- *** This bug has been marked as a duplicate of 38213 *** -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38217
[Bug testsuite/38213] gcc.dg/ia64-sync-1.c and gcc.dg/ia64-sync-2.c execution tests fails on powerpc-apple-darwin9
--- Comment #7 from ubizjak at gmail dot com 2008-11-21 17:23 --- *** Bug 38217 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38213
[Bug testsuite/38213] gcc.dg/ia64-sync-1.c and gcc.dg/ia64-sync-2.c execution tests fails on powerpc-apple-darwin9
-- ubizjak at gmail dot com changed: What|Removed |Added CC|rth at gcc dot gnu dot org | BugsThisDependsOn||37908 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-21 17:25:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38213
[Bug testsuite/38221] FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line )
--- Comment #1 from ubizjak at gmail dot com 2008-11-22 10:11 --- This test is there to check that at least one message about changed NAND semantics per file is generated. x86_64 does: ~/gcc-build/gcc/cc1 -O0 -w -quiet sync-3.c sync-3.c: In function test_op_ignore: sync-3.c:74: note: __sync_fetch_and_nand changed semantics in GCC 4.4 Does PA somehow bypass standard expansion of __sync intrinsics? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38221
[Bug testsuite/38222] gcc.target/i386/sse4_2-popcntl.c fails on i686-apple-darwin9
--- Comment #2 from ubizjak at gmail dot com 2008-11-22 10:22 ---
(In reply to comment #1)
> GNU assembler supports both
>
> popcntl %edx, %eax
> popcnt %edx, %eax
>
> I guess we can just generate
>
> popcnt %edx, %eax
No, we won't cripple the output due to assembler bugs.
I will add a configure check for broken assembler, it is the same situation as
with sun as and ffreep insn (and some version of gnu as with sahf insn).
--
ubizjak at gmail dot com changed:
What|Removed |Added
----
CC|ubizjak at gmail dot com|
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-22 10:22:47
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38222
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #21 from ubizjak at gmail dot com 2008-11-22 12:33 --- This is a trace what happens in the testcase, from .expand dump: (2) [frame + 8 ]<- si (3) [frame + 16]<- dx (4) r62 <- di (8) r63 <- virtual-incoming-args + 0 (9) r64 <- virtual-stack-vars - 64 (10) [r64] <- 8;; gp_offset (11) r65<- virtual-stack-vars - 64 (12) [r65 + 8 ] <- virtual-incoming-args;; overflow_arg_area (13) r66<- virtual-stack-vars - 64 (14) [r66 + 16] <- frame;; reg_save_area (15) r61<- [virtual-stack-vars - 64];; gp_offset if (r61 > 39) goto label 27 (19) r67<- virtual-stack-vars - 32 (20) r68<- zext (r61) (21) r69<- [virtual-stack-vars - 48];; reg_save_area (22) r70<- [r69 + r68] (23) [r67] <- r70 (24) r58<- virtual-stack-vars - 32 goto label 32 label 27: (29) r72<- [virtual-stack-vars - 56];; overflow_arg_area (30) r71<- r72 + 15 (31) r58<- r71 & -16 label 32: (34) r73<- [r58] (35) [virtual-stack-vars - 16] <- r73 (36) r74<- [r58 + 8] (37) [virtual-stack-vars - 8 ] <- r74 (38) r60<- [virual-stack-vars - 12] ;; arg$b$real (39) r59<- [virual-stack-vars - 8 ] ;; arg$b$imag So, around insn (22), gcc forgets to copy dx register to reg_save_area. r74 is then read from uninitialized reg_save_area slot. I'm looking at va-arg handling implementation in i386.c. But I'm not familiar with this code, so a bit of help would be most welcome here. -- ubizjak at gmail dot com changed: What|Removed |Added -------------------- AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug testsuite/38222] gcc.target/i386/sse4_2-popcntl.c fails on i686-apple-darwin9
--- Comment #4 from ubizjak at gmail dot com 2008-11-22 14:21 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01175.html Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38222
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #22 from ubizjak at gmail dot com 2008-11-22 17:07 ---
Aliasing problems, gcc shoots himself in the foot...
When container consists of registers in different modes (due to
X86_64_INTEGERSI_CLASS optimization):
(parallel:BLK [
(expr_list:REG_DEP_TRUE (reg:DI 0 ax)
(const_int 0 [0x0]))
(expr_list:REG_DEP_TRUE (reg:SI 1 dx)
(const_int 8 [0x8]))
])
then ix86_gimplify_va_arg happily creates code with invalid aliasing (from
_.gimple dump):
addr.0 = &va_arg_tmp.3;
> addr.4 = (long unsigned int *) addr.0;
int_addr.5 = (long unsigned int *) int_addr.1;
D.1615 = *int_addr.5;
*addr.4 = D.1615;
> addr.6 = (unsigned int *) addr.0;
D.1617 = addr.6 + 8;
We access addr.0 as (long unsigned int *) and as (unsigned int *. Following
optimization passes are more than happy to remove the second access.
So to prove my point, testcase compiled with -fno-strict-aliasing works OK.
These problems also apply to FPmode parameters passing through SSE regs, so
following patch moves registers from register area to tmp area in generic mode
that fits argument passing registers best: DImode for integer and V4SFmode for
SSE registers. This avoids aliasing problems.
Index: i386.c
===
--- i386.c (revision 142120)
+++ i386.c (working copy)
@@ -6750,7 +6750,8 @@ ix86_gimplify_va_arg (tree valist, tree
{
rtx slot = XVECEXP (container, 0, i);
rtx reg = XEXP (slot, 0);
- enum machine_mode mode = GET_MODE (reg);
+ enum machine_mode mode
+ = SSE_REGNO_P (REGNO (reg)) ? V4SFmode : DImode;
tree piece_type = lang_hooks.types.type_for_mode (mode, 1);
tree addr_type = build_pointer_type (piece_type);
tree src_addr, src;
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2008-11-16 20:58:10 |2008-11-22 17:07:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug testsuite/38221] FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for warnings, line )
--- Comment #4 from ubizjak at gmail dot com 2008-11-22 18:27 --- Ah, this is gcc-4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38221
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #7 from ubizjak at gmail dot com 2008-11-22 18:29 --- Patch that implements "memory_barrier" for x86 at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01181.html -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01181.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-22 18:29:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #25 from ubizjak at gmail dot com 2008-11-22 19:30 --- Deassigning me, this is tree stuff. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #4 from ubizjak at gmail dot com 2008-11-24 15:05 --- The sbitmap.i works for me with ~/gcc-build-43/gcc/cc1 -O2 -march=amdfam10 -mcx16 -msahf -fprofile-generate --param l1-cache-size=64 --param l1-cache-line-size=64 where GNU C (GCC) version 4.3.3 20081110 (prerelease) [gcc-4_3-branch revision 141732] (i686-pc-linux-gnu) and GNU C (GCC) version 4.4.0 20081121 (prerelease) [trunk revision 142081] (i686-pc-linux-gnu) Can you try latest 4.3 branch? -- ubizjak at gmail dot com changed: What|Removed |Added Known to work||4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #5 from ubizjak at gmail dot com 2008-11-24 15:29 --- BTW: You should report this bug to: with-bugurl=http://bugs.gentoo.org/ -- ubizjak at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug target/38177] Internal compiler error during gcc build with -march=amdfam10
--- Comment #7 from ubizjak at gmail dot com 2008-11-24 16:00 --- (In reply to comment #6) > I've already spoken to one of the GCC maintainers for gentoo - he advised me > to > report the issue directly upstream if I could reproduce it without > gentoo-specific patches (which I have); this could be an issue with how the The trick is, that gentoo maintainer should first check if the bug is already fixed in the SVN (on the branch they are using). The maintainer _should_ track the SVN branch head to filter out bugs that are already fixed. Please see http://gcc.gnu.org/bugs.html#dontwant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38177
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #10 from ubizjak at gmail dot com 2008-11-24 16:59 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/38254] [4.4 Regression] Revision 142160 causes PR27908 -O3
--- Comment #1 from ubizjak at gmail dot com 2008-11-24 22:35 ---
OK, we need a full memory clobber, as in sse2_mfence case.
I'm testing this patch:
Index: sync.md
===
--- sync.md (revision 142160)
+++ sync.md (working copy)
@@ -36,19 +36,22 @@
(unspec:BLK [(match_dup 0)] UNSPEC_MFENCE))]
""
{
- if (!TARGET_SSE2)
-{
- /* Emit a locked no-operation when SSE2 is not available. */
- int slot = virtuals_instantiated ? SLOT_TEMP : SLOT_VIRTUAL;
- rtx temp = assign_386_stack_local (QImode, slot);
- emit_insn (gen_sync_iorqi (temp, CONST0_RTX (QImode)));
- DONE;
-}
-
operands[0] = gen_rtx_MEM (BLKmode, gen_rtx_SCRATCH (Pmode));
MEM_VOLATILE_P (operands[0]) = 1;
})
+(define_insn "*memory_barrier_nosse"
+ [(set (match_operand:BLK 0 "" "")
+ (unspec:BLK [(match_dup 0)] UNSPEC_MFENCE))]
+ "!TARGET_SSE2"
+{
+ if (TARGET_64BIT)
+return "lock{%;| }or{q}\t{$0, (%%rsp)|QWORD PTR [rsp], 0}";
+ else
+return "lock{%;| }or{l}\t{$0, (%%esp)|DWORD PTR [esp], 0}";
+}
+ [(set_attr "memory" "unknown")])
+
;; ??? It would be possible to use cmpxchg8b on pentium for DImode
;; changes. It's complicated because the insn uses ecx:ebx as the
;; new value; note that the registers are reversed from the order
--
ubizjak at gmail dot com changed:
What|Removed |Added
--------------------
AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-11-24 22:35:07
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38254
[Bug c++/38253] g++.dg/ipa/iinline-1.C scan-ipa-dump inline fails on powerpc-apple-darwin9
--- Comment #2 from ubizjak at gmail dot com 2008-11-24 23:07 --- (In reply to comment #1) > Created an attachment (id=16763) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16763&action=view) [edit] > assembly file for g++.dg/ipa/iinline-1.C on powerpc-apple-darwin9 Please attach an _.inline dump (produced with -fdump-ipa-inline). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38253
[Bug target/38254] [4.4 Regression] Revision 142160 causes PR27908 -O3
--- Comment #2 from ubizjak at gmail dot com 2008-11-25 00:16 --- Subject: Bug 38256 Author: uros Date: Tue Nov 25 00:12:15 2008 New Revision: 142177 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142177 Log: PR target/38254 * config/i386/sync.md (memory_barrier_nosse): New insn (memory_barrier): Generate memory_barrier_nosse insn for !TARGET_SSE2. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sync.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38254
[Bug target/38254] [4.4 Regression] Revision 142160 causes PR27908 -O3
--- Comment #3 from ubizjak at gmail dot com 2008-11-25 00:16 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38254
[Bug c++/38256] [4.4 regression] ICE with "operator auto"
--- Comment #2 from ubizjak at gmail dot com 2008-11-25 00:17 --- (In reply to comment #1) > Subject: Bug 38256 Oops, wrong PR number in ChangeLog. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38256
[Bug target/36793] x86-64 does not get __sync_synchronize right
--- Comment #11 from ubizjak at gmail dot com 2008-11-25 09:15 --- Should we fix __sync_synchronize in 4.3 too? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36793
[Bug target/38288] i386/i386.c: 7 * set but not used variables
--- Comment #2 from ubizjak at gmail dot com 2008-11-28 13:28 --- (In reply to comment #1) > I've sent a patch to gcc-patches. Can you paste the URL to the patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38288
[Bug target/38320] missed movd opcode (32bits mm -> r/m32).
--- Comment #3 from ubizjak at gmail dot com 2008-11-30 11:43 --- (In reply to comment #2) > and what about 32-bits? The quote from i386.c: /* ??? This is a lie. We do have moves between mmx/general, and for mmx/sse2. But by saying we need secondary memory we discourage the register allocator from using the mmx registers unless needed. */ if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)) return true; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38320
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #30 from ubizjak at gmail dot com 2008-12-01 18:26 --- (In reply to comment #29) > Other compilers do this kind of transformation via reverse copy propagation. > GCC could perhaps add something like that too, when it transforms a 3-address > insn to a 2-address insn. Will this also solve PR 19398, where we have: fstps -4(%ebp) (*) movss -4(%ebp), %xmm0 (*) cvttss2si %xmm0, %eax leave Note, that we could simply have: cvttss2si -4(%ebp), %eax -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug middle-end/37908] atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand
--- Comment #17 from ubizjak at gmail dot com 2008-12-10 09:55 --- Fixed on 4.4 branch, WONTFIX on earlier branches. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37908
[Bug target/38213] gcc.dg/ia64-sync-1.c and gcc.dg/ia64-sync-2.c execution tests fails on powerpc*-*-*
--- Comment #8 from ubizjak at gmail dot com 2008-12-10 09:57 --- Fixed by http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01500.html -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38213
[Bug testsuite/38163] gcc.dg/tree-ssa/loop-3.c failure at -m64 on i686-apple-darwin9
--- Comment #4 from ubizjak at gmail dot com 2008-12-12 22:41 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38163
[Bug target/34256] mmx and movd/movq on x86_64
--- Comment #11 from ubizjak at gmail dot com 2008-12-13 19:29 --- (In reply to comment #10) > FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 4 PR 37364 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34256
[Bug bootstrap/37349] [4.4 Regression] bootstrap broken on Alpha: undefined reference to _Jv_RegisterClasses
--- Comment #7 from ubizjak at gmail dot com 2008-12-14 10:41 --- (In reply to comment #6) > Has this been fixed in the meantime? > > Uros, you wrote in > http://gcc.gnu.org/ml/gcc/2008-12/msg00228.html that bootstrap works > on Alpha... Yes, bootstrap works. I have bootstrapped gcc on gcc30 cfarm machine a couple of times, last bootstrap from a clean directory was yesterday. Bootstrap produces working compiler: u...@sarah:~/gcc-build/gcc$ ./xgcc -v Using built-in specs. Target: alphaev56-unknown-linux-gnu Configured with: ../gcc-svn/trunk/configure --enable-languages=c,c++,fortran Thread model: posix gcc version 4.4.0 20081213 (experimental) [ revision ] (GCC) u...@sarah:~/gcc-build/gcc$ And from (still running) testrun: --cut here-- LAST_UPDATED: samedi 13 décembre 2008, 16:52:13 (UTC+) (revision ) Native configuration is alphaev56-unknown-linux-gnu === gcc tests === Running target unix Compiler version: gcc gcc Platform: alphaev56-unknown-linux-gnu configure flags: --enable-languages=c,c++,fortran BOOT_CFLAGS=-g -O2 --cut here-- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37349
[Bug c/38521] -masm=intel, struct output for __asm__() block causes gcc to ask for bug report.
--- Comment #1 from ubizjak at gmail dot com 2008-12-14 11:18 ---
There were many problems with -masm=intel, that were fixed for gcc-4.3 and
later by [1] and (many) followup patches. The change that you are looking for
is (gcc/config/i386/i386.c):
@@ -9037,8 +9047,9 @@ print_operand (FILE *file, rtx x, int co
else if (MEM_P (x))
{
- /* No `byte ptr' prefix for call instructions. */
- if (ASSEMBLER_DIALECT == ASM_INTEL && code != 'X' && code != 'P')
+ /* No `byte ptr' prefix for call instructions or BLKmode operands. */
+ if (ASSEMBLER_DIALECT == ASM_INTEL && code != 'X' && code != 'P'
+ && GET_MODE (x) != BLKmode)
{
const char * size;
switch (GET_MODE_SIZE (GET_MODE (x)))
However, this is just one of many changes to properly support -masm=intel, so
my best advice is to use gcc-4.3.x. This won't be fixed for gcc-4.2.
[1] http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01254.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Known to work||4.3.0
Resolution||WONTFIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38521
[Bug c++/38525] sse2(int16) code fails with -O3
--- Comment #2 from ubizjak at gmail dot com 2008-12-14 19:29 --- I can't compile the attachment: g++ -O3 -fpreprocessed u-array.ii In file included from /home/lvv/p/lvv/sse.h:23, from /home/lvv/p/lvv/array.h:35, from u-array.cc:10: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In function float __vector__ _mm_addsub_ps(float __vector__, float __vector__): [...] However, since you already found a failing test, please reduce your source to a short, self contained runtime testcase (in plain C if possible) that fails with certain compile flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug c++/38525] sse2(int16) code fails with -O3
--- Comment #3 from ubizjak at gmail dot com 2008-12-14 19:31 --- (In reply to comment #2) > /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In > function float __vector__ _mm_addsub_ps(float __vector__, float __vector__): g++ -O3 -fpreprocessed u-array.ii In file included from /home/lvv/p/lvv/sse.h:23, from /home/lvv/p/lvv/array.h:35, from u-array.cc:10: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h: In function float __vector__ _mm_addsub_ps(float __vector__, float __vector__): /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include/pmmintrin.h:53: error: __builtin_ia32_addsubps was not declared in this scope [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38525
[Bug target/38544] missed opportunity to use adc
--- Comment #1 from ubizjak at gmail dot com 2008-12-17 08:56 --- There are various scary comments in ifcvt.c, noce_process_if_block() regarding memory operands, like: /* Only operate on register destinations, and even then avoid extending the lifetime of hard registers on small register class machines. */ and /* Don't operate on sources that may trap or are volatile. */ and /* Avoid store speculation: given "if (...) x = a" where x is a MEM, we only want to do the store if x is always set somewhere in the function. This avoids cases like if (pthread_mutex_trylock(mutex)) ++global_variable; where we only want global_variable to be changed if the mutex is held. FIXME: This should ideally be expressed directly in RTL somehow. */ I don't think it is always safe to simplify global memory operands. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544
[Bug rtl-optimization/38544] missed opportunity to use adc
--- Comment #2 from ubizjak at gmail dot com 2008-12-17 08:58 --- Setting Component to Generic RTL optimization. -- ubizjak at gmail dot com changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38544
[Bug libmudflap/28077] [4.2/4.3 regression] pass39-frag.c produces mudflap violation on alpha
--- Comment #5 from ubizjak at gmail dot com 2008-12-18 15:31 --- This does not fail on 4.4 [1] branch. [1] http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01564.html -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.2/4.3/4.4 regression]|[4.2/4.3 regression] pass39- |pass39-frag.c produces |frag.c produces mudflap |mudflap violation on alpha |violation on alpha http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28077
[Bug target/34571] [4.3/4.4 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #15 from ubizjak at gmail dot com 2008-12-18 15:36 --- (In reply to comment #14) > Patch exists, tested and all, and just needs a re-test and then submit... I will re-bootstrap/re-test this patch. Will take some days to retest. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|rask at gcc dot gnu dot org |ubizjak at gmail dot com Status|ASSIGNED|UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug target/34571] [4.3/4.4 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #16 from ubizjak at gmail dot com 2008-12-18 19:53 --- (In reply to comment #15) > I will re-bootstrap/re-test this patch. Will take some days to retest. It looks to me, that we need to fix this from the other side. According to the comment above symbolic_operand predicate, we should also accept label_ref with an offset, so: Index: varasm.c === --- varasm.c(revision 142326) +++ varasm.c(working copy) @@ -3710,7 +3710,7 @@ /* FALLTHRU */ case LABEL_REF: - tmp = XEXP (x, 0); + tmp = XEXP (tmp, 0); gcc_assert (!INSN_DELETED_P (tmp)); gcc_assert (!NOTE_P (tmp) || NOTE_KIND (tmp) != NOTE_INSN_DELETED); Index: config/alpha/predicates.md === --- config/alpha/predicates.md (revision 142326) +++ config/alpha/predicates.md (working copy) @@ -390,7 +390,8 @@ (ior (match_code "symbol_ref,label_ref") (and (match_code "const") (match_test "GET_CODE (XEXP (op,0)) == PLUS -&& GET_CODE (XEXP (XEXP (op,0), 0)) == SYMBOL_REF +&& (GET_CODE (XEXP (XEXP (op,0), 0)) == SYMBOL_REF +|| GET_CODE (XEXP (XEXP (op,0), 0)) == LABEL_REF) && GET_CODE (XEXP (XEXP (op,0), 1)) == CONST_INT" ;; Return true if OP is valid for 16-bit DTP relative relocations. BTW: The fix to varasm.c is already in mainline, need to backport 2008-03-31 James E. Wilson * varasm.c (output_constant_pool_1): In LABEL_REF check, use tmp consistently. BTW: The test doesn't fail anymore neither on 4.4 and neither on 4.3 branch. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-18 19:53:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug target/34571] [4.3 Regression] Segfault in alpha_expand_mov at -O3
--- Comment #18 from ubizjak at gmail dot com 2008-12-22 17:53 --- Patch [1] was committed to 4.4 mainline, needs to be backported to 4.3, together with varasm.c change. [1] http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01127.html -- ubizjak at gmail dot com changed: What|Removed |Added Summary|[4.3/4.4 Regression]|[4.3 Regression] Segfault in |Segfault in alpha_expand_mov|alpha_expand_mov at -O3 |at -O3 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34571
[Bug target/34163] [4.3/4.4 Regression] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64
-- ubizjak at gmail dot com changed: What|Removed |Added Summary|10% performance regression |[4.3/4.4 Regression] 10% |since Nov 1 on Polyhedron's |performance regression since |"NF" on AMD64 |Nov 1 on Polyhedron's "NF" ||on AMD64 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug target/34163] [4.3/4.4 Regression] 10% performance regression since Nov 1 on Polyhedron's "NF" on AMD64
-- ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|4.3.4 |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34163
[Bug middle-end/38652] [4.4 Regression] dse.c: In function get_call_args: dse.c:2309: error: target undeclared
--- Comment #3 from ubizjak at gmail dot com 2008-12-29 12:40 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38652
[Bug target/31488] va_list considered non-POD
--- Comment #3 from ubizjak at gmail dot com 2008-12-29 20:39 ---
The testcase:
#include
extern int foo (int a, int b, ...);
int bar (int a, int b, ...)
{
va_list args;
va_start (args, b);
int result = foo (a, b, args);
va_end (args);
return result;
}
g++ -O2:
pod.C: In function int bar(int, int, ...):
pod.C:9: warning: cannot pass objects of non-POD type struct va_list through
...; call will abort at runtime
--
ubizjak at gmail dot com changed:
What|Removed |Added
OtherBugsDependingO||38664
nThis||
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-12-29 20:39:29
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug target/31488] va_list considered non-POD
--- Comment #4 from ubizjak at gmail dot com 2008-12-29 20:42 ---
Preprocessed source, can be compiled with a crosscompiler:
--cut here--
# 1 "pod.C"
# 1 ""
# 1 ""
# 1 "pod.C"
# 1 "/usr/lib/gcc/alpha-linux-gnu/4.2.4/include/stdarg.h" 1 3 4
# 43 "/usr/lib/gcc/alpha-linux-gnu/4.2.4/include/stdarg.h" 3 4
typedef __builtin_va_list __gnuc_va_list;
# 105 "/usr/lib/gcc/alpha-linux-gnu/4.2.4/include/stdarg.h" 3 4
typedef __gnuc_va_list va_list;
# 2 "pod.C" 2
extern int foo (int a, int b, ...);
int bar (int a, int b, ...)
{
va_list args;
__builtin_va_start(args,b);
int result = foo (a, b, args);
__builtin_va_end(args);
return result;
}
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug c++/31488] va_list considered non-POD
--- Comment #6 from ubizjak at gmail dot com 2008-12-29 20:57 --- (In reply to comment #2) > It is *not* represented as an array on Alpha. But as a RECORD_TYPE. Following patch cures the warning: Index: cp/tree.c === --- cp/tree.c (revision 142948) +++ cp/tree.c (working copy) @@ -2113,6 +2113,9 @@ pod_type_p (const_tree t) argument unmodified and we assign it to a const_tree. */ t = strip_array_types (CONST_CAST_TREE(t)); + if (TREE_CODE (t) == RECORD_TYPE) +return 1; + if (t == error_mark_node) return 1; if (INTEGRAL_TYPE_P (t)) -- ubizjak at gmail dot com changed: What|Removed |Added CC| |ubizjak at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug c++/31488] va_list considered non-POD
--- Comment #8 from ubizjak at gmail dot com 2008-12-29 23:29 ---
(In reply to comment #7)
> if (! CLASS_TYPE_P (t))
> return 0; /* other non-class type (reference or function) */
> if (CLASSTYPE_NON_POD_P (t))
> return 0;
> return 1;
>
> One of those two should be set correctly.
In alpha/alpha.c we have:
alpha_build_builtin_va_list (void)
{
tree base, ofs, space, record, type_decl;
if (TARGET_ABI_OPEN_VMS || TARGET_ABI_UNICOSMK)
return ptr_type_node;
record = (*lang_hooks.types.make_type) (RECORD_TYPE);
type_decl = build_decl (TYPE_DECL, get_identifier ("__va_list_tag"), record);
TREE_CHAIN (record) = type_decl;
TYPE_NAME (record) = type_decl;
/* C++? SET_IS_AGGR_TYPE (record, 1); */
...
So, actually there is no way we can SET_CLASS_TYPE_P (t, 1) on the created
RECORD_TYPE. IOW, we should somehow be able to reach cp/lex.c/make_class_type
() function from target .c file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug c++/31488] va_list considered non-POD
--- Comment #9 from ubizjak at gmail dot com 2008-12-30 14:45 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01280.html -- ubizjak at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||12/msg01280.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug c++/31488] [4.3/4.4 Regression] va_list considered non-POD
--- Comment #10 from ubizjak at gmail dot com 2008-12-31 17:02 --- Marking as a regression, testsuite failures are always regressions. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|va_list considered non-POD |[4.3/4.4 Regression] va_list ||considered non-POD Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug target/33717] slow code generated for 64-bit arithmetic
--- Comment #4 from ubizjak at gmail dot com 2009-01-01 17:35 ---
(In reply to comment #3)
> Most likely addsi3_carry should accept 0 as one of the operands.
It does:
(define_insn "addsi3_carry"
[(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r")
(plus:SI (plus:SI (match_operand:SI 3 "ix86_carry_flag_operator" "")
(match_operand:SI 1 "nonimmediate_operand" "%0,0"))
(match_operand:SI 2 "general_operand" "ri,rm")))
(clobber (reg:CC FLAGS_REG))]
It looks to me that cprop_hardreg is the pass to handle this case, at least
this sequence should be handled (to propagate cx):
(insn 74 50 52 3 pr33717.c:12 (parallel [
(set (reg:SI 2 cx [+4 ])
(const_int 0 [0x0]))
(clobber (reg:CC 17 flags))
]) 45 {*movsi_xor} (nil))
(insn 53 52 54 3 pr33717.c:12 (parallel [
(set (reg:SI 4 si [+4 ])
(plus:SI (plus:SI (ltu:SI (reg:CC 17 flags)
(const_int 0 [0x0]))
(reg:SI 4 si [+4 ]))
(reg:SI 2 cx [+4 ])))
(clobber (reg:CC 17 flags))
]) 266 {addsi3_carry} (expr_list:REG_DEAD (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:SI 2 cx [+4 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33717
[Bug target/38706] [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #1 from ubizjak at gmail dot com 2009-01-03 16:57 --- Can you create a reduced testcase? gcc bootstrapped OK a couple of days ago on alphaev56-unknown-linux-gnu (gcc30.fsffrance.org). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug target/38706] [4.4 regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #2 from ubizjak at gmail dot com 2009-01-03 16:58 --- BTW: Did you build from a clean build directory? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug target/38749] native and core2 differ on core2 hardware
--- Comment #3 from ubizjak at gmail dot com 2009-01-07 07:21 --- (In reply to comment #2) > Andrew, ah, right. But then, why output differs? Gentoo does not modifies this > bits... gcc driver has separate checks for CPUID features. So, it first determines CPU model and then adds appropriate flags, derived from CPUID. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38749
[Bug target/38706] [4.4 Regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #7 from ubizjak at gmail dot com 2009-01-07 08:04 --- (In reply to comment #6) > Current trunk bootstraps fine on an other machine, but the testcase fails too > on it. Thanks for the testcase, it fails on a crosscompiler too. I'll look into it. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-01-07 08:04:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug target/38706] [4.4 Regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #8 from ubizjak at gmail dot com 2009-01-07 11:14 --- Created an attachment (id=17045) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17045&action=view) Patch to fix the failure We should not free cfun since it is needed in alpha_end_function. Arthur, can you perhaps bootstrap/regression test the patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug testsuite/33263] [4.3/4.4 regression] libjava testsuite failures on alpha-linux
--- Comment #7 from ubizjak at gmail dot com 2009-01-07 14:02 --- (In reply to comment #0) > FAIL: natgetargssize.cc compilation > FAIL: natgetlocalvartable.cc compilation > FAIL: natgetstacktrace.cc compilation > FAIL: natevents.cc compilation > FAIL: natgetallthreads.cc compilation > FAIL: natgeterrorname.cc compilation > FAIL: natgetmethodname.cc compilation These are in fact due to PR31488. > FAIL: Array_3 execution - source compiled test > FAIL: Array_3 -findirect-dispatch execution - source compiled test > FAIL: Array_3 -O3 execution - source compiled test > FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test > FAIL: G19990303_02 execution - source compiled test > FAIL: G19990303_02 -findirect-dispatch execution - source compiled test > FAIL: G19990303_02 -O3 execution - source compiled test > FAIL: G19990303_02 -O3 -findirect-dispatch execution - source compiled test > FAIL: Invoke_1 execution - source compiled test > FAIL: Invoke_1 -findirect-dispatch execution - source compiled test > FAIL: Invoke_1 -O3 execution - source compiled test > FAIL: Invoke_1 -O3 -findirect-dispatch execution - source compiled test > FAIL: N19990310_02 -O3 output - source compiled test > FAIL: N19990310_02 -O3 -findirect-dispatch output - source compiled test > FAIL: PR218 output - source compiled test > FAIL: PR218 -O3 output - source compiled test > FAIL: StackTrace2 execution - source compiled test > FAIL: StackTrace2 -findirect-dispatch execution - source compiled test > FAIL: StackTrace2 -O3 execution - source compiled test > FAIL: StackTrace2 -O3 -findirect-dispatch execution - source compiled test > FAIL: Throw_2 execution - source compiled test > FAIL: Throw_2 -findirect-dispatch execution - source compiled test > FAIL: Throw_2 -O3 execution - source compiled test > FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test > FAIL: Throw_3 output - source compiled test > FAIL: Throw_3 -findirect-dispatch output - source compiled test > FAIL: Throw_3 -O3 output - source compiled test > FAIL: Throw_3 -O3 -findirect-dispatch output - source compiled test > FAIL: initexc execution - source compiled test > FAIL: initexc -findirect-dispatch execution - source compiled test > FAIL: initexc -O3 execution - source compiled test > FAIL: initexc -O3 -findirect-dispatch execution - source compiled test > FAIL: invokethrow execution - source compiled test > FAIL: invokethrow -findirect-dispatch output - source compiled test > FAIL: invokethrow -O3 execution - source compiled test > FAIL: invokethrow -O3 -findirect-dispatch output - source compiled test > FAIL: pr83 -findirect-dispatch execution - source compiled test > FAIL: pr83 -O3 -findirect-dispatch execution - source compiled test These are due to some strange failure in dejagnu framework on debian alpha. >From my private communication with Matthias Close: --quote-- I'm trying to fix last remaining gcc testsuite errors [0] on Debian alpha gcc (gcc30 cfarm machine) and I tripped on some strange dejagnu/Expect/Tcl error on Debian system. This problem causes following teststuite failures: FAIL: g++.dg/ext/cleanup-10.C execution test FAIL: g++.dg/ext/cleanup-11.C execution test FAIL: g++.dg/ext/cleanup-8.C execution test FAIL: g++.dg/ext/cleanup-9.C execution test FAIL: gcc.dg/cleanup-10.c execution test FAIL: gcc.dg/cleanup-11.c execution test FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test and all remaining libjava test failures, FWIW. These runtime testcases (including java) all work OK when executed directly from the shell (using just built libraries, so all libraries are exactly the same), but fail when run from dejagnu framework. They also fail when executing these test cases through dejagnu with default installed compiler (gcc-4.2.4). The problem is, that SIGSEGV handling is somehow suppressed when run from dejagnu framework. To check this, please put attached sig.c to gcc/testsuite/dg.exp directory and execute "make -k check-gcc RUNTESTFLAGS=dg.exp=sig.c" from gcc/ subdirectory of your build dir. The testcase will fail, OTOH, it will finish without problems when executed directly from the shell. I have noticed, that in some of your testreports, these strange failures happen [1], but some of your testreports doesn't show them [2], [3]. Are these tests performed on the same machine? If not, what is the difference with runtime/testing environments between these test runs? [0] http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg02551.html [1] http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg00182.html [2] http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg01836.html [3] http://gcc.gnu.org/ml/gcc-testresults/2008-12/msg00926.html --/quote-- --quote2-- The question is, why we abort on following dejagnu testcase on alpha systems:
[Bug bootstrap/37349] [4.4 Regression] bootstrap broken on Alpha: undefined reference to _Jv_RegisterClasses
--- Comment #8 from ubizjak at gmail dot com 2009-01-07 14:05 --- Closed as WORKSFORME, since bootstrap - well - works for me. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37349
[Bug ada/36025] "cpu_set_t" not declared in "OS_Interface" compilation problem on alpha
--- Comment #1 from ubizjak at gmail dot com 2009-01-07 14:08 --- Ada stuff. -- ubizjak at gmail dot com changed: What|Removed |Added Component|other |ada http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36025
[Bug target/25687] pwlib 1.8.7 does not build on alpha due with -Os
--- Comment #3 from ubizjak at gmail dot com 2009-01-07 15:37 --- No answer in 3 months. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25687
[Bug target/26879] LibJava not compile under alpha
--- Comment #15 from ubizjak at gmail dot com 2009-01-07 15:38 --- 4.1 is not supported anymore. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26879
[Bug target/29207] gij bus errors on hppa-linux-gnu and alpha-linux-gnu
--- Comment #1 from ubizjak at gmail dot com 2009-01-07 15:39 --- Does this still fail? -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29207
[Bug target/4605] [alpha-osf]mips-tfile & spaced directory names
--- Comment #5 from ubizjak at gmail dot com 2009-01-07 15:40 --- Does this still happen with 4.3 or 4.4 branch? -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4605
[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.
--- Comment #8 from ubizjak at gmail dot com 2009-01-07 15:41 --- Does this still happen with version 4.3 or 4.4? -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7055
[Bug target/8603] [Alpha] s?addl pattern doesn't work
--- Comment #5 from ubizjak at gmail dot com 2009-01-07 17:56 --- Following patch that changes addsi3 and subsi3 expander constraint fixes this problem: --cut here-- Index: alpha.md === --- alpha.md(revision 143157) +++ alpha.md(working copy) @@ -261,7 +261,7 @@ [(set (match_operand:SI 0 "register_operand" "") (plus:SI (match_operand:SI 1 "reg_or_0_operand" "") (match_operand:SI 2 "add_operand" "")))] - "! optimize" + "" "") (define_insn "*addsi_internal" @@ -622,7 +622,7 @@ [(set (match_operand:SI 0 "register_operand" "") (minus:SI (match_operand:SI 1 "reg_or_0_operand" "") (match_operand:SI 2 "reg_or_8bit_operand" "")))] - "! optimize" + "" "") (define_insn "*subsi_internal" --cut here-- With the patch (gcc -O2): f: s4addl $16,$17,$0 ret $31,($26),1 g: s4subl $16,$16,$0 ret $31,($26),1 This regression was introduced by: Sat Feb 23 08:42:47 2002 Richard Kenner * expr.c (store_expr): When converting expression to promoted equivalent type, allow using SUBREG_REG of TARGET as the target of the expansion of EXP. * loop.c (basic_induction_var, case SUBREG): Always look inside. * config/alpha/alpha.c (rtx_equiv_function_matters): Delete decl. (alpha_emit_set_const): Handle SImode when can't make new pseudos. (alpha_emit_set_const_1, alpha_sa_mask): Use no_new_pseudos. * config/alpha/alpha.md (addsi3, subsi3): Don't use if optimizing. And the comment above addsi3 says: ;; Don't say we have addsi3 if optimizing. This generates better code. We ;; have the anonymous addsi3 pattern below in case combine wants to make it. So, is this still true? Can somebody benchmark this patch? We can perhaps look at csibe numbers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8603
[Bug target/38706] [4.4 Regression] ../../../../src/libstdc++-v3/src/strstream.cc:419: internal compiler error: Segmentation fault
--- Comment #12 from ubizjak at gmail dot com 2009-01-07 21:58 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38706
[Bug c++/31488] [4.3/4.4 Regression] va_list considered non-POD
--- Comment #12 from ubizjak at gmail dot com 2009-01-08 07:04 ---
(In reply to comment #11)
> Created an attachment (id=17051)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17051&action=view) [edit]
> Fix in pod_type_p
>
> Uros is testing this patch for me.
This patch bootstraps OK and fixes following libjava FAILs on
alphaev56-unknown-linux-gnu:
-FAIL: natgetargssize.cc compilation
-FAIL: natgetlocalvartable.cc compilation
-FAIL: natgetstacktrace.cc compilation
-FAIL: natevents.cc compilation
-FAIL: natgetallthreads.cc compilation
-FAIL: natgeterrorname.cc compilation
-FAIL: natgetmethodname.cc compilation
The patch was also bootstrapped and regression tested on x86_64-pc-linux-gnu
{,-m32} without any problems.
BTW: Cleaned testcase can be found at [1].
[1] http://gcc.gnu.org/ml/gcc-patches/2008-12/msg01280.html
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|http://gcc.gnu.org/ml/gcc- |
|patches/2008- |
|12/msg01280.html|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31488
[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault
--- Comment #11 from ubizjak at gmail dot com 2009-01-08 13:10 --- Program received signal SIGSEGV, Segmentation fault. record_one_conflict (allocnos_live=0x16103ee8, hard_regs_live=, regno=390007032) at ../../gcc-svn/branches/gcc-4_3-branch/gcc/ra-conflict.c:176 176 word = conflicts[index]; (gdb) bt #0 record_one_conflict (allocnos_live=0x16103ee8, hard_regs_live=, regno=390007032) at ../../gcc-svn/branches/gcc-4_3-branch/gcc/ra-conflict.c:176 #1 0x08535fef in global_conflicts () at ../../gcc-svn/branches/gcc-4_3-branch/gcc/ra-conflict.c:290 #2 0x0850b80d in rest_of_handle_global_alloc () at ../../gcc-svn/branches/gcc-4_3-branch/gcc/global.c:534 #3 0x081d1d43 in execute_one_pass (pass=0x86e38c0) at ../../gcc-svn/branches/gcc-4_3-branch/gcc/passes.c:1122 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault
--- Comment #12 from ubizjak at gmail dot com 2009-01-08 13:55 --- At the point of failure, we have: bitnum = 1024405, index = 32012 (BTW: The function doesn't crash when index = 26677). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault
--- Comment #10 from ubizjak at gmail dot com 2009-01-08 13:03 --- Confirmed, attached testcase fails with -O1 on 4.3 branch, works OK for 4.4 branch. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|x86_64-linux-gnu|i686-linux-gnu Known to fail||4.3.3 Known to work||4.4.0 Last reconfirmed|-00-00 00:00:00 |2009-01-08 13:03:12 date|| Summary|internal compiler error:|[4.3 Regression] internal |Segmentation fault |compiler error: Segmentation ||fault Target Milestone|--- |4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.
--- Comment #12 from ubizjak at gmail dot com 2009-01-08 15:01 --- (In reply to comment #11) > So GCC 4.1 and 4.2 no longer create the problematic definitions, but > nevertheless the problem in mips-tfile is still present. Can you please post your patch to gcc-patches@ mailing list for a review? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7055
[Bug debug/7055] [alpha osf4] G++ 3.1 Produced bad debugging entries if compiled with -gcoff, also segv.
--- Comment #14 from ubizjak at gmail dot com 2009-01-08 15:55 --- (In reply to comment #13) > Note that my original patch is for the 4.1.1 source tree. Should I post it > anyway? Yes, I think that there were no recent changes in this area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7055
[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176
--- Comment #19 from ubizjak at gmail dot com 2009-01-09 07:20 --- (In reply to comment #18) > So, only the ICE is a regression, not the memory-hog, correct? Yes. -- ubizjak at gmail dot com changed: What|Removed |Added Keywords|memory-hog | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
