Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

Steven Johnson sjohnson at sakuraindustries.com
Thu Dec 7 20:35:31 CST 2006


Till Straumann wrote:
> Aaron J. Grier wrote:
>   
>> On Thu, Dec 07, 2006 at 05:13:42PM -0800, Till Straumann wrote:
>>   
>>     
>>> Unless you can 'prove' that RTEMS is in compliance with the standard
>>> (by carefully revising the source) we should build it with
>>> -fno-strict-aliasing.
>>>     
>>>       
>> I'll ask the obvious question: "does RTEMS wish to be C99 compliant?"
>>
>> -std=c89
>> -std=gnu89
>> -std=iso9899:199409
>>
>> take your pick.  (gnu89 is the default for 3.x)
>>
>>   
>>     
> As far as the alias rule goes the standard doesn't seem to matter.
> A few simple examples I just tested indicate that gcc uses the
> strict alias rule no matter what standard you select.
>
>   
In my opinion, a rule would only be specified by the actual standard in 
question.  As far as I can determine, it is not a "rule" in anything 
other than C99. In all other cases, if GCC implements strict aliasing 
optimisations, then it is doing it as an optional optimisation that GCC 
happens to turn on by default at certain optimisation levels.  Which 
means if you don't want the optional optimisation and your code is not 
C99, but C90, there is nothing wrong with specifying 
-fnostrict-aliasing, and that does not make your code any less compliant 
with c89 or gnu89 (the standard rtems is currently built against, as the 
default for 4.x as well as 3.x).  GCC is quite clear on this, it is 
simply an optimisation. C99 may require strict aliasing to be compliant, 
and in that case specifying -fnostrict-aliasing would be making your 
code appear to be C99 when in fact it isn't compliant at all,  but for 
all other C dialects it is just an optimisation option.

My opinion is that GCC is the actual cause of the debate, and that 
unless -std=c99 is specified (or equivalent) then at -O2 and above 
-fstrict-aliasing should not be on by default, and at -std=c99, it 
should be on for all levels of optimisation and should not be able to be 
turned off.  I would guess that it isn't like this because it is too 
restrictive and the counter argument would be "if people don't want the 
optimisation they can turn it off".  So the real question I believe, has 
nothing to do with C99 compliance or not, but rather is this an 
optimisation RTEMS wants or not.  Because as it stands RTEMS being a 
-std=gnu89 compliant program means strict aliasing is NOT part of its 
language standard in any way.

Steven J



More information about the rtems-users mailing list