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