On 11/03/2010 08:44 PM, Richard Guenther wrote:
> On Wed, Nov 3, 2010 at 6:12 PM, Andrew Haley <a...@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.
