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.
I'm curious if your patch will ease this process.
Thank you,
Silvius
--joel sherrill