[Bug middle-end/78174] out of bounds array subscript in rtl.h NOTE_DATA macro

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)

Do you have an explanation of why it's "just incorrect?" or an example where it
results in warning on valid code?

I have found another compiler that issues a warning for the same code.  When
the test case from comment #2 is slightly modified and compiled with IBM XLC++
it produces the warning below.  A translation unit obtained from the emit-rtl.c
file causes tons of such warnings with this compiler.

$ cat u.c && xlC -O2 -xc++ u.c
struct A { int i, j; };
struct B { int i0, j0, i1, j1, i2, j2, i3, j3, i4, j4; };

struct C {
  union {
    struct A a[1];
    struct B b;
  } u;
};

struct D: C { };

extern "C" void* memset (void*, const void*, unsigned long);
void f (struct D *d)
{
  struct A *p = &d->u.a[3];
  memset (p, 0, sizeof *p);
}
"u.c", line 16.25: 1540-2907 (W) The subscript 3 is out of range. The valid
range is 0 to 0.

The IBM compiler also emits code that assumes there are no elements in the
array beyond the first and programs that assume otherwise tend to behave
unexpectedly.  For example, the following function only reads the value
p->u.b.k once and not in every iteration of the loop, computing a different
result than when it's compiled with GCC.

int f (struct D *p)
{
  int n = 0;

  for (int i = 0; i != p->u.b.k - 1; ++i, ++n)
    p->u.a [i + 1].a = 3;

  return n;
}

Since GCC is intended to be compiled by other compilers besides itself it
should be written in portable C++ without relying on its own extensions,
especially those that are undocumented like the one that's the subject of this
bug.

In any event, since you seem to know abvout __builtin_object_size what the rest
of us don't it would be helpful if you could document these restrictions so we
know how use the built-in correctly.  Alternatively, if you write them up
either here or in response to one of the other bugs I and others have opened
for it over the years I'd be happy to update the manual myself.  That said,
without a rationale for these restrictions comments like "it's just wrong,
don't do it" aren't helpful.