On 05/14/2014 11:34 AM, Richard Biener wrote:
On Tue, May 13, 2014 at 9:27 PM, Florian Weimer <fwei...@redhat.com> wrote:
Patterns that trigger the optimization and warning can form after inlining,
and it can be rather difficult to figure out what exactly is causing the
warning. The inlining context at least provides additional hints, enabling
developers to substitute the arguments and discover what, precisely, is
happening.
More context is provided with -g than without, but I think this is
acceptable.
I bootstrapped and tested the attached patch on x86_64-redhat-linux-gnu,
with no new regressions.
I think that your block walking code is bogus in that it looks at
only BLOCK_SOURCE_LOCATION, exposing an implementation
detail that should be hidden by using inlined_function_outer_scope_p.
Do you mean that I should replace the condition with
inlined_function_outer_scope_p (block)? I've made this change.
It also will print an unlimited call stack - isn't that too verbose?
Isn't the call stack limited by inlining parameters? I don't see a good
way to prune it. When investigating instances of this warning, you
might need all frames. I could add a parameter and set it to some
arbitrary default, like 5, and print a warning if the call stack is
longer. But I don't know if this is really worth the effort,
considering that the warning is somewhat rare to begin with.
--
Florian Weimer / Red Hat Product Security Team
