This is the mail archive of the
mailing list for the GCC project.
Re: Revert patch for MIPS TImode functions for 4.1.1
- From: Roger Sayle <roger at eyesopen dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org, Richard Sandiford <richard at codesourcery dot com>
- Date: Fri, 19 May 2006 09:38:29 -0600 (MDT)
- Subject: Re: Revert patch for MIPS TImode functions for 4.1.1
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
> for MIPS on the GCC 4.1 branch?
> (My brain failed to digest the fact that the patch was on 4.1 as well as
> on mainline, perhaps in part because there doesn't seem to be a PR;
> Richard indicated to me that he would locate or open one now.)
Please can you explicitly confirm that we want to reintroduce PR
target/22209 as a regression from gcc 4.1.0, and break the build
of libgfortran on all 64-bit MIPS platforms, including IRIX?
The MIPS backend still claims that TImode is scalar_mode_supported_p,
and it's therefore possible to write simple C and C++ testcases that
will regress with this change. I know my testing of such a reversion
will reintroduce at least 4800 new failures in the dejagnu testsuite,
for no reported improvement vs gcc 4.1.0. It's a lesser of two evils
issue, and it's only further development on mainline, and not a user
reported problem, that's revealed the potential fallout in 4.1.0.
The tradeoff is between unlinkable code in the default build on the
affected platforms, vs. unlinkable code when explicitly using
the -msoft-float flag, which isn't tested by the testsuite.
I'm happy to revert the changes at a moment's notice, especially if
that's what the realease manager and MIPS maintainers want, but I
just want to be certain that everyone's aware of the tradeoffs, so
that whatever the outcome, it's not my fault.
I'll start a bootstrap and regression test of the reversion against
the 4.1 branch straight away, it's not clear if recent backports have
introduced additional dependencies, but these machines aren't the
fastest on the planet, and it's still behind on evaluating the recent
set of mainline patches/changes.