--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-01 14:47 ---
See PR32586, there were known miscompare problems around that time.
But they are long time fixed now, if this hasn't been reproduced since then,
then there is no point keeping this bug open.
--
jakub at gc
--- Comment #7 from jakub at gcc dot gnu dot org 2007-11-12 16:20 ---
Testing a fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #9 from jakub at gcc dot gnu dot org 2007-11-12 23:23 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2007-11-12 23:17 ---
Subject: Bug 29225
Author: jakub
Date: Mon Nov 12 23:17:18 2007
New Revision: 130126
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130126
Log:
PR c++/29225
* call.c (build_new_o
--- Comment #4 from jakub at gcc dot gnu dot org 2007-11-20 10:59 ---
The testcase is wrong, static unsigned char sbox[] = {}; means zero sized
array.
But using sbox[256] makes the testcase valid and the problem is still there.
This looks like a bug in can_convert_to_perfect_nest, this
--- Comment #18 from jakub at gcc dot gnu dot org 2007-12-09 19:50 ---
Can this be closed now? Should the testcase (e.g. the #c3 one) go into the
testsuite?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34091
--- You are receiving this mail because: ---
You are on the CC
--- Comment #20 from jakub at gcc dot gnu dot org 2007-12-09 21:31 ---
Fixed for 4.3 then.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2007-12-20 19:39 ---
Yeah, works for me on the trunk too.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34628
--- You are
--- Comment #13 from jakub at gcc dot gnu dot org 2008-02-13 22:24 ---
This is not sufficient.
block_New, nal_get_annexeb, block_ChainGather still don't have prototypes and
thus:
warning: cast to pointer from integer of different size
is reported on each of the casts of these fun
--- Comment #17 from jakub at gcc dot gnu dot org 2008-02-19 17:50 ---
instantiate_type_decl calls tsubst on
chain >
nonlocal VOID file pr34950.C line 7 col 42
align 1 context
and as TYPE_DECL isn't TEMPLATE_DECL, it doesn't bump processing_template_de
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[4.2/4.3 Regression] ICE in |[4.2/4.3/4.4 Regression] ICE
|svn boost math toolkit
--- Comment #1 from jakub at gcc dot gnu dot org 2008-04-28 11:56 ---
Can you reproduce it with a newer snapshot? Can you find out which change
between 0219 and 0227 caused it? There were very few changes that might affect
it at all, I'd say just PR35071, PR35265, PR34971 and PR
--- Comment #3 from jakub at gcc dot gnu dot org 2008-04-28 13:32 ---
Closing then, if you manage to reproduce it again, please reopen with more
details.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from jakub at gcc dot gnu dot org 2008-06-24 14:44 ---
PROGRAM PR35659
DIMENSION A(1000), B(1010), AUX(8), IPIV(8), X(16)
COMMON /TLSDIM/ M1,M,N,L,IER
COMMON /SLATE/ V1,V2,IAR(24),DUM(14)
DATA A/0, 1, 0, 0, 1, 0, 2, 0, 1, 0, 0, 0, 1
--- Comment #12 from jakub at gcc dot gnu dot org 2008-06-24 15:04 ---
Even smaller reproducer:
PROGRAM PR35659
DIMENSION A(1000), B(1010), AUX(8), IPIV(8), X(16)
COMMON /TLSDIM/ M1,M,N,L,IER
COMMON /SLATE/ V1,V2,IAR(24),DUM(14)
DATA A/0, 1, 0, 0, 1, 0, 2
--- Comment #13 from jakub at gcc dot gnu dot org 2008-06-25 10:20 ---
And the miscompiled tlsc.f inline (compile with just -O2):
SUBROUTINE TLSC (A,B,AUX,IPIV,EPS,X)
COMMON /TLSDIM/ M1,M,N,L,IER
COMMON /SLATE/ BETA,H,I,IB,IB1,ID,ID1,IEND,II,IST,J,JA,JB,JK
--- Comment #14 from jakub at gcc dot gnu dot org 2008-06-25 11:31 ---
I have no idea why is speculation even attempted here (it doesn't make any
sense,
the pointer is surely non-NULL, it points to a global variable), and apparently
nothing checks whether it is safe to move ove
--- Comment #15 from jakub at gcc dot gnu dot org 2008-06-25 11:32 ---
Wrong-code bug on secondary arch.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from jakub at gcc dot gnu dot org 2008-06-26 08:01 ---
You can reproduce it with a cross compiler too.
Just use 4.3 branch (IMHO unrelated changes on the trunk made this bug latent)
and don't combine everything into the same file.
The #c12 program+routines have to
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #19 from jakub at gcc dot gnu dot org 2008-06-26 08:41 ---
To be more precise, the problem is in speculating conditional store:
ld4.a r18 = [r44]
st4 [r59] = r14, -60
...
cmp4.ge p6, p7 = r22, r18
(p7) ld4 r14 = [r62]
...
(p7) st4 [r77
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc
--- Comment #10 from jakub at gcc dot gnu dot org 2008-07-31 13:49 ---
This got actually fixed by Alan's PR target/36634 fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed |
--- Comment #11 from jakub at gcc dot gnu dot org 2008-07-31 20:38 ---
Subject: Bug 35100
Author: jakub
Date: Thu Jul 31 20:37:21 2008
New Revision: 138435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=138435
Log:
PR target/35100
* gcc.target/powerpc/lo
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #9 from jakub at gcc dot gnu dot org 2008-10-07 18:50 ---
Subject: Bug 29609
Author: jakub
Date: Tue Oct 7 18:48:40 2008
New Revision: 140948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140948
Log:
PR debug/29609
PR debug/36690
--- Comment #10 from jakub at gcc dot gnu dot org 2008-10-07 19:01 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-14 11:25 ---
Created an attachment (id=16491)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16491&action=view)
libgcc2.i
Indeed, caused by r141077. On the attached preprocessed source reproduceable
with -> s
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-14 11:50 ---
I couldn't reproduce this on powerpc64-linux --with-cpu=default32
--enable-languages=ada, I can only reproduce the var-tracking.c ICE which is
already tracked in PR37815.
--
http://gcc.gnu.org/bug
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-14 11:47 ---
vt_add_function_parameters asserts that REG_EXPR or MEM_EXPR of DECL_RTL of a
PARM decl, if it is non-NULL, is the PARM_DECL itself, but with the r141077
patch when the stack slots may be shared, decl might be
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-29 08:28 ---
I've bootstrapped/regtested the trunk last night on s390-linux just fine.
Can you reproduce this with current trunk (there has been e.g. an IRA fix
for s390* compiler miscompilation)?
If yes, can you say which
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-04 17:46 ---
Bootstrapped it again. Reopen if you still have problems with current
snapshots.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.2
Known to work||4.4.0
--- Comment #5 from jakub at gcc dot gnu dot org 2008-11-16 13:02 ---
*** Bug 38155 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2008-11-16 13:02 ---
*** This bug has been marked as a duplicate of 37739 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2008-12-02 07:59 ---
The bug is elsewhere.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2008-12-02 08:11 ---
I'd like to apologize for the last comment, the bug is related to that change,
just should be fixed on the ccp_fold_builtin side.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38360
--- You are rece
--- Comment #7 from jakub at gcc dot gnu dot org 2008-12-03 16:59 ---
Subject: Bug 38360
Author: jakub
Date: Wed Dec 3 16:57:44 2008
New Revision: 142399
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142399
Log:
PR middle-end/38360
* tree-s
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-03 17:02 ---
Fixed on the trunk so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known
--- Comment #6 from jakub at gcc dot gnu dot org 2008-12-11 10:02 ---
I think this should be P1. While a workaround (such as STAGE1_CFLAGS="-g -O1")
exists, not being able to bootstrap on a primary platform is very severe.
--
jakub at gcc dot gnu dot org changed:
--- Comment #8 from jakub at gcc dot gnu dot org 2008-12-11 16:31 ---
Testing a patch...
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc
--- Comment #10 from jakub at gcc dot gnu dot org 2008-12-19 14:57 ---
Subject: Bug 37739
Author: jakub
Date: Fri Dec 19 14:55:42 2008
New Revision: 142833
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142833
Log:
PR bootstrap/37739
* config.host: For
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-19 14:59 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-02 11:34 ---
That's unexpected. Anyway, if you move away the gch file (or directory), can
you still reproduce it and if yes, attach preprocessed source?
Otherwise it would be extremely hard to reproduce for a
--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-06 13:35 ---
So, referenceCount needs to be in any case nuked from struct __cxa_exception.
IMHO, either we define (probably in a different namespace)
struct __cxa_exception_with_refcount
{
_Atomic_word referenceCount;
struct
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Component|other |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732
--- Comment #15 from jakub at gcc dot gnu dot org 2009-01-07 12:34 ---
Working on it.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-07 13:56 ---
Created an attachment (id=17047)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17047&action=view)
gcc44-pr38732.patch
Patch I'm going to bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #18 from jakub at gcc dot gnu dot org 2009-01-07 22:50 ---
Subject: Bug 38732
Author: jakub
Date: Wed Jan 7 22:50:42 2009
New Revision: 143170
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143170
Log:
PR libstdc++/38732
* libsupc++/unwi
--- Comment #19 from jakub at gcc dot gnu dot org 2009-01-07 22:54 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-30 10:58 ---
Nothing changed in gsf-scan.c, but out of the 3 objects in libgsf.so that
changed it seems to be gsf-output-csv.c where r143570 makes difference for
gsf-scan. Looking at it now...
--
http://gcc.gnu.org/bugzilla
--- Comment #14 from jakub at gcc dot gnu dot org 2009-01-30 11:38 ---
And clearly the bug is in libgsf, not in gcc.
g_enum_register_static documentation says:
GObject keeps a reference to the data, so it cannot be stack-allocated.
so this relies on this optimization
--- Comment #15 from jakub at gcc dot gnu dot org 2009-01-30 11:39 ---
Created an attachment (id=17213)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17213&action=view)
libgsf-enum-register.patch
Patch that fixes this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #16 from jakub at gcc dot gnu dot org 2009-01-30 11:40 ---
Invalid.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #23 from jakub at gcc dot gnu dot org 2009-02-10 18:01 ---
*** Bug 39147 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-04-01 08:49 ---
Related to PR32666.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-20 23:06 ---
Note that powerpc64-linux configured gcc (both with --with-cpu=default32 and
without it, i.e. defaulting to -m32 resp. -m64) weren't exporting these in
64-bit libgcc_s.so.1, checked 4.1 and 4.3.
--
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
--- You
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38293
--- You
--- Comment #13 from jakub at gcc dot gnu dot org 2009-04-22 09:12 ---
If hppa-linux has long double the same as double (which raises the question why
it hasn't switched over to 128-bit long double together with
powerpc*/sparc*/s390*/alpha back in 2006), then __NO_LONG_DOUBLE
--- Comment #15 from jakub at gcc dot gnu dot org 2009-04-22 14:34 ---
Well, double double is IMHO really very problematic format, but only powerpc*
switched to it. alpha, s390* and sparc* use standard IEEE quad long double.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491
--- Comment #21 from jakub at gcc dot gnu dot org 2009-04-23 06:28 ---
Created an attachment (id=17682)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17682&action=view)
glibc-no-long-double-math.patch
I agree that even for __NO_LONG_DOUBLE_MATH we should provide *l pro
--- Comment #29 from jakub at gcc dot gnu dot org 2009-04-28 23:56 ---
The glibc macro AFAIK does:
# define signbit(x) \
(sizeof (x) == sizeof (float)\
? __signbitf (x
--- Comment #30 from jakub at gcc dot gnu dot org 2009-04-28 23:59 ---
Also, libstdc++.so is definitely not the right home for __signbitl symbol, so
we definitely shouldn't allow any newly linked program to use symbol from that
library. If __signbitl is ever needed (prove it), th
--- Comment #5 from jakub at gcc dot gnu dot org 2009-05-06 13:02 ---
Only ceill is actually missing in SVN.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jakub at gcc dot gnu dot org 2009-05-07 07:19 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-01 19:26 ---
Subject: Bug 40462
Author: jakub
Date: Wed Jul 1 19:25:52 2009
New Revision: 149150
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149150
Log:
PR debug/40462
* jump.c (returnjump_p)
--- Comment #2 from jakub at gcc dot gnu dot org 2009-07-21 08:32 ---
Fix I'll be testing:
--- gcc/tree-inline.c.jj2009-05-28 12:50:54.0 +0200
+++ gcc/tree-inline.c 2009-07-21 10:06:28.0 +0200
@@ -1355,8 +1355,8 @@ copy_bb (copy_body_data *id, basic_
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Component|target |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40813
--- Comment #4 from jakub at gcc dot gnu dot org 2009-07-21 14:51 ---
Subject: Bug 40813
Author: jakub
Date: Tue Jul 21 14:51:13 2009
New Revision: 149857
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149857
Log:
PR tree-optimization/40813
* tree-
--- Comment #5 from jakub at gcc dot gnu dot org 2009-07-21 14:59 ---
Subject: Bug 40813
Author: jakub
Date: Tue Jul 21 14:59:43 2009
New Revision: 149858
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149858
Log:
PR tree-optimization/40813
* tree-
--- Comment #6 from jakub at gcc dot gnu dot org 2009-07-21 15:01 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.1 |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40180
--- You
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.1 |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40181
--- You
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.1 |4.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40182
--- You
--- Comment #23 from jakub at gcc dot gnu dot org 2009-07-23 13:36 ---
Can you please
grep xmake_file= gcc/Makefile
in the gcc build directory as well as write what
gcc -Wl,--version
prints? Binutils 2.19 and later have the needed relax fixes I think, so
rs6000/x-linux-relax should be
--- Comment #25 from jakub at gcc dot gnu dot org 2009-07-23 16:56 ---
Is -Wl,--relax passed to the compiler driver when linking the binary that fails
to link then? If yes, you are looking at a ld problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
--- You are
--- Comment #27 from jakub at gcc dot gnu dot org 2009-07-24 09:46 ---
These are small helper programs. The real question is if -Wl,--relax is used
on the gcc line that actually fails with the linker errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37739
--- You are
--- Comment #1 from jakub at gcc dot gnu dot org 2009-08-04 10:04 ---
Can't reproduce, at least not with a x86_64-linux -> s390x-linux cross.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40954
--- You are receiving this mail because: ---
You reported the bug
--- Comment #4 from jakub at gcc dot gnu dot org 2010-09-16 17:13 ---
i?86 is a FLT_EVAL_METHOD 2 target, so for strict C compliance all floating
operations and constants are supposed to be evaluated in the precision
of long double. The assignment of the constant to a double var or
--- Comment #2 from jakub at gcc dot gnu dot org 2009-09-29 16:09 ---
Can't reproduce with x86_64-linux -> s390x-linux cross (-O3 -m31).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41327
--- You are receiving this mail because: ---
You reported the bug, or are
--- Comment #34 from jakub at gcc dot gnu dot org 2009-10-07 13:35 ---
Linker bug, so closing. Workaround also exists, use a non-buggy linker, or use
non-obsolete crt files.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-26 11:23 ---
Can't reproduce.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41621
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
To UNSUBSCRIBE, ema
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-03 12:05 ---
Can anyone reproduce this (with current 4.4 branch)?
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2009-12-07 17:48 ---
Likely dup of PR42317.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42323
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
To UNSUBSCRIBE, email to
--- Comment #4 from jakub at gcc dot gnu dot org 2009-12-08 09:03 ---
You were testing the patch attached here (i.e. version before
bootstrap/regtest) instead of the one posted to gcc-patches (tested), right?
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00385.html
--
http
--- Comment #7 from jakub at gcc dot gnu dot org 2009-12-10 21:59 ---
Subject: Bug 42317
Author: jakub
Date: Thu Dec 10 21:58:49 2009
New Revision: 155143
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155143
Log:
PR c++/42317
* cgraph.h (struct cgr
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-29 12:17 ---
You shouldn't use -fschedule-insns on i?86/x86_64. Vlad made some changes in
4.5 that make -fschedule-insns work in most cases on these arches, but in
4.3/4.4 you definitely shouldn't use them.
--
ja
--- Comment #3 from jakub at gcc dot gnu dot org 2009-12-31 20:43 ---
I couldn't reproduce this either.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42564
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
-
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-02 14:30 ---
With 3 register vars in the function (ebx, edi, esi) on the register starved
ix86 the error is tollerable. From the 8 registers the programmer takes 3,
%esp is fixed, without -fomit-frame-pointer %ebp is fixed too
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-02 16:44 ---
Reduced testcase:
/* { dg-do compile { target { { i?86-*-* x86_64-*-* } && ilp32 } } } */
/* { dg-options "-O2 -fno-gcse" } */
struct C;
struct B { struct C *b; };
struct C { void (*baz) (struc
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-04 15:20 ---
Shorter testcase:
struct S { int a; char b[2147483647]; };
void
foo (void)
{
struct S s;
}
with -m32.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-04 18:17 ---
It is not caused by that commit, just add asm volatile ("" : : "r" (&s)) to the
testcase and you'll reproduce it even before that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=426
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-04 19:19 ---
Created an attachment (id=19465)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19465&action=view)
gcc45-pr42611.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-05 08:43 ---
Subject: Bug 42611
Author: jakub
Date: Tue Jan 5 08:42:53 2010
New Revision: 155641
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155641
Log:
PR other/42611
* cfgexpand.c (expand
--- Comment #9 from jakub at gcc dot gnu dot org 2010-01-05 08:56 ---
Subject: Bug 42611
Author: jakub
Date: Tue Jan 5 08:56:30 2010
New Revision: 155642
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155642
Log:
PR other/42611
* cfgexpand.c (expand
1 - 100 of 153 matches
Mail list logo
