Is this an storage-reuse (aliasing) bug in gcc 6.2? - gcc

Question

From what I can tell, the following code should have 100% defined behavior under any reasonable reading of the Standard for platforms which define int64_t, and where long long has the same size and representation, regardless of whether or not long long is recognized as alias-compatible.
#include <stdint.h>
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
typedef long long T1;
typedef int64_t T2;
#define T1FMT "%lld"
#define T1VALUE 1
#define T2VALUE 2
T1 blah3(void *p1, void *p2)
{
T1 *t1p, *t1p2;
T2 *t2p;
T1 temp;
t1p = p1;
t2p = p2;
*t1p = T1VALUE; // Write as T1
*t2p = T2VALUE; // Write as T2
temp = *t2p; // Read as T2
t1p2 = (T1*)t2p; // Visible T2 to T1 pointer conversion
*t1p2 = temp; // Write as T1
return *t1p; // Read as T1
}
T1 test3(void)
{
void *p = malloc(sizeof (T1) + sizeof (T2));
T1 result = blah3(p,p);
free(p);
return result;
}
int main(void)
{
T1 result = test3();
printf("The result is " T1FMT "\n", result);
return 0;
}
See code at https://godbolt.org/g/75oLGx (GCC 6.2 x86-64 using -std=c99 -x c -O2)
Correct code for test3 should allocate some storage, then:
Writes a long long with value 1.
Sets the Effective Type of the storage to int64_t by writing an int64_t with value 2.
Reads the storage as int64_t (its Effective Type), which should yield 2
Sets the effective type of the storage to long long by storing the a long long with the aforementioned value (which should be 2).
Read the storage as type long long, which should yield 2.
The gcc x86-64 6.2 at the godbolt site, however, does not yield 2; instead it yields 1. I didn't find any other combination of types for which gcc behaves
like this. I think what's happening is that gcc is deciding that the store to *t1p2 can be omitted because it has no effect, but it's failing to recognize that the store did have the effect of changing the Effective Type of the storage from int64_t to long long.
While I consider questionable the decision not to recognize int64_t and long long as being alias-compatible, I see nothing in the Standard that would justify gcc's failure to recognize the reuse of the storage to hold the value 2 after it had previously held the value 1. Nothing is ever read as any type other than the one with which it was written, but I think gcc is deciding that the two pointers passed to "blah" can't alias.
Am I missing anything or is that an outright bug?

Answer 1

The code does not violate the strict aliasing rule, as you explain. In fact, T1 and T2 could be any types (such that the assignments are not type mismatches), there's no need for them to have the same size or anything.
I would agree that outputting 1 is a compiler bug. On the godbolt site, all versions of gcc seem to have the bug, whereas clang gives the correct output.
However, with a local installation of gcc 4.9.2 (x86_64-win32-seh-rev1), I get the correct output of 2. So it seems that the problem only exists in some builds of gcc.