RTEMS and C99: was Re: Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 4.6.99.3

[Steven Johnson]

Till Straumann wrote:
> Ralf Corsepius wrote:
>   
>> On Thu, 2006-12-07 at 09:47 +0100, Wolfram Wadepohl wrote:
>>   
>>     
>>> Till Straumann schrieb:
>>>
>>>     
>>>       
>>>> 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.
>>>>         
Is RTEMS coded to be C99 compliant?

Is this the desired direction of RTEMS?

I added the following to my build of RTEMS:
-fstrict-aliasing -Wstrict-aliasing=2 -O2 -std=c99 -pedantic

And I got many many warnings/errors,  I am not going to repeat them here 
and I didn't give them a great deal of analysis, it may just be the way 
my build is set up. Would anyone with a standard RTEMS build setup be 
able to test this?  My build setup is far from standard and so hardly 
authoritative on the issue of C99 compliance, but I didn't detect 
anything overtly caused by the way my system is set up.

I would think, before a general wholesale clean up of -fstrict-alias 
issues is performed or contemplated, wouldn't the first step be to see 
how C99 compliant the overall RTEMS tree is anyway.  To me it looked 
like there was a lot of work to get it into a fully compliant C99 state 
(strict aliasing issues aside).

I am not saying that C99 compliance isn't valuable, but I would hate to 
see a general clean up of the code to meet C99 delay any possible 
release of 4.7.

As has been pointed out in other emails, there are potentially thousands 
of places effected (with unknown consequences) by -fstrict-aliasing, 
that is going to take a large amount of time to check before anyone can 
say "yep no problems here" and the issue is going to be different from 
platform to platform.

My vote, for what it is worth, is:
1. Go with -fno-strict-aliasing for 4.7, so the release isn't delayed 
and what is now known to work, keeps working. (I have no problems with 
introducing any fixes for known strict aliasing issues, my concern is 
potential unknown strict aliasing issues that may be lurking there).
2. If C99 Compliance is what is desired, add the above line to the post 
4.7 tree, and start fixing the build errors (if any) so that the next 
version is C99 compliant, and this would also give time for any (if not 
all) latent strict aliasing issues to surface during testing, and the 
magnitude of the problem can properly be evaluated.

If full C99 compliance isn't required then I think the whole "strict 
aliasing is C99 so it must be supported" argument is a tad of an over 
statement as that is only one aspect of C99 and there are many others 
that may affect the state of the current code.   Why is strict aliasing 
more important from C99 than any other part of that specification that 
RTEMS may not conform to at the current time, which would include using 
ANY GCC extensions?  (again, I cant point to a specific instance except 
to say that building with the above options produces tons of 
warning/errors for me).  The world is full of non C99 code (newlib and 
the linux kernel, for example) any move to make GCC not build non C99 
compliant code would be met, i would guess, with a huge volume of 
resistance.

My only concern with C99 compliance is that even GCC isn't 100% C99.  
Many other compilers are even less C99 than GCC achieving full C99 
compliance may actually preclude someone from using a compiler other 
than GCC (if anyone actually does that I don't know).

My biggest fear with all of this, is that everyone seems to agree that 
strict aliasing "might" be a problem.  No one can state for a certainty 
that it is either a definite problem or not (except for the 1 case which 
triggered this discussion).  I don't like "might be" problems in 
production code, especially for hardware products that are supposed to 
run 24/7/365.

Steven J