Jason Sewall <jasonsewall@xxxxxxxxx> 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
