On 25/08/2023 23:01, Lénárd Szolnoki via Std-Proposals wrote:
> On Fri, 2023-08-25 at 16:24 -0400, Brian Bi via Std-Proposals wrote:

>>
>> As for (2) and (3), I personally think that there is value in
>> providing a way to opt out of certain forms of UB that have no
>> purpose other than to let the optimizer make extra assumptions, but
>> it is not clear whether the idea of controlling it on a per-function
>> basis is coherent. GCC has -fno-strict-aliasing, which you can
>> control only per translation, not per function;
>
> GCC does have a per-function fine-grained optimisation attribute. In
> theory it could accept "no-strict-aliasing" too, but I don't know if
> it's actually supported. However the docs say that "the optimize
> attribute should be used for debugging purposes only. It is not
> suitable in production code."
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
>

gcc is quite happy with

  __attribute__((optimize("-fno-strict-aliasing")))

and generates code just as you would expect.

<https://godbolt.org/z/n6Yb8sGfj>


The note about "not suitable in production code" is because not all
optimisation options work as expected, and which options work can change
without warning between different versions of gcc - it is not a
guaranteed stable feature. There are also issues with inlining -
typically, a change to the optimisation flags disables inlining for a
function (unless the calling function shares the same flags). This can
be surprising, and contrary to the programmer's aims in fine-tuning
optimisation flags in the first place.