I'm still waiting for the testsuite to complete (it's been running
just for about 24 hours so far). In the meanwhile I'd like to discuss
the first performance results, which I've put on the Wiki:
First number is GCC with Boehm's GC and the number in parentheses is
GCC with page collector.
On 6/23/06, Laurynas Biveinis [EMAIL PROTECTED] wrote:
All in all, IMHO this data favours against Boehm's GC in GCC. But
before deciding I would like to enable generational GC features, if
that will help with run time. On the other hand, I don't see how peak
memory usage could be reduced.
What
On Jun 23, 2006, at 8:51 AM, Laurynas Biveinis wrote:
First number is GCC with Boehm's GC and the number in parentheses is
GCC with page collector.
combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
(0.61) 4% (4%). User running time: 0m16 (0m14).
Are these with checking on or
On Jun 23, 2006, at 8:51 AM, Laurynas Biveinis wrote:
First number is GCC with Boehm's GC and the number in parentheses is
GCC with page collector.
combine.c: top mem usage: 52180k (13915k). GC execution time 0.66
(0.61) 4% (4%). User running time: 0m16 (0m14).
Are these with
Thanks! I put an updated page up at
http://kegel.com/gcc/summit2006.html
I won't be attending myself this year (I needed a break from travel),
but if anyone's blogging the event, please let me know and I'll
link to their blog from my page.
- Dan
On 6/23/06, Andrey Belevantsev [EMAIL
Bugger, this went to testresults insetad of here... sorry for that...
-- Forwarded message --
From: Christian Joensson [EMAIL PROTECTED]
Date: Jun 23, 2006 8:09 PM
Subject: Lots of gfortrans testsuite failuers on sparc64-linux:
undefined reference to `_gfortran_reshape_r8
To:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of
Ron McCall
Sent: Thursday, June 01, 2006 2:33 PM
To: gcc@gcc.gnu.org
Subject: Intermixing powerpc-eabi and powerpc-linux C code
Hi!
Does anyone happen to know if it is possible to link
(and run)
Last fall I produced the RABLE document which described the approach I
thought should be taken to write a new register allocator for GCC.
A new register allocator written from scratch is a very long term
project (measured in years), and there is no guarantee after all that
work that we'd end up
On 6/23/06, Laurynas Biveinis [EMAIL PROTECTED] wrote:
What do you think?
Is it possible to turn garbage collection totally off for a null-case
run-time comparison or would that cause thrashing except for very
small jobs?
--
David L Nicol
if life were like Opera, this would probably
have
Andrew MacLeod wrote:
A new register allocator written from scratch is a very long term
project (measured in years), and there is no guarantee after all that
work that we'd end up with something which is remarkably better. One
would hope that it is a lot more maintainable, but the generated
I'm currently working on a massive overhaul of the visibility code to
make it play nice with C++. One of the issues I've run into is the
question of priority of #pragma visibility versus other sources of
visibility information.
Consider:
#pragma GCC visibility push(hidden)
class
On Fri, 2006-06-23 at 15:29 -0400, Robert Dewar wrote:
Andrew MacLeod wrote:
A new register allocator written from scratch is a very long term
project (measured in years), and there is no guarantee after all that
work that we'd end up with something which is remarkably better. One
would
Andrew MacLeod wrote:
I am personally not a believer in combining register allocation and
scheduling. They are two different problems, and although there is some
interaction, I am still in the keep them seperate camp.
I disagree, there is in fact much more than some interaction, there
is a
On Fri, Jun 23, 2006 at 04:30:01PM -0400, Robert Dewar wrote:
However, RABLET is not writing a register allocator so its moot
anyway :-).
indeed, moot = disussable, undecided, so here we are discussing
(or if you like to use the verb, mooting) the issue.
Please try the other definition,
Daniel Jacobowitz wrote:
Please try the other definition, which he clearly meant:
2. Of purely theoretical or academic interest; having no
practical consequence; as, the team won in spite of the
bad call, and whether the ruling was correct is a moot
question.
On 6/23/06, Robert Dewar [EMAIL PROTECTED] wrote:
Well I am not sure what he meant, but for sure it is not the
case that optimal register allocation and scheduling is of only
theoretical or academic interest with no practical consequences!
Thanks for making that point.
Now, what do you think
Steven Bosscher wrote:
Now, what do you think about this RABLET idea, which has nothing to do
with either register allocation or scheduling? ;-)
Well I would not say that it has nothing to do with register allocation!
But indeed this seems a promising approach. The real question in my mind
is
Hello, I would like to know if there is a fortran compiler that runs
on AMD 64 bits. I have installed suse 10.1 linux on my computer, I
would really apreciated all your help. I heard yours also have C and
C++.
Thank you very much, I write you from Argentina,
héctor Riojas Roldan
Hello,
One of things mingw32 C runtime lacks is an implementation of
__cxa_atexit.
However, as explained in the comment below, some of the behaviour of
__cxa_atexit is already in the C runtime atexit implementation.
Adding the object below to libstdc++ or libgcc.a and configuring with
Andrew MacLeod [EMAIL PROTECTED] writes:
This describes my current work-in-progress, RABLET, which stands for
RABLE-Themes, and conveniently implies something smaller.
Thanks for this proposal.
ssa-to-rtl
spill cost analysis
global allocation
spiller
spill location optimizer
Jason Merrill wrote:
Nice to see this stuff getting improved!
#pragma GCC visibility push(hidden)
class __attribute((visibility(default))) A
{
void f ();
};
void A::f() { }
Here I think we'd all agree that f should get default visibility.
Agreed.
class A
{
Mark Mitchell [EMAIL PROTECTED] writes:
Jason Merrill wrote:
Now, templates:
templateclass T __attribute((visibility (hidden)) T f(T);
#pragma GCC visibility push(default)
extern template int f(int);
#pragma GCC visibility pop
This could really go either way. It could
Snapshot gcc-4.1-20060623 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060623/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 6/23/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
...
1 - One of the core themes in RABLE was very early selection of
instructions from patterns. RTL patterns are initially chosen by the
EXPAND pass. EXPAND tends to generates better rtl patterns by being
handed complex trees which it can
It looks like crt1.asm unconditionally includes an sh3e opcode (stc
spc,r1) which causes problems trying to build an sh2a-single-only
executable, which falls back to sh2e but doesn't have this sh3e
opcode. Comments?
1091 ! Here handler available, call it.
1092
I have run into a build problem with tonights gcc trunk on MacOS X which
didn't exist in yesterdays
svn pull. The gcc trunk build on MacOS X 10.4.6 crashes with...
checking how to run the C++ preprocessor...
/sw/src/fink.build/gcc4-4.1.999-20060623/darwin_objdir/./gcc/xgcc
-shared-libgcc
Ian Lance Taylor wrote:
Andrew MacLeod [EMAIL PROTECTED] writes:
This describes my current work-in-progress, RABLET, which stands for
RABLE-Themes, and conveniently implies something smaller.
Thanks for this proposal.
ssa-to-rtl
spill cost analysis
global allocation
spiller
spill
It looks like crt1.asm unconditionally includes an sh3e opcode (stc
spc,r1) which causes problems trying to build an sh2a-single-only
executable, which falls back to sh2e but doesn't have this sh3e
opcode. Comments?
It's not actually unconditional, but the condition it depends on is set
It's not actually unconditional, but the condition it depends on is set
conditionally with a flawed condition. Please try the attached patch.
That seems to fix it, although I only tested a simple hello.c program.
Thanks!
On Fri, 2006-06-23 at 23:08 -0400, Daniel Berlin wrote:
Ian Lance Taylor wrote:
Here I think you are waving your hands a little too hard. RTL level
CSE is significant for handling common expressions exposed by address
calculations and by DImode (and larger) computations. On some
Ian Lance Taylor wrote:
Don't you still have to deal with this case?
#pragma GCC visibility push(hidden)
templateclass T T f(T);
#pragma GCC visibility pop
...
#pragma GCC visibility push(default)
extern template int f(int);
#pragma GCC visibility pop
Personally I wouldn't mind
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
You omitted the RTL loop optimizer passes, which still do quite a bit
of work despite the tree-ssa loop passes. Also if-conversion and some
minor passes, though they are less relevant.
Which brings up a good discussion. I presume the
On Jun 23, 2006, at 9:39 PM, Andrew MacLeod wrote:
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
You omitted the RTL loop optimizer passes, which still do quite a bit
of work despite the tree-ssa loop passes. Also if-conversion and
some
minor passes, though they are less
Andrew MacLeod [EMAIL PROTECTED] writes:
On Fri, 2006-06-23 at 15:07 -0700, Ian Lance Taylor wrote:
You omitted the RTL loop optimizer passes, which still do quite a bit
of work despite the tree-ssa loop passes. Also if-conversion and some
minor passes, though they are less relevant.
Given the following:
1 double __thread data;
2 double __thread * ptr = data;
leads to following error diagnostic:
% gcc -c t.c
t.c:3: error: initializer element is not constant
compiled with:
gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)
Given that both 'data' and 'ptr' are thread
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-23 06:55 ---
I think this needs also a binutils change and technically it is not a constant
as it does change between threads.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from paul dot richard dot thomas at cea dot fr 2006-06-23
07:04 ---
It should be noted that encasing the two subroutines in a module produces the
correct error
In file pr22571.f90:15
call a(q)
1
Error: Type/rank mismatch in argument 'p' at (1)
The
--- Comment #4 from dannysmith at gcc dot gnu dot org 2006-06-23 08:25
---
Subject: Bug 27789
Author: dannysmith
Date: Fri Jun 23 08:25:33 2006
New Revision: 114927
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114927
Log:
PR target/27789
* config/i386/winnt.c
--- Comment #5 from dannysmith at users dot sourceforge dot net 2006-06-23
08:27 ---
Patch committed to trunk.
Danny
--
dannysmith at users dot sourceforge dot net changed:
What|Removed |Added
--- Comment #6 from tanaka at personal-media dot co dot jp 2006-06-23
09:52 ---
Please answer my question again.
It can not be distinguished between a function, which specified
__inline__ and an another function, which is not specified __inline__,
after gcc-3.4.
This is sample.
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-06-23 09:52 ---
Subject: Bug 28045
Author: rguenth
Date: Fri Jun 23 09:52:40 2006
New Revision: 114929
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114929
Log:
2006-06-23 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-06-23 09:57
---
Subject: Bug 28045
Author: rguenth
Date: Fri Jun 23 09:57:37 2006
New Revision: 114930
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114930
Log:
2006-06-23 Richard Guenther [EMAIL PROTECTED]
PR
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-06-23 09:57
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from info at pion dot xs4all dot nl 2006-06-23 09:59 ---
1) I installed the patches which are mentioned in the installation
documentation
2) Installed newer binutils
3) Checked on an other host
4) I have checked 4.1.0 which has the same problem
5) Could you give the
--- Comment #7 from rguenth at gcc dot gnu dot org 2006-06-23 10:06 ---
Newer gcc always inline _static_ functions that are used _once_ into their only
caller (regardless of being declared inline or not). You can disable this
behavior with -fno-inline-functions-called-once.
All gcc
--- Comment #2 from info at yourkit dot com 2006-06-23 10:31 ---
I've charged target from i386-pc-solaris2.10 to i386-pc-solaris2.9
and successfully built cross-compiler, but the resulting compiler
cannot produce 64bit binaries (as expected, because Solaris9 on Intel
is a 32bit).
I
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-23 11:57 ---
Fixed in 3.4.0.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from info at yourkit dot com 2006-06-23 12:09 ---
I can confirm this bug.
target=i386-pc-solaris2.10;
host=i386-pc-linux-gnu;
GCC 4.1.1;
BinUtils 2.16.1
Checking multilib configuration...
/bin/sh /home/anton/tmp/gcc/gcc-4.1.1/mkinstalldirs i386-pc-solaris2.10/libssp
;
--- Comment #3 from info at yourkit dot com 2006-06-23 12:28 ---
I've discovered that if only C language is specified and --disable-libssp is
added (to work around bug #25035) then cross complier can be successfully
built. So the problem somewehere in C++ part.
--
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de
2006-06-23 13:01 ---
Additional remarks (which I forget to make):
Both cases are valid Fortran as:
(1) If the length of 'variable' is less than that of 'expr', the value of
'expr' is truncated from the right until
Well, I see gcc.c-torture/execute/frame-address.c execution FAIL on sparc64,
linux and solaris,
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00985.html,
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00962.html, and
http://gcc.gnu.org/ml/gcc-testresults/2006-06/msg00907.html.
I still see it
--- Comment #29 from krebbel at gcc dot gnu dot org 2006-06-23 15:16
---
On s390x c974001, c974013 and cb20001 run into a infinite loop with current
mainline. At least the first two look related - not sure about the third.
--
krebbel at gcc dot gnu dot org changed:
What
--- Comment #7 from chris at bubblescope dot net 2006-06-23 15:33 ---
(In reply to comment #4)
Subject: Re: header dependencies
On Monday 19 June 2006 11:29, pcarlini at suse dot de wrote:
--- Comment #1 from pcarlini at suse dot de 2006-06-19 09:29
Ok, let's see what we
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-23 15:40 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pault at gcc dot gnu dot org 2006-06-23 15:40 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from pault at gcc dot gnu dot org 2006-06-23 15:41 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2006-06-23 15:42 ---
Fixed on trunk and 4.1
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from pault at gcc dot gnu dot org 2006-06-23 15:43 ---
Now for the hard work of writing simplify_transfer!
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18769
--- Comment #5 from reichelt at gcc dot gnu dot org 2006-06-23 16:00
---
Subject: Bug 11468
Author: reichelt
Date: Fri Jun 23 15:59:51 2006
New Revision: 114937
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114937
Log:
PR c++/11468
* init.c (build_new_1): Handle
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-06-23 16:05
---
Fixed on mainline.
Instead of
bug.cc:55: internal compiler error: can't find class$
we now get a regular error with more information:
bug.cc:55: error: can't find 'class$' in 'MyClass'
--
reichelt at gcc
--- Comment #6 from reichelt at gcc dot gnu dot org 2006-06-23 16:08
---
The ICE
internal compiler error: can't find class$
has been fixed on mainline (see PR 11468), but the ICE mentioned in
commment #5 is still present.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11006
--- Comment #5 from sje at gcc dot gnu dot org 2006-06-23 16:22 ---
Subject: Bug 28084
Author: sje
Date: Fri Jun 23 16:21:54 2006
New Revision: 114939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114939
Log:
PR target/28084
* inclhack.def (hpux_extern_errno):
--- Comment #8 from gdr at integrable-solutions dot net 2006-06-23 16:35
---
Subject: Re: header dependencies
chris at bubblescope dot net [EMAIL PROTECTED] writes:
| I did implement a version of this myself, basically by writing a
| mapper around each container that did a few
According to:
http://java.sun.com/docs/books/jls/second_edition/html/conversions.doc.html#25363
java conversions of floating point values to integer types smaller than int
should be done by converting to integer first, and then from int to the target
type. While the former conversion is done
--- Comment #2 from gary at intrepid dot com 2006-06-23 16:44 ---
I agree this is definitely an enhancement, but will note the following:
1. On Fedora Core 5, x86_64, I was able to successfully link and run
a null program (written in assembly) that initializes thread local
'ptr' that
--- Comment #9 from chris at bubblescope dot net 2006-06-23 16:47 ---
I just tried preprocessing vector, as an example. There isn't any obvious
low-hanging fruit. The major problem is that most of the C standard libary ends
up getting dragged in.
I think a better goal would be to make
--- Comment #1 from reichelt at gcc dot gnu dot org 2006-06-23 17:02
---
Subject: Bug 28112
Author: reichelt
Date: Fri Jun 23 17:02:38 2006
New Revision: 114941
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114941
Log:
PR c++/28112
* parser.c
--- Comment #2 from reichelt at gcc dot gnu dot org 2006-06-23 17:06
---
Subject: Bug 28112
Author: reichelt
Date: Fri Jun 23 17:06:13 2006
New Revision: 114942
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114942
Log:
PR c++/28112
* parser.c
--- Comment #3 from reichelt at gcc dot gnu dot org 2006-06-23 17:10
---
Subject: Bug 28112
Author: reichelt
Date: Fri Jun 23 17:10:11 2006
New Revision: 114943
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114943
Log:
PR c++/28112
* parser.c
--- Comment #4 from reichelt at gcc dot gnu dot org 2006-06-23 17:11
---
Fixed on mainline, 4.1 branch, and 4.0 branch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from amylaar at gcc dot gnu dot org 2006-06-23 17:55 ---
Created an attachment (id=11733)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11733action=view)
patch
I'm currently testing this patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28144
(This is not a new problem, and everyone involved is familiar with it. I was
just surprised not to find a record of it in bugzilla.)
On targets using a recent version of glibc and the NPTL threading package, if
you cancel a thread using pthread_cancel while it is writing to an ostream,
you'll
--- Comment #1 from mark at codesourcery dot com 2006-06-23 18:14 ---
Subject: Re: New: libstdc++ and pthread cancellation
are incompatible (at least with NPTL)
drow at gcc dot gnu dot org wrote:
On targets using a recent version of glibc and the NPTL threading package, if
you
--- Comment #3 from seongbae dot park at gmail dot com 2006-06-23 18:26
---
I'm able to reproduce the problem with 4.2.0 on linux/x86.
valgrind-3.2.0/memcheck/mc_main.c has
359 static AuxMapEnt hacky_auxmaps[N_AUXMAPS];
...
362 static AuxMapEnt* auxmap =
--- Comment #4 from info at pion dot xs4all dot nl 2006-06-23 18:31 ---
It works now.
First i installed gcc 3.4.6 and used that compiler (before that i used 3.2.1).
Then i used the following configuration:
Target: hppa2.0w-hp-hpux11.00
Configured with:
--- Comment #4 from seongbae dot park at gmail dot com 2006-06-23 18:43
---
The problem is causedby the extra DW_AT_const_value.
4.1.0 generates the following dwarf entry for auxmap:
1a30c: Abbrev Number: 31 (DW_TAG_variable)
DW_AT_name: (indirect string, offset: 0x35e):
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-23 19:03 ---
(In reply to comment #4)
It works now.
First i installed gcc 3.4.6 and used that compiler (before that i used 3.2.1).
No more likely 3.2.1 was miscompiling part of 4.1.1.
If you did not use make bootstrap, that is
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-06-23 19:50 ---
Can you please attach the preprocessed source rather than pasting it in? (I
know there was no way to do so on the new bug page)
Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
--- Comment #2 from gin at mo dot msk dot ru 2006-06-23 19:57 ---
Subject: Re: loses type in debug info
As for marking the bug as already reported, this seems plausible to
me. Confirming that `.i' sent in my bug report uses lost type in
exactly the same way as test code in PR 21391;
--- Comment #2 from list+gcc-bugzilla at meyering dot net 2006-06-23 19:58
---
Created an attachment (id=11734)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11734action=view)
preprocessed input
Here's the same j.i file, as an attachment.
--
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-23 20:12 ---
It produces
38b060a751ac96384cd9327eb1b1e36a21fdb71114be07434c0cc7bf63f6e1da274edebfe76f65fbd51ad2f14898b95b
for me with -O and -O2. Can you post the output of
gcc -I.. -I. -g -O2 ~/j.c -v
?
--
--- Comment #4 from list+gcc-bugzilla at meyering dot net 2006-06-23 20:26
---
Created an attachment (id=11735)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11735action=view)
Here's the output of running gcc -I.. -I. -g -O2 ~/j.c -v
Here's the output of running gcc -I.. -I. -g
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-06-23 21:03 ---
Ok, looks like it is s390 specific because I can reproduce it with
gcc version 4.1.2 20060531 (prerelease)
/usr/lib/gcc/s390-suse-linux/4.1.2/cc1 -fpreprocessed t.i -quiet -dumpbase t.i
-march=z900 -mtune=z9-109
--- Comment #3 from kargl at gcc dot gnu dot org 2006-06-23 21:05 ---
Subject: Bug 27981
Author: kargl
Date: Fri Jun 23 21:05:04 2006
New Revision: 114950
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114950
Log:
2006-06-23 Steven G. Kargl [EMAIL PROTECTED]
PR
--- Comment #4 from kargl at gcc dot gnu dot org 2006-06-23 21:12 ---
Applied to trunk. I'll apply this to 4.1 in a few days.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-06-23 21:15 ---
trying to reduce it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28146
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-23 21:29 ---
Is this fixed now after Richard G.'s newest patch?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-06-23 21:31 ---
It should be. Let's wait for new testresults.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28138
--- Comment #4 from sje at gcc dot gnu dot org 2006-06-23 21:53 ---
Subject: Bug 27019
Author: sje
Date: Fri Jun 23 21:53:36 2006
New Revision: 114952
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114952
Log:
PR c++/27019
* typeck2.c
--- Comment #2 from sje at gcc dot gnu dot org 2006-06-23 21:58 ---
Subject: Bug 28114
Author: sje
Date: Fri Jun 23 21:58:25 2006
New Revision: 114953
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114953
Log:
PR c++/28114
* name-lookup.c (pushtag): Return if we
I have a very simple piece of code that will produce the following error:
--
test.C:5: internal compiler error: in output_constant, at varasm.c:4031
--
A simple code fragment to reproduce this bug is:
--
struct foo {
public:
virtual int bar(int);
};
void (foo::*__Virtual__foo__Var1)() =
--- Comment #1 from donour at cs dot unm dot edu 2006-06-23 23:14 ---
Created an attachment (id=11736)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11736action=view)
demo of reported behavior
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28148
--- Comment #2 from bkoz at gcc dot gnu dot org 2006-06-23 23:43 ---
Created an attachment (id=11737)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11737action=view)
fix
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27984
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from seongbae dot park at gmail dot com 2006-06-23 23:55
---
Looks like this indeed is a duplicate of 27657.
In toplev.c:
1013 cgraph_varpool_assemble_pending_decls ();
...
1040 (*debug_hooks-finish) (main_input_filename);
dwarf2 finish ends up calling
--- Comment #4 from pcarlini at suse dot de 2006-06-23 23:59 ---
Just tested and seems fixed indeed. Thanks a lot!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28138
--- Comment #3 from bkoz at gcc dot gnu dot org 2006-06-24 00:13 ---
Subject: Bug 27984
Author: bkoz
Date: Sat Jun 24 00:13:08 2006
New Revision: 114955
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=114955
Log:
2006-06-23 Benjamin Kosnik [EMAIL PROTECTED]
PR
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-24 01:43 ---
Actually I think the consensus was talk to the C++ and POSIX standards comittee
about this case.
It is not just libstdc++ that could cause problems but any program that uses
throw() or catch(...) {/* fall through
--- Comment #3 from pinskia at gmail dot com 2006-06-24 01:48 ---
Subject: Re: loses type in debug info
On Jun 23, 2006, at 12:57 PM, Ilya N. Golubev wrote:
Next time please don't paste the preprocessed source in gccbug or
in the
comments section in bugzilla.
Please reverse
1 - 100 of 110 matches
Mail list logo
