Make attribute may_alias official

[Rustam Abdullaev]

The situation with strict aliasing in modern C++ is out of control.

Although I fully understand the reasoning behind strict aliasing rules (basically for performance), I don't understand why there are no fine-tuning knobs around it, for cases when performance actually matters!

Suppose I want to hash a char array (in a platform-dependent way, whatever). Now with standard C++11, it is impossible to alias a properly aligned char array as a series of integers without invoking some form of UB (no, not even via a union). I have to resort to compiler-specific __attribute__((may_alias)) or -fno-strict-aliasing to make it work.

Dear Standard designers, what were you thinking? C++ has always been the tool of choice for programming uncomfortably close to hardware. Now type punning all of a sudden is a bad thing! And the irony of it is - it's bad for performance reasons!

I know my code is implementation-dependent. Don't break it by making ridiculous assumptions about it without giving me a way to turn them off.

[[may_alias]] might just have been sufficient...

[Ville Voutilainen]

Some parts of that seem related to
http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0593r0.html,
but that paper and potential solutions to the problem are at an early stage.

[Nicol Bolas]

On Friday, February 24, 2017 at 4:33:03 PM UTC-5, Rustam Abdullaev wrote:

The situation with strict aliasing in modern C++ is out of control.

Although I fully understand the reasoning behind strict aliasing rules (basically for performance), I don't understand why there are no fine-tuning knobs around it, for cases when performance actually matters!

Suppose I want to hash a char array (in a platform-dependent way, whatever). Now with standard C++11, it is impossible to alias a properly aligned char array as a series of integers without invoking some form of UB (no, not even via a union). I have to resort to compiler-specific __attribute__((may_alias)) or -fno-strict-aliasing to make it work.

That's not UB. The strict aliasing rule allows reading of an object's value representation through a `char*` ([basic.lval]/8.8).

The only thing that's currently UB is doing pointer-arithmetic on it, since there technically isn't an array of `char` there. But that doesn't really have anything to do with aliasing.

Dear Standard designers, what were you thinking? C++ has always been the tool of choice for programming uncomfortably close to hardware. Now type punning all of a sudden is a bad thing!

... all of a sudden? As far as I know, general type punning hasn't been legal behavior in C++ since C++ had an actual standard.
 

[inkwizyt...@gmail.com]

Compiler should be able to ignore attribute and program should still work fine, this attribute do not allow this. Simply without recognizing this attribute compiler will generate wrong code that will cause UB.
I think that good rule of thumbs for attributes is that it could break valid program but not fix bad program (exactly case of [[noreturn]], if ignored program will work fine, but if misused it cause UB).

And do not forget that strict aliasing rules are for performance, thanks to that compiler can reduce numbers of reloads: http://stackoverflow.com/questions/1225741/performance-impact-of-fno-strict-aliasing