Problem report: Struct aliasing problem causes Thread_Ready_Chain corruption in 220.127.116.11
strauman at slac.stanford.edu
Tue Nov 28 18:03:06 UTC 2006
I vote for 2.
Even if we get the code totally alias clean
one day we'd have to go through this subtle cleanup
procedure again every time something new (a driver, a port, ...)
is contributed. Given that the benefits are (I suspect)
undetectable but subtle problems may be triggered under
rare circumstances I really can't see any advantage
this optimization gives us [OK, some benchmarking
should be done].
Eric Norum wrote:
>> Thomas Doerfler writes:
>>> 1.) In the previous discussion we have at least hit some spots where
>>> people started to think, whether the various RTEMS code packages
>>> with the strict aliasing requirements.
>>> 2.) Peer Stritzinger has started this discussion with his posting,
>>> RTEMS chain code breaks in rare (but legal) cases, when GCC4 is used
>>> with its heavy (and valuable) optimizations.
>>> IMHO we have four possible ways to deal with this:
>>> 1.) We simply ignore the bug report, book the occurrences in Peer's
>>> system to a variant of the Pauli Effect and keep things going as
>>> they are.
>>> 2.) We set "-fno-strict-aliasing" now and forever
>>> 3.) we use "-fno-strict-aliasing" for RTEMS 4.7 and, ASAP we build a
>>> strategy on how to get ALL code aliasing clean.
>>> 4.) We stop cutting 4.7, and build a strategy right now on how to get
>>> the code aliasing clean.
>>> I personally would tend to 3). The disadvantage is, that we loose
>>> performance boost (which we did not have with GCC3), but we will not
>>> delay 4.7 for half a year.
> I vote for 2 or 3 -- in the short term they're the same. I suspect
> that 2 is going to be the final answer, though.
> I expect we're not really losing any performance doing this. I don't
> recall anyone reporting a big speedup going from gcc-3 (which didn't
> have the strict aliasing rules) to gcc-4.
More information about the users