On Fri, Jan 31, 2014 at 10:12 AM, Joseph S. Myers
<[email protected]> wrote:
> On Fri, 31 Jan 2014, Andrew Pinski wrote:
>
>> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu <[email protected]> wrote:
>> > Hi,
>> >
>> > For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
>> > This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
>> > Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
>> > -mlong-double-64 and -mlong-double-80 negate each other so that the
>> > last one on command line wins. It os OK since we don't support
>> > -mlong-double-xxx in target attribute. I added some testcases to verify
>> > it works correctly. OK for trunk?
>>
>> I don't see any where in the documentation that explains the
>> difference between -mlong-double-128 and -m128bit-long-double. Can
>> you please add that -mlong-double-128 causes soft-floating point.
I will update it together with -m128bit-long-double clarification.
>> Also what about the interactions between these two options.
They have nothing to do with each other. -m128bit-long-double
controls the storage size of __float80 amd -mlong-double-XXX
controls the size of long double, 64, 80 and 128 bits.
>
> Yes, I think the invoke.texi documentation for each of these options needs
> to cross-reference the other one of the options and explain the difference
> explicitly.
>
> I would add: to confirm, does __float80 remain available on 64-bit Android
Yes, it does. There is a testcase for it:
[hjl@gnu-6 testsuite]$ cat gcc.target/i386/long-double-80-5.c
/* { dg-do compile } */
/* { dg-options "-O2 -mlong-double-64" } */
__float80
foo (__float80 x)
{
return x * x;
}
/* { dg-final { scan-assembler "fldt" } } */
[hjl@gnu-6 testsuite]$
> and provide access to XFmode there? (If not, the documentation of
> __float80 needs updating.)
>
> If in future we implement TS 18661-3 in GCC, it will be necessary to work
> out in cases such as this whether _Float64x should have the representation
> of __float80 or __float128 (I'd guess __float80 would be better).
>
--
H.J.
