https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91707
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |88443
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The false positive is caused by the usual interaction between the sanitizer and
the checker. The sanitized GIMPLE looks like this:
md_test (unsigned int D, const long int * idims)
{
unsigned char D.2358[0:18446744073709551615];
long int[0:D.2325] * dimsR.1;
unsigned int _3;
void * saved_stack.4_4;
sizetype _38;
sizetype _39;
long int * _46;
<bb 2> [local count: 1073741824]:
saved_stack.4_4 = __builtin_stack_save ();
_3 = D_7(D) + 1;
if (_3 == 0)
goto <bb 3>; [0.00%]
else
goto <bb 5>; [100.00%]
<bb 3> [count: 0]:
__builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, 0);
.UBSAN_NULL (&D.2358, 1B, 8);
MEM[(long int *)&D.2358] = 2; <<< warning
The warning code calls compute_builtin_object_size() to get the size of the
D.2358 array, which in turn obtains its size from DECL_SIZE_UNIT(D.2358), which
is zero in this case, even though its domain is [0, SIZE_MAX]. Maybe
compute_builtin_object_size() could give up on such impossible domains.
Alternatively, a more general solution might be to suppress the middle-end
warnings for code that's preceded by a call to a sanitizer error handler.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
