[libubsan] Handling of floating-point types

[Kostya Serebryany]

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.


>
> 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/b8084302/attachment.html>