Re: Using may_alias

[Ian Lance Taylor <iant at google dot com>]

Jason Sewall <jasonsewall@gmail.com> writes:

> I've heard of the __may_alias__ attribute in gcc and I thought that I
> could clue the compiler in by replacing the as_vec2 function with:
>
> vec<2> &__attribute__((__may_alias__)) as_vec2(vec<3> &__attribute__
> ((__may_alias__))v3)
> {
>     typedef vec<2>*__attribute__((__may_alias__)) ret_t;
>     return *reinterpret_cast<ret_t>(&v3);
> }

You can't use may_alias that way.  You can apply may_alias to a
variable, typically via the type of the variable, and it will affect
uses of the variable.  Using may_alias in a type cast won't do
anything.

> I'm also kind of curious what flag actually causes this warning to
> appear, since -O1 -Wall with all of the additional options shown for
> -O2 in the gcc info page doesn't trigger it. I suspect that my info
> page doesn't reflect what -O2 really means to the compiler.

It should be controlled by -fstrict-aliasing.

> As a matter of fact, I seem to recall that there's a command to have
> gcc tell you about what the various optimization levels to from the
> command line, but I can't seem to figure out how to get it.

In general the -O options are not equivalent to any set of -f options.
Some operations are controlled simply by the -O level.

> Any thoughts on how to tell the compiler that this function's return
> value aliases its input? Any ideas what's going on with the compiler
> args?

If you need to write your code this way for some reason, then you need
to use -fno-strict-aliasing.

Ian