Is the gcc-3_3-branch creation still on target?

Is the gcc-3_3-branch creation still on target?

[David O'Brien]

Are things still on schedule to branch mainline, creating the
gcc-3_3-branch, on 15-Oct-2002?

FreeBSD 5.0 will use some form of GCC 3.3 snapshot.  I know this isn't
desired by the GCC Steering Committee to have another "gcc 2.96", but
FreeBSD has little choice.  It ICE's on many popular packages, X11 as
just one example.  It has serious optimization bugs for modern x86
processors, for which the PR's aren't getting fixed.  It has regressions
from 2.95 that aren't getting fixed.  All in all, GCC 3.2 is poo.  There
needs to be a balance between adding new features, re-abstracting the
code, etc; and basic usability.  So far the 3.x series has leaned too far
to the former.  GCC 3.1.1 was the most stable of any of the 3.x
compilers, but it has a broken C++ ABI and is EOL'ed by the GCC
developers, which makes it a poor choice to base an OS on.

-- 
-- David  (obrien@FreeBSD.org)

Re: Is the gcc-3_3-branch creation still on target?

[H. J. Lu]

On Fri, Oct 04, 2002 at 08:09:15AM -0700, David O'Brien wrote:
> Are things still on schedule to branch mainline, creating the
> gcc-3_3-branch, on 15-Oct-2002?
> 
> FreeBSD 5.0 will use some form of GCC 3.3 snapshot.  I know this isn't
> desired by the GCC Steering Committee to have another "gcc 2.96", but
> FreeBSD has little choice.  It ICE's on many popular packages, X11 as
> just one example.  It has serious optimization bugs for modern x86
> processors, for which the PR's aren't getting fixed.  It has regressions
> from 2.95 that aren't getting fixed.  All in all, GCC 3.2 is poo.  There
> needs to be a balance between adding new features, re-abstracting the
> code, etc; and basic usability.  So far the 3.x series has leaned too far
> to the former.  GCC 3.1.1 was the most stable of any of the 3.x
> compilers, but it has a broken C++ ABI and is EOL'ed by the GCC
> developers, which makes it a poor choice to base an OS on.
> 

I am not saying 3.2.1 is great. I am still using gcc 2.96. I am just
curious. Isn't the only difference between 3.1 and 3.2 is the C++ ABI
change? How come 3.1.1 is more stable than 3.2.1?

BTW, I applaud FreeBSD's decision to use gcc 3.x in FreeBSD 5.0. That
is what is needed to make gcc 3.x as great as it can be. Without RedHat
8.0 and FreeBSD 5.0 which try to use gcc 3.x to compile everything,
many very bad bugs won't be discovered in time.

FWIW, RedHat has a bunch of patches for their gcc 3.2 in RedHat 8.0. I
guess they make a difference.


H.J.

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 08:23:11AM -0700, H. J. Lu wrote:
> I am just curious. Isn't the only difference between 3.1 and 3.2 is the
> C++ ABI change? How come 3.1.1 is more stable than 3.2.1?

3.2[.0] was supose to have just the C++ ABI change (as shown in
gcc/cp/ChangeLog), but it had a bit more in the base compiler.  Since
3.2[.0]'s release, a lot of changes have gone into gcc-3_2-branch.  Some
things that did not compile with 3.2.1, now compile due to fixes in the
gcc-3_2-branch.  But now other things that did compile cause ICE's.  It
has been a never ending chase since 2.95.3 to find a truly usable GCC.

cvs diff -u0 -r gcc_3_2_release -r gcc-3_2-branch, gcc/ChangeLog 508
lines of diff, and cp/ChangeLog has 63 lines of diff.  Bugs have been
added since 3.2.0.  FreeBSD is using a GCC 3.2.1 20020916 snapshot, and
it isn't anywhere near the quality what would have been 3.1.3 should be.


Index: ChangeLog
===================================================================
RCS file: /cvs/gcc/egcs/gcc/ChangeLog,v
retrieving revision 1.13152.2.657
retrieving revision 1.13152.2.657.2.12
diff -u -r1.13152.2.657 -r1.13152.2.657.2.12
--- ChangeLog	25 Jul 2002 23:34:59 -0000	1.13152.2.657
+++ ChangeLog	14 Aug 2002 08:59:50 -0000	1.13152.2.657.2.12
@@ -1,3 +1,96 @@
+2002-08-14  Release Manager
+
+	* GCC 3.2 Released.
+
+2002-08-08  Jakub Jelinek  <jakub@redhat.com>
+
+	* config/rs6000/rs6000.h, config/rs6000/aix.h,
+	config/rs6000/darwin.h, config/rs6000/linux64.h: Revert last
+	two patches.
+	* config/rs6000/sysv4.h: Likewise, remove #undef ADJUST_FIELD_ALIGN.
+
+2002-08-08  Jakub Jelinek  <jakub@redhat.com>
+
+	* config/rs6000/rs6000-protos.h (rs6000_field_alignment): Remove.
+	* config/rs6000/rs6000.c (rs6000_field_alignment): Move...
+	* config/rs6000/rs6000.h (ADJUST_FIELD_ALIGN): ...inline into the
+	macro.
+
+2002-08-08  Jakub Jelinek  <jakub@redhat.com>
+
+	* stor-layout.c (place_union_field): For bitfields if
+	PCC_BITFIELD_TYPE_MATTERS and TYPE_USER_ALIGN, set record's
+	TYPE_USER_ALIGN.
+
+2002-08-07  Jakub Jelinek  <jakub@redhat.com>
+	    Richard Henderson  <rth@redhat.com>
+
+	* stor-layout.c (place_union_field): Apply ADJUST_FIELD_ALIGN
+	to type_align when PCC_BITFIELD_TYPE_MATTERS.  Only apply
+	ADJUST_FIELD_ALIGN if not DECL_USER_ALIGN resp. TYPE_USER_ALIGN.
+	(place_field): Likewise.
+	* config/i386/i386.c (x86_field_alignment): Don't check
+	TARGET_ALIGN_DOUBLE for the second time.
+	Apply min for all MODE_INT and MODE_CLASS_INT modes.
+	* config/rs6000/rs6000.c (rs6000_field_alignment): New.
+	* config/rs6000/rs6000-protos.h (rs6000_field_alignment): New
+	prototype.
+	* config/rs6000/rs6000.h (ADJUST_FIELD_ALIGN): Define.
+	* config/rs6000/aix.h (ADJUST_FIELD_ALIGN): Remove.
+	* config/rs6000/darwin.h (ADJUST_FIELD_ALIGN): Remove.
+	* config/rs6000/linux64.h (ADJUST_FIELD_ALIGN): Remove.
+	* config/rs6000/sysv4.h (ADJUST_FIELD_ALIGN): Remove.
+	* doc/tm.texi (ADJUST_FIELD_ALIGN): Update description.
+
+2002-08-06  Jakub Jelinek  <jakub@redhat.com>
+
+	* config/i386/mmintrin.h (__m64): Make the type 64-bit aligned.
+
+2002-08-06  Jakub Jelinek  <jakub@redhat.com>
+
+	* config.gcc (*-*-linux*): Default to --enable-threads=posix if no
+	--{enable,disable}-threads is given to configure.
+	(alpha*-*-linux*, hppa*-*-linux*, i[34567]86-*-linux*,
+	x86_64-*-linux*, ia64*-*-linux*, m68k-*-linux*, mips*-*-linux*,
+	powerpc-*-linux-gnualtivec*, powerpc-*-linux*, s390-*-linux*,
+	s390x-*-linux*, sh-*-linux*, sparc-*-linux*, sparc64-*-linux*):
+	Remove thread_file setting here.
+
+2002-08-04  Mark Mitchell  <mark@codesourcery.com>
+
+	* doc/install.texi (Installing GCC): Refer to buildstat.html,
+	rather than listing version-specific build status files.
+
+2002-08-04  Joseph S. Myers  <jsm@polyomino.org.uk>
+
+	* doc/include/gcc-common.texi (version-GCC): Increase to 3.2.
+
+2002-08-01  Benjamin Kosnik  <bkoz@redhat.com>
+
+	* gcc.c: Set __GXX_ABI_VERSION to 102.
+
+2002-07-30  Franz Sirl  <Franz.Sirl-kernel@lauterbach.com>
+
+	* gcc.c (cpp_unique_options): Define __GXX_ABI_VERSION, bump it to 101.
+
+2002-07-24  Frank van der Linden  <fvdl@wasabisystems.com>
+
+	PR optimization/7291
+	* config/i386/i386.c (ix86_expand_clrstr): Fix bzero alignment
+	problem on x86_64.
+
+2002-05-16  Jason Merrill  <jason@redhat.com>
+
+	* config/mips/mips.c (mips_output_external): Don't do sdata
+	optimization for a variable with DECL_COMDAT set.
+
+2002-01-03  Jakub Jelinek  <jakub@redhat.com>
+
+	* c-decl.c (build_compound_literal): Set decl TREE_READONLY from TYPE.
+
+	* c-decl.c (build_compound_literal): Defer compound literal decls
+	until until file end to emit them only if they are actually used.
+
 2002-07-25  Release Manager
 
 	* GCC 3.1.1 Released.

Re: Is the gcc-3_3-branch creation still on target?

[H. J. Lu]

On Fri, Oct 04, 2002 at 08:45:15AM -0700, David O'Brien wrote:
> On Fri, Oct 04, 2002 at 08:23:11AM -0700, H. J. Lu wrote:
> > I am just curious. Isn't the only difference between 3.1 and 3.2 is the
> > C++ ABI change? How come 3.1.1 is more stable than 3.2.1?
> 
> 3.2[.0] was supose to have just the C++ ABI change (as shown in
> gcc/cp/ChangeLog), but it had a bit more in the base compiler.  Since
> 3.2[.0]'s release, a lot of changes have gone into gcc-3_2-branch.  Some
> things that did not compile with 3.2.1, now compile due to fixes in the
> gcc-3_2-branch.  But now other things that did compile cause ICE's.  It
> has been a never ending chase since 2.95.3 to find a truly usable GCC.
> 

I don't expect it will end any time soon after a new releae of gcc. I
am talking months if not years.

> cvs diff -u0 -r gcc_3_2_release -r gcc-3_2-branch, gcc/ChangeLog 508
> lines of diff, and cp/ChangeLog has 63 lines of diff.  Bugs have been
> added since 3.2.0.  FreeBSD is using a GCC 3.2.1 20020916 snapshot, and

I assume you have filed bug reports marked them as regression.



H.J.

Re: Is the gcc-3_3-branch creation still on target?

[Andreas Jaeger]

"David O'Brien" <obrien@FreeBSD.org> writes:

> Are things still on schedule to branch mainline, creating the
> gcc-3_3-branch, on 15-Oct-2002?
>
> FreeBSD 5.0 will use some form of GCC 3.3 snapshot.  I know this isn't
> desired by the GCC Steering Committee to have another "gcc 2.96", but
> FreeBSD has little choice.  It ICE's on many popular packages, X11 as
> just one example.  It has serious optimization bugs for modern x86
> processors, for which the PR's aren't getting fixed.  It has regressions

Honza just fixed and verified a few PRs.  

Just getting off-topic:
Honza, I noticed you commit them this way:

Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>

        * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.

The rule is to mention the PR number so that everybody knows which
report is fixed, in this case the ChangeLog should be:
       
Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>

        PR c/7242
        * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.

Can you follow the example please? 

Ok, back to your claims: Did you report everything?  GCC 3.2 (and
neither current CVS from last week) ICEs on Linux/x86 and Linux/x86-64
while compiling X11 nor on any package that is in the current SuSE
distribution for these platforms.  So, please send bug reports that
are reproduceable.

> from 2.95 that aren't getting fixed.  All in all, GCC 3.2 is poo.  There
> needs to be a balance between adding new features, re-abstracting the
> code, etc; and basic usability.  So far the 3.x series has leaned too far
> to the former.  GCC 3.1.1 was the most stable of any of the 3.x
> compilers, but it has a broken C++ ABI and is EOL'ed by the GCC
> developers, which makes it a poor choice to base an OS on.

GCC 3.2 is pretty good, e.g. Mandrake, Red Hat and SuSE use it as
basis for their current Linux distribution.

I understand that you want to switch to 3.3 but I would suggest the
following (that's how we have done it at SuSE and I guess Red Hat did
something similar):
- use the current CVS mainline for your work and test everything with it

- report all bugs that you encounter

- integrate regularly (e.g. using the weekly snapshot) the current CVS
  version into your system and start from the beginning ;-)

- release FreeBSD 3.0 with the final release of GCC 3.3.

This is quite involved but if you follow the development closely, your
permanent testing will help make GCC 3.3 a suitable compiler for your
environment.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote:
> I assume you have filed bug reports marked them as regression.

Yes.  One finally got fixed in mainline, but I'm sure it wont get back
ported and I wonder if I could get permission to commit it if I back
ported it.  There are 6 Athlon and related PR's that I know of.  A few
also apply to Pentium-4.

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 06:14:09PM +0200, Andreas Jaeger wrote:
> Ok, back to your claims: Did you report everything?  GCC 3.2 (and
> neither current CVS from last week) ICEs on Linux/x86 and Linux/x86-64
> while compiling X11 nor on any package that is in the current SuSE
> distribution for these platforms.  So, please send bug reports that
> are reproduceable.

One from the GCC 3.1 is "-fno-align-functions regression from 2.95"
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6627

Some other things are reported, some things I know simply wont get fixed
in the 3.2_branch.  Trimming down why I get an ICE compiling the XFree86
4.2.0 server, isn't worth the time it would take to narrow it down as
long as the below PR's are still open.

From the ones that are reported (querry done in Sept):

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&category=all&severity=all&priority=all&responsible=all&submitter_id=all&state=all&ignoreclosed=Ignore%20Closed&class=all&synopsis=athlon&multitext=&columns=category&columns=state&columns=class&columns=responsible&columns=synopsis&displaydate=Display%20Current%20Date&cmd=submit%20query&sortby=Responsible&.cgifields=columns&.cgifields=originatedbyme&.cgifields=displaydate&.cgifields=ignoreclosed

PR   Category     State Class            Responsible Synopsis
6845 optimization open ice-on-legal-code unassigned ICE with -O -march=pentium3/pentium2/athlon
7034 optimization open ice-on-legal-code unassigned ICE on -march=athlon for CLAPACK code
7124 optimization open ice-on-legal-code unassigned -O2 -march=athlon produces ICE
7134 optimization open ice-on-legal-code unassigned Athlon: ICE in extract_insn, at recog.c:2130
7174 optimization open sw-bug            unassigned ICE:seg fault with O2 and athlon-xp architecture
7390 optimization open ice-on-legal-code unassigned ICE with gcc 3.1, happens only with -march athlon 

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7134
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7390

Re: Is the gcc-3_3-branch creation still on target?

[H. J. Lu]

On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote:
> On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote:
> > I assume you have filed bug reports marked them as regression.
> 
> Yes.  One finally got fixed in mainline, but I'm sure it wont get back
> ported and I wonder if I could get permission to commit it if I back

Is that a regression? If it is, why can't it be back ported?

> ported it.  There are 6 Athlon and related PR's that I know of.  A few
> also apply to Pentium-4.

Are they also regression?


H.J.

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 09:36:29AM -0700, H. J. Lu wrote:
> On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote:
> > On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote:
> > > I assume you have filed bug reports marked them as regression.
> > 
> > Yes.  One finally got fixed in mainline, but I'm sure it wont get back
> > ported and I wonder if I could get permission to commit it if I back
> 
> Is that a regression? If it is, why can't it be back ported?

It is.  FreeBSD's bootloader had to loose some of it's strings as one
could not produce a binary as small as one could with GCC 2.95.
 

> > ported it.  There are 6 Athlon and related PR's that I know of.  A few
> > also apply to Pentium-4.
> 
> Are they also regression?

Probably not seen as such as GCC 2.95 did not support Athon and Pentium-4
optimizations.   But believe me, users are trying to use -march=athlon.

Re: Is the gcc-3_3-branch creation still on target?

[H. J. Lu]

On Fri, Oct 04, 2002 at 09:46:00AM -0700, David O'Brien wrote:
> On Fri, Oct 04, 2002 at 09:36:29AM -0700, H. J. Lu wrote:
> > On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote:
> > > On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote:
> > > > I assume you have filed bug reports marked them as regression.
> > > 
> > > Yes.  One finally got fixed in mainline, but I'm sure it wont get back
> > > ported and I wonder if I could get permission to commit it if I back
> > 
> > Is that a regression? If it is, why can't it be back ported?
> 
> It is.  FreeBSD's bootloader had to loose some of it's strings as one
> could not produce a binary as small as one could with GCC 2.95.
>  

I guess no one else used it. It may be too bad for FreeBSD. I hope it
won't happen again since you are testing gcc before it is branched. I
tend to agree that back port it to 3.2 is not a very good idea in this
case. But you can certainly do a private port for FreeBSD.

> 
> > > ported it.  There are 6 Athlon and related PR's that I know of.  A few
> > > also apply to Pentium-4.
> > 
> > Are they also regression?
> 
> Probably not seen as such as GCC 2.95 did not support Athon and Pentium-4
> optimizations.   But believe me, users are trying to use -march=athlon.

As long as they are fixed in gcc 3.3, I am happy.



H.J.

Re: Is the gcc-3_3-branch creation still on target?

[Zack Weinberg]

On Fri, Oct 04, 2002 at 09:29:36AM -0700, David O'Brien wrote:
> On Fri, Oct 04, 2002 at 08:50:14AM -0700, H. J. Lu wrote:
> > I assume you have filed bug reports marked them as regression.
> 
> Yes.  One finally got fixed in mainline, but I'm sure it wont get back
> ported and I wonder if I could get permission to commit it if I back
> ported it.   There are 6 Athlon and related PR's that I know of.  A few
> also apply to Pentium-4.

Anything that is a regression, including from 2.x, should at least be
considered for backport.  Send me the PR numbers, and change log
entries if you know they've been fixed for 3.3.

I personally expect the release of 3.2.1 to be delayed so that the
regressions can be addressed.

zw

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 09:52:59AM -0700, H. J. Lu wrote:
> As long as they are fixed in gcc 3.3, I am happy.

That is the stance I am starting to take.  But no one is answering the
main question of when will the branch be created.

-- 
-- David  (obrien@FreeBSD.org)

Re: Is the gcc-3_3-branch creation still on target?

[Gerald Pfeifer]

On Fri, 4 Oct 2002, David O'Brien wrote:
>> I assume you have filed bug reports marked them as regression.
> Yes.  One finally got fixed in mainline, but I'm sure it wont get back
> ported and I wonder if I could get permission to commit it if I back
> ported it.

I'd say, let's try: Go ahead and submit a patch, Cc:ing our release
manager (Mark).

And if this is a regression in 3.2.x as well and the PR has been closed
or is not of priority high, please reopen the PR and/or mark it as high
priority.

(Mark has been explicitly asking about the numbers of regression PRs, and
I suppose he's still interested.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Is the gcc-3_3-branch creation still on target?

[Gerald Pfeifer]

On Fri, 4 Oct 2002, David O'Brien wrote:
>> As long as they are fixed in gcc 3.3, I am happy.
> That is the stance I am starting to take.  But no one is answering the
> main question of when will the branch be created.

I understood there has been some consensus to possibly delay generating
to branch to allow mainline to further stabilize before the branch.

As Zack mentioned, also 3.2.1 might be delayed to allow further back-
porting a problems already fixed and to be fixed on mainline.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Is the gcc-3_3-branch creation still on target?

[Gerald Pfeifer]

On Fri, 4 Oct 2002, Andreas Jaeger wrote:
> Just getting off-topic:
> Honza, I noticed you commit them this way:
>
> Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>
>
>         * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.
>
> The rule is to mention the PR number so that everybody knows which
> report is fixed, in this case the ChangeLog should be:
>
> Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>
>
>         PR c/7242
>         * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.
>
> Can you follow the example please?

In fact, may I suggest you (Honza) update the ChangeLogs with these PR
numbers?

This is useful for people like Joe who destill list of fixed PRs on the
release branch from these ChangeLogs.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Is the gcc-3_3-branch creation still on target?

[Andreas Jaeger]

"David O'Brien" <obrien@FreeBSD.org> writes:

> On Fri, Oct 04, 2002 at 06:14:09PM +0200, Andreas Jaeger wrote:
>> Ok, back to your claims: Did you report everything?  GCC 3.2 (and
>> neither current CVS from last week) ICEs on Linux/x86 and Linux/x86-64
>> while compiling X11 nor on any package that is in the current SuSE
>> distribution for these platforms.  So, please send bug reports that
>> are reproduceable.
>
> One from the GCC 3.1 is "-fno-align-functions regression from 2.95"
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6627
>
> Some other things are reported, some things I know simply wont get fixed
> in the 3.2_branch.  Trimming down why I get an ICE compiling the XFree86
> 4.2.0 server, isn't worth the time it would take to narrow it down as
> long as the below PR's are still open.
>
>From the ones that are reported (querry done in Sept):
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?database=gcc&category=all&severity=all&priority=all&responsible=all&submitter_id=all&state=all&ignoreclosed=Ignore%20Closed&class=all&synopsis=athlon&multitext=&columns=category&columns=state&columns=class&columns=responsible&columns=synopsis&displaydate=Display%20Current%20Date&cmd=submit%20query&sortby=Responsible&.cgifields=columns&.cgifields=originatedbyme&.cgifields=displaydate&.cgifields=ignoreclosed
>
> PR   Category     State Class            Responsible Synopsis
> 6845 optimization open ice-on-legal-code unassigned ICE with -O -march=pentium3/pentium2/athlon
> 7034 optimization open ice-on-legal-code unassigned ICE on -march=athlon for CLAPACK code
> 7124 optimization open ice-on-legal-code unassigned -O2 -march=athlon produces ICE
> 7134 optimization open ice-on-legal-code unassigned Athlon: ICE in extract_insn, at recog.c:2130
> 7174 optimization open sw-bug            unassigned ICE:seg fault with O2 and athlon-xp architecture
> 7390 optimization open ice-on-legal-code unassigned ICE with gcc 3.1, happens only with -march athlon 
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7134
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174

All of these are closed with comments that they got  fixed or could
not reproduced anymore.

> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7390

This one is open and Honza mentioned "have tentative fix"

So, let's get back to your original claim:
> [...]  It has serious optimization bugs for modern x86
> processors, for which the PR's aren't getting fixed.  It has regressions

From the 6 bugs "serious optimization bugs" that you mention, 5 are
fixed and one is worked one.  Is this really nothing "gets fixed"?

I'm glad to see that the situation has improved since last time you
looked at this...

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Is the gcc-3_3-branch creation still on target?

[Jan Hubicka]

> On Fri, 4 Oct 2002, Andreas Jaeger wrote:
> > Just getting off-topic:
> > Honza, I noticed you commit them this way:
> >
> > Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>
> >
> >         * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.
> >
> > The rule is to mention the PR number so that everybody knows which
> > report is fixed, in this case the ChangeLog should be:
> >
> > Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>
> >
> >         PR c/7242
> >         * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.
> >
> > Can you follow the example please?
> 
> In fact, may I suggest you (Honza) update the ChangeLogs with these PR
> numbers?

Will do at begining of next week (remind me if I will forged, but I am
adding this to the todo folder).
The queue has been rather long after returning from the trip and many of
the bugreports has been just fixed independently. 
I tried to mention it
in each closing email, so I guess it is better to harvest these.
I didn't know we want to track fixed bugreports. THis opens interesting
problems, like what to do if I find that some bug has been fixed by old
change. Should I update CHangeLog?  What to do in the case the testcase
just works on the branch and I am unsure why?

Honza
> 
> This is useful for people like Joe who destill list of fixed PRs on the
> release branch from these ChangeLogs.
> 
> Gerald
> -- 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Is the gcc-3_3-branch creation still on target?

[Jan Hubicka]

> > PR   Category     State Class            Responsible Synopsis
> > 6845 optimization open ice-on-legal-code unassigned ICE with -O -march=pentium3/pentium2/athlon
> > 7034 optimization open ice-on-legal-code unassigned ICE on -march=athlon for CLAPACK code
> > 7124 optimization open ice-on-legal-code unassigned -O2 -march=athlon produces ICE
> > 7134 optimization open ice-on-legal-code unassigned Athlon: ICE in extract_insn, at recog.c:2130
> > 7174 optimization open sw-bug            unassigned ICE:seg fault with O2 and athlon-xp architecture
> > 7390 optimization open ice-on-legal-code unassigned ICE with gcc 3.1, happens only with -march athlon 
> >
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7134
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174
> 
> All of these are closed with comments that they got  fixed or could
> not reproduced anymore.

Note that all of these manifest in some way the same bug where GCC
decided to use MMX registers when it should not, so it is no surprise
that they got fixed quickly.
Some of bugs, like 7134 and 7390 are different and I am not sure why
they has been fixed, but I din't investigated.

Honza

Re: Is the gcc-3_3-branch creation still on target?

[Andreas Jaeger]

Jan Hubicka <jh@suse.cz> writes:

>> On Fri, 4 Oct 2002, Andreas Jaeger wrote:
>> > Just getting off-topic:
>> > Honza, I noticed you commit them this way:
>> >
>> > Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>
>> >
>> >         * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.
>> >
>> > The rule is to mention the PR number so that everybody knows which
>> > report is fixed, in this case the ChangeLog should be:
>> >
>> > Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>
>> >
>> >         PR c/7242
>> >         * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.
>> >
>> > Can you follow the example please?
>> 
>> In fact, may I suggest you (Honza) update the ChangeLogs with these PR
>> numbers?
>
> Will do at begining of next week (remind me if I will forged, but I am
> adding this to the todo folder).
> The queue has been rather long after returning from the trip and many of
> the bugreports has been just fixed independently. 
> I tried to mention it
> in each closing email, so I guess it is better to harvest these.
> I didn't know we want to track fixed bugreports. THis opens interesting
> problems, like what to do if I find that some bug has been fixed by old
> change. Should I update CHangeLog?  What to do in the case the testcase

The procedure is as far as I can see:
- you look at bug report no. c/X
- create a fix for bug c/X
- add to the ChangeLog: PR c/X

If you look at the report and notice it's fixed already, there's IMO
nothing for you to do.  Especially no need to commit a new ChangeLog.

> just works on the branch and I am unsure why?

I would simply ask ;-)

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Is the gcc-3_3-branch creation still on target?

[Phil Edwards]

On Fri, Oct 04, 2002 at 06:14:09PM +0200, Andreas Jaeger wrote:
> The rule is to mention the PR number so that everybody knows which
> report is fixed, in this case the ChangeLog should be:
>        
> Thu Oct  3 23:15:15 CEST 2002  Jan Hubicka  <jh@suse.cz>
> 
>         PR c/7242
>         * i386.h (CPP_SPECS): fix defines for -msse, -msse2, -mpentium2,3.

Also, the CVS server will notice the text, and the commit log will be
automatically appended to the PR's audit trail.


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002

Re: Is the gcc-3_3-branch creation still on target?

[Alexander Kabaev]

On Fri, 4 Oct 2002 19:28:06 +0200
Jan Hubicka <jh@suse.cz> wrote:

> Some of bugs, like 7134 and 7390 are different and I am not sure why
> they has been fixed, but I din't investigated.

7134 has been fixed in mainline in April, and the fix has been merged
back before September 16th. So far I only have two ICEs reported to me
by FreeBSD users: one in XFree86 and one with GCC dumping core on
invalid code. I will try to post a PR for the last one. The XFree86
looks like this:

>I'm getting this when trying to compile XFree86-4-libraries with
> CPUTYPE=k6-2:

 > miPck1Prim.c: In function `CheckFAreaPick1':
 > miPck1Prim.c:337: unable to find a register to spill in class
`FLOAT_REGS' > miPck1Prim.c:337: this is the insn:
 > (insn 266 264 268 (set (subreg:SF (reg/v:DI 29 rmm0 [64]) 0)
 >         (float:SF (mem/s/j:HI (reg/v/f:SI 1 edx [61]) [0
<variable>.x+0 S2 +A16]))) 167 {floathisf2} (insn_list 262 (nil))
 >     (nil))
 > miPck1Prim.c:337: confused by earlier errors, bailing out

Should this have been fixed by disabling moves between MMX and FP
registers? I am just guessing here.

-- 
Alexander Kabaev

Re: Is the gcc-3_3-branch creation still on target?

[Zack Weinberg]

On Fri, Oct 04, 2002 at 07:47:36PM +0200, Andreas Jaeger wrote:
> The procedure is as far as I can see:
> - you look at bug report no. c/X
> - create a fix for bug c/X
> - add to the ChangeLog: PR c/X
> 
> If you look at the report and notice it's fixed already, there's IMO
> nothing for you to do.  Especially no need to commit a new ChangeLog.

Well, I would suggest annotating the PR with the change log entry of
the patch that fixed it, if this can be determined, or just 'works for
me with <platform>, <date>, <branch>' otherwise.

zw

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 07:23:53PM +0200, Andreas Jaeger wrote:
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6845
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7034
> > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7124

Only yesterday (I do thank rth for fixing these).  And the posted patch
didn't mention anything about getting into the 3.2_branch line.


> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7174
> 
> All of these are closed with comments that they got  fixed or could
> not reproduced anymore.

Only today after my email. ;-)
    
    State-Changed-When: Thu Oct  3 09:38:14 2002
    State-Changed-When: Thu Oct  3 09:40:44 2002

The PR#7174 closure didn't state if the test case was tested with
mainline or a 3.2_branch compiler.  It would have been useful to know.
If possible please try to state that next time.  [this is 110% with my
freebsd.org hat on, not employer hat]

The fact that serious bugs like these are just now getting fixed in the
4th release from a branch doesn't give one the warm fuzzies for basing a
product on.  (3.2.1 is equivlically 3.1.3)


> So, let's get back to your original claim:
> > [...]  It has serious optimization bugs for modern x86
> > processors, for which the PR's aren't getting fixed.  It has regressions
> From the 6 bugs "serious optimization bugs" that you mention, 5 are
> fixed and one is worked one.  Is this really nothing "gets fixed"?
> 
> I'm glad to see that the situation has improved since last time you
> looked at this...

It may be too late.  We've been looking for six months for a GCC code
base for FreeBSD 5.0.  Everything we've tried has failed to not ICE on
the base system + 8000 3rd party packages for i386.  Based on past
experiences with GCC branches this long in the tooth, we've mostly
decided to go with GCC 3.3 where we have a chance of getting ICE's and
other regressions fixed on a planable timeline..

-- 
-- David  (obrien@FreeBSD.org)

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 10:58:36AM -0700, Zack Weinberg wrote:
> Well, I would suggest annotating the PR with the change log entry of
> the patch that fixed it, if this can be determined, or just 'works for
> me with <platform>, <date>, <branch>' otherwise.

That would be very good information to have in the PR.

Re: Is the gcc-3_3-branch creation still on target?

[Joseph S. Myers]

On Fri, 4 Oct 2002, David O'Brien wrote:

> It may be too late.  We've been looking for six months for a GCC code
> base for FreeBSD 5.0.  Everything we've tried has failed to not ICE on
> the base system + 8000 3rd party packages for i386.  Based on past

I'd favour having not ICEing on the 8000 packages be included in the
application testing in the release criteria (rather than just the handful
of software currently there).  How long does it take to do a build of 8000
packages, and could there be an automatic regression tester for mainline
doing those tests (and reporting regressions since last test to
gcc-regression - ideally with .i files to reproduce the failures)?

(The criterion needs to be "not ICEing" rather than actually successfully
building the packages, because there will inevitably be changes breaking
old invalid C++ code etc..)

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Is the gcc-3_3-branch creation still on target?

[Richard Henderson]

On Fri, Oct 04, 2002 at 01:51:24PM -0400, Alexander Kabaev wrote:
>  > (insn 266 264 268 (set (subreg:SF (reg/v:DI 29 rmm0 [64]) 0)
>  >         (float:SF (mem/s/j:HI (reg/v/f:SI 1 edx [61]) [0
> <variable>.x+0 S2 +A16]))) 167 {floathisf2} (insn_list 262 (nil))
>  >     (nil))
>  > miPck1Prim.c:337: confused by earlier errors, bailing out
> 
> Should this have been fixed by disabling moves between MMX and FP
> registers? I am just guessing here.

Yes.


r~

Re: Is the gcc-3_3-branch creation still on target?

[Jan Hubicka]

> On Fri, Oct 04, 2002 at 10:58:36AM -0700, Zack Weinberg wrote:
> > Well, I would suggest annotating the PR with the change log entry of
> > the patch that fixed it, if this can be determined, or just 'works for
> > me with <platform>, <date>, <branch>' otherwise.
> 
> That would be very good information to have in the PR.
OK, this looks good, I will try to use this scheme next time.

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Fri, Oct 04, 2002 at 09:40:59PM +0100, Joseph S. Myers wrote:
> I'd favour having not ICEing on the 8000 packages be included in the
> application testing in the release criteria (rather than just the handful
> of software currently there).  How long does it take to do a build of 8000
> packages, and could there be an automatic regression tester for mainline
> doing those tests (and reporting regressions since last test to
> gcc-regression - ideally with .i files to reproduce the failures)?

I spoke with our package builder about this.  He says it takes 24 hours
with a cluster of 8 build machines (pentium-III/800).

With all the activities he already does; build packages for FreeBSD/4.x;
for FreeBSD/5.x; experimental runs on both versions to flush out
upgrading core packages like gtk, iconv, gettext, etc... there is little
bandwidth on his time to try experimental compilers. :-(

The scripts to do this are publically available though.

Re: Is the gcc-3_3-branch creation still on target?

[Joe Buck]

On Fri, Oct 04, 2002 at 09:40:59PM +0100, Joseph S. Myers wrote:
> > I'd favour having not ICEing on the 8000 packages be included in the
> > application testing in the release criteria (rather than just the handful
> > of software currently there).  How long does it take to do a build of 8000
> > packages, and could there be an automatic regression tester for mainline
> > doing those tests (and reporting regressions since last test to
> > gcc-regression - ideally with .i files to reproduce the failures)?

David O'Brien writes:
> I spoke with our package builder about this.  He says it takes 24 hours
> with a cluster of 8 build machines (pentium-III/800).

That works out to 86.4 sec/package if each machine builds 1000 packages.
Seems a bit on the slow side, but quite possible.

> With all the activities he already does; build packages for FreeBSD/4.x;
> for FreeBSD/5.x; experimental runs on both versions to flush out
> upgrading core packages like gtk, iconv, gettext, etc... there is little
> bandwidth on his time to try experimental compilers. :-(

It seems that the main bottleneck is availability of machine time, as once
the build process is set up, it can just be fired off.

Unfortunately, if no volunteers can be found for such tasks, we tend to
find these things out the hard way.  You say you want to go to 3.3-pre
because you're not satisfied with 3.2's quality, but there's no magic
that's going to make 3.3 better, other than people building 8000 packages
with "experimental compilers" (whether from the 3.2 or the 3.3 branch).
I'd rather try to persuade people to put in the resources to bang on what
will become 3.2.1.

Re: Is the gcc-3_3-branch creation still on target?

[David O'Brien]

On Wed, Oct 09, 2002 at 11:56:08AM -0700, Joe Buck wrote:
> David O'Brien writes:
> > I spoke with our package builder about this.  He says it takes 24 hours
> > with a cluster of 8 build machines (pentium-III/800).
> 
> That works out to 86.4 sec/package if each machine builds 1000 packages.
> Seems a bit on the slow side, but quite possible.

Oh, how I wish each of the gcc33, gcc32, and gcc31 ports built in only
86.4 seconds.  Don't supose you could help with that? ;-)

Seriously, each port is build in a clean chroot environment that takes a
while to set up?  Including pkg_add'ing dependent packages, etc.



> Unfortunately, if no volunteers can be found for such tasks, we tend to
> find these things out the hard way.  You say you want to go to 3.3-pre
> because you're not satisfied with 3.2's quality, but there's no magic
> that's going to make 3.3 better, other than people building 8000 packages
> with "experimental compilers" (whether from the 3.2 or the 3.3 branch).

We still plan to move to 3.3; *and* do it before it is released.  One
reason is to feed into the pre-release testing phase, while things can be
more easily fixed.