Why doesn't GCC and Clang do this aliasing-optimization?

Question

I have a case where a friend casts a non-base class object of type "Base" to a class type object "Derived", where "Derived" is a derived class of "Base" and only adds functions, but no data. In the below code, I did add a data member x to the derived class

struct A {
  int a;
};

struct B : A {
  // int x;
  int x;
};

A a;

int g(B *b) {
   a.a = 10;
   b->a++;
   return a.a;
}

With strict alias analysis on, GCC (also Clang) always returns 10, and not 11, because b can never point to a in a well-defined code. However, if I remove B::x (as is actually the case in the code of my friend), GCC's output assembler code does not optimize the return access of a.a and reloads the value from memory. So the code of my friend that calls g "works" on GCC (as he intended) even though I think it still has undefined behavior

g((B*)&a);

So in essentially the same two cases, GCC optimizes one case and doesn't optimize the other case. Is it because b can then legally point to a? Or is it because GCC just wants to not break real-world code?

---

I tested the answer that states

If you remove B::x, then B meets the requirements in 9p7 for a standard-layout class and the access becomes perfectly well-defined because the two types are layout-compatible, 9.2p17.

With two layout compatible enums

enum A : int { X, Y };
enum B : int { Z };

A a;

int g(B *b) {
   a = Y;
   *b = Z;
   return a;
}

The assembler output for g returns 1, not 0, even though A and B are layout compatible (7.2p8).

---

So my further question is (quoting an answer): "two classes with exactly the same layout may be considered "almost the same" and they are left out of the optimization.". Can someone provide a proof of this for GCC or Clang?

Answer 1

If you remove B::x, then B meets the requirements in 9p7 for a standard-layout class and the access becomes perfectly well-defined because the two types are layout-compatible, 9.2p17 and the members both have the same type.

---

A standard-layout class is a class that:

• has no non-static data members of type non-standard-layout class (or array of such types) or reference,
• has no virtual functions (10.3) and no virtual base classes (10.1),
• has the same access control (Clause 11) for all non-static data members,
• has no non-standard-layout base classes,
• either has no non-static data members in the most derived class and at most one base class with non-static data members, or has no base classes with non-static data members, and
• has no base classes of the same type as the first non-static data member.

---

Two standard-layout struct types are layout-compatible if they have the same number of non-static data members and corresponding non-static data members (in declaration order) have layout-compatible types.

Answer 2

Undefined behavior includes case that it does work, even if it shouldn't.

According to standard usage of this union allows to access type and size fields of either header or data members:

union Packet {
   struct Header {
   short type;
   short size;  
   } header;
   struct Data {
   short type;
   short size;  
   unsigned char data[MAX_DATA_SIZE];
   } data;
}

This is strictly limited to unions, but many compilers support that as kind of extension, provided the "incomplete" type would be ended with array of undefined size. If you delete extra static non-member from child class it indeed becomes trivial and layout compatible, which allows aliasing?

struct A {
  int a;
};

struct B  {
  int a;
  //int x;
};

A a;

int g(B *b) {
   a.a = 10;
   b->a++;
   return a.a;
}

Still performs aliasing optimization, though. In your case with same amount of non-static members the most derived class is assumed to be same as the base class. Let's invert the order:

#include <vector>
#include <iostream>

struct A {
  int a;
};

struct B : A  {
  int x;
};

B a;

int g(A *b) {
   a.a = 10;
   b->a++;
   return a.a;
}

int main()
{
    std::cout << g((A*)&a);
}

This returns 11 as expected, as a B is clearly also an A, unlike the original attempt. Let's play further

struct A {
  int a;
};

struct B : A {
    int  foo() { return a;}
};

Would not cause aliasing optimization, unless foo() is virtual. Adding non-static or const member to B would result in "10" answer, adding non-trivial constructor or a static doesn't.

PS. In second example

enum A : int { X, Y };
enum B : int { Z };

Layout compatibleness between those two here is defined by C++14, and they aren't compatible with underlying type (but convertible). although something like

 enum A a = Y;
 enum B b = (B*)a;

may produce undefined behavior, just like if you try to map float with arbitrary 32bit value.

Answer 3

I think your code is UB, as you are dereferencing a pointer that comes from a casting that violates the type aliasing rules.

Now, if you activate the strict aliasing flag, you are allowing the compiler to optimize the code for UB. How to use this UB is up to the compiler. You can see the answers for this question.

Regarding gcc, the documentation for -fstrict-aliasing shows it can optimize based on:

(...) an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same.

I have not been able to find a definition for "almost the same", but two classes with exactly the same layout may be considered "almost the same" and they are left out of the optimization.

Answer 4

I believe the following is legal C++ (without invoking UB):

#include <new>

struct A {
  int a;
};

struct B : A {
  // int x;
};

static A a;

int g(B *b);
int g(B *b) {
   a.a = 10;
   b->a++;
   return a.a;
}

int f();
int f() {
  auto p = new (&a) B{};
  return g(p);
}

because (the global) a always refers to an object of type A (even though it's subobject of a B-object after a call to f()) and p points to an object of type B.

If you mark a to have static storage duration (as I did above), all compilers I've tested will happily apply strict aliasing and optimize to return 10.

On the other hand, if you mark g() with __attribute__((noinline)) or add a function h() that returns a pointer to a

A* h();
A* h() { return &a; }

the compilers I've tested assume that &a and the parameter b can alias and reload the value.