Why is -fstrict-aliasing excluded from function "optimize" attribute?

[Andrew Haley]

On 11/03/2010 08:44 PM, Richard Guenther wrote:
> On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley <aph@redhat.com> wrote:
>> On 11/03/2010 04:49 PM, Bingfeng Mei wrote:
>>> Hello,
>>> I came across an issue with function "optimize" attribute. The code is like:
>>> __attribute__((optimize("-fno-strict-aliasing")))
>>> void foo()
>>> {
>>>    ...
>>> }
>>>
>>> When compiling with -O2, we expect this function is compiled without following
>>> strict aliasing rule, whereas other code does. However, I found this function still
>>> has strict aliasing flag turned on during compilation. After a little investigation,
>>> I found the following lines of code in parse_optimize_options of c-common.c
>>> (4.5, 4.6 is similar)
>>>
>>> ...
>>>   saved_flag_strict_aliasing = flag_strict_aliasing;
>>>
>>>   /* Now parse the options.  */
>>>   decode_options (opt_argc, opt_argv);
>>>
>>>   targetm.override_options_after_change();
>>>
>>>   /* Don't allow changing -fstrict-aliasing.  */
>>>   flag_strict_aliasing = saved_flag_strict_aliasing;
>>> ...
>>>
>>> -fstrict-aliasing is excluded from function specific optimize option. I checked
>>> both internal manual and gcc manual. It seems not to be documented. I wonder
>>> whether there is a good reason for this? If yes, at least we should document it.
>>> BTW, the code certainly works in 4.4.
>>
>> As far as I can tell the problem was that it didn't work.
>>
>> See http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00073.html
> 
> A proper way to implement it nowadays would be to make sure that
> during gimplification we make the alias type in all MEM-REFs
> ref-all if no-strict-aliasing is in effect.  This would of course also require
> to wrap all memory accesses in a MEM_REF tree.

In the meantime, should we not emit a warning?

Andrew.