[Bug tree-optimization/99372] New: gimplefe-28.c ICEs when sqrt insn is not available

[Bug tree-optimization/99372] New: gimplefe-28.c ICEs when sqrt insn is not available

[aoliva at gcc dot gnu.org]

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

            Bug ID: 99372
           Summary: gimplefe-28.c ICEs when sqrt insn is not available
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aoliva at gcc dot gnu.org
  Target Milestone: ---

Try to compile gimplefe-28.c from the testsuite with -mno-powerpc-gpopt or
-msoft-float on a powerpc target, and it will ICE, because it doesn't check for
the availability of the .SQRT instrinsic explicitly called in the test.

Fixes for the See-Also bugs are likely to prevent the bug from showing up in
test results.

[Bug target/99372] gimplefe-28.c ICEs when sqrt insn is not available

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |11.0
          Component|tree-optimization           |target
             Target|                            |powerpc

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It does check for that:

/* { dg-do compile { target sqrt_insn } } */

the error is with the powerpc target not implementing the dg sqrt_insn target
properly.

[Bug target/99372] gimplefe-28.c ICEs when sqrt insn is not available

[aoliva at gcc dot gnu.org]

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.