Joe Buck wrote:
If you first prove that there is no cross-type aliasing, then turn on
-fstrict-aliasing, it seems to me that your alias sets won't change at
all. The reason is that if there is a change, it means that you
eliminated an aliasing possibility based on the fact that it's not
allowed because of cross-type aliasing, which you said you proved there
is none of.
There have been concerns expressed in the past that if gcc checks for
strict aliasing violations, users will be upset when it misses some
violations but does optimization that breaks an ill-formed program.
I personally am not that worried about that; I think that it will help
train users if they see warning messages about blatant violations, to
the point where they will be less likely to create subtle, hard-to-detect
violations.
Yes, using the alias information produced by a complex algorithm may
lead to errors as false negatives might sneak in. That is OK when
warning programmers, but will probably not be accepted as a
preconditioner. I was thinking more of a simplified check. For
instance, the most conservative and simplest would be verifying that
there are no conversions to pointers to different types. That will
produce many false positives, but no false negatives. However, if I
understood you well, in such cases the complex algorithm will end up
with the same alias sets with or without -fstrict-aliasing, so my
conclusion is that it is probably not worth doing it.
Thank you,
Silvius
