Oppolzer - Informatik / Blog

My opinion, which is somehow different:

it's all about optimization.

If we want the highest possible level of optimization, we must accept some
comfort limitation on the compiler's (and programmer's) side. That's what the
ANSIALIAS option is all about. This option tells the compiler that a pointer of
type unsigned short never points to an object of type unsigned long, so the line
which assigns the value 222 never may have an effect to the variable a. The
compiler may assume this, when the ANSIALIAS option is in effect, and move the
assignment anywhere out of the scope of the actual function to optimize the
overall performance; in this case, the compiler is free to remove it completely,
because this assignment has no effect to any known variable of type unsigned
short. I believe that the compiler has no obligation to do further checks for
the storage areas (if they overlay or not) in this case, although I too would
suggest that it should produce a suitable warning.

If you don't want this behaviour of the compiler, you simply don't use the
ANSIALIAS (or similar) options - which I would do at least sometimes, by the
way, because some of my programs also rely on such storage overlays.

That means of course - and that's one of the things I've learned from this
discussion: we may never test a function using - say - optimize level n and then
move the function into production using optimize level n + 1 - untested!

Kind regards

Bernd




Am 05.01.2014 07:59, schrieb D.T.:
> Bernd Oppolzer wrote:
>
> [...]
>> This is not an error, but correct behaviour,
>> given the meaning of the ANSIALIAS option and
>> the optimization strategy of the compiler.
>> For us human readers it is obvious that the
>> third line relates to the variable a;
>> for the compiler it is not.
> I strongly and respectfully disagree.
>
> It is extremely trivial for the compiler to determine the area of storage
> the two pointers point to overlap one another and therefore it should by
> definition be obvious to the compiler that the third line relates to the
> variable and thus should not engage in the incorrect behavior it is
> demonstrably engaging in.
>
> This is incorrect compiler optimization behavior, plain and simple.
>