What is the difference between...?

    struct foo
    {
            uint16_t a;
            uint16_t b;
            uint16_t c;
            uint16_t not_used;
    };

and

    union foo
    {
        uint64_t dont_care;
        struct
        {
                uint16_t a;
                uint16_t b;
                uint16_t c;
                uint16_t not_used;
        };
    };

Well yes, 47 characters. But apart from that, what if you e.g. make a std::atomic<foo>?

For a compare-exchange, the difference is around 200 instructions! And no, the union is not the one with more instructions. :)

It is of course well-known that std::atomic doesn't guarantee that just about everything be atomic, in particular it gives no guarantees whatsoever except on atomic_flag. How could one guarantee every possible thing being atomic, anyway -- the hardware doesn't necessarily even support that. OK. Accepted.

But you can somewhat expect that something that easily fits within the instruction set's capabilities (an integer, a struct of two integers, four smaller integers) is "just atomic" anyway. Well, that's not the case.

But what's really stunning is not so much that the compiler fails to emit e.g. a single CMPXCHG8B when it could just do that in the first case. What truly does me is that if you give the compiler a "hint" by aliasing with an uint64_t as in the second case, then all of a sudden, as if by magic, it works...

How did I find out? You don't want to know. :lol:

The first struct has 2 byte alignment so is not compatible with CMPXCHG8B. The second struct is 8 byte aligned. That seems like a sensible, non-magic answer :D

Yes, obviously... except, no. :)

Trying struct alignas(8) foo {...} which should align the struct compatibly to CMPXCHG8B has exactly the same effect. In a union, it works (well it works either way...) but as a sole struct, it calls into library functions.

On 15.6.2017 at 0:55 AM, Hodgman said:

error

That must be the funniest ever error message I've seen in my life. And maybe the longest (standard library template errors with 5,000 lines of "instantiated from", doesn't really count). But you can't say it doesn't tell you exactly what's wrong in the compiler's opinion or what you have to do.

The compiler I used to get the above was GCC 7.1, I didn't bother trying clang... was too frustrating with a single compiler already.