On 08/06/2017 05:08 PM, Martin Sebor wrote: >> >> Well, simply because the way as implemented isn't a must-alias query >> but maybe one that's good enough for warnings (reduces false positives >> but surely doesn't eliminate them). > > I'm very interested in reducing the rate of false positives in > these and all other warnings. As I mentioned in my comments, > I did my best to weed them out of the implementation by building > GDB, Glibc, Busybox, and the Linux kernel. That of course isn't > a guarantee that there aren't any. But the first implementation > of any non-trivial feature is never perfect, and hardly any > warning of sufficient complexity is free of false positives, no > matter here it's implemented (the middle-end, front-end, or > a standalone static analysis tool). If you spotted some cases > I had missed I'd certainly be grateful for examples. Otherwise, > they will undoubtedly be reported as more software is exposed > to the warning and, if possible, fixed, as happens with all > other warnings. I think Richi is saying that the must alias query you've built isn't proper/correct. It's less about false positives for Richi and more about building a proper must alias query if I understand him correctly.
I suspect he's also saying that you can't reasonably build must-alias on top of a may-alias query framework. They're pretty different queries. If you need something that is close to, but not quite a must alias query, then you're going to have to make a argument for that and you can't call it a must alias query. > >> There's a must alias query already, in stmt_kills_ref_p. It's a matter >> of refactoring to make a refs_must_alias_p. >> >> Then propose that "overlap range" stuff separately. > > I appreciate constructive suggestions for improvements and I will > look into the stmt_kills_ref_p suggestion. But since my work > elicited such an strong response from you I feel I should explain: > I tried to make my changes as unintrusive as possible. The alias > oracle is a new area for me and I didn't want to make mistakes in > the process of making overly extensive modifications to it. Note that I've got a reasonably good handle on how we use stmt_kills_ref_p. So I can help with questions on that side. Jeff
