https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82655
Bug ID: 82655
Summary: missing -Walloc-size-larget-than with
-fcheck-pointer-bounds
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Without the -fcheck-pointer-bounds and -mmpx options, GCC issues a
-Walloc-size-larger-than warning for the following test case as expected. But
with the two options it fails to do the same.
$ cat y.c && gcc -O2 -S -Wall -Walloc-size-larger-than=1023
-fcheck-pointer-bounds -mmpx y.c
void* f (void *p, unsigned n)
{
if (n < 1024)
n = 1024;
return __builtin_realloc (p, n);
}
The expected output is:
y.c:6:10: warning: argument 2 range [1024, 4294967295] exceeds maximum object
size 1023 [-Walloc-size-larger-than=]
return __builtin_realloc (p, n);
^~~~~~~~~~~~~~~~~~~~~~~~
y.c:6:10: note: in a call to built-in allocation function ‘__builtin_realloc’
The problem is that that the maybe_warn_alloc_args_overflow() function in
calls.c fails to take into the account the difference between __builtin_realloc
signature when compiled with the option and without. When
-fcheck-pointer-bounds is used, __builtin_realloc is declared like so:
__builtin_realloc (void *ptr, bitsizetype ptrbounds, size_t n)
with bitsizetype being a 128 bit type. Ptrbounds is then (mistakenly) used in
get_size_range() called from maybe_warn_alloc_args_overflow() to try to
determine the range of the size of the allocation, which fails.
It seems to me that having -fcheck-pointer-bounds change the signature of
standard builtins wasn't the best idea, especially not changing the types of
existing arguments. If the new arguments had instead been added after the
existing arguments this kind of mixup would not have been possible.
