GCC 7, aligned_storage and "dereferencing type-punned pointer will break strict-aliasing rules"

Question

A code that I wrote was warning-free in GCC 4.9, GCC 5 and GCC 6. It was also warning-free with some older GCC 7 experimental snapshots (for example 7-20170409). But in the most recent snapshot (including the first RC), it started to produce a warning about aliasing. The code basically boils down to this:

#include <type_traits>

std::aligned_storage<sizeof(int), alignof(int)>::type storage;

int main()
{
    *reinterpret_cast<int*>(&storage) = 42;
}

Compilation with latest GCC 7 RC:

$ g++ -Wall -O2 -c main.cpp
main.cpp: In function 'int main()':
main.cpp:7:34: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
  *reinterpret_cast<int*>(&storage) = 42;

(interesting observation is that the warning is not produced when optimizations are disabled)

Compilation with GCC 6 gives no warnings at all.

Now I'm wondering, the code above definitely HAS type-punning, no question about that, but isn't std::aligned_storage meant to be used that way?

For instance the example code given here generally produces no warning with GCC 7 but only because:

• std::string somehow is not affected,
• std::aligned_storage is accessed with an offset.

By changing std::string into int, removing offset access to std::aligned_storage and removing irrelevant parts you get this:

#include <iostream>
#include <type_traits>
#include <string>

template<class T, std::size_t N>
class static_vector
{
    // properly aligned uninitialized storage for N T's
    typename std::aligned_storage<sizeof(T), alignof(T)>::type data[N];
    std::size_t m_size = 0;

public:

    // Access an object in aligned storage
    const T& operator[](std::size_t pos) const
    {
        return *reinterpret_cast<const T*>(data/*+pos*/); // <- note here, offset access disabled
    }
};

int main()
{
    static_vector<int, 10> v1;
    std::cout << v1[0] << '\n' << v1[1] << '\n';
}

And this produces exactly the same warning:

main.cpp: In instantiation of 'const T& static_vector<T, N>::operator[](std::size_t) const [with T = int; unsigned int N = 10; std::size_t = unsigned int]':
main.cpp:24:22:   required from here
main.cpp:17:16: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
         return *reinterpret_cast<const T*>(data/*+pos*/);
                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So my question is - is this a bug or a feature?

Answer 1

I can't answer whether or not there really is a potential for undefined behavior due to aliasing or if the warning is unwarranted. I find the aliasing topic to be a rather complex minefield.

However, I think that the following variation of your code eliminates the aliasing problem without any overhead (and perhaps is more readable).

#include <iostream>
#include <type_traits>
#include <string>

template<class T, std::size_t N>
class static_vector
{
    // properly aligned uninitialized storage for N T's
    union storage_t_ {
        T item;
        typename std::aligned_storage<sizeof(T), alignof(T)>::type aligned_member;
    };
    storage_t_ data[N];

    std::size_t m_size = 0;

public:

    // Access an object in aligned storage
    const T& operator[](std::size_t pos) const
    {
        return data[0].item;
    }
};

int main()
{
    static_vector<int, 10> v1;
    std::cout << v1[0] << '\n' << v1[1] << '\n';
}

Whether it's acceptable for your situation, I can't be sure.

Answer 2

Your code causes undefined behaviour (although the warning text is a bit tangential to the underlying cause). In C++ the concepts storage and objects are different things. Objects occupy storage; but storage may exist without objects in it.

The aligned_storage mechanism provides storage with no objects in it. You may create objects in it by using placement-new. However your code uses the assignment operator on storage that does not contain any objects. If you consult the definition of the assignment operator you'll find that it has no provision for creating an object; and in fact it only defines what happens when the left-hand side designates an object that already exists.

The code in your main should be:

new(&storage) int(42);

Note that since we are working with a primitive type here, it's not required to do any form of destructor call, and you can call placement-new multiple times on the same space with no issue.

The section [basic.life] of the standard talks about what you can do with storage that doesn't contain objects, and what happens if you use placement-new or destructor calls on objects that do exist within storage.

See also this answer.

---

The code in the cppreference aligned_storage is correct. You provide some incorrect code based on that which you described as "removing irrelevant parts", however you removed a very relevant part which was the call to placement-new to create objects in the storage:

new(data+m_size) T(std::forward<Args>(args)...);

Then it is correct to write return *reinterpret_cast<const T*>(data+pos); when pos is a valid index, and the expression accesses the object created by an earlier placement-new call.