Joel Sherrill writes: > Silvius Rus wrote: > > > > I wrote some code (not released yet) that improves the accuracy of > > -Wstrict-aliasing using tree-ssa-alias information. The primary idea > > was to tell the programmer "go fix the types of variables x and y at > > lines ..." when -fstrict-aliasing breaks their code. > > > > It occurred to me that part of this code could be used as a > > preconditioner to aggressive optimization that would normally require > > -fstrict-aliasing, so this more aggressive optimization can then be > > performed selectively on individual functions even with > > -fno-strict-aliasing on the command line. I fear a little though that > > the functions which are provably free of cross-type aliasing might > > also not benefit much from -fstrict-aliasing, but I have very little > > experience with C compilers and GCC. Is this something worth pursuing? > > > How reliable is this detection and warning? Is it ready for testers yet? > > I ask because we have found a case where code in RTEMS breaks when > strict-aliasing is enabled. We are having discussions on how to > effectively perform an audit on RTEMS for other breakages. Right > now, the best idea is Ralf's to diff the assembly generated for > each file compiled with and without strict-aliasing. If there is a > difference, we will have to review it. This eliminates a lot of > the code base but it is still generating a lot of cases to examine > by hand.
Ewww, that's scary. All it tells you is which code breaks today; even a minor bug fix in gcc might make a difference. Nonetheless, this is a really interesting idea, and I'm sure we'd all be very interested to see the results. Andrew.
