aliasing again

[Steven Johnson]

Kate Feng wrote:
> I think I am missing something  practical here.
>
> In 4.7.1,  I noticed the code :
> RTEMS_INLINE_ROUTINE void _Heap_Block_remove (
>   Heap_Block *the_block
> )
> {
>   Heap_Block *block = the_block;
>
>   Heap_Block *next = block->next;
>   Heap_Block *prev = block->prev;
>   prev->next = next;
>   next->prev = prev;
> }
>
> What is the effect of this discussion of alias  in
> Heap_Block_remove  ?
>
> I extended the test with gcc-4.1.1 with either
> -fstrict-aliasing or  -fno-strict-aliasing with or
> without  -O -fschedule-insns.  However, I got the
> same result :
>   
Hi Kate,

The results with -fstrict-aliasing and without it are not deterministic, 
meaning it can not be predicted.  Invalid code may still result in a 
valid result (I make no comment on if the code cited here is valid by 
C99 or not).  Worse, code that works fine for years with -fstrict-alias 
may suddenly "break" when you change something seemingly unrelated as 
the compiler finds an previously non-existent opportunity for 
optimisation.  So testing with the options can not tell you if your code 
is correct or not.  Further, the GCC warning is less than helpful, 
because it misses cases of non-conformance, and also reports false 
positives.

For what its worth, I think the fact that so many reasonable thinking 
people, can have such long and tiring debates over this (in my 
opinion)"very controversial" aspect of C99 says it all.

My opinion is that the people that specified Strict Aliasing in C99 were 
not thinking about low level coding issues at all, because they 
eliminate a good programmers ability to write efficient code, while 
providing the C compiler with a dubious opportunity to "maybe" make an 
optimisation.  For example, you can no longer take an address of a 32 
bit quantity as a pointer to 16 bit quantities and then operate on the 2 
halves of the original 32 bit quantity independently "safely".  Typical 
of common practice in systems programming for achieving data processing 
optimisation.  The alternatives are just too painful and before someone 
says "use a union", that is also impermissible under the strict aliasing 
rules, regardless of what GCC might or might not do, even if it is 
permissible it is often torturous and inconvenient, and it may also make 
certain code more obscure.  My suggestion is always build system 
software with -fno-strict-aliasing,  then your code will perform exactly 
as you have written it and it is doubtful the "potential" optimisations 
will make one stick of difference to the quality or speed of the code 
produced by the compiler.  (I am yet to see any benchmarks that show in 
real world cases, the optimisation yields any benefits at all.) 

Regards,
Steven Johnson