Sorry about the slow response on IRC today, I got distracted onto
another issue and forgot to check back. What I started to write:
I'm exploring your suggestion to see if the back end could emit the
diagnostics. But I'm not sure it has sufficient context (location information)
to point to the line of code that uses the function.
Hmm, that's a good point. I think it would make sense for the ADDR_EXPR
to carry location information as long as we're dealing with trees, but I
suspect we don't currently set the location of an ADDR_EXPR. So that
would need to be fixed as part of this approach.
I suspect the back end or even the middle end route isn't going to work even if
there was enough context to diagnose the problem expressions because some of them
will have been optimized away by then (e.g., 'if (& __builtin_foo != 0)' is
optimized into if (1) by gimple).
I was thinking that if they're optimized away, they aren't problematic
anymore; that was part of the attraction for me of handling this lower down.
The second question is about your suggestion to consolidate the code into
mark_rvalue_use. The problem I'm running into there is that mark_rvalue_use is
called for calls to builtins as well as for other uses and doesn't have enough
context to tell one from the other.
Ah, true. But special-casing call uses is still fewer places than
special-casing all non-call uses.
Jason
