--- 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
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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]>
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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
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
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)
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
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
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
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
--- 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
> ---
--- 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 #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 #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 #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: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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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
#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 #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
--- 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 #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 #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 #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 #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
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 #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
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 #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
--- 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 #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 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 #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 #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 #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 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 #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 #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
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 #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
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 #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
89 matches
Mail list logo
