4 ms·
> if you just wrote a double to a union member, you can’t expect that reading integer from the same union has any meaning at all so they optimized that away “pe
by boomlinde 8y ago
> if you just wrote a double to a union member, you can’t expect that reading integer from the same union has any meaning at all so they optimized that away “per standard”.
gcc 4.9.2 for sure does not (-O3 -fstrict-aliasing). Not sure what clang does, but I'd be surprised if it ignores the standard. The standard makes it pretty clear what meaning it will have. Sure, gcc and clang maintainers may seem to read the standards like a lawyer looking to void a contract, but in this case it is actually very clear what they should do.
> what is not said that it “must work” in spite of other “must work” and “undefined” standard statements.
The standard makes it clear how to deal with the semantics: "In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object)." Only constraints directly use "shall"/"shall not" type language, but the expressions should still be evaluated as specified by the semantics.
- acqq 8y agoGoogling I've found for example this: “GNU extensions to standard C++ (and to C90) do explicitly allow type-punning with unions. Other compilers that don't support GNU extensions may also support union type-punning, but it's not part of the base language standard.” Also, apparently in C99 one relevant statement was: “The value of a union member other than the last one stored into [is unspecified]” https://stackoverflow.com/questions/25664848/unions-and-type-punning https://stackoverflow.com/questions/25664848/unions-and-type... Note: In case it's not obvious, I, personally, believe that, at least, using unions for type-punning has to exist and should be explicitly supported in the standards too. And that the compiler contributors should not produce practically unusable results even when some standard is wrong (for common use) or unclear. But the quotes like the above give a hint on which basis some try to cling to bad approaches in this special case. In other cases it's probably even harder to avoid unwanted results.