This is the mail archive of the gcc-patches@gcc.gnu.org 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, May 21, 2014 at 02:51:00PM +0200, 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.
> Common macros moved to float-cast.h.

Clearly libubsan doesn't support _Decimal* either, so I guess for now
we should just avoid emitting any __ubsan_* diagnostics for any of the
__float{80,128} or _Decimal{32,64,128} types for now, and work with upstream
to add support for that (given the problematic design where a type
is identified only by kind and bitsize, I guess for _Decimal* we need to use
a different (new) kind, not sure what can be done about __float{80,128},
as libubsan treats both bitsize 80 and 128 as long double.

Note that libstdc++ doesn't support conversion of _Decimal{32,64,128}
nor std::decimal::decimal{32,64,128} to strings, and not sure if libubsan
would like to be linked against something that rarely used as libdecnumber.
So, I guess at least for now, we should have a way to tell libubsan
about those types (both decimal and __float{80,128}, but if libubsan
can't easily print those values into strings, it should just print
<unprintable value> or something similar for now.

> Yes.  I suspect adding support for _Decimal* shouldn't be hard,
> what's needed is to find the place where the conversion from _Decimal
> to integer is taking place and add similar code as is in convert.c.
> Jakub says he's writing another testcase that tests various type
> combination conversions and max/min values - so we'll get even more
> coverage.

Here is a testcase that (IMHO, not tested with your patch) should
test various boundary cases that shouldn't result in undefined behavior.
I've tried to keep it portable across various architectures, assumes
primarily two's complement and (likely) only supports binary and decimal
floating point formats.
Seems _Decimal{32,64,128} is not convertible
to/from int128 right now, so that is disabled in the test for now.

	Jakub

Attachment: float-cast-overflow-3.c
Description: Text document


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