https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86768
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
CC| |msebor at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can confirm the warning with GCC 8.2 and -O2 -m32 and the smaller test case
below. GCC 9.0 currently doesn't trigger it due to bug 86631 (it does with
-Walloc-size-larger-than=2GB).
$ cat pr86768.c && gcc -O2 -Wall -S -m32 -fdump-tree-vrp2=/dev/stdout pr86768.c
| grep malloc
int f (int);
void* g (int i)
{
for ( ; i > 1 && f (i); --i)
if (f (i) == 7)
return 0;
unsigned n = i - 2;
unsigned *p = __builtin_malloc (n * sizeof *p);
for (unsigned i = 0; i < n; ++i)
p[i] = i;
return p;
}
p_21 = __builtin_malloc (_4);
p_65 = __builtin_malloc (4294967292);
pr86768.c: In function ‘g’:
pr86768.c:10:17: warning: argument 1 value ‘4294967292’ exceeds maximum object
size 2147483647 [-Walloc-size-larger-than=]
unsigned *p = __builtin_malloc (n * sizeof *p);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pr86768.c:10:17: note: in a call to built-in allocation function
‘__builtin_malloc’
But I think the warning is actually justified in this case. Calling
g(1073741825, ...), for example, and the right argv (or the right definition of
f() in the smaller test case above) will set n = 1073741823 and end up calling
malloc (1073741823 * 4) or 4294967292.
To avoid the possibility of calling malloc() with an excessive argument
constrain argc value before computing nr_B2 (ot i and n in the small test
case), e.g., like so:
if (argc < 3 || __PTRDIFF_MAX__ / 4 < argc)
return 1;
