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
