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.