[Bug target/69245] [6 Regression] ICE in extract_insn, at recog.c:2286 on arm-linux-gnueabihf

ktkachov at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Tue Jan 12 16:44:00 GMT 2016


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69245

--- Comment #5 from ktkachov at gcc dot gnu.org ---
The problem is we never end up setting TREE_TARGET_GLOBALS for fn2.
>From what I can gather that's TARGET_SET_CURRENT_FUNCTION's job (although the
documentation for these things is scarce :( )

When we call arm_set_current_function for fn2 the old_tree is NULL because
arm_pragma_target_parse will have reset arm_previous_fndecl when popping the
target pragma.

new_tree will also be NULL because DECL_FUNCTION_SPECIFIC_TARGET for fndecl is
only supposed to be set in the target attribute parsing code, but not the
pragma parsing code (again, documentation here is scarce).

So we end up bypassing all the content in arm_set_current_function and not
setting TREE_TARGET_GLOBALS which means the midend doesn't try to reset the
optabs for fn2.

x86 gets away with this because ix86_reset_previous_fndecl besides clearing the
previous fndecl cache also sets TREE_TARGET_GLOBALS for
target_option_current_node.

rs6000 seems to never reset its previous fndecl (rs6000_previous_fndecl) so its
version old_tree will always point to some tree (AFAICT).

Ugh. So for arm my thoughts are we should not exit early on the old_tree ==
new_tree condition if both trees are NULL but rather follow the second arm of
the if statement in arm_set_current_function where we set new_tree to
target_option_current_code.

Hacking a prototype for that idea fixes the testcase for me.
Christian, what do you think?


More information about the Gcc-bugs mailing list