--- 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
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40182
--- You
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|4.4.4 |4.4.5
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.4 |4.4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40181
--- You
--- Comment #9 from jakub at gcc dot gnu dot org 2010-02-08 14:40 ---
The testcase fails on the 4.4 branch, as -fipa-sra isn't a valid option there.
H.J., can you please before committing testsuite backports at least run make
check?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-22 17:03 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-21 00:42 ---
Subject: Bug 42715
Author: jakub
Date: Thu Jan 21 00:42:02 2010
New Revision: 156102
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156102
Log:
PR debug/42715
* var-tracking.c (use_type): Choose
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-13 10:06 ---
I believe this is a dupe of PR42604, at least the testcase in there comes from
http://bugzilla.redhat.com/show_bug.cgi?id=552073
which is also ICE on dcraw.cc in the same function.
*** This bug has been marked
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-13 11:56 ---
More reduced testcase (-m32 -g -O2 -fpic):
struct A { unsigned a1; char a2[15]; };
struct B { long b1; unsigned char b2; long b3; };
struct C { void *c1; unsigned c2; unsigned c3; };
static struct A v1;
struct
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-13 12:09 ---
Looks like some var-tracking bug. We have:
(insn:TI 108 37 38 3 (set (reg/f:SI 2 cx [93]) (const:SI (unspec:SI
[(symbol_ref:SI (v1) [flags 0x2] var_decl 0x7fc316f38000 v1)] 1))) 247
{*lea_1} (expr_list:REG_EQUAL
--- 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=gccview=revrev=155641
Log:
PR other/42611
* cfgexpand.c (expand_one_var
--- 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=gccview=revrev=155642
Log:
PR other/42611
* cfgexpand.c (expand_one_var
--- Comment #10 from jakub at gcc dot gnu dot org 2010-01-05 08:57 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- 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=42611
--- You are receiving
--- 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=19465action=view)
gcc45-pr42611.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
--- 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) (struct B *, void *, int
--- 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 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.
--
jakub at gcc
--- 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=gccview=revrev=155143
Log:
PR c++/42317
* cgraph.h (struct cgraph_node): Add
--- 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 #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
--- 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 #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 #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 watching
--- 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 #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
--- 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
--- 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
--
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 #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_block
--
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=gccview=revrev=149857
Log:
PR tree-optimization/40813
* tree-inline.c
--- 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=gccview=revrev=149858
Log:
PR tree-optimization/40813
* tree-inline.c
--- 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
--- 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=gccview=revrev=149150
Log:
PR debug/40462
* jump.c (returnjump_p): Revert
--- 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 #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 #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
--
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 #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.
--
http
--
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 #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
--- 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 #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=17213action=view)
libgsf-enum-register.patch
Patch that fixes this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39015
--- 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 #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=17047action=view)
gcc44-pr38732.patch
Patch I'm going to bootstrap/regtest.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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=gccview=revrev=143170
Log:
PR libstdc++/38732
* libsupc++/unwind-cxx.h
--- 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-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 #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 anyone
--- 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=gccview=revrev=142833
Log:
PR bootstrap/37739
* config.host: For powerpc
--- 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 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:
What
--- 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 #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=gccview=revrev=142399
Log:
PR middle-end/38360
* tree-ssa-ccp.c
--- 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 #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 receiving
--- 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
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to fail||4.3.2
Known to work||4.4.0
--- 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
--- 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=16491action=view)
libgcc2.i
Indeed, caused by r141077. On the attached preprocessed source reproduceable
with - sparc-linux cross
--- 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/bugzilla
--- 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
--- 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=gccview=revrev=140948
Log:
PR debug/29609
PR debug/36690
PR debug
--- 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
--
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
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 |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
--
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
--- 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 over
--- 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 #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 #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 PR35390
--- 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 #17 from jakub at gcc dot gnu dot org 2008-02-19 17:50 ---
instantiate_type_decl calls tsubst on
type_decl 0x2ea83300 unused
type typename_type 0x2ea83180 unnecessary VOID
align 8 symtab 0 alias set -1 structural equality context
template_type_parm
--
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 #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 function
--
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
--- 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
--- 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 #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
1 - 100 of 144 matches
Mail list logo
