Andrew Haley wrote:
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.
Yep. But even scarier was how hard it was for a user to find the breakage.
It took hours of run-time in a real embedded systems before it showed up.
We have only begin to experiment with -Wstrict-aliasing=2 and I haven't
looked
yet to see if this particular case is caught by the warning code or
not. Personally, I
am really hoping that any problems like this were flagged by that
warning because...
Ralf's initial report says that for x86, he gets about 1/3 of the 900
files he
tested are flagged as having different generated code when compiled with
and
without strict aliasing. This is core operating system, file system,
networking
type code so no heavy duty math loops. Flagging a file doesn't mean it
is broken --
only that the option had an impact and it needs to be looked at more
closely. So
we have some work ahead of us.
At the moment, we decided our only option was to disabled strict-aliasing
on the current release branch and try to methodically review the differences
Ralf's procedure identifies.
Nonetheless, this is a really interesting idea, and I'm sure we'd all
be very interested to see the results.
I think it will be useful to cross-check it against the warnings. I
would hope
that addressing all strict aliasing warnings would be enough to eliminate
breakages BUT who knows.
If someone has ideas on how ot make this review less painful, more accurate
or wants to help review assembly code, please speak up.
Andrew.
--joel
