https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99372
--- Comment #2 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I didn't mean that the testcase didn't check, I meant that the gimple parser
didn't check. It swallows the .SQRT call even though it the attempt to expand
the call will ICE because there's no usable opcode:
[aoliva@gcc1-power7 gcc]$ ./xgcc -B./ ../../gcc/testsuite/gcc.dg/gimplefe-28.c
-
fgimple -msoft-float
during RTL pass: expand
../../gcc/testsuite/gcc.dg/gimplefe-28.c: In function ‘f1’:
../../gcc/testsuite/gcc.dg/gimplefe-28.c:6:1: internal compiler error: in
expand
_direct_optab_fn, at internal-fn.c:3360
6 | f1 (double x)
| ^~
0x10d017d7 expand_direct_optab_fn
../../gcc/internal-fn.c:3360
0x10d076bf expand_SQRT
../../gcc/internal-fn.def:256
0x10d09187 expand_internal_call(internal_fn, gcall*)
../../gcc/internal-fn.c:4079
0x10d091db expand_internal_call(gcall*)
../../gcc/internal-fn.c:4087
0x1087e637 expand_call_stmt
../../gcc/cfgexpand.c:2749
[...]
internal-fn.c:3359:
insn_code icode = direct_optab_handler (optab, TYPE_MODE (types.first));
gcc_assert (icode != CODE_FOR_nothing);
As an altenative for the gimple parser's checking, I suppose we could have an
expander that fell back to a regular function call, though the assert check
suggests we didn't expect the intrinsic call to be present when the opcode is
not available.
cdce3.c suggests other parts of the compiler can tell, ahead of expand, whether
a sqrt insn is available, to decide whether or not to shrink-wrap, so it might
make sense to use the same test here. I haven't identified what the early test
is.
