This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Implement -fsanitize=float-cast-overflow (take 2)
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 21 May 2014 17:49:56 +0000
- Subject: Re: [PATCH] Implement -fsanitize=float-cast-overflow (take 2)
- Authentication-results: sourceware.org; auth=none
- References: <20140513170801 dot GG2663 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1405131745570 dot 23277 at digraph dot polyomino dot org dot uk> <20140514113839 dot GE10386 at tucnak dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1405141727440 dot 16785 at digraph dot polyomino dot org dot uk> <20140515190929 dot GQ10386 at tucnak dot redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1405152124440 dot 911 at digraph dot polyomino dot org dot uk> <20140516073654 dot GS10386 at tucnak dot redhat dot com> <20140520203343 dot GF4561 at redhat dot com> <Pine dot LNX dot 4 dot 64 dot 1405202147260 dot 5599 at digraph dot polyomino dot org dot uk> <20140521125100 dot GB5135 at redhat dot com>
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
joseph@codesourcery.com