Sergei Organov wrote:
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
Sergei Organov <[EMAIL PROTECTED]> writes:
Below are two example functions foo() and boo(), that I think both are
valid from the POV of strict aliasing rules. GCC 4.2 either warns about
both (with -Wstrict-aliasing=2) or doesn't warn about any (with
-Wstrict-aliasing), and generates the assembly as if the functions don't
violate the rules, i.e, both functions return 10.
-Wstrict-aliasing=2 is documented to return false positives. Actually
both current versions of -Wstrict-aliasing are pretty bad.
Well, they are indeed bad, but on the other hand I fail to see how to
make them pretty without analyzing the entire source of a program, and
even then the "effective type of an object" could change at run-time :(
Overall, I tend to refrain from blaming gcc too much for weakness of
these warnings.
The current implementation of -Wstrict-aliasing runs in the C front end
and looks at a single expression at once. Although I think it does OK
given the limited scope, it has several drawbacks.
First, it produces false positives, i.e., it warns when it should not.
For instance, it warns about pointer conversions even when the pointers
are not dereferenced.
Second, it produces false negatives, i.e., it does not warn when it
should. For instance, aliases to malloc-ed memory are not detected,
among others.
Third, it only checks C programs (and not C++).
I am about to submit a patch that implements -Wstrict-aliasing in the
backend based on flow-sensitive points-to information, which is computed
by analyzing the entire source of each function. It is not perfect (the
problem is undecidable), but it improves in all three directions: it
checks whether pointers get dereferenced, it detects cross-type aliasing
in heap (and other multiple statements situations) and it works on both
C and C++.
Silvius
