This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Implement -fsanitize=float-cast-overflow (take 2)

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 

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 

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]