--- 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
--- 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
--- 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
--- 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
--- 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 |
--- 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
--- 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
--- 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/sho
--- 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 regis
--- 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* } } */
Howe
--- 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
--- 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
--- 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 ..
--- 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
--- 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
--- 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
--- 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)
--- 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
--- 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
--- 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
--- 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
--- 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 cro
--- 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/b
--- Comment #10 from ubizjak at gmail dot com 2008-11-18 22:06 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- 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|
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
ubizjak at gmail dot com changed:
What|Removed |Added
CC|rth at gcc dot gnu dot org |
BugsThisDependsOn||37908
Status
--- 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
--- 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 d
--- 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
--- Comment #4 from ubizjak at gmail dot com 2008-11-22 14:21 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 patc
--- 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
--- 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)
+++ sy
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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 in
--- 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
--- 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
--- 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
--- 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
--- 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 b
--- 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
--- 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/li
--- 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.
--- 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
--- 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
--- 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
--- 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 chan
--- 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 predic
--- 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
--
ubizjak at gmail dot com changed:
What|Removed |Added
Summary|10% performance regression |[4.3/4.4 Regression] 10%
|since Nov 1 on Polyhedron&#
--
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
--- 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
--- 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
--- 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&qu
--- 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/tre
--- 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 th
--- 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
--- 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
--- 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&q
--- 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
--- 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
--- 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 the
--- 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 a
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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@ mailin
--- 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/bu
--- 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 |Ad
1 - 100 of 6720 matches
Mail list logo
