[libubsan] Handling of floating-point types

[Alexey Samsonov]

On Fri, May 23, 2014 at 8:10 AM, Kostya Serebryany <kcc at google.com> wrote:

> ... and I had to disable the test for -m32 in r209517
> because there are bots that don't work with -m32:
>
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-centos-6.5/builds/5151/steps/test/logs/stdio
>
>
> On Fri, May 23, 2014 at 6:55 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>>
>> On Thu, May 22, 2014 at 9:39 PM, Marek Polacek <polacek at redhat.com>wrote:
>>
>>> Hi!
>>>
>>> I'm trying to implement -fsanitize=float-cast-overflow support to GCC.
>>> One of the issues is that libubsan doesn't handle 96-bit floating-point
>>> types, so e.g. on
>>>
>>> int
>>> main ()
>>> {
>>>   volatile long double ld = 300.0;
>>>   char c = ld;
>>>   return 0;
>>> }
>>>
>>> with -m32 we hit
>>> ==27463==Sanitizer CHECK failed:
>>> /builddir/build/BUILD/llvm-3.4/projects/compiler-rt/lib/ubsan/ubsan_value.cc:100
>>> ((0 && "unexpected floating point bit width")) != (0) (0, 0)
>>>
>>> The same for __float80 types in -m32 mode (but since clang doesn't
>>> support __float{80,128} types, this is not so relevant for you I guess).
>>> Fix is simple:
>>>
>>> diff --git a/libsanitizer/ubsan/ubsan_value.cc
>>> b/libsanitizer/ubsan/ubsan_value.cc
>>> index 141e8b5..e2f664d 100644
>>> --- a/libsanitizer/ubsan/ubsan_value.cc
>>> +++ b/libsanitizer/ubsan/ubsan_value.cc
>>> @@ -92,6 +92,7 @@ FloatMax Value::getFloatValue() const {
>>>      switch (getType().getFloatBitWidth()) {
>>>      case 64: return *reinterpret_cast<double*>(Val);
>>>      case 80: return *reinterpret_cast<long double*>(Val);
>>> +    case 96: return *reinterpret_cast<long double*>(Val);
>>>      case 128: return *reinterpret_cast<long double*>(Val);
>>>      }
>>>    }
>>>
>>
>>
>>> Could someone please review & commit this one?
>>>
>>
>> Thanks! Committed with a tests and and another related fix:
>> http://llvm.org/viewvc/llvm-project?view=revision&revision=209516
>>
>> Alexey, Nick, do we want to have in ubsan the same lit magic as in asan
>> that runs all the tests in both 32-bit and 64-bit?
>> Currently the ubsan tests seem to be running only in one bit-ness.
>>
>
I think it makes sense to run UBsan test suite in 32-bit mode as well, as
long as we build and provide libclang_rt.ubsan-i386.a
Richard, we claim this configuration as "supported", right?


>
>>
>>>
>>> Another issue is printing of __float128 and _Decimal{32,64,128} types;
>>> libubsan doesn't handle such types, so currently there's no way how
>>> to print them.  Unfortunately, I don't think the solution is as simple
>>> as adding e.g. TK_Decimal/TK_Float_Extended constants, because
>>> libstdc++ I think doesn't have the routines to convert such values to
>>> strings, and adding extra library dependencies to e.g. libdecnumber
>>> doesn't sound viable.  But for these rather obscure types we can use
>>> TK_Unknown - and just print "<unknown>".  I'd guess that DFP types
>>> are rare anyway and I'm fine with keeping it this way.
>>>
>>> Thanks.
>>>
>>>         Marek
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140523/a4371924/attachment.html>