gcc compiler bug

[Sergei Organov]

Kate Feng <feng1 at bnl.gov> writes:
> 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.

No. This code is not affected as it's insensitive to swapping of 2 last
lines due to the fact that Heap_Block structures never overlap.

-- Sergei.