gcc optimization bug or C++ rule broken?

Question

Here's the test code:

#include <stdio.h>

struct test
{
   int m[1];
};

struct test2: public test
{
   int m1[22];
   void set(int x, int y) { m[x] = y; }
};

int main()
{
    test2 t;
    t.m[1] = 123;
    t.set(0, 0);
    t.set(1, 1);
    printf("%d %d\n", t.m[0], t.m[1]);
    return 0;
}

I compile it once without and once with optimization:

$ g++ -O0 testf.cpp 
$ ./a.out 
0 1
$ g++ -O2 testf.cpp 
$ ./a.out 
1 123

It seems to me that gcc sees array size m[1] and optimizes access to it to be always to the first element m[0]. The question is: is it optimization bug or, some C++ rule is broken so that gcc can do what it does, and if so then what rule?

Note that no memory/stack overrun takes place because of extra m1[22] memory (which was by design in the real app). I don't ask if that's a good programming style, I'm just curious to get the correct answer to the question above.

UPDATE: I accepted the answer with std details, but the biggest help was the comment with the following link: Is the "struct hack" technically undefined behavior?

Answer 1

Your program has undefined behavior. Here:

t.m[1] = 123;

You are writing to an out-of-bounds location (m is an array of one element, and you are indexing a non-existing second element), and the same is true for:

t.set(1, 1);

Since it basically ends up doing:

m[1] = 1;

You cannot expect anything from a program with undefined behavior - especially not a consistent behavior.

Answer 2

Here's the relevant rule, from 5.7:

When an expression that has integral type is added to or subtracted from a pointer, the result has the type of the pointer operand... If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined.

Recall that t.m[i] is equivalent to *(t.m+i) and therefore the pointer addition rules come into play.

Clearly the pointer operand t.m and the result (t.m + 1) do not point to members of the same array object. However, in this case the result is "one past the last element of the array object". So the pointer is valid, but cannot be dereferenced under strict pointer safety rules. Since you are attempting to dereference it, you are back to undefined behavior.

Note that there is no guarantee that t.m + 1 == t.m1, since the compiler is permitted to insert padding between base subobjects and members.

Note also that the compiler WOULD BE required to generate memory access to the correct location for the expression reinterpret_cast<int*>(reinterpret_cast<intptr_t>(t.m) + i * sizeof (int)), unless it defines __STDCPP_STRICT_POINTER_SAFETY__. But it's not specified how that will overlap with the m1 array. And you could be overwriting some sort of magic metadata written there by the compiler (more likely with polymorphic types, of course).