aliasing again

[Kate Feng]

See below :

Steven Johnson wrote:

> 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

What you explained above  is what I understood and agreeed upon by
following the RTEMS list on the aliasing thread.
I was  a little bit confused with the original message :
http://www.rtems.com/ml/rtems-users/2007/may/msg00153.html

Till Straumann wrote about the "gcc compiler bug (sparc, ppc) " :
>The bug is apparently triggered by -fschedule-insns; if I turn
> on all other optimizations (including -fstrict-aliasing) correct
> code is generated.

I think he meant the "correct code" is the  expected  Assembly
code which has the same order as that was written in C.  However,
I could not reproduce the "expected correct code" based on what
he described so far.  Is your  gcc compiler 3.2.3 and above ?
Could you reproduce the "expected correct code"  by
using  -fstrict-aliasing ?  The following  sounds vague :

Till Straumann wrote :
> if I turn on all other optimizations (including -fstrict-aliasing)

What was all other  optimizations ?  Only  -O -fschedule-insns
or more  others which was not mentioned ?

Thanks,
Kate


> 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