Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Steven Johnson]

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
>
>
>