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

Reply via email to