[Bug target/80210] ICE in in extract_insn, at recog.c:2311 on ppc64 for with __builtin_pow

bergner at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Apr 14 18:53:00 GMT 2017


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.


More information about the Gcc-bugs mailing list