--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-04-13 07:20
---
The "engima" referred to in comment#2 is because it is a list directed read and
commas and spaces are deliminators. If you turn this into a read with a format
of '(a)' you get the whole string.
I am still workin
I'm compiling the LLVM compiler infrastructure and have noticed that GCC 4.1
takes an excessively long time to compile versus GCC 4.0. In particular, one
file (albeit 2 million source lines) takes over 10 minutes (618.97 seconds) of
CPU time to compile. On the exact same source, GCC 4.0.2 takes jus
--- Comment #1 from rspencer at x10sys dot com 2006-04-13 07:48 ---
Created an attachment (id=11253)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11253&action=view)
source code and -ftime-report output for both 4.0.2 and 4.1.0
This tarball contains 2MB of pre-compiled source code
This code:
struct D {
D() {}
virtual ~D() {}
void operator delete(void*, void*) {}
};
void f() { D d(); }
is rejected with "no suitable 'operator delete' for 'D'".
It is true that the placement deallocation function hides any
"usual" one, but surely it is only necessary fo
--- Comment #4 from tbm at cyrius dot com 2006-04-13 11:27 ---
I can confirm that this test case works with 20060408. However, a slightly
longer test case (directly from delta, without Falk's manual reduction) still
produces a segfault, but only when you pass -finline-functions:
(sid)1
--- Comment #7 from amylaar at gcc dot gnu dot org 2006-04-13 11:45 ---
(In reply to comment #6)
> > -#define INDEX_REG_CLASS \
> > - (!ALLOW_INDEXED_ADDRESS ? NO_REGS : TARGET_SHMEDIA ? GENERAL_REGS :
> > R0_REGS)
> > +#define INDEX_REG_CLASS_FOR_MODE(MODE) \
> > + ((MODE) == DImode
--- Comment #6 from uweigand at gcc dot gnu dot org 2006-04-13 11:47
---
I've now tested and submitted the patch, thanks.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-04-13 12:00
---
Confirmed.
The original testcase compiles fine for me with today's compiler.
If I remove the (unused) typedef in the third line, I get the ICE.
Here's a reduced testcase:
=
struct
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-04-13 12:01
---
Forgot to mention that you have to compile the testcase from comment #5
with "-O2".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27103
--- Comment #2 from paul dot richard dot thomas at cea dot fr 2006-04-13
12:04 ---
Created an attachment (id=11254)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11254&action=view)
Patch for PR26787
This has been regtested on Cygwin_NT/PIV and will be submitted tonight.
The test
--- Comment #3 from paul dot richard dot thomas at cea dot fr 2006-04-13
12:07 ---
Created an attachment (id=11255)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11255&action=view)
Patch for PR26787
Sorry, this is the patch that was regtested on Cygwin_NT/PIV and will be
submitte
--- Comment #4 from paul dot richard dot thomas at cea dot fr 2006-04-13
12:08 ---
(From update of attachment 11254)
This was the testcase, of course.
--
paul dot richard dot thomas at cea dot fr changed:
What|Removed |Added
--
--- Comment #3 from rainer-gccbugzilla at 7val dot com 2006-04-13 12:25
---
make bootstrap succeeded after setting -L and -D to the directory where
libiconv was installed. Setting CONFIG_SHELL might have helped.
--
rainer-gccbugzilla at 7val dot com changed:
What|Rem
--- Comment #3 from jakub at gcc dot gnu dot org 2006-04-13 12:31 ---
Looking into this.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|u
The following code snippet causes an ICE when compiled with -O:
==
struct A
{
char c;
int bar() const;
int foo() const { return bar(); }
};
A a;
void baz()
{
a.foo();
extern A a;
a.foo();
}
=
--- Comment #6 from paul dot richard dot thomas at cea dot fr 2006-04-13
13:04 ---
Created an attachment (id=11256)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11256&action=view)
Patch to fix P26822
This took a depressingly long time to get to the bottom of - particularly since
I get a segfault with 4.2.0 20060408 on x86_64. It does not happen on i386.
(sid)3185:[EMAIL PROTECTED]: ~/delta/bin] cat mini.c
typedef struct { void *p; }
hvl_t;
test_vltypes_compound_vlen_vlen (void) {
typedef struct {
int i;
float f;
hvl_t v;
}
s1;
s1 wdata[128];
unsigne
--- Comment #15 from paul dot richard dot thomas at cea dot fr 2006-04-13
13:36 ---
I can now compile tonto-1.0 without any kludges or tricks. That said, it
segfaults immediately after reading the input data. I will endeavour to find
the cause.
tonto-2.x is blocked by complex(ie. com
--- Comment #16 from hjl at lucon dot org 2006-04-13 13:48 ---
Created an attachment (id=11257)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11257&action=view)
A patch to nullify pointers in local variables
Tonto 1.0 has many local variables with uninitialized pointers. This patc
--- Comment #17 from hjl at lucon dot org 2006-04-13 13:49 ---
Created an attachment (id=11258)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11258&action=view)
Another patch
This is another patch to initialize local variable and fix a typo.
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #8 from kkojima at gcc dot gnu dot org 2006-04-13 14:00 ---
I've tested Joern's patch with #7 tweak on i686-pc-linux-gnu,
x86 cross sh{64,4}-unknown-linux-gnu and x86 cross sh64-elf targets.
There are no bootstrap or build problems and the results of
regression tests look fin
--- Comment #3 from trt at acm dot org 2006-04-13 14:05 ---
The patch for bug 19541 should resolve this, thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27137
--- Comment #4 from patchapp at dberlin dot org 2006-04-13 14:25 ---
Subject: Bug number PR27095
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00494.html
--
http://gcc.gnu.org/bugzilla/sh
#include
int main()
{
int array[2];
bool boolval = true;
array[0] = 3;
array[1] = 7;
int total;
total= array[0] + boolval ? array[1] : 0;
printf("with boolval true, total = %d\n",total);
boolval = false;
total= array[0] + boolval ? array[1] : 0;
--- Comment #7 from dje at gcc dot gnu dot org 2006-04-13 15:37 ---
Paolo, I'm not sure why you think that two splats and two adds is too
expensive. Memory is moving farther and farther away from the processor.
--
dje at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from 1fhcwee02 at sneakemail dot com 2006-04-13 15:51
---
I was asked about this yesterday. I see my comments didn't make it here, so
I'll try putting them in myself with this new account. (No, I can't monitor bug
reports with any regularity; I can't even really keep up w
--- Comment #3 from jkanze at cheuvreux dot com 2006-04-13 16:28 ---
(In reply to comment #1)
> Are you building from a release version, correct?
As far as I know. It's version 4.1.0, downloaded
yesterday or the day before. How can I tell?
(I do want something more or less stable, sin
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 16:30 ---
I bet it has nothing to do with those but instead PR 26830.
Just a quick question since you might know before I go looking into the source.
Does this source has a big switch and a couple of loops in it?
If it does t
--- Comment #3 from sabre at nondot dot org 2006-04-13 16:31 ---
Note: "(albeit 2 million source lines)" isn't right, it's only 79K LOC. :)
-Chris
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27140
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-13 16:35 ---
This is the same as PR 26490.
*** This bug has been marked as a duplicate of 26490 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-13 16:35 ---
*** Bug 27103 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-13 16:37 ---
It is the same issue really, the C++ front-end is producing two DECLs with one
UID which is wrong.
*** This bug has been marked as a duplicate of 26757 ***
--
pinskia at gcc dot gnu dot org changed:
--- Comment #6 from law at redhat dot com 2006-04-13 16:38 ---
Fixed a couple days ago.
--
law at redhat dot com changed:
What|Removed |Added
Status|NEW
--- Comment #11 from pinskia at gcc dot gnu dot org 2006-04-13 16:37
---
*** Bug 27143 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26757
--- Comment #16 from law at redhat dot com 2006-04-13 16:39 ---
Fixed a couple weeks ago.
--
law at redhat dot com changed:
What|Removed |Added
Status|NEW
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-04-13 16:42
---
This is a latent bug as show by PR 16792 and PR 20357. Both show the same
problem of two DECLs pointing to the same variable and having the same UID.
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-13 16:45 ---
*** This bug has been marked as a duplicate of 19541 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-04-13 16:45 ---
*** Bug 27137 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-13 16:48 ---
You forgot about operator precidence.
So "array[0] + boolval ? array[1] : 0;"
is the same as "(array[0] + boolval )? array[1] : 0;"
and not what you want:
array[0] + (boolval ? array[1] : 0);
--
pinskia at gcc do
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-13 16:51 ---
But only fixed on the mainline for 4.2 and not for 4.1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-13 16:55 ---
((unsigned int *) t1->p) is most likely giving it troubles.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27144
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-13 16:57 ---
It is an ICE while doing scev.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-13 17:01 ---
Confirmed, here is a slightly reduced testcase:
typedef struct {unsigned *p; }
hvl_t;
test_vltypes_compound_vlen_vlen (void) {
typedef struct {
int i;
float f;
hvl_t v;
}
s1;
s1 wdata[128];
unsi
--- Comment #8 from law at redhat dot com 2006-04-13 17:05 ---
Subject: Re: [4.1 regression] ICE in
merge_alias_info
On Thu, 2006-04-13 at 16:51 +, pinskia at gcc dot gnu dot org wrote:
>
> --- Comment #7 from pinskia at gcc dot gnu dot org 2006-04-13 16:51
> ---
There's a bogus comma in the following warning message:
"the address of x, will always evaluate"
Happens at least with 4.2.0 20060325.
--
Summary: English in warning not grammatical: "the address of x,
will always evaluate"
Product: gcc
Vers
Testcase:
int g(int f)
{
return (&f)!=0;
}
-
Just like PR 25861.
t.c:5: internal compiler error: tree check: expected tree that contains "decl
with visibility" structure, have "parm_decl" in build_binary_op, at
c-typeck.c:7987
Please submit a full bug report,
with preprocessed source if appr
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27150
--- Comment #4 from rspencer at x10sys dot com 2006-04-13 17:26 ---
Re: 2 million lines:
Yes, my apologies for the late night blunder. It is 2,231,753 bytes and 79,037
lines.
Re: large switch statements:
There are several switch statements, none of them large. The largest is about
200 l
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-13 17:26 ---
testcase:
int g(int f)
{
return !(&f);
}
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #20 from law at redhat dot com 2006-04-13 18:14 ---
Subject: Re: VRP/DOM does not like
TRUTH_AND_EXPR
On Fri, 2006-04-07 at 12:23 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #19 from rguenth at gcc dot gnu dot org 2006-04-07 12:23
> ---
>
--- Comment #7 from patchapp at dberlin dot org 2006-04-13 18:55 ---
Subject: Bug number PR26822
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00505.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from patchapp at dberlin dot org 2006-04-13 18:55 ---
Subject: Bug number PR26787
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2006-04/msg00506.html
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #5 from rspencer at x10sys dot com 2006-04-13 20:13 ---
Created an attachment (id=11260)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11260&action=view)
Timing results when using GCC 4.1.1
This attachment provides the -ftime-report output for the same compilation but
--- Comment #8 from uweigand at gcc dot gnu dot org 2006-04-13 20:27
---
Subject: Bug 27006
Author: uweigand
Date: Thu Apr 13 20:26:59 2006
New Revision: 112923
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112923
Log:
2006-04-13 Paolo Bonzini <[EMAIL PROTECTED]>
--- Comment #6 from rspencer at x10sys dot com 2006-04-13 20:30 ---
Created an attachment (id=11261)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11261&action=view)
Timing results with -fno-tree-salias
Andrew Pinskia suggested that I try -fno-tree-salias. This decreased
compilati
--- Comment #9 from uweigand at gcc dot gnu dot org 2006-04-13 20:33
---
Subject: Bug 27006
Author: uweigand
Date: Thu Apr 13 20:33:51 2006
New Revision: 112924
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112924
Log:
2006-04-13 Paolo Bonzini <[EMAIL PROTECTED]>
--- Comment #10 from uweigand at gcc dot gnu dot org 2006-04-13 20:35
---
Fixed for 4.1 and mainline.
--
uweigand at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2006-04-13 21:04 ---
Subject: Bug 26522
Author: tromey
Date: Thu Apr 13 21:04:04 2006
New Revision: 112925
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112925
Log:
PR libgcj/26522:
* Makefile.in: Rebuilt.
--- Comment #5 from tromey at gcc dot gnu dot org 2006-04-13 21:08 ---
Subject: Bug 26522
Author: tromey
Date: Thu Apr 13 21:08:49 2006
New Revision: 112926
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112926
Log:
PR libgcj/26522:
* Makefile.in: Rebuilt.
--- Comment #6 from tromey at gcc dot gnu dot org 2006-04-13 21:10 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
On Apr 13, 2006, at 1:30 PM, rspencer at x10sys dot com wrote:
--- Comment #6 from rspencer at x10sys dot com 2006-04-13
20:30 ---
Created an attachment (id=11261)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11261&action=view)
Timing results with -fno-tree-salias
Andrew P
--- Comment #7 from dberlin at gcc dot gnu dot org 2006-04-13 22:40 ---
Subject: Re: Compiling LLVM now takes nearly 5x as long with 4.1 as it did
with 4.0
On Apr 13, 2006, at 1:30 PM, rspencer at x10sys dot com wrote:
>
>
> --- Comment #6 from rspencer at x10sys dot com 2006-04
The following testcase fails on 4.1.0 and 4.2.0 when compiled with:
gcc -O2 -march=athlon64 -ftree-vectorize -c test.c
test.c: In function vis_clear_data:
test.c:9: error: unrecognizable insn:
(insn 28 27 29 5 (set (reg:V4SF 73)
(vec_duplicate:V4SF (reg/v:SI 71 [ vis_type ]))) -1 (nil)
Ok, I have been trying to track this bug down for weeks and spent quite a lot
of time on it. I am now pretty much sure that this is a bug within gcc even
though it's quite hard to prove. So before I sum it up again here, first two
links to my original bug reports over at the Gentoo and Xorg bugzill
--- Comment #3 from rth at gcc dot gnu dot org 2006-04-13 23:44 ---
Subject: Bug 26651
Author: rth
Date: Thu Apr 13 23:44:25 2006
New Revision: 112935
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112935
Log:
PR 26651
* gimple-low.c (lower_omp_directive): Remove
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-13 23:45 ---
We cannot do anything without a testcase.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2006-04-13 23:54
---
This is not a compiler bug.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from rakdver at gcc dot gnu dot org 2006-04-14 00:06
---
Created an attachment (id=11262)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11262&action=view)
Updated version of the patch
This patch (this time more or less a final version, bootstrapped & regtested on
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-14 00:28 ---
What the vectorizer does looks good:
MEM[symbol: vs_data, base: (vector float *) ivtmp.54 * 16B] = VEC_COND_EXPR <
vect_cst_.35 != { 1, 1, 1, 1 } , { 0.0, 0.0, 0.0, 0.0 } , { 1.0e+0, 1.0e+0,
1.0e+0, 1.0e+0 } > ;
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-14 00:51 ---
I get:
t.c:7: internal compiler error: in immed_double_const, at emit-rtl.c:464
Anyways this is either a middle-end issue while expanding the VEC_COND_EXPR or
a target one while expanding it.
--
pinskia at gcc d
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-14 00:56 ---
Confirmed, it also ICEs on powerpc-linux-gnu with -maltivec -O1
-ftree-vectorize so it is a middle-end issue.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-14 01:01 ---
Actually I take that back about being a middle-end issue and not a vectorizer
one.
vector float vect_cst_.35;
int vis_type;
vect_cst_.35 = {vis_type, vis_type, vis_type, vis_type};
so it is getting the w
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-04-14 01:05 ---
Try replacing each .o file with one that is compiled at -O0 and then see if the
program works. This is the standard way of finding miscompiling objects.
After finding the one which works, try compiling with -fwrapv
An error occurs when a function result is dereferenced if used as another
function's argument:
void *func(int num) {
static int val;
val=num;
return (void*)&val;
}
int main() {
printf("%d %d %d\n", *((int*)func(1)), *((int*)func(2)), *((int*)func(3)));
return 0;
}
Output is "1 1 1" in
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2006-04-14 02:31
---
Subject: Bug 26890
Author: jvdelisle
Date: Fri Apr 14 02:31:28 2006
New Revision: 112943
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112943
Log:
2006-04-14 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-04-14 02:31 ---
It is undefined on which function call is done in what order and also were the
dereferencing is done, before or after the next function call.
*** This bug has been marked as a duplicate of 11751 ***
--
pinskia a
--- Comment #67 from pinskia at gcc dot gnu dot org 2006-04-14 02:31
---
*** Bug 27153 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-04-14 02:36
---
Subject: Bug 26980
Author: jvdelisle
Date: Fri Apr 14 02:36:49 2006
New Revision: 112944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112944
Log:
2006-04-14 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #2 from alexey at cs dot sunysb dot edu 2006-04-14 02:46
---
> It is undefined on which function call is done in what order
It does not matter in this example.
> and also were the
> dereferencing is done, before or after the next function call.
It does not matter either.
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-04-14 02:50 ---
(In reply to comment #2)
> > It is undefined on which function call is done in what order
>
> It does not matter in this example.
>
Why do you think that?
It does generate a call to func but not as you expected i
--- Comment #68 from pinskia at gcc dot gnu dot org 2006-04-14 02:50
---
*** Bug 27153 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11751
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-04-14 02:55 ---
(In reply to comment #2)
> It does not matter either. The evaluation of a function argument is an atomic
> procedure. If it starts it should generate a result. Isn't it strange if the
> compiler evaluates a little bi
--- Comment #5 from alexey at cs dot sunysb dot edu 2006-04-14 03:06
---
> > > It is undefined on which function call is done in what order
> > It does not matter in this example.
> Why do you think that?
Because the result is "x x x" for all orders instead of 1 2 3.
> int *a, *b, *c;
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2006-04-14 03:14
---
Testcase was committed to 4.1 branch as well, but I typoed the pr number so it
did not register commit here.
Fixed on 4.1 and trunk.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2006-04-14 03:16
---
Closing
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #5 from amodra at gcc dot gnu dot org 2006-04-14 03:20 ---
Subject: Bug 27095
Author: amodra
Date: Fri Apr 14 03:20:21 2006
New Revision: 112948
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112948
Log:
PR middle-end/27095
* builtins.c: (expand_built
The following testcase triggers an ICE on 4.1.1 20060410:
static int NumLevels = 16, ImageWidth = 640, ImageHeight = 350;
int
main (int argc, char **argv)
{
int i, j, FlipDir;
unsigned char Color;
unsigned char *Line;
for (Color = NumLevels, i = 0; i < ImageHeight; i++)
{
for (j
--- Comment #4 from uros at gcc dot gnu dot org 2006-04-14 05:01 ---
Subject: Bug 27134
Author: uros
Date: Fri Apr 14 05:01:18 2006
New Revision: 112949
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112949
Log:
PR middle-end/27134
* builtins.c (expand_builtin_in
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-04-14 05:50
---
Created an attachment (id=11263)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11263&action=view)
Proposed Patch
This is a proposed patch you can try out while I work up a more complete test
case. The exam
89 matches
Mail list logo
