* Re: GCC 3.1 Prerelease @ 2002-04-20 17:16 ` Peter Schmid 2002-04-20 17:57 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Peter Schmid @ 2002-04-20 17:16 UTC (permalink / raw) To: gcc; +Cc: mark In my option PR c++/5504, a gcc 3.0 regression, is a critical bug which should be fixed for the upcoming gcc 3.1 release. Otherwise blitz will not compile on systems with less than 1.2 GB of virtual memory, for this small example. A full blown program will contain much more user code requiring even more memory. gcc 2.95.2 consumes about 100 MB of virtual memory when optimisation is turned on. Peter Schmid ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 17:16 ` GCC 3.1 Prerelease Peter Schmid @ 2002-04-20 17:57 ` Mark Mitchell 2002-04-21 14:16 ` Richard Henderson 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 17:57 UTC (permalink / raw) To: Peter Schmid, gcc; +Cc: jason, rth --On Sunday, April 21, 2002 02:35:57 AM +0200 Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de> wrote: > In my option PR c++/5504, a gcc 3.0 regression, is a critical bug > which should be fixed for the upcoming gcc 3.1 release. Otherwise > blitz will not compile on systems with less than 1.2 GB of virtual > memory, for this small example. A full blown program will contain much > more user code requiring even more memory. This is a compile-time performance regression caused by fixing a correctness bug. Correctness trumps; if we can't be both efficient and correct, we should be correct, within reason. (And here lots of programs still compile efficiently; some heavily inlined programs are now taking more memory to compile.) I don't quite understand Richard's last note on the topic -- but I understand his conclusion, which is basically that it's not easy to fix this problem. It sounds like maybe if the front end were to promise that there were no gotos in a particular function, this would improve things, but I'm not sure. Jason, Richard, what do you think about this? The only practical option, beyond the speedups Richard already implemented, is to revert Jason's correctness patch at this point. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 17:57 ` Mark Mitchell @ 2002-04-21 14:16 ` Richard Henderson 2002-04-21 16:54 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Richard Henderson @ 2002-04-21 14:16 UTC (permalink / raw) To: Mark Mitchell; +Cc: Peter Schmid, gcc, jason On Sat, Apr 20, 2002 at 05:24:15PM -0700, Mark Mitchell wrote: > It sounds like maybe if the front end were to promise that there > were no gotos in a particular function, this would improve things, > but I'm not sure. Less severe than that. No gotos within a specific region. Or more to the point, binding cleanup code with exception regions before generating rtl for them rather than after. > Jason, Richard, what do you think about this? The only practical > option, beyond the speedups Richard already implemented, is to > revert Jason's correctness patch at this point. I really dislike the idea of reverting the correctness patch. The most practical solution for people actually using these sorts of template packages is to not nest the expressions quite so deeply. I.e. use c = a + b; e = c * d; g = e + f; instead of g = (a + b) * d + f; or whatever. r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 14:16 ` Richard Henderson @ 2002-04-21 16:54 ` Mark Mitchell 2002-04-23 5:46 ` Jason Merrill 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-21 16:54 UTC (permalink / raw) To: Richard Henderson; +Cc: Peter Schmid, gcc, jason --On Sunday, April 21, 2002 01:50:47 PM -0700 Richard Henderson <rth@redhat.com> wrote: > On Sat, Apr 20, 2002 at 05:24:15PM -0700, Mark Mitchell wrote: >> It sounds like maybe if the front end were to promise that there >> were no gotos in a particular function, this would improve things, >> but I'm not sure. > > Less severe than that. No gotos within a specific region. Or > more to the point, binding cleanup code with exception regions > before generating rtl for them rather than after. OK. >> Jason, Richard, what do you think about this? The only practical >> option, beyond the speedups Richard already implemented, is to >> revert Jason's correctness patch at this point. > > I really dislike the idea of reverting the correctness patch. Me too. > The most practical solution for people actually using these > sorts of template packages is to not nest the expressions > quite so deeply. In general, that hoses the performance of those packages. The point is to do loop fusion and such using the expression-template magic; less nesting means less loop fusion means worse performance. Perhaps, however, they could avoid using *destructors* in these objects; that's not necessary in many of the situations I'm familiar with. I'm inclined just to suffer here, but let's see what Jason thinks. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 16:54 ` Mark Mitchell @ 2002-04-23 5:46 ` Jason Merrill 2002-04-23 9:12 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Jason Merrill @ 2002-04-23 5:46 UTC (permalink / raw) To: Mark Mitchell; +Cc: Richard Henderson, Peter Schmid, gcc >>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes: > I'm inclined just to suffer here, but let's see what Jason thinks. I think I'm inclined to restore the bug on the branch. The code affected by the bug (throwing an exception in a destructor) is much less common than the expression template code; killing compile-time performance for expression templates will impair 3.1's usefulness much more than failing to fix a bug which has always been present. Jason ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 5:46 ` Jason Merrill @ 2002-04-23 9:12 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 9:12 UTC (permalink / raw) To: Jason Merrill; +Cc: Richard Henderson, Peter Schmid, gcc --On Tuesday, April 23, 2002 01:43:27 PM +0100 Jason Merrill <jason@redhat.com> wrote: >>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes: > >> I'm inclined just to suffer here, but let's see what Jason thinks. > > I think I'm inclined to restore the bug on the branch. That makes some sense. OK, let's respect your decision. Would you please undo your change? I guess we should keep the PR open -- and high priority -- since keeping the change on the mainline means we already have a known performance regression to GCC 3.2. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease
@ 2002-04-23 14:56 Tom Tromey
0 siblings, 0 replies; 84+ messages in thread
From: Tom Tromey @ 2002-04-23 14:56 UTC (permalink / raw)
To: gcc
>>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes:
Mark> From this point hence, please do not make any further
Mark> non-documentation check-ins to the GCC 3.1 branch without my
Mark> explicit approval.
Please approve these:
http://gcc.gnu.org/ml/java-patches/2002-q2/msg00209.html
Fixes a bug in the new resource compilation feature.
Without this patch this feature simply doesn't work.
http://gcc.gnu.org/ml/java-patches/2002-q2/msg00208.html
Changes -P to --resource. PR 6314.
Tom
^ permalink raw reply [flat|nested] 84+ messages in thread
* GCC 3.1 prerelease @ 2002-04-23 13:38 Mark Mitchell 2002-04-23 18:37 ` Kurt Wall 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 13:38 UTC (permalink / raw) To: gcc The GCC 3.1 prerelease is on gcc.gnu.org and its mirrors in the snapshots directory. Look for files with 20020423 in their names. Please download the prerelease tarballs and try to build and install them. When the next batch of critical bugs gets fixed, I will spin another prerelease. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 prerelease 2002-04-23 13:38 GCC 3.1 prerelease Mark Mitchell @ 2002-04-23 18:37 ` Kurt Wall 2002-04-23 19:23 ` Phil Edwards 2002-04-24 9:49 ` Mark Mitchell 0 siblings, 2 replies; 84+ messages in thread From: Kurt Wall @ 2002-04-23 18:37 UTC (permalink / raw) To: gcc Scribbling feverishly on April 23, Mark Mitchell managed to emit: > The GCC 3.1 prerelease is on gcc.gnu.org and its mirrors in the snapshots > directory. Look for files with 20020423 in their names. > > Please download the prerelease tarballs and try to build and install them. > > When the next batch of critical bugs gets fixed, I will spin another > prerelease. Is it a matter of policy not to generate MD5 sums for the bz2 archives? If so, I'll grab the gzip archives instead. I feel more comfortable being able to verify the checksums... Thanks, Kurt -- Senate, n.: A body of elderly gentlemen charged with high duties and misdemeanors. -- Ambrose Bierce ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 prerelease 2002-04-23 18:37 ` Kurt Wall @ 2002-04-23 19:23 ` Phil Edwards 2002-04-24 9:49 ` Mark Mitchell 1 sibling, 0 replies; 84+ messages in thread From: Phil Edwards @ 2002-04-23 19:23 UTC (permalink / raw) To: Kurt Wall; +Cc: gcc On Tue, Apr 23, 2002 at 09:20:14PM -0400, Kurt Wall wrote: > Scribbling feverishly on April 23, Mark Mitchell managed to emit: > > The GCC 3.1 prerelease is on gcc.gnu.org and its mirrors in the snapshots > > directory. Look for files with 20020423 in their names. > > Is it a matter of policy not to generate MD5 sums for the bz2 > archives? If so, I'll grab the gzip archives instead. I feel more > comfortable being able to verify the checksums... No, we generate MD5 sums for everything, but not at the same time we upload the files. In fact, if memory serves, it happens overnight, so the checksums should be updated w/n 24 hours. Phil -- If ye love wealth greater than liberty, the tranquility of servitude greater than the animating contest for freedom, go home and leave us in peace. We seek not your counsel, nor your arms. Crouch down and lick the hand that feeds you; and may posterity forget that ye were our countrymen. - Samuel Adams ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 prerelease 2002-04-23 18:37 ` Kurt Wall 2002-04-23 19:23 ` Phil Edwards @ 2002-04-24 9:49 ` Mark Mitchell 2002-04-24 11:03 ` Joseph S. Myers 1 sibling, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-24 9:49 UTC (permalink / raw) To: Kurt Wall, gcc No, it's a matter of the release script not generating either. Probably the md5 checksums lying around with the gzips are out of date. I'll try to add this to the release script. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 prerelease 2002-04-24 9:49 ` Mark Mitchell @ 2002-04-24 11:03 ` Joseph S. Myers 2002-04-24 19:03 ` Kurt Wall 0 siblings, 1 reply; 84+ messages in thread From: Joseph S. Myers @ 2002-04-24 11:03 UTC (permalink / raw) To: Mark Mitchell; +Cc: Kurt Wall, gcc On Wed, 24 Apr 2002, Mark Mitchell wrote: > No, it's a matter of the release script not generating either. Probably > the md5 checksums lying around with the gzips are out of date. > > I'll try to add this to the release script. The MD5 sums are I think generated by some process that runs on gcc.gnu.org and generates them for new FTP files. I don't know the details - this isn't documented at <URL:http://sources.redhat.com/sourceware/ftp.html>. It would be better for actual releases to be cryptographically signed. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 prerelease 2002-04-24 11:03 ` Joseph S. Myers @ 2002-04-24 19:03 ` Kurt Wall 0 siblings, 0 replies; 84+ messages in thread From: Kurt Wall @ 2002-04-24 19:03 UTC (permalink / raw) To: gcc [CCs trimmed] Scribbling feverishly on April 24, Joseph S. Myers managed to emit: > On Wed, 24 Apr 2002, Mark Mitchell wrote: > > > No, it's a matter of the release script not generating either. Probably > > the md5 checksums lying around with the gzips are out of date. > > > > I'll try to add this to the release script. > > The MD5 sums are I think generated by some process that runs on > gcc.gnu.org and generates them for new FTP files. I don't know the > details - this isn't documented at > <URL:http://sources.redhat.com/sourceware/ftp.html>. Ah. Revaming the autogeneration of md5 sums apparently a long-standing TODO item: http://sources.redhat.com/sourceware/TODO.txt > It would be better for actual releases to be cryptographically signed. Agreed, although I realize my opinion carries little weight here. Kurt -- I'm defending her honor, which is more than she ever did. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease
@ 2002-04-23 10:46 Paolo Carlini
0 siblings, 0 replies; 84+ messages in thread
From: Paolo Carlini @ 2002-04-23 10:46 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: gcc
Gerald Pfeifer wrote:
> As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3,
> the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800
> and 1200, respectively, and the 3.2-branch as of yesterday.
Hi,
even if it's not immediately useful in order to deal with the performance problems of 3.1-branch, I think it would be interesting to see what the 3.2-branch numbers would become with the following patch reverted:
http://gcc.gnu.org/ml/gcc/2002-03/msg00216.html
Any chance you can do that?
(I would guess that the improvement on 3.1 comes from the better alias analysis)
Ciao,
Paolo.
^ permalink raw reply [flat|nested] 84+ messages in thread
* GCC 3.1 Prerelease @ 2002-04-23 2:12 Mark Mitchell 2002-04-23 3:53 ` Alan Modra ` (2 more replies) 0 siblings, 3 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 2:12 UTC (permalink / raw) To: gcc I'm now spinning the prerelease. Assuming it works, the tarballs will be on the FTP server by the type I wake up tomorrow morning... From this point hence, please do not make any further non-documentation check-ins to the GCC 3.1 branch without my explicit approval. There are a handful of open bugs remaining that need fixes. By far and away the most worrisome are the IRIX regressions in PR 6212 and PR 6304. These are significant problems (crashes in the generated code). The first allegedly stems from a patch by Kenner -- although one problematic part of that patch has already been reverted. The second problem allegedly stems from a patch by Jan. Gentlemen, your help in tracking down these problems would be very much appreciated. I unfortunately at temporarily without access to my IRIX development platform; my access to ASCI bluemountain should be back soon, but I don't have it now. So, we're going to need someone else to look at these if possible. Joseph, if you have time to look at PR 6343 (C front end regression involving "attribute((weak))"), please do so. I can imagine this being a significant problem. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 2:12 Mark Mitchell @ 2002-04-23 3:53 ` Alan Modra 2002-04-23 4:13 ` Franz Sirl 2002-04-23 9:08 ` Per Bothner 2002-04-23 13:19 ` Richard Henderson 2 siblings, 1 reply; 84+ messages in thread From: Alan Modra @ 2002-04-23 3:53 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote: > > Joseph, if you have time to look at PR 6343 (C front end regression > involving "attribute((weak))"), please do so. I can imagine this > being a significant problem. I've been using this, which at least cures the problem with __register_frame_info*. Credit for the patch goes to Franz Sirl. diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/c-decl.c gcc-31/gcc/c-decl.c --- gcc-31.orig/gcc/c-decl.c 2002-04-03 09:00:04.000000000 +0930 +++ gcc-31/gcc/c-decl.c 2002-04-23 18:06:31.000000000 +0930 @@ -1955,7 +1955,16 @@ duplicate_decls (newdecl, olddecl, diffe } /* Merge the storage class information. */ - DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); + if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) + declare_weak (olddecl); + if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) + declare_weak (newdecl); + if (DECL_WEAK (newdecl) && DECL_RTL (newdecl) + && GET_CODE (DECL_RTL (newdecl)) == MEM + && XEXP (DECL_RTL (newdecl), 0) + && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF) + SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1; + /* For functions, static overrides non-static. */ if (TREE_CODE (newdecl) == FUNCTION_DECL) { diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/cp/decl.c gcc-31/gcc/cp/decl.c --- gcc-31.orig/gcc/cp/decl.c 2002-04-17 18:56:57.000000000 +0930 +++ gcc-31/gcc/cp/decl.c 2002-04-23 18:06:31.000000000 +0930 @@ -3645,7 +3645,15 @@ duplicate_decls (newdecl, olddecl) } /* Merge the storage class information. */ - DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); + if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) + declare_weak (olddecl); + if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) + declare_weak (newdecl); + if (DECL_WEAK (newdecl) && DECL_RTL (newdecl) + && GET_CODE (DECL_RTL (newdecl)) == MEM + && XEXP (DECL_RTL (newdecl), 0) + && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF) + SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1; DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl); DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl); TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl); -- Alan Modra IBM OzLabs - Linux Technology Centre ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 3:53 ` Alan Modra @ 2002-04-23 4:13 ` Franz Sirl 2002-04-23 4:32 ` Alan Modra 0 siblings, 1 reply; 84+ messages in thread From: Franz Sirl @ 2002-04-23 4:13 UTC (permalink / raw) To: Alan Modra; +Cc: Mark Mitchell, gcc At 12:28 23.04.2002, Alan Modra wrote: >On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote: > > > > Joseph, if you have time to look at PR 6343 (C front end regression > > involving "attribute((weak))"), please do so. I can imagine this > > being a significant problem. > >I've been using this, which at least cures the problem with >__register_frame_info*. Credit for the patch goes to Franz Sirl. Hmm, have you tried recompiling glibc with this patch? I seem to recall glibc using constructs that would produce an error now. Anyway, I'll look into that stuff again later today. Franz. >diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/c-decl.c gcc-31/gcc/c-decl.c >--- gcc-31.orig/gcc/c-decl.c 2002-04-03 09:00:04.000000000 +0930 >+++ gcc-31/gcc/c-decl.c 2002-04-23 18:06:31.000000000 +0930 >@@ -1955,7 +1955,16 @@ duplicate_decls (newdecl, olddecl, diffe > } > > /* Merge the storage class information. */ >- DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); >+ if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) >+ declare_weak (olddecl); >+ if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) >+ declare_weak (newdecl); >+ if (DECL_WEAK (newdecl) && DECL_RTL (newdecl) >+ && GET_CODE (DECL_RTL (newdecl)) == MEM >+ && XEXP (DECL_RTL (newdecl), 0) >+ && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF) >+ SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1; >+ > /* For functions, static overrides non-static. */ > if (TREE_CODE (newdecl) == FUNCTION_DECL) > { >diff -urpN -xCVS -x'*~' -xTAGS gcc-31.orig/gcc/cp/decl.c gcc-31/gcc/cp/decl.c >--- gcc-31.orig/gcc/cp/decl.c 2002-04-17 18:56:57.000000000 +0930 >+++ gcc-31/gcc/cp/decl.c 2002-04-23 18:06:31.000000000 +0930 >@@ -3645,7 +3645,15 @@ duplicate_decls (newdecl, olddecl) > } > > /* Merge the storage class information. */ >- DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); >+ if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) >+ declare_weak (olddecl); >+ if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) >+ declare_weak (newdecl); >+ if (DECL_WEAK (newdecl) && DECL_RTL (newdecl) >+ && GET_CODE (DECL_RTL (newdecl)) == MEM >+ && XEXP (DECL_RTL (newdecl), 0) >+ && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF) >+ SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1; > DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl); > DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl); > TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl); > > >-- >Alan Modra >IBM OzLabs - Linux Technology Centre ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 4:13 ` Franz Sirl @ 2002-04-23 4:32 ` Alan Modra 2002-04-23 10:40 ` Franz Sirl 0 siblings, 1 reply; 84+ messages in thread From: Alan Modra @ 2002-04-23 4:32 UTC (permalink / raw) To: Franz Sirl; +Cc: Mark Mitchell, gcc On Tue, Apr 23, 2002 at 01:04:39PM +0200, Franz Sirl wrote: > At 12:28 23.04.2002, Alan Modra wrote: > >On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote: > >> > >> Joseph, if you have time to look at PR 6343 (C front end regression > >> involving "attribute((weak))"), please do so. I can imagine this > >> being a significant problem. > > > >I've been using this, which at least cures the problem with > >__register_frame_info*. Credit for the patch goes to Franz Sirl. > > Hmm, have you tried recompiling glibc with this patch? I seem to recall > glibc using constructs that would produce an error now. I've been compiling a glibc snapshot with a last ChangeLog entry of 2002-01-18 Andreas Schwab <schwab@suse.de> -- Alan Modra IBM OzLabs - Linux Technology Centre ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 4:32 ` Alan Modra @ 2002-04-23 10:40 ` Franz Sirl 2002-04-23 11:42 ` Richard Henderson 2002-04-23 12:22 ` Jason Merrill 0 siblings, 2 replies; 84+ messages in thread From: Franz Sirl @ 2002-04-23 10:40 UTC (permalink / raw) To: Alan Modra; +Cc: Mark Mitchell, gcc, Jason Merrill, rth [-- Attachment #1: Type: text/plain, Size: 1376 bytes --] At 13:13 23.04.2002, Alan Modra wrote: >On Tue, Apr 23, 2002 at 01:04:39PM +0200, Franz Sirl wrote: > > At 12:28 23.04.2002, Alan Modra wrote: > > >On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote: > > >> > > >> Joseph, if you have time to look at PR 6343 (C front end regression > > >> involving "attribute((weak))"), please do so. I can imagine this > > >> being a significant problem. > > > > > >I've been using this, which at least cures the problem with > > >__register_frame_info*. Credit for the patch goes to Franz Sirl. > > > > Hmm, have you tried recompiling glibc with this patch? I seem to recall > > glibc using constructs that would produce an error now. > >I've been compiling a glibc snapshot with a last ChangeLog entry of >2002-01-18 Andreas Schwab <schwab@suse.de> OK, try compiling glibc with the attached patch, it should give you some warnings :-). What do you all think about this patch? It covers all the cases I could think of, but maybe I missed something. Please take a close look at my changes to declare_weak, I'm not too sure my DECL checking is 100% correct/allowed. Can someone think of a better warning message? And what about a merge_weak() function (naming? in which file?) instead of duplicating the code? The testcases are planned for the dg framework, but I haven't added all the dg funkiness yet :-). Franz. [-- Attachment #2: gcc-weaksym-4.patch --] [-- Type: application/octet-stream, Size: 3000 bytes --] Index: gcc/c-decl.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v retrieving revision 1.300.2.5 diff -u -p -r1.300.2.5 c-decl.c --- gcc/c-decl.c 28 Mar 2002 18:49:57 -0000 1.300.2.5 +++ gcc/c-decl.c 23 Apr 2002 16:51:11 -0000 @@ -1955,7 +1955,16 @@ duplicate_decls (newdecl, olddecl, diffe } /* Merge the storage class information. */ - DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); + if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) + declare_weak (olddecl); + if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) + declare_weak (newdecl); + if (DECL_WEAK (newdecl) && DECL_RTL (newdecl) + && GET_CODE (DECL_RTL (newdecl)) == MEM + && XEXP (DECL_RTL (newdecl), 0) + && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF) + SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1; + /* For functions, static overrides non-static. */ if (TREE_CODE (newdecl) == FUNCTION_DECL) { Index: gcc/varasm.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/varasm.c,v retrieving revision 1.250.2.7 diff -u -p -r1.250.2.7 varasm.c --- gcc/varasm.c 25 Mar 2002 00:54:26 -0000 1.250.2.7 +++ gcc/varasm.c 23 Apr 2002 16:51:11 -0000 @@ -4998,12 +4998,14 @@ declare_weak (decl) { if (! TREE_PUBLIC (decl)) error_with_decl (decl, "weak declaration of `%s' must be public"); - else if (TREE_ASM_WRITTEN (decl)) + else if (TREE_CODE (decl) == FUNCTION_DECL && TREE_ASM_WRITTEN (decl)) error_with_decl (decl, "weak declaration of `%s' must precede definition"); else if (SUPPORTS_WEAK) { if (! DECL_WEAK (decl)) weak_decls = tree_cons (NULL, decl, weak_decls); + if (TREE_USED (decl)) + warning_with_decl (decl, "weak declaration of `%s' after first use may result in unspecified behaviour"); } else warning_with_decl (decl, "weak declaration of `%s' not supported"); Index: gcc/cp/decl.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/cp/decl.c,v retrieving revision 1.866.2.23 diff -u -p -r1.866.2.23 decl.c --- gcc/cp/decl.c 16 Apr 2002 03:15:54 -0000 1.866.2.23 +++ gcc/cp/decl.c 23 Apr 2002 16:51:12 -0000 @@ -3645,7 +3645,16 @@ duplicate_decls (newdecl, olddecl) } /* Merge the storage class information. */ - DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); + if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) + declare_weak (olddecl); + if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) + declare_weak (newdecl); + if (DECL_WEAK (newdecl) && DECL_RTL (newdecl) + && GET_CODE (DECL_RTL (newdecl)) == MEM + && XEXP (DECL_RTL (newdecl), 0) + && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF) + SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1; + DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl); DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl); TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl); [-- Attachment #3: weak-2.c --] [-- Type: text/plain, Size: 2508 bytes --] // test function addresses with __attribute__((weak)) extern void * ffoo1a (void) __attribute__((weak)); extern void * ffoo1a (void); void * foo1a (void) { return (void *)ffoo1a; } extern void * ffoo2a (void); extern void * ffoo2a (void) __attribute__((weak)); void * foo2a (void) { return (void *)ffoo2a; } extern void * ffoo3a (void); void * foo3a (void) { return (void *)ffoo3a; } extern void * ffoo3a (void) __attribute__((weak)); // test function addresses with #pragma weak #pragma weak ffoo1b extern void * ffoo1b (void); void * foo1b (void) { return (void *)ffoo1b; } extern void * ffoo2b (void); #pragma weak ffoo2b void * foo2b (void) { return (void *)ffoo2b; } extern void * ffoo3b (void); void * foo3b (void) { return (void *)ffoo3b; } #pragma weak ffoo3b // test variable addresses with __attribute__((weak)) extern int vfoo1c __attribute__((weak)); extern int vfoo1c; void * foo1c (void) { return (void *)&vfoo1c; } extern int vfoo2c; extern int vfoo2c __attribute__((weak)); void * foo2c (void) { return (void *)&vfoo2c; } extern int vfoo3c; void * foo3c (void) { return (void *)&vfoo3c; } extern int vfoo3c __attribute__((weak)); extern int vfoo4c __attribute__((weak)); int vfoo4c; void * foo4c (void) { return (void *)&vfoo4c; } int vfoo5c; extern int vfoo5c __attribute__((weak)); void * foo5c (void) { return (void *)&vfoo5c; } int vfoo6c; void * foo6c (void) { return (void *)&vfoo6c; } extern int vfoo6c __attribute__((weak)); extern int vfoo7c; void * foo7c (void) { return (void *)&vfoo7c; } int vfoo7c __attribute__((weak)); extern int vfoo8c __attribute__((weak)); void * foo8c (void) { return (void *)&vfoo8c; } extern int vfoo8c __attribute__((weak)); int vfoo8c; // test variable addresses with #pragma weak #pragma weak vfoo1d extern int vfoo1d; void * foo1d (void) { return (void *)&vfoo1d; } extern int vfoo2d; #pragma weak vfoo2d void * foo2d (void) { return (void *)&vfoo2d; } extern int vfoo3d; void * foo3d (void) { return (void *)&vfoo3d; } #pragma weak vfoo3d #pragma weak vfoo4d int vfoo4d; void * foo4d (void) { return (void *)&vfoo4d; } int vfoo5d; #pragma weak vfoo5d void * foo5d (void) { return (void *)&vfoo5d; } int vfoo6d; void * foo6d (void) { return (void *)&vfoo6d; } #pragma weak vfoo6d extern int vfoo7d; void * foo7d (void) { return (void *)&vfoo7d; } #pragma weak vfoo7d int vfoo7d; extern int vfoo8d; void * foo8d (void) { return (void *)&vfoo8d; } int vfoo8d; #pragma weak vfoo8d [-- Attachment #4: weak-3.c --] [-- Type: text/plain, Size: 120 bytes --] extern void * foo (void); void * foo (void) { return (void *)foo; } extern void * foo (void) __attribute__((weak)); [-- Attachment #5: weak-4.c --] [-- Type: text/plain, Size: 89 bytes --] extern void * foo (void); void * foo (void) { return (void *)foo; } #pragma weak foo ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 10:40 ` Franz Sirl @ 2002-04-23 11:42 ` Richard Henderson 2002-04-23 15:08 ` Franz Sirl 2002-04-23 12:22 ` Jason Merrill 1 sibling, 1 reply; 84+ messages in thread From: Richard Henderson @ 2002-04-23 11:42 UTC (permalink / raw) To: Franz Sirl; +Cc: Alan Modra, Mark Mitchell, gcc, Jason Merrill On Tue, Apr 23, 2002 at 07:28:22PM +0200, Franz Sirl wrote: > What do you all think about this patch? It covers all the cases I could > think of, but maybe I missed something. I don't see why functions should be singled out in having to have the weakening before the definition. Otherwise it looks ok. r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 11:42 ` Richard Henderson @ 2002-04-23 15:08 ` Franz Sirl 2002-04-23 15:10 ` Richard Henderson 2002-04-24 10:56 ` Jason Merrill 0 siblings, 2 replies; 84+ messages in thread From: Franz Sirl @ 2002-04-23 15:08 UTC (permalink / raw) To: Richard Henderson; +Cc: Alan Modra, Mark Mitchell, gcc, Jason Merrill [-- Attachment #1: Type: text/plain, Size: 1548 bytes --] On Tuesday 23 April 2002 20:04, Richard Henderson wrote: > On Tue, Apr 23, 2002 at 07:28:22PM +0200, Franz Sirl wrote: > > What do you all think about this patch? It covers all the cases I could > > think of, but maybe I missed something. > > I don't see why functions should be singled out in having to have > the weakening before the definition. Hmm, I didn't want to get too aggressive in here (declare_weak wasn't called for VAR_DECLs before) and judging from the comments in tree.h it looks like TREE_ASM_WRITTEN has a slightly different meaning for a VAR_DECL. But if you think it's OK, I'll happily change it. Looking at the warnings in glibc it turned out I was already too aggressive, the patch would warn for: extern double strtod (__const char *__restrict __nptr, char **__restrict __endptr); extern double __strtod_internal (__const char *__restrict __nptr, char **__restrict __endptr, int __group); extern __inline double strtod (__const char *__restrict __nptr, char **__restrict __endptr) { return __strtod_internal (__nptr, __endptr, 0); } extern __inline double atof (__const char *__nptr) { return strtod (__nptr, (char **) ((void *)0)); } double __attribute__ ((weak)) strtod (nptr, endptr) const char *nptr; char **endptr; { return __strtod_internal (nptr, endptr, 0 ); } I don't think we want a warning here for strtod? Appended an updated patch with Jason's suggestions integrated as well. I'll run a few more tests tomorrow. Franz. [-- Attachment #2: gcc-weaksym-5.patch --] [-- Type: text/plain, Size: 2826 bytes --] Index: gcc/c-decl.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/c-decl.c,v retrieving revision 1.300.2.5 diff -u -p -r1.300.2.5 c-decl.c --- gcc/c-decl.c 28 Mar 2002 18:49:57 -0000 1.300.2.5 +++ gcc/c-decl.c 23 Apr 2002 21:41:28 -0000 @@ -1955,7 +1955,11 @@ duplicate_decls (newdecl, olddecl, diffe } /* Merge the storage class information. */ - DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); + if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) + declare_weak (olddecl); + if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) + declare_weak (newdecl); + /* For functions, static overrides non-static. */ if (TREE_CODE (newdecl) == FUNCTION_DECL) { Index: gcc/varasm.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/varasm.c,v retrieving revision 1.250.2.7 diff -u -p -r1.250.2.7 varasm.c --- gcc/varasm.c 25 Mar 2002 00:54:26 -0000 1.250.2.7 +++ gcc/varasm.c 23 Apr 2002 21:41:28 -0000 @@ -4998,17 +4998,25 @@ declare_weak (decl) { if (! TREE_PUBLIC (decl)) error_with_decl (decl, "weak declaration of `%s' must be public"); - else if (TREE_ASM_WRITTEN (decl)) + else if (TREE_CODE (decl) == FUNCTION_DECL && TREE_ASM_WRITTEN (decl)) error_with_decl (decl, "weak declaration of `%s' must precede definition"); else if (SUPPORTS_WEAK) { if (! DECL_WEAK (decl)) weak_decls = tree_cons (NULL, decl, weak_decls); + if (TREE_CODE (decl) != FUNCTION_DECL && TREE_USED (decl)) + warning_with_decl (decl, "weak declaration of `%s' after first use may result in unspecified behaviour"); } else warning_with_decl (decl, "weak declaration of `%s' not supported"); DECL_WEAK (decl) = 1; + + if (DECL_RTL_SET_P (decl) + && GET_CODE (DECL_RTL (decl)) == MEM + && XEXP (DECL_RTL (decl), 0) + && GET_CODE (XEXP (DECL_RTL (decl), 0)) == SYMBOL_REF) + SYMBOL_REF_WEAK (XEXP (DECL_RTL (decl), 0)) = 1; } /* Emit any pending weak declarations. */ Index: gcc/cp/decl.c =================================================================== RCS file: /cvsroot/gcc/gcc/gcc/cp/decl.c,v retrieving revision 1.866.2.23 diff -u -p -r1.866.2.23 decl.c --- gcc/cp/decl.c 16 Apr 2002 03:15:54 -0000 1.866.2.23 +++ gcc/cp/decl.c 23 Apr 2002 21:41:28 -0000 @@ -3645,7 +3645,11 @@ duplicate_decls (newdecl, olddecl) } /* Merge the storage class information. */ - DECL_WEAK (newdecl) |= DECL_WEAK (olddecl); + if (DECL_WEAK (newdecl) && !DECL_WEAK (olddecl)) + declare_weak (olddecl); + if (!DECL_WEAK (newdecl) && DECL_WEAK (olddecl)) + declare_weak (newdecl); + DECL_ONE_ONLY (newdecl) |= DECL_ONE_ONLY (olddecl); DECL_DEFER_OUTPUT (newdecl) |= DECL_DEFER_OUTPUT (olddecl); TREE_PUBLIC (newdecl) = TREE_PUBLIC (olddecl); ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 15:08 ` Franz Sirl @ 2002-04-23 15:10 ` Richard Henderson 2002-04-24 10:56 ` Jason Merrill 1 sibling, 0 replies; 84+ messages in thread From: Richard Henderson @ 2002-04-23 15:10 UTC (permalink / raw) To: Franz Sirl; +Cc: Alan Modra, Mark Mitchell, gcc, Jason Merrill On Wed, Apr 24, 2002 at 12:03:42AM +0200, Franz Sirl wrote: > (declare_weak wasn't called for VAR_DECLs before) Huh? It must have been. > ... and judging from the comments in tree.h it looks like > TREE_ASM_WRITTEN has a slightly different meaning for a VAR_DECL. What makes you think that? > I don't think we want a warning here for strtod? I can make an argument either way. I'm inclined to warn, since older gcc would in fact render this into rtl right away, which has then already made decisions based on DECL_WEAK. r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 15:08 ` Franz Sirl 2002-04-23 15:10 ` Richard Henderson @ 2002-04-24 10:56 ` Jason Merrill 2002-04-24 12:04 ` Franz Sirl 1 sibling, 1 reply; 84+ messages in thread From: Jason Merrill @ 2002-04-24 10:56 UTC (permalink / raw) To: Franz Sirl; +Cc: Richard Henderson, Alan Modra, Mark Mitchell, gcc [-- Attachment #1: Type: text/plain, Size: 215 bytes --] While I was looking at this bug earlier (before I saw that you were working on it), I made this change. Checking TREE_SYMBOL_REFERENCED makes more sense than TREE_USED anyway, since it's the symbol we care about. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: Type: text/x-patch, Size: 652 bytes --] *** varasm.c.~1~ Wed Apr 24 01:04:56 2002 --- varasm.c Tue Apr 23 15:43:46 2002 *************** weak_finish () *** 5022,5028 **** tree decl = TREE_VALUE (t); const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)); ! if (! TREE_USED (decl)) continue; #ifdef ASM_WEAKEN_DECL --- 5022,5030 ---- tree decl = TREE_VALUE (t); const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (decl)); ! /* We can't rely on TREE_USED here, as decl might be a discarded ! duplicate. */ ! if (! TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))) continue; #ifdef ASM_WEAKEN_DECL ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-24 10:56 ` Jason Merrill @ 2002-04-24 12:04 ` Franz Sirl 2002-04-24 13:03 ` Richard Henderson 2002-04-24 13:14 ` Jason Merrill 0 siblings, 2 replies; 84+ messages in thread From: Franz Sirl @ 2002-04-24 12:04 UTC (permalink / raw) To: Jason Merrill; +Cc: Richard Henderson, Alan Modra, Mark Mitchell, gcc On Wednesday 24 April 2002 19:31, Jason Merrill wrote: > While I was looking at this bug earlier (before I saw that you were working > on it), I made this change. Checking TREE_SYMBOL_REFERENCED makes more > sense than TREE_USED anyway, since it's the symbol we care about. Hmm, it seems to make more sense for the warning check too, with TREE_USED changed to TREE_SYMBOL_REFERENCED the c++ regression g++.old-deja/g++.jason/template39.C went away along with a bunch of regressions in the libstdc++ testsuite, except one: FAIL: 26_numerics/complex_inserters_extractors.cc (test for excess errors) Excess errors: /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h: In instantiation of `const size_t std::basic_string<char, gnu_cha r_traits, std::allocator<char> >::npos': /home/fsirl/TC/gcc/BUILD/gcc-3.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc:109: instantiated from here /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h:217: warning: weak declaration of `const size_t std::basic_string< char, gnu_char_traits, std::allocator<char> >::npos' after first use may result in unspecified behaviour Can a c++ expert tell me if this warning makes sense in this testcase or does the warning check need still more refinement? Hmm, Jason, I'm just noticing the purpose of the test in weak_finish. This seems to be a behaviour change compared to earlier gcc releases. A simple file like that: #pragma weak foo1 extern int foo2 __attribute__((weak)); will now result in this assembly file: .file "weak-pragma.c" .ident "GCC: (GNU) 3.1 20020423 (prerelease)" But upto 3.0.x we got: .file "weak-pragma.c" .weak foo2 .weak foo1 .ident "GCC: (GNU) 3.0.3 20011213 (prerelease)" Are we sure there is no code out there relying on these lonely .weak statements? Was this change intended? Franz. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-24 12:04 ` Franz Sirl @ 2002-04-24 13:03 ` Richard Henderson 2002-04-24 13:14 ` Jason Merrill 1 sibling, 0 replies; 84+ messages in thread From: Richard Henderson @ 2002-04-24 13:03 UTC (permalink / raw) To: Franz Sirl; +Cc: Jason Merrill, Alan Modra, Mark Mitchell, gcc On Wed, Apr 24, 2002 at 09:01:39PM +0200, Franz Sirl wrote: > Are we sure there is no code out there relying on these lonely .weak > statements? Was this change intended? Yes and yes. r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-24 12:04 ` Franz Sirl 2002-04-24 13:03 ` Richard Henderson @ 2002-04-24 13:14 ` Jason Merrill 1 sibling, 0 replies; 84+ messages in thread From: Jason Merrill @ 2002-04-24 13:14 UTC (permalink / raw) To: Franz Sirl; +Cc: Richard Henderson, Alan Modra, Mark Mitchell, gcc >>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes: > Hmm, it seems to make more sense for the warning check too, with TREE_USED > changed to TREE_SYMBOL_REFERENCED the c++ regression > g++.old-deja/g++.jason/template39.C went away along with a bunch of > regressions in the libstdc++ testsuite, except one: > FAIL: 26_numerics/complex_inserters_extractors.cc (test for excess errors) > Excess errors: > /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h: > In instantiation of `const size_t std::basic_string<char, gnu_char_traits, std::allocator<char> >::npos': > /home/fsirl/TC/gcc/BUILD/gcc-3.1/libstdc++-v3/testsuite/26_numerics/complex_inserters_extractors.cc:109: > instantiated from here > /home/fsirl/TC/gcc/BUILD/obj-gcc31-ppc/ppc-linux/libstdc++-v3/include/bits/basic_string.h:217: > warning: weak declaration of `const size_t std::basic_string<char, > gnu_char_traits, std::allocator<char> >::npos' after first use may result > in unspecified behaviour > Can a c++ expert tell me if this warning makes sense in this testcase or does > the warning check need still more refinement? The latter. We don't want to warn about the C++ frontend's internal trickery with DECL_WEAK. I'd prefer to omit the warning entirely on the branch. > Hmm, Jason, I'm just noticing the purpose of the test in weak_finish. ... > Are we sure there is no code out there relying on these lonely .weak > statements? Was this change intended? I believe so. But Richard was the one who made the change. Jason ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 10:40 ` Franz Sirl 2002-04-23 11:42 ` Richard Henderson @ 2002-04-23 12:22 ` Jason Merrill 1 sibling, 0 replies; 84+ messages in thread From: Jason Merrill @ 2002-04-23 12:22 UTC (permalink / raw) To: Franz Sirl; +Cc: Alan Modra, Mark Mitchell, gcc, rth >>>>> "Franz" == Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes: > + if (DECL_WEAK (newdecl) && DECL_RTL (newdecl) > + && GET_CODE (DECL_RTL (newdecl)) == MEM > + && XEXP (DECL_RTL (newdecl), 0) > + && GET_CODE (XEXP (DECL_RTL (newdecl), 0)) == SYMBOL_REF) > + SYMBOL_REF_WEAK (XEXP (DECL_RTL (newdecl), 0)) = 1; This should use DECL_RTL_SET_P. Also, wouldn't it make sense to handle this in declare_weak? Jason ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 2:12 Mark Mitchell 2002-04-23 3:53 ` Alan Modra @ 2002-04-23 9:08 ` Per Bothner 2002-04-23 9:30 ` Mark Mitchell 2002-04-23 13:19 ` Richard Henderson 2 siblings, 1 reply; 84+ messages in thread From: Per Bothner @ 2002-04-23 9:08 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc I just created pr java/6425. I'm biased, but I think this needs to be fixed before the release. Nic Ferrier discovered it, I verified it yesterday, and sent a message to the java list. No answers yet. -- --Per Bothner per@bothner.com http://www.bothner.com/per/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 9:08 ` Per Bothner @ 2002-04-23 9:30 ` Mark Mitchell 2002-04-23 10:12 ` Per Bothner 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 9:30 UTC (permalink / raw) To: Per Bothner; +Cc: gcc --On Tuesday, April 23, 2002 08:54:45 AM -0700 Per Bothner <per@bothner.com> wrote: > I just created pr java/6425. > I'm biased, but I think this needs to be fixed before the release. Don't be biased; just tell me if it's a regression. :-) If it is, we should fix it. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 9:30 ` Mark Mitchell @ 2002-04-23 10:12 ` Per Bothner 2002-04-23 13:25 ` Mark Mitchell 2002-04-23 14:52 ` Tom Tromey 0 siblings, 2 replies; 84+ messages in thread From: Per Bothner @ 2002-04-23 10:12 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Mark Mitchell wrote: > > > --On Tuesday, April 23, 2002 08:54:45 AM -0700 Per Bothner > <per@bothner.com> wrote: > >> I just created pr java/6425. >> I'm biased, but I think this needs to be fixed before the release. > > > Don't be biased; just tell me if it's a regression. :-) > > If it is, we should fix it. It's a regression. Last time I tried to build Kawa using gcj, it worked. Now it doesn't. -- --Per Bothner per@bothner.com http://www.bothner.com/per/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 10:12 ` Per Bothner @ 2002-04-23 13:25 ` Mark Mitchell 2002-04-23 14:52 ` Tom Tromey 1 sibling, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 13:25 UTC (permalink / raw) To: Per Bothner; +Cc: gcc --On Tuesday, April 23, 2002 09:49:34 AM -0700 Per Bothner <per@bothner.com> wrote: > Mark Mitchell wrote: >> >> >> --On Tuesday, April 23, 2002 08:54:45 AM -0700 Per Bothner >> <per@bothner.com> wrote: >> >>> I just created pr java/6425. >>> I'm biased, but I think this needs to be fixed before the release. >> >> >> Don't be biased; just tell me if it's a regression. :-) >> >> If it is, we should fix it. > > It's a regression. Last time I tried to build Kawa using > gcj, it worked. Now it doesn't. Please mark that sucker high priority then. And see if you can fix it! :-) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 10:12 ` Per Bothner 2002-04-23 13:25 ` Mark Mitchell @ 2002-04-23 14:52 ` Tom Tromey 2002-04-23 15:02 ` Per Bothner 1 sibling, 1 reply; 84+ messages in thread From: Tom Tromey @ 2002-04-23 14:52 UTC (permalink / raw) To: Per Bothner; +Cc: gcc, Alexandre Petit-Bianco, Java Discuss List >>>>> "Per" == Per Bothner <per@bothner.com> writes: Per> I just created pr java/6425. I'm biased, but I think this needs Per> to be fixed before the release. I looked at this. First, the problem occurs on this line: sbuf.append(RealNum.toScaledInt(number, 10).toString()); Breaking this into two lines, like so, makes the code compile: IntNum x = RealNum.toScaledInt(number, 10); sbuf.append(x.toString()); That's interesting information. It helped me track down the difference between what happens when things go ok and when they don't. However I don't fully understand what it means. The class-loading code seems pretty fragile. If it is going to compare file names it seems like it ought to compare the results of realpath(). Otherwise there might be ways to fool it. However, while this code isn't ideal (as far as I can see anyway), I think the problem lies elsewhere. The appended patch fixes the problem for me. What happened was we got to this code with an EXPR_WITH_FILE_LOCATION like this: arg 0 <expr_with_file_location 0x4012a420 arg 0 <identifier_node 0x4012a480 RealNum.toScaledInt tree_2> arg 1 <identifier_node 0x40126340 FixedRealFormat.java> arg 2 <tree_list 0x4012917c purpose <expr_with_file_location 0x4012a4a0 arg 0 <identifier_node 0x4012a400 RealNum> arg 1 <identifier_node 0x40126340 FixedRealFormat.java> FixedRealFormat.java:9:16> chain <tree_list 0x40129190 purpose <expr_with_file_location 0x4012a4c0 arg 0 <identifier_node 0x4012a440 toScaledInt> arg 1 <identifier_node 0x40126340 FixedRealFormat.java> FixedRealFormat.java:9:23>>> FixedRealFormat.java:9:16> If we strip the outer EXPR_WITH_FILE_LOCATION, as the patch does, we end up with qual_wfl as: <identifier_node 0x4012a400 RealNum> Anyway, I don't really understand what is going on here. I assume there is some reason for the existing `if', but I don't know what it is. I'm going to try rebuilding libgcj with this patch and see how that goes. Alex, can you look at this quickly? As far as I know you're the only one who really understands this code. Tom Index: ChangeLog from Tom Tromey <tromey@redhat.com> * parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose EXPR_WFL_QUALIFICATION of qual_wfl. Index: parse.y =================================================================== RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v retrieving revision 1.353.2.17 diff -u -r1.353.2.17 parse.y --- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17 +++ parse.y 23 Apr 2002 21:01:01 -0000 @@ -11219,11 +11219,8 @@ { case CALL_EXPR: qual_wfl = TREE_OPERAND (qual_wfl, 0); - if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION) - { - qual = EXPR_WFL_QUALIFICATION (qual_wfl); - qual_wfl = QUAL_WFL (qual); - } + qual = EXPR_WFL_QUALIFICATION (qual_wfl); + qual_wfl = QUAL_WFL (qual); break; case NEW_ARRAY_EXPR: case NEW_ANONYMOUS_ARRAY_EXPR: ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 14:52 ` Tom Tromey @ 2002-04-23 15:02 ` Per Bothner 2002-04-23 16:11 ` Tom Tromey 0 siblings, 1 reply; 84+ messages in thread From: Per Bothner @ 2002-04-23 15:02 UTC (permalink / raw) To: tromey; +Cc: gcc, Alexandre Petit-Bianco, Java Discuss List Tom Tromey wrote: > Index: ChangeLog > from Tom Tromey <tromey@redhat.com> > > * parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose > EXPR_WFL_QUALIFICATION of qual_wfl. > > Index: parse.y > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v > retrieving revision 1.353.2.17 > diff -u -r1.353.2.17 parse.y > --- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17 > +++ parse.y 23 Apr 2002 21:01:01 -0000 > @@ -11219,11 +11219,8 @@ > { > case CALL_EXPR: > qual_wfl = TREE_OPERAND (qual_wfl, 0); > - if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION) > - { > - qual = EXPR_WFL_QUALIFICATION (qual_wfl); > - qual_wfl = QUAL_WFL (qual); > - } > + qual = EXPR_WFL_QUALIFICATION (qual_wfl); > + qual_wfl = QUAL_WFL (qual); > break; > case NEW_ARRAY_EXPR: > case NEW_ANONYMOUS_ARRAY_EXPR: This patch causes building Kawa to break even earlier (while generating class files). -- --Per Bothner per@bothner.com http://www.bothner.com/per/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 15:02 ` Per Bothner @ 2002-04-23 16:11 ` Tom Tromey 2002-04-24 10:14 ` Alexandre Petit-Bianco 0 siblings, 1 reply; 84+ messages in thread From: Tom Tromey @ 2002-04-23 16:11 UTC (permalink / raw) To: Per Bothner; +Cc: gcc, Alexandre Petit-Bianco, Java Discuss List >>>>> "Per" == Per Bothner <per@bothner.com> writes: Per> This patch causes building Kawa to break even earlier (while Per> generating class files). Yeah, I saw that once I started rebuilding libgcj with it. Try the appended. We really need Alex to look at this though. Tom Index: ChangeLog from Tom Tromey <tromey@redhat.com> * parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose EXPR_WFL_QUALIFICATION of qual_wfl. Index: parse.y =================================================================== RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v retrieving revision 1.353.2.17 diff -u -r1.353.2.17 parse.y --- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17 +++ parse.y 23 Apr 2002 23:04:15 -0000 @@ -11219,7 +11219,9 @@ { case CALL_EXPR: qual_wfl = TREE_OPERAND (qual_wfl, 0); - if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION) + if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION + || (EXPR_WFL_QUALIFICATION (qual_wfl) + && TREE_CODE (EXPR_WFL_QUALIFICATION (qual_wfl)) == TREE_LIST)) { qual = EXPR_WFL_QUALIFICATION (qual_wfl); qual_wfl = QUAL_WFL (qual); ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 16:11 ` Tom Tromey @ 2002-04-24 10:14 ` Alexandre Petit-Bianco 2002-04-24 10:30 ` Tom Tromey 0 siblings, 1 reply; 84+ messages in thread From: Alexandre Petit-Bianco @ 2002-04-24 10:14 UTC (permalink / raw) To: tromey; +Cc: Per Bothner, gcc, Java Discuss List Tom Tromey writes: > Yeah, I saw that once I started rebuilding libgcj with it. Try the > appended. We really need Alex to look at this though. From the debug session information that you sent, this is making sense. I'm not seing any regression in all my build tests (3500 files) and I believe it improves the situation with my (old) copy of Freenet. I'll be able to do some real debugging tonight at the earliest. In the meantime, if we're short on time, this should probably go in. Thank you for looking into this, ./A ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-24 10:14 ` Alexandre Petit-Bianco @ 2002-04-24 10:30 ` Tom Tromey 2002-04-24 10:32 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Tom Tromey @ 2002-04-24 10:30 UTC (permalink / raw) To: apbianco; +Cc: Per Bothner, gcc, Java Discuss List, Mark Mitchell >>>>> "Alex" == Alexandre Petit-Bianco <apbianco@cygnus.com> writes: Alex> From the debug session information that you sent, this is making Alex> sense. I'm not seing any regression in all my build tests (3500 Alex> files) and I believe it improves the situation with my (old) Alex> copy of Freenet. Alex> I'll be able to do some real debugging tonight at the Alex> earliest. In the meantime, if we're short on time, this should Alex> probably go in. Thanks. It rebuilt libgcj fine. I'll run the test suite (plus Mauve) shortly. I also plan to rebuild rhug with this patch. Mark, assuming the tests go well, is this ok for the branch? It fixes the last high priority gcj PR. Alex, Tom Index: ChangeLog from Tom Tromey <tromey@redhat.com> For PR java/6425: * parse.y (qualify_ambiguous_name) [case CALL_EXPR]: Always choose EXPR_WFL_QUALIFICATION of qual_wfl. Index: parse.y =================================================================== RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v retrieving revision 1.353.2.17 diff -u -r1.353.2.17 parse.y --- parse.y 15 Apr 2002 09:28:53 -0000 1.353.2.17 +++ parse.y 24 Apr 2002 17:24:30 -0000 @@ -11219,7 +11219,9 @@ { case CALL_EXPR: qual_wfl = TREE_OPERAND (qual_wfl, 0); - if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION) + if (TREE_CODE (qual_wfl) != EXPR_WITH_FILE_LOCATION + || (EXPR_WFL_QUALIFICATION (qual_wfl) + && TREE_CODE (EXPR_WFL_QUALIFICATION (qual_wfl)) == TREE_LIST)) { qual = EXPR_WFL_QUALIFICATION (qual_wfl); qual_wfl = QUAL_WFL (qual); ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-24 10:30 ` Tom Tromey @ 2002-04-24 10:32 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-24 10:32 UTC (permalink / raw) To: tromey, apbianco; +Cc: Per Bothner, gcc, Java Discuss List, Mark Mitchell > Mark, assuming the tests go well, is this ok for the branch? It fixes > the last high priority gcj PR. Yes, thanks! -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 2:12 Mark Mitchell 2002-04-23 3:53 ` Alan Modra 2002-04-23 9:08 ` Per Bothner @ 2002-04-23 13:19 ` Richard Henderson 2002-04-23 13:28 ` Mark Mitchell 2 siblings, 1 reply; 84+ messages in thread From: Richard Henderson @ 2002-04-23 13:19 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote: > There are a handful of open bugs remaining that need fixes. By far and > away the most worrisome are the IRIX regressions in PR 6212 and PR 6304. I've been looking at them off and on for the last week or so, but have made practically no headway. I've been thwarted by the inability to attach a debugger to an N64 binary. (SGI's dbx crashes and GDB complains about incorrect dwarf2, i.e. gdb doesn't understand the random changes SGI made to dwarf2.) I've been considering ripping out all of the MIPS_DEBUGGING_INFO bits in dwarf2out.c and seeing if that would allow progress. :-/ r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 13:19 ` Richard Henderson @ 2002-04-23 13:28 ` Mark Mitchell 2002-04-23 13:35 ` Richard Henderson 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 13:28 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc --On Tuesday, April 23, 2002 12:22:54 PM -0700 Richard Henderson <rth@redhat.com> wrote: > On Tue, Apr 23, 2002 at 02:01:25AM -0700, Mark Mitchell wrote: >> There are a handful of open bugs remaining that need fixes. By far and >> away the most worrisome are the IRIX regressions in PR 6212 and PR 6304. > > I've been looking at them off and on for the last week or so, but have > made practically no headway. I've been thwarted by the inability to > attach a debugger to an N64 binary. Bummer. > I've been considering ripping out all of the MIPS_DEBUGGING_INFO bits > in dwarf2out.c and seeing if that would allow progress. :-/ Or use printf? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 13:28 ` Mark Mitchell @ 2002-04-23 13:35 ` Richard Henderson 2002-04-23 13:50 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Richard Henderson @ 2002-04-23 13:35 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Tue, Apr 23, 2002 at 01:22:18PM -0700, Mark Mitchell wrote: > Or use printf? In all likelyhood, it's a problem restoring registers. In which case, making any function calls at all is a non-starter. r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 13:35 ` Richard Henderson @ 2002-04-23 13:50 ` Mark Mitchell 2002-04-23 13:52 ` Richard Henderson 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 13:50 UTC (permalink / raw) To: Richard Henderson; +Cc: gcc --On Tuesday, April 23, 2002 01:28:40 PM -0700 Richard Henderson <rth@redhat.com> wrote: > On Tue, Apr 23, 2002 at 01:22:18PM -0700, Mark Mitchell wrote: >> Or use printf? > > In all likelyhood, it's a problem restoring registers. In > which case, making any function calls at all is a non-starter. I meant in the unwinder to try to see what it thought it was doing. Are we already hosed at that point? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 13:50 ` Mark Mitchell @ 2002-04-23 13:52 ` Richard Henderson 0 siblings, 0 replies; 84+ messages in thread From: Richard Henderson @ 2002-04-23 13:52 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Tue, Apr 23, 2002 at 01:35:05PM -0700, Mark Mitchell wrote: > I meant in the unwinder to try to see what it thought it was doing. Oh, I see. Yes, one could verify that we did in fact find the frame we intended that way. > Are we already hosed at that point? I doubt it. r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: GCC 3.1 Prerelease @ 2002-04-22 20:00 Billinghurst, David (CRTS) 0 siblings, 0 replies; 84+ messages in thread From: Billinghurst, David (CRTS) @ 2002-04-22 20:00 UTC (permalink / raw) To: Mark Mitchell, gcc I have updated the two irix PRs with test cases and additional information PR6212 - g++ testsuite EH regressions for irix6 -mabi=64 PR6304 - Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease
@ 2002-04-22 4:07 Wolfgang Bangerth
0 siblings, 0 replies; 84+ messages in thread
From: Wolfgang Bangerth @ 2002-04-22 4:07 UTC (permalink / raw)
To: gcc; +Cc: mark
> To that end, I would very much like to see if we can get some more of
> the open bugs fixed before that point. (I know that people are already
> working on some of these at this point.)
>
> Here is a list of the current high-priority bugs order by category.
Maybe it's too late, but maybe not: PR c++/6256 is another one that might
be worth fixing since it can't be worked around and since it is a
regression from 2.95.
Regards
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: bangerth@math.ethz.ch
www: http://www.math.ethz.ch/~bangerth
^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease @ 2002-04-22 0:07 Toon Moene 0 siblings, 0 replies; 84+ messages in thread From: Toon Moene @ 2002-04-22 0:07 UTC (permalink / raw) To: mark; +Cc: gcc Dave wrote: >> 2002-04-21 Mark Mitchell <mark@codesourcery.com> >> >> PR f/6318. > Thanks for spending your precious time to fix this problem. Seconded ! The fix makes clear that this problem was far beyond my capabilities w.r.t. hacking gcc ... Thanks Mark ! -- Toon Moene, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands. Tel. +31302206443, Fax +31302210407, e-mail moene@knmi.nl URL: http://www.knmi.nl/hirlam ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease @ 2002-04-20 20:09 John David Anglin 2002-04-20 21:44 ` Mark Mitchell 2002-04-21 7:06 ` Toon Moene 0 siblings, 2 replies; 84+ messages in thread From: John David Anglin @ 2002-04-20 20:09 UTC (permalink / raw) To: gcc; +Cc: mark These are the PA issues regarding the 3.1 release: Fortran: PR6138: Incorrect access of interger*1 variables on PA. This is a regression from 3.0.x, and it also affects powerpc. In my opinion, it is a verious serious bug affecting many programs and should be fixed before the 3.1 release. The problem is in the front-end, in code that I am not familiar with. C++: g++.jason/synth5.C: this testsuite fail is a regression that occurred about March 15. The errors are: synth5.h:3: storage size of `_ZTI1A' isn't known synth5.h:7: storage size of `_ZTI1B' isn't known At the moment, I don't consider this regression to be a very serious problem. It also affects powerpc. C: This thread <http://gcc.gnu.org/ml/gcc/2002-04/msg00534.html> discusses a problem initially found building bleadperl with hppa64-hp-hpux. While there is a problem with the machine definition, the analysis done so far points to problems in register allocation and optimization as the root causes of the compilation failure. These problems are not in 3.0.x. The register allocation issue seems similar to that discussed in this thread <http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01094.html>. In the PA case, a FP register was selected in a situation where a general register should have been selected. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 20:09 John David Anglin @ 2002-04-20 21:44 ` Mark Mitchell 2002-04-23 12:19 ` John David Anglin 2002-04-21 7:06 ` Toon Moene 1 sibling, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 21:44 UTC (permalink / raw) To: John David Anglin, gcc > C++: > > g++.jason/synth5.C: this testsuite fail is a regression that occurred > about March 15. The errors are: Please file a PR for this issue and send me the PR number. > C: Likewise. It would have been really nice to have known about these issues sooner. Let's all try to use our bug-tracking system. Please mark regressions as high-priority when they are discovered -- or ask a maintainer to do it for you. Also, when these issues get reported on mailing lists, we should try to fix them quickly. For example, if the synth5.C problem was discovered March 15th, and the offending patch identified, and the offending patcher pinged, we'd likely already have a fix. :-) If you can identify a patch that causes a new failure, please hound the contributor until they fix the problem. Don't fear being rude; the person who checked in the patch is responsible for fixing the damage done, or backing out the patch. Thanks to all, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 21:44 ` Mark Mitchell @ 2002-04-23 12:19 ` John David Anglin 0 siblings, 0 replies; 84+ messages in thread From: John David Anglin @ 2002-04-23 12:19 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc, jason > > C++: > > > > g++.jason/synth5.C: this testsuite fail is a regression that occurred > > about March 15. The errors are: > > Please file a PR for this issue and send me the PR number. I have updated PR6395 after confirming this afternoon that the suspected patch 2002-03-15 Jason Merrill <jason@redhat.com> * decl.c (make_rtl_for_nonlocal_decl): Also defer COMDAT variables. is in fact the cause of the regression. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 20:09 John David Anglin 2002-04-20 21:44 ` Mark Mitchell @ 2002-04-21 7:06 ` Toon Moene 2002-04-21 12:57 ` Mark Mitchell 1 sibling, 1 reply; 84+ messages in thread From: Toon Moene @ 2002-04-21 7:06 UTC (permalink / raw) To: John David Anglin; +Cc: gcc, mark John David Anglin wrote: > Fortran: > > PR6138: Incorrect access of interger*1 variables on PA. > > This is a regression from 3.0.x, and it also affects powerpc. In my opinion, > it is a verious serious bug affecting many programs and should be fixed > before the 3.1 release. The problem is in the front-end, in code that > I am not familiar with. This and PR Fortran/6304 are indeed the only Fortran *regressions* I'm aware of. Whether this one affects a lot of people is open to debate: In my experience not many are using the INTEGER*1 extension (mostly because its support in g77 is not complete). I'm not entirely sure it's a bug in the frontend; however, in the four hours I spent on it yesterday I was unable to find a C equivalent for the following, minimal, example of the problem: integer*2 j integer*1 k j = -9 k = j if (k .ne. j) call abort print*,j end [ The `print*,j' line is necessary because it forces gcc to store j on the stack - which leads to the access error. ] The problem is hard to track down - already the .f.00.rtl dump is wrong when optimizing (another hint that it might be a bug in the frontend - however, that means that we have to explain how the frontend can generate different RTL based on optimization flags) ... Affects powerpc and hppa. Hope this helps, -- Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 7:06 ` Toon Moene @ 2002-04-21 12:57 ` Mark Mitchell 2002-04-21 13:50 ` Franz Sirl ` (2 more replies) 0 siblings, 3 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-21 12:57 UTC (permalink / raw) To: Toon Moene, John David Anglin, rth; +Cc: gcc --On Sunday, April 21, 2002 02:46:52 PM +0200 Toon Moene <toon@moene.indiv.nluug.nl> wrote: > John David Anglin wrote: > >> Fortran: >> >> PR6138: Incorrect access of interger*1 variables on PA. > The problem is hard to track down - already the .f.00.rtl dump is wrong > when optimizing (another hint that it might be a bug in the frontend - > however, that means that we have to explain how the frontend can > generate different RTL based on optimization flags) ... > > Affects powerpc and hppa. Often, the change between optimizing and non-optimizing comes up in fixup_var_refs -- and that is the culprit here. (When optimizing, we try to keep things in registers, and only dump them to the stack when necessary.) Before fixup_var_refs, we have: (insn 12 10 14 (set (reg/v:SI 115) (const_int -9 [0xfffffffffffffff7])) -1 (nil) (nil)) (insn 17 15 19 (set (reg/v:SI 116) (sign_extend:SI (subreg:QI (reg/v:SI 115) 3))) -1 (nil) (nil)) Insn 17 is the one that gets screwed up. What happens is that we replace (reg/v:SI 115) with (mem/f:HI (reg/f:SI 111 virtual-stack-vars)) because the original mode of the variable was HImode, not SImode. (We created an SImode register because we thought that would be more efficient.) So, after substitution, we have, in insn 17: (set (reg/v:SI 116) (sign_extend:SI (subreg:QI (mem/f:HI ...) 3))) This is bogus; we no longer want byte 3 of the HI mode mem, we want byte 1 of the HI mode mem. Here's a patch which I think will fix the problem. I'm going to test this on i686-pc-linux-gnu, but I'd appreciate it if a) someone knowledgeable would sanity check the patch, and b) someone would bootstrap/test on a PowerPC or HPPA platform, which we know is susceptible to these issues. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com 2002-04-21 Mark Mitchell <mark@codesourcery.com> PR f/6318. * function.c (fixup_memory_subreg): Add promoted_mode parameter. (walk_fixup_memory_subreg): Likewise. (fixup_var_refs_insn): Adjust accordingly. (fixup_var_refs_1): Likewise. Index: function.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/function.c,v retrieving revision 1.347.2.4 diff -c -p -r1.347.2.4 function.c *** function.c 12 Apr 2002 11:37:42 -0000 1.347.2.4 --- function.c 21 Apr 2002 18:36:43 -0000 *************** static void fixup_var_refs_insn PARAMS ( *** 252,259 **** int, int, rtx)); static void fixup_var_refs_1 PARAMS ((rtx, enum machine_mode, rtx *, rtx, struct fixup_replacement **, rtx)); ! static rtx fixup_memory_subreg PARAMS ((rtx, rtx, int)); ! static rtx walk_fixup_memory_subreg PARAMS ((rtx, rtx, int)); static rtx fixup_stack_1 PARAMS ((rtx, rtx)); static void optimize_bit_field PARAMS ((rtx, rtx, rtx *)); static void instantiate_decls PARAMS ((tree, int)); --- 252,260 ---- int, int, rtx)); static void fixup_var_refs_1 PARAMS ((rtx, enum machine_mode, rtx *, rtx, struct fixup_replacement **, rtx)); ! static rtx fixup_memory_subreg PARAMS ((rtx, rtx, enum machine_mode, int)); ! static rtx walk_fixup_memory_subreg PARAMS ((rtx, rtx, enum machine_mode, ! int)); static rtx fixup_stack_1 PARAMS ((rtx, rtx)); static void optimize_bit_field PARAMS ((rtx, rtx, rtx *)); static void instantiate_decls PARAMS ((tree, int)); *************** fixup_var_refs_insn (insn, var, promoted *** 1868,1874 **** /* OLD might be a (subreg (mem)). */ if (GET_CODE (replacements->old) == SUBREG) replacements->old ! = fixup_memory_subreg (replacements->old, insn, 0); else replacements->old = fixup_stack_1 (replacements->old, insn); --- 1869,1876 ---- /* OLD might be a (subreg (mem)). */ if (GET_CODE (replacements->old) == SUBREG) replacements->old ! = fixup_memory_subreg (replacements->old, insn, ! promoted_mode, 0); else replacements->old = fixup_stack_1 (replacements->old, insn); *************** fixup_var_refs_insn (insn, var, promoted *** 1908,1914 **** { if (GET_CODE (note) != INSN_LIST) XEXP (note, 0) ! = walk_fixup_memory_subreg (XEXP (note, 0), insn, 1); note = XEXP (note, 1); } } --- 1910,1917 ---- { if (GET_CODE (note) != INSN_LIST) XEXP (note, 0) ! = walk_fixup_memory_subreg (XEXP (note, 0), insn, ! promoted_mode, 1); note = XEXP (note, 1); } } *************** fixup_var_refs_1 (var, promoted_mode, lo *** 2079,2085 **** return; } else ! tem = fixup_memory_subreg (tem, insn, 0); } else tem = fixup_stack_1 (tem, insn); --- 2082,2088 ---- return; } else ! tem = fixup_memory_subreg (tem, insn, promoted_mode, 0); } else tem = fixup_stack_1 (tem, insn); *************** fixup_var_refs_1 (var, promoted_mode, lo *** 2194,2200 **** return; } ! replacement->new = *loc = fixup_memory_subreg (x, insn, 0); INSN_CODE (insn) = -1; if (! flag_force_mem && recog_memoized (insn) >= 0) --- 2197,2204 ---- return; } ! replacement->new = *loc = fixup_memory_subreg (x, insn, ! promoted_mode, 0); INSN_CODE (insn) = -1; if (! flag_force_mem && recog_memoized (insn) >= 0) *************** fixup_var_refs_1 (var, promoted_mode, lo *** 2285,2291 **** This was legitimate when the MEM was a REG. */ if (GET_CODE (tem) == SUBREG && SUBREG_REG (tem) == var) ! tem = fixup_memory_subreg (tem, insn, 0); else tem = fixup_stack_1 (tem, insn); --- 2289,2295 ---- This was legitimate when the MEM was a REG. */ if (GET_CODE (tem) == SUBREG && SUBREG_REG (tem) == var) ! tem = fixup_memory_subreg (tem, insn, promoted_mode, 0); else tem = fixup_stack_1 (tem, insn); *************** fixup_var_refs_1 (var, promoted_mode, lo *** 2387,2393 **** SET_SRC (x) = replacement->new; else if (GET_CODE (SET_SRC (x)) == SUBREG) SET_SRC (x) = replacement->new ! = fixup_memory_subreg (SET_SRC (x), insn, 0); else SET_SRC (x) = replacement->new = fixup_stack_1 (SET_SRC (x), insn); --- 2391,2398 ---- SET_SRC (x) = replacement->new; else if (GET_CODE (SET_SRC (x)) == SUBREG) SET_SRC (x) = replacement->new ! = fixup_memory_subreg (SET_SRC (x), insn, promoted_mode, ! 0); else SET_SRC (x) = replacement->new = fixup_stack_1 (SET_SRC (x), insn); *************** fixup_var_refs_1 (var, promoted_mode, lo *** 2440,2446 **** rtx pat, last; if (GET_CODE (SET_DEST (x)) == SUBREG) ! SET_DEST (x) = fixup_memory_subreg (SET_DEST (x), insn, 0); else SET_DEST (x) = fixup_stack_1 (SET_DEST (x), insn); --- 2445,2452 ---- rtx pat, last; if (GET_CODE (SET_DEST (x)) == SUBREG) ! SET_DEST (x) = fixup_memory_subreg (SET_DEST (x), insn, ! promoted_mode, 0); else SET_DEST (x) = fixup_stack_1 (SET_DEST (x), insn); *************** fixup_var_refs_1 (var, promoted_mode, lo *** 2492,2498 **** /* Convert (SUBREG (MEM)) to a MEM in a changed mode. */ if (GET_CODE (fixeddest) == SUBREG) { ! fixeddest = fixup_memory_subreg (fixeddest, insn, 0); promoted_mode = GET_MODE (fixeddest); } else --- 2498,2505 ---- /* Convert (SUBREG (MEM)) to a MEM in a changed mode. */ if (GET_CODE (fixeddest) == SUBREG) { ! fixeddest = fixup_memory_subreg (fixeddest, insn, ! promoted_mode, 0); promoted_mode = GET_MODE (fixeddest); } else *************** fixup_var_refs_1 (var, promoted_mode, lo *** 2531,2554 **** } } \f ! /* Given X, an rtx of the form (SUBREG:m1 (MEM:m2 addr)), ! return an rtx (MEM:m1 newaddr) which is equivalent. ! If any insns must be emitted to compute NEWADDR, put them before INSN. UNCRITICAL nonzero means accept paradoxical subregs. This is used for subregs found inside REG_NOTES. */ static rtx ! fixup_memory_subreg (x, insn, uncritical) rtx x; rtx insn; int uncritical; { ! int offset = SUBREG_BYTE (x); rtx addr = XEXP (SUBREG_REG (x), 0); enum machine_mode mode = GET_MODE (x); rtx result; /* Paradoxical SUBREGs are usually invalid during RTL generation. */ if (GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))) && ! uncritical) --- 2538,2569 ---- } } \f ! /* Previously, X had the form (SUBREG:m1 (REG:PROMOTED_MODE ...)). ! The REG was placed on the stack, so X now has the form (SUBREG:m1 ! (MEM:m2 ...)). ! ! Return an rtx (MEM:m1 newaddr) which is equivalent. If any insns ! must be emitted to compute NEWADDR, put them before INSN. UNCRITICAL nonzero means accept paradoxical subregs. This is used for subregs found inside REG_NOTES. */ static rtx ! fixup_memory_subreg (x, insn, promoted_mode, uncritical) rtx x; rtx insn; + enum machine_mode promoted_mode; int uncritical; { ! int offset; rtx addr = XEXP (SUBREG_REG (x), 0); enum machine_mode mode = GET_MODE (x); rtx result; + offset = (SUBREG_BYTE (x) + - (GET_MODE_SIZE (promoted_mode) + - GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))); + /* Paradoxical SUBREGs are usually invalid during RTL generation. */ if (GET_MODE_SIZE (mode) > GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))) && ! uncritical) *************** fixup_memory_subreg (x, insn, uncritical *** 2571,2584 **** If X itself is a (SUBREG (MEM ...) ...), return the replacement expression. Otherwise return X, with its contents possibly altered. ! If any insns must be emitted to compute NEWADDR, put them before INSN. ! ! UNCRITICAL is as in fixup_memory_subreg. */ static rtx ! walk_fixup_memory_subreg (x, insn, uncritical) rtx x; rtx insn; int uncritical; { enum rtx_code code; --- 2586,2599 ---- If X itself is a (SUBREG (MEM ...) ...), return the replacement expression. Otherwise return X, with its contents possibly altered. ! INSN, PROMOTED_MODE and UNCRITICAL are as for ! fixup_memory_subreg. */ static rtx ! walk_fixup_memory_subreg (x, insn, promoted_mode, uncritical) rtx x; rtx insn; + enum machine_mode promoted_mode; int uncritical; { enum rtx_code code; *************** walk_fixup_memory_subreg (x, insn, uncri *** 2591,2597 **** code = GET_CODE (x); if (code == SUBREG && GET_CODE (SUBREG_REG (x)) == MEM) ! return fixup_memory_subreg (x, insn, uncritical); /* Nothing special about this RTX; fix its operands. */ --- 2606,2612 ---- code = GET_CODE (x); if (code == SUBREG && GET_CODE (SUBREG_REG (x)) == MEM) ! return fixup_memory_subreg (x, insn, promoted_mode, uncritical); /* Nothing special about this RTX; fix its operands. */ *************** walk_fixup_memory_subreg (x, insn, uncri *** 2599,2611 **** for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--) { if (fmt[i] == 'e') ! XEXP (x, i) = walk_fixup_memory_subreg (XEXP (x, i), insn, uncritical); else if (fmt[i] == 'E') { int j; for (j = 0; j < XVECLEN (x, i); j++) XVECEXP (x, i, j) ! = walk_fixup_memory_subreg (XVECEXP (x, i, j), insn, uncritical); } } return x; --- 2614,2628 ---- for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--) { if (fmt[i] == 'e') ! XEXP (x, i) = walk_fixup_memory_subreg (XEXP (x, i), insn, ! promoted_mode, uncritical); else if (fmt[i] == 'E') { int j; for (j = 0; j < XVECLEN (x, i); j++) XVECEXP (x, i, j) ! = walk_fixup_memory_subreg (XVECEXP (x, i, j), insn, ! promoted_mode, uncritical); } } return x; ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 12:57 ` Mark Mitchell @ 2002-04-21 13:50 ` Franz Sirl 2002-04-22 3:20 ` Gerald Pfeifer 2002-04-22 10:50 ` Franz Sirl 2002-04-21 20:54 ` John David Anglin 2002-04-22 0:13 ` Richard Henderson 2 siblings, 2 replies; 84+ messages in thread From: Franz Sirl @ 2002-04-21 13:50 UTC (permalink / raw) To: Mark Mitchell, Toon Moene, John David Anglin, rth; +Cc: gcc On Sunday 21 April 2002 20:44, Mark Mitchell wrote: > b) someone would bootstrap/test on a PowerPC or HPPA platform, which > we know is susceptible to these issues. I can confirm that this patch fixes the testcase on powerpc-linux-gnu, I'll run a full bootstrap tomorrow, as I've currently a -O3 bootstrap running. Overall I'm currently _highly_ satisfied with the status of the branch on powerpc-linux-gnu :-))). Mark, this leaves only one PR I would like to see fixed before the release, namely PR c++/6112 (which hasn't been upgraded to 'high priority', even though it's a regression). This PR may be related to the other PR's on lost 'const' qualifiers in c++. Franz. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 13:50 ` Franz Sirl @ 2002-04-22 3:20 ` Gerald Pfeifer 2002-04-22 10:50 ` Franz Sirl 1 sibling, 0 replies; 84+ messages in thread From: Gerald Pfeifer @ 2002-04-22 3:20 UTC (permalink / raw) To: Franz Sirl Cc: Mark Mitchell, Toon Moene, John David Anglin, Richard Henderson, gcc On Sun, 21 Apr 2002, Franz Sirl wrote: > Mark, this leaves only one PR I would like to see fixed before the release, > namely PR c++/6112 (which hasn't been upgraded to 'high priority', even > though it's a regression). I have upgraded it for you now. (As you have CVS write access, you should have also received GNATS write access with your account, BTW.) Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 13:50 ` Franz Sirl 2002-04-22 3:20 ` Gerald Pfeifer @ 2002-04-22 10:50 ` Franz Sirl 2002-04-22 10:56 ` Mark Mitchell 1 sibling, 1 reply; 84+ messages in thread From: Franz Sirl @ 2002-04-22 10:50 UTC (permalink / raw) To: Mark Mitchell, Toon Moene, John David Anglin, rth; +Cc: gcc On Sunday 21 April 2002 21:58, Franz Sirl wrote: > On Sunday 21 April 2002 20:44, Mark Mitchell wrote: > > b) someone would bootstrap/test on a PowerPC or HPPA platform, which > > we know is susceptible to these issues. > > I can confirm that this patch fixes the testcase on powerpc-linux-gnu, I'll > run a full bootstrap tomorrow, as I've currently a -O3 bootstrap running. Bootstrapped and tested on powerpc-linux-gnu without regressions. Built and checked glibc with it, no problems either. Franz. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-22 10:50 ` Franz Sirl @ 2002-04-22 10:56 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-22 10:56 UTC (permalink / raw) To: Franz Sirl, Toon Moene, John David Anglin, rth; +Cc: gcc --On Monday, April 22, 2002 07:46:53 PM +0200 Franz Sirl <Franz.Sirl-kernel@lauterbach.com> wrote: > On Sunday 21 April 2002 21:58, Franz Sirl wrote: >> On Sunday 21 April 2002 20:44, Mark Mitchell wrote: >> > b) someone would bootstrap/test on a PowerPC or HPPA platform, which >> > we know is susceptible to these issues. >> >> I can confirm that this patch fixes the testcase on powerpc-linux-gnu, >> I'll run a full bootstrap tomorrow, as I've currently a -O3 bootstrap >> running. > > Bootstrapped and tested on powerpc-linux-gnu without regressions. Built > and checked glibc with it, no problems either. Thanks! -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 12:57 ` Mark Mitchell 2002-04-21 13:50 ` Franz Sirl @ 2002-04-21 20:54 ` John David Anglin 2002-04-22 0:13 ` Richard Henderson 2 siblings, 0 replies; 84+ messages in thread From: John David Anglin @ 2002-04-21 20:54 UTC (permalink / raw) To: Mark Mitchell; +Cc: toon, rth, gcc Mark, > 2002-04-21 Mark Mitchell <mark@codesourcery.com> > > PR f/6318. > * function.c (fixup_memory_subreg): Add promoted_mode parameter. > (walk_fixup_memory_subreg): Likewise. > (fixup_var_refs_insn): Adjust accordingly. > (fixup_var_refs_1): Likewise. I have completed a bootstrap and check with the patch on hppa2.0w-hp-hpux11.11. There are no regressions and the fortran problem is fixed. There are now no unexpected failures in the fortran testsuite :-) Thanks for spending your precious time to fix this problem. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 12:57 ` Mark Mitchell 2002-04-21 13:50 ` Franz Sirl 2002-04-21 20:54 ` John David Anglin @ 2002-04-22 0:13 ` Richard Henderson 2002-04-22 7:48 ` Mark Mitchell 2 siblings, 1 reply; 84+ messages in thread From: Richard Henderson @ 2002-04-22 0:13 UTC (permalink / raw) To: Mark Mitchell; +Cc: Toon Moene, John David Anglin, gcc On Sun, Apr 21, 2002 at 11:44:27AM -0700, Mark Mitchell wrote: > + offset = (SUBREG_BYTE (x) > + - (GET_MODE_SIZE (promoted_mode) > + - GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))); Surely this adjustment should be big-endian only. r~ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-22 0:13 ` Richard Henderson @ 2002-04-22 7:48 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-22 7:48 UTC (permalink / raw) To: Richard Henderson; +Cc: Toon Moene, John David Anglin, gcc --On Monday, April 22, 2002 12:07:01 AM -0700 Richard Henderson <rth@redhat.com> wrote: > On Sun, Apr 21, 2002 at 11:44:27AM -0700, Mark Mitchell wrote: >> + offset = (SUBREG_BYTE (x) >> + - (GET_MODE_SIZE (promoted_mode) >> + - GET_MODE_SIZE (GET_MODE (SUBREG_REG (x))))); > > Surely this adjustment should be big-endian only. Indeed. Also, there is this oddity in fixup_var_refs_1: if (GET_CODE (fixeddest) == SUBREG) { fixeddest = fixup_memory_subreg (fixeddest, insn, 0); promoted_mode = GET_MODE (fixeddest); } This makes no sense since promoted_mode is supposed to be the property of the thing being replaced and that's not changing. I fixed that, too; only the new temporary register needs the mode of fixeddest. I'll commit a modified version of the patch that corrects these two issues after one more test cycle on my local box. Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
[parent not found: <FAC87D7C874EAB46A847604DA4FD5A640346FC@crtsmail.corp.riotinto.o rg>]
* RE: GCC 3.1 Prerelease @ 2002-04-20 20:05 ` Billinghurst, David (CRTS) 2002-04-20 20:16 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Billinghurst, David (CRTS) @ 2002-04-20 20:05 UTC (permalink / raw) To: Mark Mitchell, gcc These two irix6.5 PRs are significant regressions PR6212 - g++ testsuite EH regressions for irix6 -mabi=64 PR6304 - Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2 PR6304 was introduced on 2001-12-13 between 00:00 and 13:00 UTC. I should find the exact patch in the next 24 hours, or so. ^ permalink raw reply [flat|nested] 84+ messages in thread
* RE: GCC 3.1 Prerelease 2002-04-20 20:05 ` Billinghurst, David (CRTS) @ 2002-04-20 20:16 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 20:16 UTC (permalink / raw) To: Billinghurst, David (CRTS), gcc --On Sunday, April 21, 2002 12:03:47 PM +1000 "Billinghurst, David (CRTS)" <David.Billinghurst@riotinto.com> wrote: > These two irix6.5 PRs are significant regressions > > PR6212 - g++ testsuite EH regressions for irix6 -mabi=64 Have you gotten Kenner the preprocessed source of the file that changed with his patch? Can you confirm that reverting Kenner's patch still fixes the problem, or is there something else going wrong as well? The expand_eh_return/expand_builtin_eh_return changes could certainly be affecting things. (The change you highlighted in your original posting has already been reverted.) Please update the PR with this additional information and work with Kenner to resolve the problem if it is indeed his patch that is causing it. > PR6304 - Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2 I've upgraded these to high priority. Please add the dsptrf.f source to the bug report for convenience of those trying to fix it. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* GCC 3.1 Prerelease @ 2002-04-20 13:08 Mark Mitchell 2002-04-20 13:51 ` Stan Shebs ` (7 more replies) 0 siblings, 8 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 13:08 UTC (permalink / raw) To: gcc The GCC 3.1 release is starting to take shape. Many people have worked very hard. I will make GCC 3.1 prerelease tarballs on Monday. To that end, I would very much like to see if we can get some more of the open bugs fixed before that point. (I know that people are already working on some of these at this point.) Here is a list of the current high-priority bugs order by category. I suspect that some of these (Java bugs, especially) are not really regressions. If you know about any of these bugs and know that they are not regressions, please let me know. I have deliberately omitted Ada bugs; hopefully they will get fixed, but they will not block the release in any event. Similarly for PR3386 which refers to undocumented target macros. C = PR6300 sparc-sun-solaris2.7 failure in gcc.dg/cpp/charconst.c C++ === PR4979 g++ compile fails with "unable to find register to spill" PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3 Libstdc++ ========= PR5396 ifstream read()'s data multiple times on Solaris PR4150 Catastrophic performance decrease in C++ code Java ==== PR6314 gcj -R options conflicts with gcc PR6066 incorrect error message compiling classpath Bootstrap ========= PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language c++ PR3373 make boostrap fails in libjava if --with-gnu-as is used -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell @ 2002-04-20 13:51 ` Stan Shebs 2002-04-20 14:07 ` Mark Mitchell 2002-04-20 16:10 ` Joel Sherrill 2002-04-20 13:56 ` Joseph S. Myers ` (6 subsequent siblings) 7 siblings, 2 replies; 84+ messages in thread From: Stan Shebs @ 2002-04-20 13:51 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc Mark Mitchell wrote: > > PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language c++ Why is this one critical? The SH isn't even listed as a release criterion, and sh-coff/hms is kind of an archaic config. It might be a fun bit of nostalgia to fix (once upon a time I was one of ver few people who knew how to work an E7000), but there are a hundred more important things to do first. Stan ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:51 ` Stan Shebs @ 2002-04-20 14:07 ` Mark Mitchell 2002-04-20 16:10 ` Joel Sherrill 1 sibling, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 14:07 UTC (permalink / raw) To: Stan Shebs; +Cc: gcc --On Saturday, April 20, 2002 01:50:28 PM -0700 Stan Shebs <shebs@apple.com> wrote: > Mark Mitchell wrote: >> >> PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language >> c++ > > Why is this one critical? The SH isn't even listed as a release > criterion, and sh-coff/hms is kind of an archaic config. It might > be a fun bit of nostalgia to fix (once upon a time I was one of > ver few people who knew how to work an E7000), but there are a > hundred more important things to do first. Me, I just print out what's in GANTS. :-) It does look like this PR was never verified as a regression; is there an SH maintainer who cares to comment? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:51 ` Stan Shebs 2002-04-20 14:07 ` Mark Mitchell @ 2002-04-20 16:10 ` Joel Sherrill 1 sibling, 0 replies; 84+ messages in thread From: Joel Sherrill @ 2002-04-20 16:10 UTC (permalink / raw) To: Stan Shebs; +Cc: Mark Mitchell, gcc Stan Shebs wrote: > > Mark Mitchell wrote: > > > > PR4165 gcc 3.0.1 fails to build on linux for sh-coff,sh-hms for language c++ > > Why is this one critical? The SH isn't even listed as a release > criterion, and sh-coff/hms is kind of an archaic config. It might > be a fun bit of nostalgia to fix (once upon a time I was one of > ver few people who knew how to work an E7000), but there are a > hundred more important things to do first. Besides the targets sh-coff and sh-elf appear to be a bit healthier than this PR indicates. A long way from perfect as these test runs I made reflect: sh-elf results for 3.1 on 4/18 http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00723.html sh-coff results for 3.1 on 4/18 http://gcc.gnu.org/ml/gcc-testresults/2002-04/msg00716.html > Stan -- Joel Sherrill, Ph.D. Director of Research & Development joel@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell 2002-04-20 13:51 ` Stan Shebs @ 2002-04-20 13:56 ` Joseph S. Myers 2002-04-20 13:59 ` Mark Mitchell 2002-04-20 14:36 ` Jakub Jelinek ` (5 subsequent siblings) 7 siblings, 1 reply; 84+ messages in thread From: Joseph S. Myers @ 2002-04-20 13:56 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Sat, 20 Apr 2002, Mark Mitchell wrote: > The GCC 3.1 release is starting to take shape. Many people have worked > very hard. > > I will make GCC 3.1 prerelease tarballs on Monday. I think the mainline gcc_release script should be merged to the branch. Relevant fixes: the mainline script properly generates .bz2 diffs and generates diffs for Ada. (However, the mainline script has a stray reference to Chill that should go away.) gcc.pot (mainline and branch) should be regenerated before the prerelease, and the prerelease tarball submitted to the translation project. This will save translators from translating Chill messages, if they haven't already translated them. -- Joseph S. Myers jsm28@cam.ac.uk ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:56 ` Joseph S. Myers @ 2002-04-20 13:59 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 13:59 UTC (permalink / raw) To: Joseph S. Myers; +Cc: gcc > Relevant fixes: the mainline script properly generates .bz2 diffs and > generates diffs for Ada. (However, the mainline script has a stray > reference to Chill that should go away.) I'll do this. > gcc.pot (mainline and branch) should be regenerated before the prerelease, > and the prerelease tarball submitted to the translation project. This > will save translators from translating Chill messages, if they haven't > already translated them. I don't do internationalization. I'm not really sure it's helpful to give them the prerelease tarball; we'll soon have a release tarball to send. In any case, if someone wants to do this, by all means feel free. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell 2002-04-20 13:51 ` Stan Shebs 2002-04-20 13:56 ` Joseph S. Myers @ 2002-04-20 14:36 ` Jakub Jelinek 2002-04-20 17:17 ` Mark Mitchell 2002-04-20 16:35 ` Tom Tromey ` (4 subsequent siblings) 7 siblings, 1 reply; 84+ messages in thread From: Jakub Jelinek @ 2002-04-20 14:36 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Sat, Apr 20, 2002 at 12:46:06PM -0700, Mark Mitchell wrote: > PR6300 sparc-sun-solaris2.7 failure in gcc.dg/cpp/charconst.c Doesn't look serious enough to be a blocker. There are lots of far more serious bugs in GNATS IMHO. This one is about wchar_t x = L'Very long'; generating two warnings instead of one... I'd say a blocker on SPARC shall be instead inoperability between compiler defaulting to 64-bit and compiler defaulting to 32-bit (the libgcc_s naming problem). Jakub ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 14:36 ` Jakub Jelinek @ 2002-04-20 17:17 ` Mark Mitchell 2002-04-23 9:49 ` Jakub Jelinek 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 17:17 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc > I'd say a blocker on SPARC shall be instead inoperability between > compiler defaulting to 64-bit and compiler defaulting to 32-bit > (the libgcc_s naming problem). Submit a PR explaining the problem and send me a pointer to the PR. My brain is not clever enough to remember everything, sadly. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 17:17 ` Mark Mitchell @ 2002-04-23 9:49 ` Jakub Jelinek 2002-04-24 10:07 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Jakub Jelinek @ 2002-04-23 9:49 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Sat, Apr 20, 2002 at 05:13:26PM -0700, Mark Mitchell wrote: > > I'd say a blocker on SPARC shall be instead inoperability between > > compiler defaulting to 64-bit and compiler defaulting to 32-bit > > (the libgcc_s naming problem). > > Submit a PR explaining the problem and send me a pointer to the PR. target/6429 Though I'm afraid I won't have time for it until Thursday afternoon. Should I mark it high priority? Jakub ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 9:49 ` Jakub Jelinek @ 2002-04-24 10:07 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-24 10:07 UTC (permalink / raw) To: Jakub Jelinek; +Cc: gcc --On Tuesday, April 23, 2002 12:44:28 PM -0400 Jakub Jelinek <jakub@redhat.com> wrote: > On Sat, Apr 20, 2002 at 05:13:26PM -0700, Mark Mitchell wrote: >> > I'd say a blocker on SPARC shall be instead inoperability between >> > compiler defaulting to 64-bit and compiler defaulting to 32-bit >> > (the libgcc_s naming problem). >> >> Submit a PR explaining the problem and send me a pointer to the PR. > > target/6429 > Though I'm afraid I won't have time for it until Thursday afternoon. > Should I mark it high priority? If it's a regression, yes. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell ` (2 preceding siblings ...) 2002-04-20 14:36 ` Jakub Jelinek @ 2002-04-20 16:35 ` Tom Tromey 2002-04-20 17:28 ` Mark Mitchell 2002-04-20 19:04 ` David S. Miller ` (3 subsequent siblings) 7 siblings, 1 reply; 84+ messages in thread From: Tom Tromey @ 2002-04-20 16:35 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc >>>>> "Mark" == Mark Mitchell <mark@codesourcery.com> writes: Mark> Here is a list of the current high-priority bugs order by Mark> category. I suspect that some of these (Java bugs, especially) Mark> are not really regressions. Mark> PR6314 gcj -R options conflicts with gcc I'm working on a patch. This isn't a regression per se but letting this go out unfixed would be irresponsible. Mark> PR6066 incorrect error message compiling classpath This is a regression, sort of. We used to be able to compile Classpath. Now Classpath has changed (but is still valid code) and we can't compile it. It is a regression in the utility of gcj. Tom ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 16:35 ` Tom Tromey @ 2002-04-20 17:28 ` Mark Mitchell 0 siblings, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 17:28 UTC (permalink / raw) To: tromey; +Cc: gcc > Mark> PR6066 incorrect error message compiling classpath > > This is a regression, sort of. We used to be able to compile > Classpath. Now Classpath has changed (but is still valid code) and we > can't compile it. It is a regression in the utility of gcj. Is a fix in progress? Thanks, -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell ` (3 preceding siblings ...) 2002-04-20 16:35 ` Tom Tromey @ 2002-04-20 19:04 ` David S. Miller 2002-04-20 20:08 ` Mark Mitchell 2002-04-20 22:09 ` Alan Modra ` (2 subsequent siblings) 7 siblings, 1 reply; 84+ messages in thread From: David S. Miller @ 2002-04-20 19:04 UTC (permalink / raw) To: mark; +Cc: gcc From: Mark Mitchell <mark@codesourcery.com> Date: Sat, 20 Apr 2002 12:46:06 -0700 Java ==== PR6314 gcj -R options conflicts with gcc Tom Tromey did the fix, but it needs a Java person to approve it. See the thread starting at: http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01167.html ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 19:04 ` David S. Miller @ 2002-04-20 20:08 ` Mark Mitchell 2002-04-20 20:13 ` David S. Miller 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 20:08 UTC (permalink / raw) To: David S. Miller; +Cc: gcc, tromey > Tom Tromey did the fix, but it needs a Java person to approve it. > See the thread starting at: > > http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01167.html Thanks. You underestimate your own power; you have global write privileges so you may approve the patch. :-) I've reviewed it, too, and it looks OK to me. Tom, please check this in and close the PR. Thanks! -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 20:08 ` Mark Mitchell @ 2002-04-20 20:13 ` David S. Miller 2002-04-20 20:18 ` Per Bothner 2002-04-20 20:45 ` Mark Mitchell 0 siblings, 2 replies; 84+ messages in thread From: David S. Miller @ 2002-04-20 20:13 UTC (permalink / raw) To: mark; +Cc: gcc, tromey From: Mark Mitchell <mark@codesourcery.com> Date: Sat, 20 Apr 2002 20:02:51 -0700 You underestimate your own power; you have global write privileges so you may approve the patch. :-) I've reviewed it, too, and it looks OK to me. Tom, please check this in and close the PR. I wanted to give Java maintainers an opportunity to say "Don't use -P because..." I do this out of courtesy to the Java people, not because I don't know what my global write privileges afford me. Indeed, it is a privilege not a right, and being conscientious is a part of retaining that privilege. ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 20:13 ` David S. Miller @ 2002-04-20 20:18 ` Per Bothner 2002-04-21 11:27 ` Tom Tromey 2002-04-20 20:45 ` Mark Mitchell 1 sibling, 1 reply; 84+ messages in thread From: Per Bothner @ 2002-04-20 20:18 UTC (permalink / raw) To: David S. Miller; +Cc: mark, gcc, tromey David S. Miller wrote: > I wanted to give Java maintainers an opportunity to > say "Don't use -P because..." And at least two of us have said we'd rather use a lang format like --resources. -- --Per Bothner per@bothner.com http://www.bothner.com/per/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 20:18 ` Per Bothner @ 2002-04-21 11:27 ` Tom Tromey 0 siblings, 0 replies; 84+ messages in thread From: Tom Tromey @ 2002-04-21 11:27 UTC (permalink / raw) To: Per Bothner; +Cc: David S. Miller, mark, gcc, Bryce McKinlay >>>>> "Per" == Per Bothner <per@bothner.com> writes: >> I wanted to give Java maintainers an opportunity to >> say "Don't use -P because..." Per> And at least two of us have said we'd rather use a Per> lang format like --resources. I'm rewriting it to use `--resource'. I prefer singular over plural, but perhaps --resource-name is even more appropriate since it is more accurate. I'll submit it soon, but probably not today. I thought Mark was asking about the Classpath bug though. This bug has probably been resolved in a different way, at least if a small patch gets approved. There's a recent post from Mark Wielaard on the issue on the java list. Tom ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 20:13 ` David S. Miller 2002-04-20 20:18 ` Per Bothner @ 2002-04-20 20:45 ` Mark Mitchell 1 sibling, 0 replies; 84+ messages in thread From: Mark Mitchell @ 2002-04-20 20:45 UTC (permalink / raw) To: David S. Miller; +Cc: gcc, tromey > I do this out of courtesy to the Java people, not because > I don't know what my global write privileges afford me. :-) > Indeed, it is a privilege not a right, and being conscientious > is a part of retaining that privilege. Certainly true; you perhaps interpreted my comment too seriously. We certainly do not want to stomp over one-another's areas of expertise. It's fine to wait for Per/Alexandre to approve the patch On the other hand, Tom is an experienced contributor both for Java and in general; if there's something risky about -P, I'm confident he'd have noticed it and/or warner about it, and I'm confident that we can easily change -P to something else, so it's not like it's very risky to have the patch in the tree. Tom, use your best judgement. It's OK to check it in. If you don't want to, that's OK too. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell ` (4 preceding siblings ...) 2002-04-20 19:04 ` David S. Miller @ 2002-04-20 22:09 ` Alan Modra 2002-04-21 3:47 ` Gerald Pfeifer 2002-04-21 8:16 ` Andreas Schwab 7 siblings, 0 replies; 84+ messages in thread From: Alan Modra @ 2002-04-20 22:09 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc c/6343 causes glibc build failures on powerpc64-linux, and probably other targets. Franz Sirl provided a patch in http://gcc.gnu.org/ml/gcc-patches/2002-04/msg01026.html, which with the obvious extension to cp/decl.c seems to be the right thing. c/6344 miscompiles the linux kernel on powerpc64-linux. I suspect this one is a generic bug too. I tried to fix it but quickly became lost. -- Alan Modra IBM OzLabs - Linux Technology Centre ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell ` (5 preceding siblings ...) 2002-04-20 22:09 ` Alan Modra @ 2002-04-21 3:47 ` Gerald Pfeifer 2002-04-23 8:24 ` Gerald Pfeifer 2002-04-21 8:16 ` Andreas Schwab 7 siblings, 1 reply; 84+ messages in thread From: Gerald Pfeifer @ 2002-04-21 3:47 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Sat, 20 Apr 2002, Mark Mitchell wrote: > PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3 This is a report of mine. I believe it can be (more or less) closed, but will do a careful investigation tomorrow and possible Tuesday and provide an analysis then. Gerald ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-21 3:47 ` Gerald Pfeifer @ 2002-04-23 8:24 ` Gerald Pfeifer 2002-04-23 9:13 ` Mark Mitchell 0 siblings, 1 reply; 84+ messages in thread From: Gerald Pfeifer @ 2002-04-23 8:24 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc On Sun, 21 Apr 2002, Gerald Pfeifer wrote: >> PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3 > This is a report of mine. I believe it can be (more or less) closed, but > will do a careful investigation tomorrow and possible Tuesday and provide > an analysis then. As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3, the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800 and 1200, respectively, and the 3.2-branch as of yesterday. ANALYSIS: The situation isn't as bad as it used to be, but still release critical. Compiling the file attached to PR 3083/C++ takes 62.4s with the 3.1-branch versus 46.9s with GCC 3.0.3 (on a PIII/1000). Considering not only PR 3083/C++, but the situation in general, it seems that for template/STL-heavy code with deeply nested structures, GCC 2.95 still is the compiler of choice, especially in terms of code quality. GCC 3.1 seems to generate equivalent code to GCC 3.0.3 but is measurably slower. Current mainline produces slightly better code than 3.0.3 and 3.1 at the expense of even longer build times, but still does not reach GCC 2.95 on average. (Note that the first test above was performed using the same preprocessed file, while the other tests were performed compiling from source, which means that GCC 2.95 gets the benefit of a much lighter libstdc++.) DIAGNOSIS: Especially considering the runs where I increased -finline-limit, I strongly suspect our inliner is still quite bad. DETAILED DATA: The first table shows the time needed to build DLV (http://www.dbai.tuwien.ac.at/proj/dlv/), a C++ application that makes heavy use of STL and has deeply nested template structures, on an Athlon/1200. It also shows the size of the resulting static binary. The second table shows DLV running selected benchmarks that exercise different modules of the system (which is basically equivalent to evaluating GCC code generation on completely separate applications). | 2.95.3| 3.0 | 3.0.3 | 3.1 |...-800|..-1200| 3.2 | --------------------+-------+-------+-------+-------+-------+-------+-------+ Build time 4:01 23:54 3:58 4:38 6:37 16:50 5:15 Binary size 4430752 6295044 3948444 3996096 4177344 4597888 4003276 | 2.95.3| 3.0 | 3.0.3 | 3.1 |...-800|..-1200| 3.2 | --------------------+-------+-------+-------+-------+-------+-------+-------+ STRATCOMP1-ALL| 3.57 | 79.39 | 71.41 | 96.33 | 85.40 | 82.83 | 92.01 | STRATCOMP-770.2-Q| 0.73 | 0.93 | 0.90 | 0.95 | 0.98 | 0.87 | 0.93 | 2QBF1| 19.08 | 27.66 | 22.96 | 22.25 | 19.90 | 18.46 | 20.97 | PRIMEIMPL2| 10.74 | 16.39 | 12.92 | 12.90 | 11.74 | 10.29 | 12.35 | ANCESTOR| 8.88 | 9.23 | 9.63 | 9.55 | 10.52 | 9.15 | 9.46 | 3COL-SIMPLEX1| 6.30 | 6.75 | 7.20 | 7.15 | 7.29 | 6.75 | 7.26 | 3COL-LADDER1| 36.24 | 49.20 | 44.47 | 42.35 | 39.27 | 35.79 | 40.99 | 3COL-N-LADDER1| 19.81 | 23.25 | 21.27 | 22.60 | 21.11 | 19.99 | 21.32 | 3COL-RANDOM1| 10.69 | 15.38 | 12.72 | 12.22 | 11.69 | 10.61 | 11.55 | HP-RANDOM1| 13.16 | 13.85 | 14.55 | 14.79 | 14.39 | 14.08 | 14.43 | HAMCYCLE-FREE| 1.18 | 1.42 | 1.71 | 1.70 | 1.58 | 1.54 | 1.59 | DECOMP2| 21.91 | 26.36 | 24.24 | 24.08 | 24.15 | 22.48 | 24.38 | BW-P4-Esra-a| 91.71 |102.26 | 97.70 | 99.30 | 95.60 | 92.25 | 96.51 | BW-P5-nopush| 6.96 | 7.89 | 7.42 | 7.44 | 7.26 | 7.01 | 7.24 | BW-P5-pushbin| 6.20 | 6.99 | 6.52 | 6.48 | 6.30 | 6.04 | 6.31 | BW-P5-nopushbin| 1.94 | 2.23 | 2.10 | 2.07 | 2.05 | 1.94 | 2.04 | 3SAT-1| 32.92 | 47.37 | 37.65 | 38.45 | 35.10 | 30.96 | 36.81 | 3SAT-1-CONSTRAINT| 17.46 | 27.28 | 21.97 | 20.62 | 18.95 | 17.06 | 19.26 | HANOI-Towers| 4.73 | 5.36 | 5.03 | 4.96 | 5.09 | 4.81 | 5.05 | RAMSEY| 8.00 | 9.55 | 9.08 | 8.68 | 8.95 | 8.00 | 8.66 | CRISTAL| 11.07 | 12.54 | 13.15 | 13.35 | 13.47 | 12.65 | 13.28 | HANOI-K| 33.41 | 46.27 | 38.33 | 38.66 | 34.79 | 32.50 | 36.76 | 21-QUEENS| 9.66 | 13.73 | 10.92 | 10.41 | 9.95 | 9.07 | 9.23 | MSTDir[V=13,A=40]| 25.71 | 24.85 | 24.46 | 21.09 | 19.52 | 19.31 | 20.47 | MSTDir[V=15,A=40]| 25.81 | 24.88 | 24.47 | 21.15 | 19.61 | 19.39 | 20.52 | MSTUndir[V=13,A=40]| 12.86 | 12.86 | 12.82 | 11.45 | 10.53 | 10.40 | 11.04 | MSTUndir[V=15,A=40]|214.87 |210.69 |210.63 |188.57 |172.70 |171.26 |182.65 | TIMETABLING| 9.63 | 10.58 | 10.74 | 10.62 | 11.78 | 9.98 | 10.80 | --------------------+-------+-------+-------+-------+-------+-------+-------+ (The STRATCOMP1-ALL regression is probably due to third-party code -- a SAT solver -- experiencing alignment issues due to dirty programming.) ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 8:24 ` Gerald Pfeifer @ 2002-04-23 9:13 ` Mark Mitchell 2002-04-23 9:36 ` Joe Buck 0 siblings, 1 reply; 84+ messages in thread From: Mark Mitchell @ 2002-04-23 9:13 UTC (permalink / raw) To: Gerald Pfeifer; +Cc: gcc --On Tuesday, April 23, 2002 05:22:54 PM +0200 Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote: > On Sun, 21 Apr 2002, Gerald Pfeifer wrote: >>> PR3083 C++ frontend consumes inacceptable amounts of CPU with -O3 >> This is a report of mine. I believe it can be (more or less) closed, but >> will do a careful investigation tomorrow and possible Tuesday and provide >> an analysis then. > > As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3, > the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800 > and 1200, respectively, and the 3.2-branch as of yesterday. Thanks very much for doing this. The good news is that your code compiles and runs. I don't think we're in a position to do much at this point. The numbers look only slightly different from GCC 3.0.x. There are even some improvements assuming that smaller numbers in your benchmark table imply better results. I agree that we should investigate these issues, but I don't think we should hold up the release to try to work on them. Do you agree or disagree? -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 9:13 ` Mark Mitchell @ 2002-04-23 9:36 ` Joe Buck 2002-04-23 14:21 ` Gerald Pfeifer 0 siblings, 1 reply; 84+ messages in thread From: Joe Buck @ 2002-04-23 9:36 UTC (permalink / raw) To: Mark Mitchell; +Cc: Gerald Pfeifer, gcc Gerald writes: > > As promised, I performed tests comparing GCC 2.95.3, GCC 3.0, GCC 3.0.3, > > the 3.1-branch as of yesterday, the 3.1-branch with -finline-limit=800 > > and 1200, respectively, and the 3.2-branch as of yesterday. > > Thanks very much for doing this. > > The good news is that your code compiles and runs. > > I don't think we're in a position to do much at this point. The numbers > look only slightly different from GCC 3.0.x. There are even some > improvements assuming that smaller numbers in your benchmark table > imply better results. It's still a performance regression from 2.95.x, but as you say it looks like a wash with respect to 3.0.4. I have other test cases where 3.1 does about as well as 2.95.x. Only in very C-like code do we really see improvements in 3.1. > I agree that we should investigate these issues, but I don't think we > should hold up the release to try to work on them. Any fixes will probably need architectural changes that will need extensive testing, so it really isn't feasible. If we're going to do something, I think that we should consider insisting on performance improvements in 3.2, otherwise we do mandatory schedule slips for as long as it takes. There's no point in continuing down the track we're on: releases that take longer and longer to compile code that is no better. (but then didn't we say something like that about 3.1? Sigh) I think Gerald's right: the problem seems to be that the new inliner sucks for some reason. 3.1 does have many bug fixes and C on x86 is faster, so I think it's releasable (modulo the last few high-priority bugs). ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-23 9:36 ` Joe Buck @ 2002-04-23 14:21 ` Gerald Pfeifer 0 siblings, 0 replies; 84+ messages in thread From: Gerald Pfeifer @ 2002-04-23 14:21 UTC (permalink / raw) To: gcc; +Cc: Mark Mitchell, Joe Buck On Tue, 23 Apr 2002, Mark Mitchell wrote: > I don't think we're in a position to do much at this point. The numbers > look only slightly different from GCC 3.0.x. What most worries me is the following part of my report: | Compiling the file attached to PR 3083/C++ takes 62.4s with the 3.1-branch | versus 46.9s with GCC 3.0.3 (on a PIII/1000). This is a slowdown by one third or 33% from 3.0.3 to the 3.1-branch! > I agree that we should investigate these issues, but I don't think we > should hold up the release to try to work on them. It's a bit frustrating that the high priority PR with this testcase is now over 10 months old, but I agree we shouldn't hold up the release just because of this issue. It would be nice, though, if someone could have a look to see whether there's some easy fish to be caught there. On Tue, 23 Apr 2002, Joe Buck wrote: > Any fixes will probably need architectural changes that will need > extensive testing, so it really isn't feasible. Well, perhaps some of the improvements are not too intrusive and could be backported in time for 3.1.1 after a period of testing on mainline? > If we're going to do something, I think that we should consider > insisting on performance improvements in 3.2, otherwise we do mandatory > schedule slips for as long as it takes. There's no point in continuing > down the track we're on: releases that take longer and longer to compile > code that is no better. Agreed! (Though ideally the problem will be attacked much sooner, that is, before 3.2 branches.) > I think Gerald's right: [...] It's kind of relieving to see that I'm not the only experiencing this kind of problem; sometimes I've been wondering whether I was doing something stupid... Gerald -- Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/ ^ permalink raw reply [flat|nested] 84+ messages in thread
* Re: GCC 3.1 Prerelease 2002-04-20 13:08 Mark Mitchell ` (6 preceding siblings ...) 2002-04-21 3:47 ` Gerald Pfeifer @ 2002-04-21 8:16 ` Andreas Schwab 7 siblings, 0 replies; 84+ messages in thread From: Andreas Schwab @ 2002-04-21 8:16 UTC (permalink / raw) To: Mark Mitchell; +Cc: gcc I have upgraded PR6331 to high priority, it's a regression against 3.0. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de SuSE GmbH, Deutschherrnstr. 15-19, D-90429 Nürnberg Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 84+ messages in thread
end of thread, other threads:[~2002-04-24 23:44 UTC | newest] Thread overview: 84+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <Pine.LNX.4.30.0204210235010.13395-100000@snake.iap.physik.tu-da rmstadt.de> 2002-04-20 17:16 ` GCC 3.1 Prerelease Peter Schmid 2002-04-20 17:57 ` Mark Mitchell 2002-04-21 14:16 ` Richard Henderson 2002-04-21 16:54 ` Mark Mitchell 2002-04-23 5:46 ` Jason Merrill 2002-04-23 9:12 ` Mark Mitchell 2002-04-23 14:56 Tom Tromey -- strict thread matches above, loose matches on Subject: below -- 2002-04-23 13:38 GCC 3.1 prerelease Mark Mitchell 2002-04-23 18:37 ` Kurt Wall 2002-04-23 19:23 ` Phil Edwards 2002-04-24 9:49 ` Mark Mitchell 2002-04-24 11:03 ` Joseph S. Myers 2002-04-24 19:03 ` Kurt Wall 2002-04-23 10:46 GCC 3.1 Prerelease Paolo Carlini 2002-04-23 2:12 Mark Mitchell 2002-04-23 3:53 ` Alan Modra 2002-04-23 4:13 ` Franz Sirl 2002-04-23 4:32 ` Alan Modra 2002-04-23 10:40 ` Franz Sirl 2002-04-23 11:42 ` Richard Henderson 2002-04-23 15:08 ` Franz Sirl 2002-04-23 15:10 ` Richard Henderson 2002-04-24 10:56 ` Jason Merrill 2002-04-24 12:04 ` Franz Sirl 2002-04-24 13:03 ` Richard Henderson 2002-04-24 13:14 ` Jason Merrill 2002-04-23 12:22 ` Jason Merrill 2002-04-23 9:08 ` Per Bothner 2002-04-23 9:30 ` Mark Mitchell 2002-04-23 10:12 ` Per Bothner 2002-04-23 13:25 ` Mark Mitchell 2002-04-23 14:52 ` Tom Tromey 2002-04-23 15:02 ` Per Bothner 2002-04-23 16:11 ` Tom Tromey 2002-04-24 10:14 ` Alexandre Petit-Bianco 2002-04-24 10:30 ` Tom Tromey 2002-04-24 10:32 ` Mark Mitchell 2002-04-23 13:19 ` Richard Henderson 2002-04-23 13:28 ` Mark Mitchell 2002-04-23 13:35 ` Richard Henderson 2002-04-23 13:50 ` Mark Mitchell 2002-04-23 13:52 ` Richard Henderson 2002-04-22 20:00 Billinghurst, David (CRTS) 2002-04-22 4:07 Wolfgang Bangerth 2002-04-22 0:07 Toon Moene 2002-04-20 20:09 John David Anglin 2002-04-20 21:44 ` Mark Mitchell 2002-04-23 12:19 ` John David Anglin 2002-04-21 7:06 ` Toon Moene 2002-04-21 12:57 ` Mark Mitchell 2002-04-21 13:50 ` Franz Sirl 2002-04-22 3:20 ` Gerald Pfeifer 2002-04-22 10:50 ` Franz Sirl 2002-04-22 10:56 ` Mark Mitchell 2002-04-21 20:54 ` John David Anglin 2002-04-22 0:13 ` Richard Henderson 2002-04-22 7:48 ` Mark Mitchell [not found] <FAC87D7C874EAB46A847604DA4FD5A640346FC@crtsmail.corp.riotinto.o rg> 2002-04-20 20:05 ` Billinghurst, David (CRTS) 2002-04-20 20:16 ` Mark Mitchell 2002-04-20 13:08 Mark Mitchell 2002-04-20 13:51 ` Stan Shebs 2002-04-20 14:07 ` Mark Mitchell 2002-04-20 16:10 ` Joel Sherrill 2002-04-20 13:56 ` Joseph S. Myers 2002-04-20 13:59 ` Mark Mitchell 2002-04-20 14:36 ` Jakub Jelinek 2002-04-20 17:17 ` Mark Mitchell 2002-04-23 9:49 ` Jakub Jelinek 2002-04-24 10:07 ` Mark Mitchell 2002-04-20 16:35 ` Tom Tromey 2002-04-20 17:28 ` Mark Mitchell 2002-04-20 19:04 ` David S. Miller 2002-04-20 20:08 ` Mark Mitchell 2002-04-20 20:13 ` David S. Miller 2002-04-20 20:18 ` Per Bothner 2002-04-21 11:27 ` Tom Tromey 2002-04-20 20:45 ` Mark Mitchell 2002-04-20 22:09 ` Alan Modra 2002-04-21 3:47 ` Gerald Pfeifer 2002-04-23 8:24 ` Gerald Pfeifer 2002-04-23 9:13 ` Mark Mitchell 2002-04-23 9:36 ` Joe Buck 2002-04-23 14:21 ` Gerald Pfeifer 2002-04-21 8:16 ` Andreas Schwab
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).