This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: New implementation of -Wstrict-aliasing


Gabriel Dos Reis wrote:
Silvius Rus <rus@google.com> writes:

|[...]
| Can you please advise on the following choice of warning levels.
| Please let me know which of the following levels you would like to see
| in 4.3, in which order.  In all cases, the warnings are conditioned by
| -fstrict-aliasing.
| Thank you,
| Silvius

Hi Silvius,

Thanks for taking time for expanding on this.

All of the levels seem good to me.  However I would appreciate an
explanation about the choice of the levels.

First I thought that the accuracy of the diagnostics improves as
the level increases, meaning less false positives and less false negatives.
In my first proposal (last week), that was the case. However, I thought it over and realized it exposed too much detail to the user (extensive use of --param) with insufficient practical impact. After I redesigned it, the interface looked very similar to the previous -Wstrict-aliasing implementation.
However, I'm under the impression that under your
proposal, the accuracy decreases as the level increases. Is that
reading correct?
That is correct.
My general thinking was that, the compile-time consumed by warning about non-conforming aliasing will increase with the level. So, for
example level=1 will be quick but not very precise, and level=4 might
be slow but more accurate. Just like with optimization levels.
What motivates your choice in the other direction?
I made this choice for consistency with the existent -Wstrict-aliasing. In the previous implementation, level 2 was usually less accurate than level 1, in the sense that it produces more false positives. However, I agree that ordering them by increasing accuracy (and effort) makes good sense by analogy to optimization levels. I have no problem reversing the proposed order, as long as the most accurate one is the default. Let me know if you are OK with this revised order:
level 1: least precise due to many false positives
level 2: more precise, still some false positives
level 3 (default): most precise, very few false positives and few false negatives
level 4: improvement to level 3, but cannot be default because it breaks bootstrap
Also, ordering them by increasing complexity allows us to add future detection methods as higher level numbers. I can see in the future a more precise implementation based on virtual SSA rather than points-to information.


Talking about levels: Unfortunately, we cannot come up with a perfect solution, because "accuracy" does not define a total order on the set of analysis methods we have available. First, we measure accuracy by a pair, <false positives, false negatives>. In the previous implementation, level 1 has fewer false positives than level 2, but it has more false negatives. Second, even if we look just at false negatives, they are measured as sets, which are not always in an inclusion relation with each other (from one -Wstrict-aliasing level to another).

The order I am proposing now is clearly biased towards a low count of false positives. I can see that to certain users better accuracy could mean a low count of false negatives, and in that case my proposed order would seem confusing, but there is just that much you can pack in a small integer.


Thank you! Silvius



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]