[PATCH, AArch64 4/6] soft-fp: Commonize creation of TImode types
Richard Henderson
rth@redhat.com
Thu Jan 9 15:57:00 GMT 2014
On 01/08/2014 12:39 PM, Joseph S. Myers wrote:
> On Wed, 8 Jan 2014, Richard Henderson wrote:
>
>> diff --git a/libgcc/soft-fp/soft-fp.h b/libgcc/soft-fp/soft-fp.h
>> index 696fc86..b54b1ed 100644
>> --- a/libgcc/soft-fp/soft-fp.h
>> +++ b/libgcc/soft-fp/soft-fp.h
>> @@ -237,6 +237,11 @@ typedef int DItype __attribute__ ((mode (DI)));
>> typedef unsigned int UQItype __attribute__ ((mode (QI)));
>> typedef unsigned int USItype __attribute__ ((mode (SI)));
>> typedef unsigned int UDItype __attribute__ ((mode (DI)));
>> +#if _FP_W_TYPE_SIZE == 64
>> +typedef int TItype __attribute__ ((mode (TI)));
>> +typedef unsigned int UTItype __attribute__ ((mode (TI)));
>> +#endif
>
> This isn't the right conditional. _FP_W_TYPE_SIZE is ultimately an
> optimization choice and need not be related to whether any TImode
> functions are being defined using soft-fp, or whether TImode is supported
> at all. I think the most you can do is have sfp-machine.h define a macro
> to say that TImode should be supported in soft-fp, rather than actually
> defining the types itself.
The documentation for longlong.h say we must have a double-word type defined.
Given how easy it is to support a double-word type...
>
> (If someone were to use soft-fp on hppa64, then they might well use
> _FP_W_TYPE_SIZE == 64, but hppa64 doesn't support TImode.)
>
... I can't imagine that this is anything but a bug. Not that anyone seems to
be doing any hppa work at all these past years.
r~
More information about the Gcc-patches
mailing list