Re: [PATCH 7/7] Libsanitizer merge from upstream r249633.

[Maxim Ostapenko <m dot ostapenko at partner dot samsung dot com>]

On 14/10/15 14:06, Jakub Jelinek wrote:
> On Wed, Oct 14, 2015 at 01:51:44PM +0300, Maxim Ostapenko wrote:
> > Ok, got it. The first solution would require changes in libsanitizer because
> > heuristic doesn't work for GCC, so perhaps new UBSan entry point should go
> > upstream, right? Or this may be implemented as local patch for GCC?
> No.  The heuristics relies on:
> 1) either it is old style float cast overflow without location
> 2) or it is new style float cast with location, but the location must:
>     a) not have NULL filename
>     b) the filename must not be ""
>     c) the filename must not be "\1"
> So, my proposal was to emit in GCC the old style float cast overflow if a), b) or
> c) is true, otherwise the new style.  I have no idea what you mean by
> heuristic doesn't work for GCC after that.

I mean that there are some cases where (FilenameOrTypeDescriptor[0] + 
FilenameOrTypeDescriptor[1] < 2) is not sufficient to determine if we 
should use old style. I actually caught this on float-cast-overflow-10.c 
testcase. Here:

$ /home/max/build/master-ref/gcc/xgcc -B/home/max/build/master-ref/gcc/ 
/home/max/workspace/downloads/svn/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-10.c 
-B/home/max/build/master-ref/x86_64-unknown-linux-gnu/./libsanitizer/ 
-B/home/max/build/master-ref/x86_64-unknown-linux-gnu/./libsanitizer/ubsan/ 
-L/home/max/build/master-ref/x86_64-unknown-linux-gnu/./libsanitizer/ubsan/.libs 
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 
-fsanitize=float-cast-overflow -fsanitize-recover=float-cast-overflow 
-DUSE_INT128 -DUSE_DFP -DBROKEN_DECIMAL_INT128 -lm -o 
./float-cast-overflow-10.s -S

$ cat float-cast-overflow-10.s

cvt_sc_d32:
.LFB0:
        .cfi_startproc
        pushq   %rbx
......
.L6:
        movl    %ebx, %esi
        movl    $.Lubsan_data0, %edi
        call    __ubsan_handle_float_cast_overflow
.......
.Lubsan_data0:
        .quad   .Lubsan_type1
        .quad   .Lubsan_type0
        .align 2
        .type   .Lubsan_type1, @object
        .size   .Lubsan_type1, 17
.Lubsan_type1:
        .value  -1  // <- TypeKind
        .value  32
        .string "'_Decimal32'"
        .align 2
        .type   .Lubsan_type0, @object
        .size   .Lubsan_type0, 18
.Lubsan_type0:
        .value  0 // <- TypeKind
        .value  7
        .string "'signed char'"
        .section        .rodata.cst4,"aM",@progbits,4
        .align 4

Here, one can see, we have FilenameOrTypeDescriptor[0]  == -1 and 
FilenameOrTypeDescriptor[1] == 0. So, we end up with wrong decision and 
have SEGV later.
> > BTW, I actually saw UNKNOWN_LOCATION for this expr:
> >
> > volatile double var;  // this is tcc_decaration, so we have UNKNOWN_LOCATION
> > for it.
> This is not a complete testcase, so I wonder what exactly you are talking
> about.  The above doesn't not generate any
> __ubsan_handle_float_cast_overflow calls with
> -fsanitize=float-cast-overflow, and
> volatile double d;
> int bar (void) { return d; }
> has location.
>
> 	Jakub