GCC 3.2.1 -- Request for Bug Fixers

GCC 3.2.1 -- Request for Bug Fixers

[Mark Mitchell]

We've got about 13 high-priority regressions that we need to fix
before GCC 3.2.1 at this point.  We've made huge progress over the
last week or two; a final push now can put us over the top.

Benjamin -- PR 6476 is a libstdc++ issue assigned to you.  I know you're
figuring out madness what to put in the next version of the C++
library this week, but find some time to nail this PR. :-)

Nick, Richard Earnshaw -- PR 7856 is an ARM bug; would one of you take
a look?

Jakub -- PR 6981 is an x86 bug assigned to you; what is the status?

Richard Henderson -- It's not like this is any way really to do with
you, but if you had time to look at PR 7944 (a reload crash), that
would be way helpful.

I will keep banging on the C++ bugs.

Getting closer...

-- 
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC 3.2.1 -- Request for Bug Fixers

[Joe Buck]

> We've got about 13 high-priority regressions that we need to fix
> before GCC 3.2.1 at this point.  We've made huge progress over the
> last week or two; a final push now can put us over the top.

Yes, the number has gone down even though we made about six more bugs
priority "high" in the last couple of days.

The 3.2.1 release note it getting big; I'll hold off on reposting it
for a bit since the bug fixes are rolling in.

I count 12 definite, and 2 in feedback:

6545 in feedback state since Aug.
7090 it appears that a patch was applied for this one, but it is still
     in "feedback" state.

Any idea about those two, are they real?

The other 12 are

5509, 6718, 6746, 6981, 6994, 7228, 7266, 7363, 7385, 7856, 7944, 8067

and the other 12 high-priority PRs only affect the trunk

Re: GCC 3.2.1 -- Request for Bug Fixers

[Joel Sherrill]

Joe Buck wrote:
> 
> > We've got about 13 high-priority regressions that we need to fix
> > before GCC 3.2.1 at this point.  We've made huge progress over the
> > last week or two; a final push now can put us over the top.
> 
> Yes, the number has gone down even though we made about six more bugs
> priority "high" in the last couple of days.
> 
> The 3.2.1 release note it getting big; I'll hold off on reposting it
> for a bit since the bug fixes are rolling in.
> 
> I count 12 definite, and 2 in feedback:
> 
> 6545 in feedback state since Aug.
> 7090 it appears that a patch was applied for this one, but it is still
>      in "feedback" state.
> 
> Any idea about those two, are they real?
> 
> The other 12 are
> 
> 5509, 6718, 6746, 6981, 6994, 7228, 7266, 7363, 7385, 7856, 7944, 8067
> 
> and the other 12 high-priority PRs only affect the trunk

I couldn't file it as high priority and didn't want to bump it up to
high until I had a fix for it but I would like to see PR8314 fixed
in 3.2.1 and the trunk.

Also the bug Pater Barada is tracking down seems to impact a number
of m68k/coldfire users (PR8309).  If someone could fix that in time 
for 3.2.1, it would be appreciated.

http://gcc.gnu.org/ml/gcc/2002-10/msg01441.html

-- 
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

Re: GCC 3.2.1 -- Request for Bug Fixers

[Peter Barada]

>Also the bug Pater Barada is tracking down seems to impact a number
>of m68k/coldfire users (PR8309).  If someone could fix that in time 
>for 3.2.1, it would be appreciated.
>
>http://gcc.gnu.org/ml/gcc/2002-10/msg01441.html

I just checked out the trunk and it exhibits this bug.  I'm
currently pulling out gcc-3_2-branch to see if its there.
If not, then I'll binary search the gcc-3_2-branch for when it showed
up. 

-- 
Peter Barada                                   Peter.Barada@motorola.com
Wizard                                         781-852-2768 (direct)
WaveMark Solutions(wholly owned by Motorola)   781-270-0193 (fax)

Re: GCC 3.2.1 -- Request for Bug Fixers

[Benjamin Kosnik]

>Benjamin -- PR 6476 is a libstdc++ issue assigned to you.  I know you're
>figuring out madness what to put in the next version of the C++
>library this week, but find some time to nail this PR. :-)

I'm on the road for the next couple of days. I'll move this up to high
priority, so that as soon as I'm in one place, I'll try to nail it.

-benjamin

Re: GCC 3.2.1 -- Request for Bug Fixers

[Richard Earnshaw]

 
> Nick, Richard Earnshaw -- PR 7856 is an ARM bug; would one of you take
> a look?

Fixed.  

Joe, could you update your release notes accordingly?

R.

Re: GCC 3.2.1 -- Request for Bug Fixers

[Joe Buck]

> > Nick, Richard Earnshaw -- PR 7856 is an ARM bug; would one of you take
> > a look?
> 
> Fixed.  

Cool!

> Joe, could you update your release notes accordingly?

I've been trying to add things as we go; there have been 25 (!) bug fixes
added to the branch since my last draft release notes post, if I've
counted right.

We may be reaching the point of diminishing returns; perhaps it's time to
do triage on the remaining bugs.  I don't see the point of holding up
3.2.1 further to fix every last ICE-on-illegal-code, given the vast number
of bug fixes we already have, but there are still a couple of bugs that
should be fixed.

The bug I'm most worried about at the moment is bootstrap/8362.  The
audit trail is empty, so I don't know if anyone has looked at it; also
I don't know enough about the various powerpc flavors to know how big
a disaster it is.

Re: GCC 3.2.1 -- Request for Bug Fixers

[David Edelsohn]

>>>>> Joe Buck writes:

Joe> The bug I'm most worried about at the moment is bootstrap/8362.  The
Joe> audit trail is empty, so I don't know if anyone has looked at it; also
Joe> I don't know enough about the various powerpc flavors to know how big
Joe> a disaster it is.

	I have been looking at it and Daniel Berlin also has been
helping.  We have not been able to track down where this failure begins.
It is unclear whether reload is not replacing all occurances of the pseudo
correctly or the pseudo is getting unshared when it should not.

	I can work around the symptom by tweaking abi_check.cc so that the
code eliciting the failure is not built for that target, but this is a
pretty serious bug affecting the PowerPC.

David