This is the mail archive of the
mailing list for the GCC project.
Re: GCC build failed with your patch on 2001-01-09T11:35:00Z.
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: GCC build failed with your patch on 2001-01-09T11:35:00Z.
- From: Richard Henderson <rth at redhat dot com>
- Date: Tue, 9 Jan 2001 13:58:07 -0800
- Cc: Mark Mitchell <mark at codesourcery dot com>, aoliva at redhat dot com, 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
- References: <email@example.com> <200101092050.PAA38976@mal-ach.watson.ibm.com>
On Tue, Jan 09, 2001 at 03:50:57PM -0500, David Edelsohn wrote:
> Mark> - Why does this change cause correctness problems?
> I do not know the root cause of all of the problems, but there are
> problems in the rs6000 port which assumes that an int is sign-extended.
> Basically, the port is not safe in the face of 64-bit CONST_INT.
The correctness issue is that with a 32-bit H_W_I we cannot do 128-bit
arithmetic in the compiler. Since bitsizetype is TImode for a 64-bit
target, cross-compiling from a 32-bit H_W_I does not work. This has
been broken ever since bitsizetype was introduced.
> Mark> - What class of compiler are affected?
> Mark> Are 32-bit targets affected, or just 64-bit targets?
> Mark> Are native compilers affected, or just cross compilers?
> Mark> For example, is a x86 GNU/Linux native compiler affected? Or
> Mark> only a x86 GNU/Linux hosted compiler targeting an IA64 target?
> Mark> Or what?
> Because some targets are runtime selectable between 32-bits and
> 64-bits, this is not limited to targets of a particular width or
> cross-compilers. Targetting a different width is a subset of a
> cross-compiler. The hwint.h decision depends upon MAX_LONG_TYPE_SIZE
> which is the maximum of the runtime selectable values.
The class of targets for which I consider the patch to be incorrect
are 32-bit natives for which there is a runtime selectable 64-bit
variant -- PA, MIPS, and PowerPC. Sparc is in a different class
since it controls the presence of Sparc64 code with SPARC_BI_ARCH,
which is not defined by default for 32-bit natives.
For other 64-bit targets I do not consider the patch broken, as
otherwise the cross-compile won't work.