This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 11 Jul 2014 07:56:13 +0000
- Subject: [Bug middle-end/61776] [4.9/4.10 Regression] ICE: verify_flow_info failed: control flow in the middle of basic block with -fprofile-generate
- Auto-submitted: auto-generated
- References: <bug-61776-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Keywords| |ice-checking
Last reconfirmed| |2014-07-11
Component|tree-optimization |middle-end
CC| |hubicka at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE: verify_flow_info |[4.9/4.10 Regression] ICE:
|failed: control flow in the |verify_flow_info failed:
|middle of basic block with |control flow in the middle
|-fprofile-generate |of basic block with
| |-fprofile-generate
Target Milestone|--- |4.9.1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
There are several possibilities:
- don't instrument pure/const functions
- do not reset the pure/const flag (I see no reason to - the compiler might
not insert side-effects and we can consider the counter updates as
non-side-effect)
That is, I wonder why we do
/* Drop pure/const flags from instrumented functions. */
FOR_EACH_DEFINED_FUNCTION (node)
{
if (!gimple_has_body_p (node->decl)
|| !(!node->clone_of
|| node->decl != node->clone_of->decl))
continue;
/* Don't profile functions produced for builtin stuff. */
if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
continue;
cgraph_set_const_flag (node, false, false);
cgraph_set_pure_flag (node, false, false);
}
but don't then call execute_fixup_cfg () again (but it doesn't yet deal
with a const/pure function becoming non-pure/const and thus a bb-ending
stmt).
Btw, this is yet another case where transitioning to call flags instead
of decl flags would save us - definitely even the instrumented call cannot
return abnormally.
Dropping the clearing of const/pure fixes the bug. Honza? I only can think
of the case where we have
for (..)
{
const ();
const ();
}
and inline only one of the calls where after that loop store-motion might
apply store-motion to the counter updates of the inline clone, overwriting
the updates from the non-inline call. But do we really care?
Anyway, confirmed. Btw, goo() should be leaf but it seems we don't
auto-compute 'leaf' yet?