Created attachment 48818 [details] test case The attached code uses a scalar_storage_order to access a byte field in big endian. On an x86-64 Windows system, the output without optimization, as expected, is "aabbccdd 1122". The output with optimization (Og) is "ddccbbaa 2211". The same happens on the https://gcc.godbolt.org/ site. With O0 a bswap can be found, but it is gone in -O1 and -Og. I was unable to find the responsible option by bisection on the godbolt instance, but that could just be a godbolt thing.
I think Eric posted patches for this?
See the manual: Moreover, the use of type punning or aliasing to toggle the storage order is not supported; that is to say, a given scalar object cannot be accessed through distinct types that assign a different storage order to it.
So AFAIU int main(int argc, char *argv[]) { uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 }; SS instance; memcpy (&instance, raw, sizeof (SS)); printf("%x, %x\n", instance.a, instance.b); return 0; } would be OK(?)
> So AFAIU > > int main(int argc, char *argv[]) { > uint8_t raw[] = { 0xaa, 0xbb, 0xcc, 0xdd, 0x11, 0x22 }; > SS instance; > memcpy (&instance, raw, sizeof (SS)); > printf("%x, %x\n", instance.a, instance.b); > return 0; > } > > would be OK(?) Yes, this should work once the patch (or a variant thereof) I posted some time ago to make memcpy a storage order barrier is installed. :-)