[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