This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 05/14/2014 11:34 AM, Richard Biener wrote:
On Tue, May 13, 2014 at 9:27 PM, Florian Weimer <fweimer@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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |