[Bug c/99159] New: Confusing -Warray-bounds warning

[Bug c/99159] New: Confusing -Warray-bounds warning

[sirl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99159

            Bug ID: 99159
           Summary: Confusing -Warray-bounds warning
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

Hi,

with this minimized testcase, compiled with -O2 -Warray-bounds:

struct s1
{
  char b[12];
};

struct s2
{
  int x;
  struct s1 y;
} *pb, c;

extern struct s2 *es;

void test1 (int f)
{
  struct s2 *p = f ? 0 : es;
  __builtin_memcpy (&pb->y, p->y.b, sizeof(struct s1));
}

void test2 ()
{
  struct s2 *p = 0;
  __builtin_memcpy (&pb->y, p->y.b, sizeof(struct s1));
}

trunk@r11-7270 warns like this:
testcase.c: In function 'test2':
testcase.c:23:3: warning: '__builtin_memcpy' offset [0, 11] is out of the
bounds [0, 0] [-Warray-bounds=]
   23 |   __builtin_memcpy (&pb->y, p->y.b, sizeof(struct s1));
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I believe -Warray-bounds shouldn't warn here (or at least not with this
message) and gcc-10.2 and also trunk@r11-3693 don't.
Note that the real code is more like test1(), where it's not clear that 'p' is
always zero.

[Bug tree-optimization/99159] Confusing -Warray-bounds warning

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99159

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |tree-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think the warning is correct or rather there should be a warning as it might
be null but just worded incorrectly.

[Bug tree-optimization/99159] missing -Wnonull on member access through null

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99159

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
                 CC|                            |msebor at gcc dot gnu.org
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2021-02-19
            Summary|Confusing -Warray-bounds    |missing -Wnonull on member
                   |warning                     |access through null
     Ever confirmed|0                           |1
             Blocks|                            |95507

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
To expand on what Andrew said in comment #1: The code in test2() is undefined
because it dereferences a null pointer.  It's diagnosed by -Warray-bounds and
(with it disabled) by -Wstringop-overread, both of which expect objects to be
allocated at valid addresses.

-Wnonnull would arguably be a better warning to issue for this case but it
doesn't have the same logic as the other two.  In addition, and by the time
-Wnonnull runs, the null pointer has already been replaced by the non-null
address of the member:

void test2 ()
{
  struct s2 * p;
  struct s2 * pb.0_2;
  struct s1 * _3;

  <bb 2> :
  pb.0_2 = pb;
  _3 = &pb.0_2->y;
  __builtin_memcpy (_3, 4B, 12);
  return;
}

Issuing -Wnonull here would mean either running the warning earlier (which runs
the risk of issuing more false positives) or also assuming that objects don't
live at constant addresses.

The code test1() is "conditionally undefined" (it's defined when f is zero) and
isn't diagnosed only because -Wnonnull doesn't handle conditionals (PHI nodes).
 A simple test case that shows the limitation is:

void f (void)
{ 
  char *q = 0;
  __builtin_puts (q);   // -Wnonnull
}

void g (char *p)
{
  char *q = *p ? p : 0;
  __builtin_puts (q);   // -Wnonnull
}

I can confirm this as an enhancement request for -Wnonull to diagnose both
problem(s).  That should automatically disable any subsequent warnings for the
same bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
[Bug 95507] [meta-bug] bogus/missing -Wnonnull