This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/86768] gcc wrongly decides that variable is <=1 after "while (x>1 && blah)" construct.


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;

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]