Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Till Straumann]

I agree with Linus' sentiment, too. The problem, however,
is (repeating mantra) that this is not just some weirdo
gcc optimization that can be switched off. It is the C99 *standard*.
Even if you can switch this off for gcc today, there is no
guarantee that you will be able to in the future or on other
compilers. If we want to produce C99 compliant code then
we must comply with the alias rule. period.

-- Till

Steven Johnson wrote:
> Hi All,
>
> I have been quietly following this thread, but I find the whole 
> -fstrict-aliasing/-fnostrict-aliasing issue to be very disturbing.  
> Luckily my program isn't built with -O2 or I probably would have been 
> tracking untold numbers of strange bugs in known working code.  For 
> the C language to change so that a pointer (regardless of the pointer 
> type used to reference that memory) no longer points to a known piece 
> of memory, in a predictable way is whacked.
>
> I for one do not look forward to adding __attribute__ ((may_alias)) to 
> the hundreds of places where I change the way I address memory using 
> pointers.  It is a monumental waste of time, prone to error and in my 
> opinion putting in declarations to fix a broken compiler 
> optimisation.  When a compiler optimisation breaks a fundamental 
> aspect of C that has existed since the beginnings of the language, 
> then I consider that optimisation to be broken, and not the code 
> itself.  I will be adding -fno-strict-aliasing to all of my builds in 
> future, and I will be making sure RTEMS (and all of the other Open 
> Source libraries I use) builds with -fno-strict-aliasing, regardless 
> of what is ultimately decided here),  I just don't want the headache.  
> In my opinion you wouldn't be fixing RTEMS by adding these 
> declarations or changing the code, you would be working around a 
> broken compiler.  The other OS's that use -fno-strict-aliasing are (in 
> my opinion) doing the right thing.  I also fail to see how the option 
> could yield any tangible benefits on performance that would warrant 
> the pain and difficulty it causes.
>
> But that is my 2c.
>
> Linus Torvalds when discussing this issue regarding the Linux Kernel 
> said:
>> Why do you think the kernel uses "-fno-strict-aliasing"?
>>
>> The gcc people are more interested in trying to find out what can be
>> allowed by the c99 specs than about making things actually _work_. The
>> aliasing code in particular is not even worth enabling, it's just not
>> possible to sanely tell gcc when some things can alias.
> I am not suggesting Linux is the authority on this sort of thing or 
> that his arguments/views are necessarily valid in this context (he 
> gets it wrong on average about as much as everyone else does), I do 
> however agree with his sentiment here.
>
> The full post is at: http://lkml.org/lkml/2003/2/26/158
>
>
> Steven J
>
> Till Straumann wrote:
>> Just for the record:
>>
>> The RPC/XDR facility violates the alias rules
>> (I don't think current gcc exploits it, though).
>>
>> This is a bit more complex because it involves
>> the XDR library [which dereferences a non-compliant
>> alias] and the 'rpcgen' ('host-tool') program that
>> generates non-compliant source code.
>>
>> Just to illustrate that IMHO a *lot* of code is affected
>> in obscure ways.
>>
>> -- Till
>>
>> Ralf Corsepius wrote:
>>  
>>> On Wed, 2006-12-06 at 11:17 -0600, Joel Sherrill wrote:
>>>      
>>>> Peer Stritzinger wrote:
>>>>           
>>>      
>>>> And most importantly, does it fix your known miscompilation?
>>>>           
>>> ... and even more importantly: Would you guys please check if current
>>> rtems-4-7-branch and/or rtems-HEAD still exposes Peer's/Thomas's issue.
>>>
>>> I believe to have hacked around it for all targets.
>>>
>>> Ralf
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>   
>