https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80210
--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> --- A more direct test case: bergner@bns:~/gcc/BUGS/PR80210> cat sqrt.i double foo (double a) { return __builtin_sqrt (a); } #pragma GCC target "no-powerpc-gpopt" bergner@bns:~/gcc/BUGS/PR80210> /home/bergner/gcc/build/gcc-fsf-mainline-pr80210-debug/gcc/xgcc -B/home/bergner/gcc/build/gcc-fsf-mainline-pr80210-debug/gcc -Ofast -S sqrt.i sqrt.i: In function ‘foo’: sqrt.i:5:1: error: unrecognizable insn: } ^ (insn 6 3 10 2 (set (reg:DF 155 [ <retval> ]) (sqrt:DF (reg/v:DF 156 [ a ]))) "sqrt.i":4 -1 (nil)) sqrt.i:5:1: internal compiler error: in extract_insn, at recog.c:2311 The issue is that when we initialize for compilation, TARGET_PPC_GPOPT is true due to TARGET_DEFAULT including it, which in turn is used to set HAVE_sqrtdf2. We then call init_all_optabs() and that does "ena[342] = HAVE_sqrtdf2;" which records the fact we have the sqrtdf2 pattern, which will allow (later) the __builtin_sqrt() to call down into the backend to generate the pattern. Otherwise, it would generate a call to sqrt. After init_all_optabs, but before we expand the function, we scan the pragma and that turns off TARGET_PPC_GPOPT disallowing the pattern which leads to the ICE. Now the pragma, since it is textually after the function, should not affect the options used to compile the function foo, but it does. This seems to be caused by rs6000_pragma_target_parse() incorrectly modifying the global_options that will be used to compile function foo. Mike, you wrote this code. When we see the pragma, shouldn't we be saving off the current options for use by foo, before we alter the options that would be used by functions that follow the pragma? Our code in this area looks a fair amount different than say x86, s390 and ARM, but it looks like they each are creating a copy of the options, while we don't.