This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]