This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: state of 3.2.1-pre: how far from release?
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Joe Buck <jbuck at synopsys dot com>, David Edelsohn <dje at watson dot ibm dot com>, geoffk at geoffk dot org
- Cc: Joe Buck <Joe dot Buck at synopsys dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, bkoz at redhat dot com
- Date: Wed, 06 Nov 2002 15:41:15 -0800
- Subject: Re: state of 3.2.1-pre: how far from release?
Perhaps that's the best thing for now. I would be satisfied with a
workaround for 3.2.1.
Without help from GCC experts who understand the reload pass, this
will take a while to debug and fix.
Don't we plan to redo/replace reload for 3.4? Or am I confused?
In any case: Mark, what's your thinking? Are there other bugs that you
consider blockers?
That's a good question, and one I was just looking at. I am concerned
about 8453 which is a silent code-gen failure in C++, and 8467 which
is a silent code-gen failure with sibcalls, and 5351 which is a
silent code-gen failure with structure passing.
I am also concerned about 6746, which is a libstdc++ problem; I mentioned
it to Benjamin some time back, but there has been no action in GNATS.
I am also concerned about 8146, the bootstrap failure with GCC 2.95.3. Do
we yet have information about what is causing the problem?
These are all problems that could cause people real problems.
I don't see that we have many options; people are more interested in
working on BIB than 3.2.1, I have cajoled about as much as I am able,
and I have no other tools at my disposal.
My preference would be to see the load multiple/store multiple
instructions that are causing the problem disabled. Better a slow
compiler than a broken one, since David says the problem can come up
relatively often.
If the RS6000 maintainers do not want to do that, then David's
work-around for abi_check.cc is OK.
I would like the RS6000 maintainers to decide one way or the other,
and check in one or the other approach ASAP.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com