https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61925
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, it seems this is a complete mess.
The reason why we ICE is that the target pragma support is broken.
The main issue I see is that ix86_reset_to_default_globals doesn't actually
reset to defaults (== target_option_default_node), but to the current target
pragma (== target_option_current_node), and that even only if
ix86_previous_fndecl was previously non-NULL and had non-NULL target specific
option. And then ix86_set_current_function for some strange reason special
cases the defaults (i.e. NULL or == target_option_default_node), both for the
old and new, rather than the current target pragma (==
target_option_current_node). So, the important question is, is there any
reason
why in between functions the target options (both in global_options and target
globals) should be set to something other than the defaults (==
target_option_default_node)? I mean, it is hard to guess in what state it is
anyway, as ix86_set_current_function when going to NULL will keep it at the
latest state, so say __attribute__((target (avx2))) function definition in
a #pragma GCC target ("avx") region will keep it in avx2 state afterwards
anyway.
Also, I wonder about the start of
ix86_pragma_target_parse, shouldn't prev_tree be set to
target_option_current_node rather than whatever happens to be in global_options
at that point?
Or is keeping global_options to match the current active target pragma needed
for say vector type modes? If yes, then we should arrange for
target_option_current_node != target_option_default_node case that whenever we
ix86_set_current_function to NULL, we also restore global_options to that.
And there is another thing - I've noticed nested
ix86_valid_target_attribute_tree calls, the thing is when we are in pragma
target, decl_attributes call this function again, and that happens even when
calling ix86_add_new_builtins from this function. I wonder if we shouldn't
temporarily clear current_target_pragma, I think the target builtin decls don't
really need that and if pragma GCC target isn't used (but target attribute
instead), it isn't done anyway.
