GCC build failed with your patch on 2001-01-09T11:35:00Z.

Richard Henderson rth@redhat.com
Tue Jan 9 13:58:00 GMT 2001


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.


r~


More information about the Gcc-regression mailing list