gcc compiler -O flags (was Re: gcc compiler bug)

[Kate Feng]

For this particular  case that Till mentioned,  the result is inversed
between -O,  and -O2 (-O4,  too).   I think -fschedule-insns is tuned
on by default for the -O2 and -O4..  It's possible that there is some
sort of optimization logic flow that needs to be followed for this
case.  Some how -fschedule-insns  inverses that schedule flow.
I did not study the gcc compiler enough.  The above statement is
only based on my tests.  Anyway, we can still call it a bug.
I think the price to pay for optimization is the risk. No one pointed
out I have a different gcc4.1.1 from everyone else yet.

Heap_Block_remove is the one case I found for this case.
More findings needs to be explored.
Is there  other case out there besides this one among -O, -O2, and -O4 ?
Perhaps, that needs to be explored as well.  Only some thoughts.

Regards,
Kate

Kate Feng wrote:

> Sergei Organov wrote:
>
> > Steven Johnson <sjohnson at sakuraindustries.com> writes:
> > > 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 :
> > >>
> >
> > [...]
> >
> > > 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 fail to see how your post is relevant.
>
> Yes, it is  not relevant.
>
> > Did you miss the fact that
> > -fno-strict-aliasing *does not help* in the particular case Till has
> > encountered?
>
> I ran some more tests with gcc-4.1.1. It seems to me that
> -fstrict-aliasing "does not help" in the particular case
> either.    Actually  when I tested  with
> -fstrict-aliasing -O and  -fno-strict-aliasing -O,
> both of them produced the same assembly code.
> In fatc, the tests reversed  the situation from
> the previous one that  I posted at the
> http://www.rtems.com/ml/rtems-users/2007/may/msg00197.html.
> Now the result proved that the bug affects the 2nd
> routine instead.   heapfree.c is compiled with -O,
> which means _Heap_Block_remove is affected
> by this compiler bug as well.  One needs to have a closer
> look on this, please.  Oh, well.  Do I have a different
> gcc-4.1.1 compiler from everyone else ?
>
> 00000000 <xtract>:
>    0: 81 63 00 00  lwz     r11,0(r3)
>    4: 81 23 00 04  lwz     r9,4(r3)
>    8: 91 2b 00 04  stw     r9,4(r11)
>    c: 91 69 00 00  stw     r11,0(r9)
>   10: 4e 80 00 20  blr
>
> 00000014 <nodeRemove>:
>   14: 81 63 00 00  lwz     r11,0(r3)
>   18: 81 23 00 04  lwz     r9,4(r3)
>   1c: 91 69 00 00  stw     r11,0(r9)
>   20: 91 2b 00 04  stw     r9,4(r11)
>   24: 4e 80 00 20  blr
>
> Later,
> Kate
>
> >
> >
> > -- Sergei.
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users