RTEMS and C99: was Re: Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 18.104.22.168
sjohnson at sakuraindustries.com
Thu Dec 7 17:35:49 CST 2006
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
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
More information about the rtems-users