I am implementing -Wstrict-aliasing by catching simple cases in the
frontend and more complex ones in the backend. The frontend mechanism
is tree pattern matching. The backend one uses flow-sensitive points-to
information.
I want to avoid duplicate warnings. I thought of a few ways, but none
seems perfect. Can you please advise which of the following I should
choose, suggest alternatives, or let me know if a solution exists.
1. Save location info for the warnings issued in the frontend + have the
backend check before issuing warnings.
This would be simple, but it involves communication between frontend and
backend.
2. Turn off frontend checking at -O2 and let the backend do all the work.
This might affect the applicability of the warning, as the code may be
simplified before it gets to the warning check (although the common case
would be caught).
3. Make the backend skip cases that are likely to be warned by the frontend.
This is finicky because complex expression trees in the frontend are
distributed over multiple GIMPLE statements by the time they reach the
check in the backend.
4. Just allow duplicates. The problem of duplicates is actually more
general and should be solved (is it already?) in a generic way for all
warnings, and not just for -Wstrict-aliasing. Even the backend alone
will issue duplicate warnings, e.g., when inlining a function from a
header file causes type punning at or around several call sites. This
may happen in the same or in several .c files that may be processed
together by the compiler/LTO. With -Wstrict-aliasing this may be more
common than with some other warnings, because type punning sometimes
involves set/get methods that are usually inlined.
Thank you,
Silvius
