I think of adding a warning too. Should I submit a patch?
Bingfeng
> -----Original Message-----
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Andrew Haley
> Sent: 04 November 2010 08:31
> To: Richard Guenther
> Cc: gcc@gcc.gnu.org
> Subject: Re: Why is -fstrict-aliasing excluded from function "optimize"
> attribute?
>
> 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.