This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC build failed with your patch on 2001-01-09T11:35:00Z.
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: GCC build failed with your patch on 2001-01-09T11:35:00Z.
- From: David Edelsohn <dje at watson dot ibm dot com>
- Date: Tue, 09 Jan 2001 15:13:34 -0500
- cc: Alexandre Oliva <aoliva at redhat dot com>, Geoff Keating <geoffk at redhat dot com>, gcc at gcc dot gnu dot org, gcc-regression at gcc dot gnu dot org, grahams at redhat dot com, jsm28 at cam dot ac dot uk, mhayes at redhat dot com, neil at daikokuya dot demon dot co dot uk, osk at hem dot passagen dot se, Mark Mitchell <mark at codesourcery dot com>
>>>>> Richard Henderson writes:
Richard> On Tue, Jan 09, 2001 at 02:25:37PM -0500, David Edelsohn wrote:
>> It was very poor judgment to install this destabilizing change at
>> this time, especially without more extensive testing.
Richard> I think this is a bit harsh.
Richard> Only rs6000, mips and hppa vary MAX_LONG_TYPE_SIZE like this, and
Richard> only rs6000 breaks when you build with a 64-bit H_W_I. What you
Richard> are implying is that *every* patch must be tested on rs6000 before
Richard> it is installed, as opposed to fixing problems with the patch when
Richard> they appear.
I disagree. GCC's handling of constants is fundamentally broken
because it relies too much on the host system's native data types and
arithmetic manipulations and comparisons of those host values. Because of
the overly-delicate nature of this aspect of GCC, changing those
underlying host data types must be carefully tested on many platforms.
Fixing this problem with the rs6000 port would be great, but needs
to be done at an appropriate time in the GCC development cycle. Days
before the gcc-3.0 branch is not that moment. The fix itself is too
destabilizing.
Even beyond the breakage, I still fundamentally disagree with the
patch and its lack of cost-benefit analysis. While rs6000 target needs to
work safely on 64-bit hosts, the patch should be redesigned as well in the
context of a larger discussion of this implicit trade-off.
David