On Wed, 21 May 2014, Marek Polacek wrote: > On Tue, May 20, 2014 at 09:50:10PM +0000, Joseph S. Myers wrote: > > On Tue, 20 May 2014, Marek Polacek wrote: > > > > > * is missing tests for long doubles/-mlong-double-128, > > > > Also missing tests for float - as far as I can see, only double is tested. > > Ideally all of float, double, long double, __float128 (where supported), > > __float80 (where supported) would be tested (the functionality supported > > for __fp16 (ARM) is a bit more restricted) - hopefully using some shared > > macros to avoid too much duplication between tests. > > Ok, I've added some tests for float, long double, __float128 and > __float80. A snag was in __float128 type: libubsan supposedly can't > handle __float128 values and prints "0". libubsan also can't handle > __float80 types with -m32 it seems.
__float80 is normally the same as long double (in terms of representation anyway, whether or not it's a distinct type). On x86, it's only -mlong-double-128 (64-bit Bionic) that means they are different; on IA64 it's HP-UX where they are different. (On x86_64, typically __float80 and __float128 will both have the same size, although different representations.) It looks to me from i386.c like __float80 is just a built-in typedef for long double if long double is XFmode, but __float128 is always distinct (always created with a separate make_node (REAL_TYPE) call) (although for IA64 HP-UX, __float128 looks like it is a typedef - and for IA64 in general, it looks like __float80 is always distinct). I don't know if cleanup in this area is worthwhile at this point - FWIW, draft TS 18661-3, soon to go to PDTS ballot, makes its types such as _Float64x and _Float128 all distinct from each other and from the standard types such as long double. I'd hope that if a type has the same representation as one of the standard types, it could be handled the same in libubsan without needing any special support there (so you'd need new support for __float128, but not for __float80 when that has the same representation as long double) - just as libgcc just needs one set of XFmode functions and one set of TFmode functions even if there are multiple types with those modes. -- Joseph S. Myers jos...@codesourcery.com
