[Bug lto/114713] New: incorrect TBAA for struct with flexible array member or GNU zero size

[Bug lto/114713] New: incorrect TBAA for struct with flexible array member or GNU zero size

[muecker at gwdg dot de]

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

            Bug ID: 114713
           Summary: incorrect TBAA for struct with flexible array member
                    or GNU zero size
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: muecker at gwdg dot de
  Target Milestone: ---

If one mixes a struct with FAM and one with zero size at the end, then TBAA
considers them incompatible for aliasing purposes when using LTO. One could
decide that those are incompatible types, but this would break code that mixes
both, e.g. during a transition time to standard FAMs. Also affects old versions
of GCC.

https://godbolt.org/z/xodMK9sqE


struct foo { int x; char a[]; };

void test_bar(void* b);

__attribute__((noinline))
int test_foo(struct foo* a, void* b)
{
        a->x = 1;
        test_bar(b);
        return a->x;
}

int main()
{
        struct foo y;

        if (2 != test_foo(&y, &y))
                __builtin_abort();

        return 0;
}

// TU2
struct foo { int x; char a[0]; };

void test_bar(void* b)
{
        struct foo *p = b;
        p->x = 2;
}

[Bug lto/114713] incorrect TBAA for struct with flexible array member or GNU zero size

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |14.0
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
[] and [0] are not the same.  Note the C and C++ frontends encode [0] (or did
encode) differently.

See tree.cc:gimple_canonical_types_compatible_p

I agree that from a QOI perspective [] and [0] should be compatible.

Note [0] can have many "equivalent" domains, [3:2], [0:-1], [1:0], etc.
but the current code has

      /* Array types are the same if the element types are the same and
         the number of elements are the same.  */
...
              /* The minimum/maximum values have to be the same.  */
              if ((min1 == min2
                   || (min1 && min2

which is somewhat contradicting comments.

See also layout_type which says, when computing TYPE_SIZE of an array:

            /* ??? We have no way to distinguish a null-sized array from an
               array spanning the whole sizetype range, so we arbitrarily
               decide that [0, -1] is the only valid representation.  */
            if (integer_zerop (length)
                && TREE_OVERFLOW (length)
                && integer_zerop (lb))
              length = size_zero_node;

revealing that the constraints on TYPE_DOMAIN are not very well specified.

[Bug lto/114713] incorrect TBAA for struct with flexible array member or GNU zero size

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Also note that people might find it reasonable to access

struct { int n; int a[4]; } a = { 4, };

via

struct X { int n; int a[] } *p;

The fortran frontend goes some lengths to make this work for array
descriptors statically allocated by accessing the storage always
via the type with the flexible array member.  But that also relies
on GCC middle-end semantics, accessing an automatic variable with
a declared type via a not compatible type, thus changing its effective type.

The only valid C way is to resort to dynamic (stack) allocation.