On Thu, Jan 19, 2006 at 08:49:34PM -0500, David Edelsohn wrote:
Jakub Jelinek writes:
Jakub * config/rs6000/rs6000.md (UNSPEC_LWSYNC, UNSPEC_ISYNC,
Jakub UNSPEC_SYNC_OP, UNSPEC_ATOMIC, UNSPEC_CMPXCHG, UNSPEC_XCHG): Rename
Jakub to...
Jakub (UNSPECV_LWSYNC, UNSPECV_ISYNC, UNSPECV_SYNC_OP,
Daniel Berlin wrote:
On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Mainline fails to bootstrap for me (revision 110017)
on i686-pc-linux-gnu.
Configured as:
$GCC_SRC_DIR/configure --prefix=$HOME/gcc
On 1/20/06, Steven Bosscher [EMAIL PROTECTED] wrote:
On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
... the real
solution is to transfer the information that the stack space sharing
knows into some simple set
The tree is still broken for me. Daniel, did you commit your patch?
Andreas
--
Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/
SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
Kenneth Zadeck [EMAIL PROTECTED] writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed according to
(I've sent this first to gcc-patches accidently :(
Kenny thought it would be nice, rather than pass the actual bb info to free
to the freeing function, to instead pass some random bitmap.
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
Andreas Jaeger wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the
Andreas Jaeger wrote:
Kenneth Zadeck [EMAIL PROTECTED] writes:
Daniel Berlin wrote:
The attached fixes *that*, but this just causes a crash deeper in trying to
free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the
Hello Ioannis;
Ioannis E. Venetis wrote:
Would __builtin_stack_size (F) retrieve information about F's stack frame
only, or would it also recursively account for every other function that
F may call ?
Implementing the former is probably possible, though I'm not sure
exactly how
On Fri, 2006-01-20 at 12:34 +0100, Andreas Jaeger wrote:
The tree is still broken for me. Daniel, did you commit your patch?
No, because i realized last night that you will just hit the rest of the
problem during bootstrap, without fail.
Andreas
Hello,
The attached fixes *that*, but this just causes a crash deeper in trying
to free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed according to
Daniel, there's still another problem.
Jakub Jelinek writes:
Jakub Not sure why sched allows that, because insn 42 clearly operates on
volatile
Jakub memory. Do you think that's a bug in sched that it should be honoring
Jakub /v and not moving insns accross it, or that something is broken with the
Jakub ppc* patterns?
I
Zdenek Dvorak wrote:
Hello,
The attached fixes *that*, but this just causes a crash deeper in trying
to free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed according to
Geoff Keating wrote:
On 19/01/2006, at 9:08 AM, Peter O'Gorman wrote:
Eric Botcazou wrote:
|Yes the workaround is to add -fexceptions or -shared-libgcc to the
|command line when linking libgnat but I don't know if that is the
correct
|fix or some hacking to config/darwin.h is needed.
|
|
|
LIBGNAT=../rts/libgnat.a
GCC_LINK=$(CC) -static-libgcc $(ADA_INCLUDES)
+TOOL_CC=$(CC) -static-libgcc
I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.
Otherwise the tools part is generally fine with me (passing -static-libgcc
to build
On Fri, 2006-01-20 at 16:06 +0100, Zdenek Dvorak wrote:
Hello,
The attached fixes *that*, but this just causes a crash deeper in trying
to free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is
On Fri, Jan 20, 2006 at 10:10:23AM -0500, David Edelsohn wrote:
Jakub Jelinek writes:
Jakub Not sure why sched allows that, because insn 42 clearly operates on
volatile
Jakub memory. Do you think that's a bug in sched that it should be honoring
Jakub /v and not moving insns accross it,
On Fri, 20 Jan 2006, Kenneth Zadeck wrote:
I would like permission to revert Zdenek's patch for a few days. There
is nothing wrong with zdenek's patch, pe se, but it excercises a part of
df that should work but does not.
I'm going to make an executive decision on this one, to restore
Hello,
The attached fixes *that*, but this just causes a crash deeper in
trying
to free some chains.
[...]
Sorry for the problems and thanks for looking into them.
Ken, please reread the email. The issue is *not* fixed according to
Daniel, there's
Hello,
On Fri, 20 Jan 2006, Kenneth Zadeck wrote:
I would like permission to revert Zdenek's patch for a few days. There
is nothing wrong with zdenek's patch, pe se, but it excercises a part of
df that should work but does not.
I'm going to make an executive decision on this one, to
[...]
| Btw.: of course it may happen that some patch sometimes breaks
| bootstrap, it happened to everyone of us. But, with your patch, not
| even libgcc builds. This means that you did not even try to build gcc
| before commiting your patch.
|
| This is simply not true.
| I in
So he updated his tree, saw changes in the middle-end and committed
his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
only to discover that something again changed in-between, and so on?
--
Eric Botcazou
Eric Botcazou [EMAIL PROTECTED] writes:
| So he updated his tree, saw changes in the middle-end and committed
| his without testing.
|
| So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
| only to discover that something again changed in-between, and so on?
I don't
Hello,
So he updated his tree, saw changes in the middle-end and committed
his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
only to discover that something again changed in-between, and so on?
while the testing procedures for gcc
Eric Botcazou wrote:
So he updated his tree, saw changes in the middle-end and committed
his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of hours
only to discover that something again changed in-between, and so on?
This is exactly what I did,
I don't know whether it would take him hours, since the tree does not
even bootstrap, but most certainly Zdenek's statement was accurate and
our commit procedure wasn't observed.
I'm not sure the commit procedure requires you to retest in that case.
--
Eric Botcazou
On Fri, 20 Jan 2006, Zdenek Dvorak wrote:
I propose the following workaround instead, that also restores
bootstrap. It changes the way loop-iv uses df to more conservative one,
that does not seem to cause problems.
That's what I like to see... options. Yes, this is OK for mainline,
please
Hello,
Eric Botcazou wrote:
So he updated his tree, saw changes in the middle-end and committed
his without testing.
So Kenny would have had to lauch a new bootstrap, wait for a couple of
hours only to discover that something again changed in-between, and so on?
This is
Richard Guenther wrote:
A patch was also posted based on ideas in the audit trail. It's third
incarnation at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
would need a review.
This patch uses type_i == type_j which is usually a mistake; are we
sure we don't need the usual
On Friday 20 January 2006 18:21, Mark Mitchell wrote:
Richard Guenther wrote:
A patch was also posted based on ideas in the audit trail. It's third
incarnation at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
would need a review.
This patch uses type_i == type_j which is
On 1/20/06, Mark Mitchell [EMAIL PROTECTED] wrote:
Richard Guenther wrote:
A patch was also posted based on ideas in the audit trail. It's third
incarnation at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
would need a review.
This patch uses type_i == type_j which is
Steven Bosscher wrote:
On Friday 20 January 2006 18:21, Mark Mitchell wrote:
Richard Guenther wrote:
A patch was also posted based on ideas in the audit trail. It's third
incarnation at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
would need a review.
This patch uses type_i ==
On Friday 20 January 2006 18:34, Steven Bosscher wrote:
On Friday 20 January 2006 18:21, Mark Mitchell wrote:
Richard Guenther wrote:
A patch was also posted based on ideas in the audit trail. It's third
incarnation at
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00967.html
would
Richard Guenther wrote:
patch needs a paragraph-long comment explaining what the problem is and
how this approach solves it.
Ok, I'll try to come up with an explanation.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Friday 20 January 2006 18:38, Mark Mitchell wrote:
Steven Bosscher wrote:
On Friday 20 January 2006 18:21, Mark Mitchell wrote:
Richard Guenther wrote:
A patch was also posted based on ideas in the audit trail. It's third
incarnation at
Anatoly Sokolov [EMAIL PROTECTED] writes:
Hello.
I am the member of the project 'avr-libc' (AVR C Runtime Library). As
a result of this work there were patches with additions of support of
new Atmel devices in gcc the toolchain. I have a desire to add them in
official GCC sources,
On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
FWIW, I don't believe this is a fix, but rather a solid work-around
for the problem. I'm still trusting rth's superior compiler brain and
GCC knowledge to ultimately be ingredients in a real fix ;-)
I don't think it's quite
Richard Henderson wrote:
On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote:
In team.c solaris fails due to the fact that alloca is defined in
alloca.h iso stdlib.h ...
Er, *not* defined did you mean? This should probably be fixed
with a #define to __builtin_alloca in libgomp.h
On 1/20/06, Richard Henderson [EMAIL PROTECTED] wrote:
On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
FWIW, I don't believe this is a fix, but rather a solid work-around
for the problem. I'm still trusting rth's superior compiler brain and
GCC knowledge to ultimately be
Richard Henderson wrote:
On Fri, Jan 20, 2006 at 06:39:21PM +0100, Steven Bosscher wrote:
FWIW, I don't believe this is a fix, but rather a solid work-around
for the problem. I'm still trusting rth's superior compiler brain and
GCC knowledge to ultimately be ingredients in a real fix ;-)
Andreas Tobler wrote:
Richard Henderson wrote:
On Thu, Jan 19, 2006 at 10:45:39PM +0100, Andreas Tobler wrote:
In team.c solaris fails due to the fact that alloca is defined in
alloca.h iso stdlib.h ...
Er, *not* defined did you mean? This should probably be fixed
with a #define to
On Thu, Jan 19, 2006 at 09:56:54PM -0500, DJ Delorie wrote:
Nobody has said anything about this for the last two weeks. Can we
remove this restriction now?
Have you done any testing on common platforms to see what
happens when you change this?
r~
Have you done any testing on common platforms to see what happens
when you change this?
It's been in my x86-64 builds for the last few months. That's the
gcc that gets used for everything else. Are there other platforms
that are likely to have one-bit insv patterns? (of course, that's the
On Fri, Jan 20, 2006 at 10:18:18PM +0100, Andreas Tobler wrote:
or with double guard:
#ifdef HAVE_GETLOADAVG
#ifdef HAVE_SYS_LOADAVG_H
# include sys/loadavg.h
#endif
#endif
This, I guess.
Sounds like a typo in the specs for the platform.
Hm, in gcc.c I find a hardcoded -pthread
On Fri, Jan 20, 2006 at 04:44:04PM -0500, DJ Delorie wrote:
It's been in my x86-64 builds for the last few months. That's the
gcc that gets used for everything else. Are there other platforms
that are likely to have one-bit insv patterns? (of course, that's the
question nobody answered last
Richard Henderson wrote:
On Fri, Jan 20, 2006 at 10:18:18PM +0100, Andreas Tobler wrote:
or with double guard:
#ifdef HAVE_GETLOADAVG
#ifdef HAVE_SYS_LOADAVG_H
# include sys/loadavg.h
#endif
#endif
This, I guess.
Ok. Thanks.
Sounds like a typo in the specs for the platform.
Hm, in
On Fri, Jan 20, 2006 at 03:42:57AM -0500, Jakub Jelinek wrote:
The mem in the sync insn has alias set 0 and no attributes
except MEM_VOLATLE_P. The reason why sched1 decided to move it anyway
is that it proved that the MEMs are different:
Ah yes. I'd meant to go back and add a bit or tag to
m68k and ia64 spring to mind. Both have set-one-bit-in-register
type instructions. But the point isn't that x86-64 continues to
build, but that it's still using the right patterns.
If you could suggest a proper testing strategy, I'm willing to test
it.
On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
I guess a secondary question is: is the workaround sufficiently useful
in many of the problematic cases and sufficiently non-harmful in other
cases as to merit inclusion, given that we don't have a better solution?
I replied with
Richard Henderson wrote:
On Fri, Jan 20, 2006 at 01:26:51PM -0800, Mark Mitchell wrote:
I guess a secondary question is: is the workaround sufficiently useful
in many of the problematic cases and sufficiently non-harmful in other
cases as to merit inclusion, given that we don't have a better
Hm, then sol2.h and sol26.h build the minority where we have pthread_s_.
Don't know the history yet.
That doesn't seem to be a Sun-ism.
--
Eric Botcazou
On Fri, Jan 20, 2006 at 04:56:38PM -0500, DJ Delorie wrote:
If you could suggest a proper testing strategy, I'm willing to test it.
Write a small test that is supposed to use one of the set-bit
insns. Verify that it does before and after the patch.
r~
Snapshot gcc-4.1-20060120 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060120/
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
Arnaud Charlet wrote:
LIBGNAT=../rts/libgnat.a
GCC_LINK=$(CC) -static-libgcc $(ADA_INCLUDES)
+TOOL_CC=$(CC) -static-libgcc
I'd rather avoid code duplication and reuse GCC_LINK if possible, or
split GCC_LINK in two if needed.
I thought so too, and indeed tried it this way at first, but got:
Hi All,
I found following code snippet in file, trunk/gcc/loop-unroll.c
1814 /* Locate in EXPR the expression corresponding to the location recorded
1815in IVTS, and return a pointer to the RTX for this location. */
1816
1817 static rtx *
1818 get_ivts_expr (rtx expr, struct
I noticed today that there were three projects which were merged into
the mainline within a 24 hour period yesterday.
Date: Thu, 19 Jan 2006 01:42:49 - IAB - Daniel Berlin
Date: Thu, 19 Jan 2006 10:24:04 - Vect - Dorit
Date: Thu, 19 Jan 2006 16:55:54 - GOMP - Diego Novillo
So I
On Thu, Jan 19, 2006 at 06:44:28PM -0800, Mark Mitchell wrote:
Joe Buck wrote:
So the answer is that, after consulting with some of the affected people
(which is why you got mail, Mike) the SC told RMS that it would be
changed. If it hasn't been done yet, then it's a release blocker,
This fixes the problems that became apparent from zdeneks patch.
Bootstrapped and regression tested against the version with zdenek's
original code (since this directly tickled the failure and bootstrapped
(and in the process of regression testing) against the current mainline.
Both on
On Sun, 15 Jan 2006 10:40:19 -0600, Perry Smith wrote:
From Andreas's reply, it may not. In AIX, they want the message to
come out in the user's native language so they print out the
translated message (that comes from a separate file).
It's the same with gettext. You have a file
Joe Buck wrote:
It is PR 25892.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
Kenneth Zadeck [EMAIL PROTECTED] writes:
Bootstrapped and regression tested against the version with zdenek's
original code (since this directly tickled the failure and
bootstrapped (and in the process of regression testing) against the
current mainline. Both on i686-pc-linux-gnu.
Kenny
Eric Fisher [EMAIL PROTECTED] writes:
I guess that the macro NGARDS is relevant to the guard digit. But I
still failed to have a clear conception about what it means. Others
are easy to know by IEEE 754 and What Every Computer Scientist Should
Know about Floating-Point Arithmetic. Except,
Steven Bosscher [EMAIL PROTECTED] writes:
The proposed work-around is to avoid confusing RTL alias analysis by
simply not presenting it with situations where two references to the
same memory can have different alias sets.
To recapitulate.
RTL alias analysis assumes that you can reorder
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-01-20 09:30 ---
Subject: Bug 5520
Author: rguenth
Date: Fri Jan 20 09:30:22 2006
New Revision: 110019
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110019
Log:
2006-01-20 Dirk Mueller [EMAIL PROTECTED]
PR
--- Comment #61 from rguenth at gcc dot gnu dot org 2006-01-20 09:39
---
Subject: Bug 24626
Author: rguenth
Date: Fri Jan 20 09:38:56 2006
New Revision: 110020
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110020
Log:
2006-01-20 Richard Guenther [EMAIL PROTECTED]
--- Comment #62 from rguenth at gcc dot gnu dot org 2006-01-20 09:44
---
Done. Let the flames come down to the two of us. :/ (I agree on the
obviousness of the patch, but the part reverting Mostafas fix and four
testcases made the patch somewhat big).
So, fixed on mainline.
--
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-01-20 10:11
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-20 10:19 ---
Confirmed. I can't see anything wrong with the testcase. EDG accepts it in
-strict_ansi mode, as does the old C++ parser.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-20 10:31 ---
Crashes in PRE:
#0 fancy_abort (
file=0x8706c14 ../../../src/svn/gcc/gcc/tree-ssa-operands.c, line=1563,
function=0x870743d add_stmt_operand) at diagnostic.c:602
#1 0x0815126d in add_stmt_operand
The following code crashes the C++ frontend gomp-branch as of today
(yesterdays version worked fine):
void foo()
{
#pragma omp parallel
foo();
}
bug.cc: In function 'void foo()':
bug.cc:1: internal compiler error: in
--- Comment #63 from steven at gcc dot gnu dot org 2006-01-20 12:05 ---
I still think there should be a comment in cfgloopmanip explaining the use of
ir_type there, but I'll take care of that with the additional-checking patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626
--- Comment #36 from matz at suse dot de 2006-01-20 14:01 ---
Yes. Should be done shortly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--
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=25869
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-20 14:06 ---
This is a bug in your installation (distro's problem) of GNU/Linux.
Use --disable-mulitlib unless you need a 32bit gcj and if you do please report
the issue to slackware as it is an issue there and not in GCC.
--
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 14:10 ---
Conifmred but this is actually not a regression from any versions of GCC (after
the EGCS split) that I can tell from as the source has not changed that much.
--
pinskia at gcc dot gnu dot org changed:
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #19 from danglin at gcc dot gnu dot org 2006-01-20 14:30
---
Subject: Bug 24533
Author: danglin
Date: Fri Jan 20 14:30:33 2006
New Revision: 110025
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110025
Log:
PR ada/24533
* s-osinte-linux-hppa.ads:
--- Comment #20 from danglin at gcc dot gnu dot org 2006-01-20 14:32
---
Subject: Bug 24533
Author: danglin
Date: Fri Jan 20 14:32:10 2006
New Revision: 110026
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110026
Log:
PR ada/24533
* s-osinte-linux-hppa.ads:
--- Comment #21 from danglin at gcc dot gnu dot org 2006-01-20 14:34
---
Subject: Bug 24533
Author: danglin
Date: Fri Jan 20 14:34:29 2006
New Revision: 110027
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=110027
Log:
PR ada/24533
* s-osinte-linux-hppa.ads:
Current g++ from the gomp branch ICEs on the attached test case, but only
when -O and -fopenmp is specified:
~/data/planck/LevelSg++ -v -O -fopenmp -c bug.ii
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/gompcc/configure --quiet --prefix=/scratch/ugccgomp
--- Comment #1 from martin at mpa-garching dot mpg dot de 2006-01-20 14:41
---
Created an attachment (id=10685)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10685action=view)
test case to reproduce the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25874
ICEs with 4.1 and 4.2 (but not 4.0):
typedef union {
} ktime_t;
static inline ktime_t ktime_set(const long secs, const unsigned long nsecs)
{
return (ktime_t) { .tv = { .sec = (s32)ts.tv_sec,
.nsec = (s32)ts.tv_nsec } };
--
Summary: [4.1/4.2 Regression] ICE: segmentation
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords||error-recovery
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 14:51 ---
backtrace:
#0 0x00052510 in digest_init (type=0x42ca5960, init=0x0, strict_string=1
'\001', require_constant=0) at
/Users/pinskia/src/gcc/alias/gcc/gcc/c-typeck.c:4497
#1 0x00050ef0 in store_init_value
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-01-20 14:59 ---
Subject: Re: [4.2 Regression] ice with -g -O2
-fPIC
Yes, this is an easy bug to fix.
What happens is PRE things it can PRE anything that is just a bunch of
indirect_ref's, but in reality, there is one
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2006-01-20
15:08 ---
Subject: Re: gnatmake: error while loading shared libraries: libgcc_s.so.4:
cannot open
Indeed, gnatmake has to be handled specially.
So I guess the gnatmake rule needs to use $(GCC_LINK)
one way or
/mnt/gnu/gcc-3.3/objdir/./gcc/xgcc -B/mnt/gnu/gcc-3.3/objdir/./gcc/
-B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/bin/
-B/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/lib/ -isystem
/opt/gnu/gcc/gcc-4.2.0/hppa2.0w-hp-hpux11.11/include -isystem
The attached testcase needs an excessive amount of memory and compile-time to
build with -O2. 500MB max. virtual memory and 1m10s compile-time on a x86_64
machine.
The problem is inlining causes the CodeMaps::CodeMaps constructor to explode
in CFG size (also due to exception handling).
--
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 15:21 ---
Also happens on solaris.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-01-20 15:23 ---
Created an attachment (id=10688)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10688action=view)
testcase
Preprocessed testcase, preprocessed with gcc 4.1 on a SuSE 10.1 beta x86_64.
I minimized it for
A simple example like:
ypedef int nl_item;
extern char *nl_langinfo (nl_item __item) __attribute__ ((__nothrow__));
char *
xtermEnvEncoding(void)
{
static char *result;
if (result == 0) {
result = nl_langinfo(1);
;
}
return result;
}
---
and compile with -O2
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-01-20 15:26 ---
Basically, the initialization sequence expands to a sequence of (.03.gimple):
__comp_ctor (D.68628);
try
{
__comp_ctor (D.68629, ab[0], D.68628);
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-01-20 15:34 ---
Created an attachment (id=10689)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10689action=view)
patch which removes TDF_CHAIN and changes debug_tree_chain to debug_decl_chain
This patch removes TDF_CHAIN and
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
|
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-01-20 15:37 ---
This is all due to recursive inlining IIRC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
--- Comment #4 from tony dot linthicum at amd dot com 2006-01-20 15:48
---
I've been looking at this a bit, and tried the patch. It does indeed fix the
problem in test1 above, but it does not appear to be the complete solution.
The load of 'x' in test1 is actually split fairly early,
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-01-20 15:48 ---
This is all caused by C++ and temporary variables.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25878
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-01-20 15:50 ---
At .ssa we have for the posted fragment the following loads of basic blocks
and exception objects:
bb 1:
D.68636_176 = this_1-iso639_1;
D.68641_177 = operator[] (D.68636_176, D.68639);
bb 2:
this_230 =
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-20 15:52 ---
(In reply to comment #4)
I'm going to experiment with moving where the subreg lowering code occurs and
moving up the splitting into subregs and see if I can get the desired
results.
I'm pretty new to GCC, so
--- Comment #6 from rguenth at gcc dot gnu dot org 2006-01-20 15:53 ---
And we can hope that the SSA inliner will do better on the temporaries, but I
guess the resulting CFG will be unchanged. Penaltizing try/finally in
estimate_num_insn_1 instead of declaring them /* Containers have
1 - 100 of 193 matches
Mail list logo
