On 07/28/2015 09:38 PM, Jason Merrill wrote:
Sorry about the slow response on IRC today, I got distracted onto
another issue and forgot to check back. What I started to write:
No problem.
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.
Okay, let me look into this.
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.
Yes, they're not problematic in that they don't cause linker unsats.
I have a few concerns with the approach of accepting or rejecting
constructs based on optimization (e.g., that it might lead to
similar problems as with -Wmaybe-uninitialized; or that it could
be perceived as inconsistent). But it may not be as bad as it seems
-- let me look into it if only as a learning exercise and see how
it goes.
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.
This will be moot if I can implement it the middle-end. If not,
I'll give it a try to see if this alternative ends up reducing
the footprint of the patch.
Thanks
Martin
