[Bug target/105975] New: OpenMP/nvptx offloading: 'internal compiler error: in maybe_legitimize_operand, at optabs.cc:7785'

["tschwinge at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 105975
           Summary: OpenMP/nvptx offloading: 'internal compiler error: in
                    maybe_legitimize_operand, at optabs.cc:7785'
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: openmp
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org, rsandifo at gcc dot gnu.org,
                    vries at gcc dot gnu.org
  Target Milestone: ---
            Target: nvptx

The recent commit r13-1068-g1d205dbac1e1754c01c22a31bd1688126545401e "Factor
out common internal-fn idiom" causes a class of ICEs in OpenMP/nvptx offloading
compilation: 'during RTL pass: expand', 'internal compiler error: in
maybe_legitimize_operand, at optabs.cc:7785', seen for a lot of libgomp
OpenMP/nvptx offloading test cases (with '-O1' and higher).

    0xb1b0b3 maybe_legitimize_operand
            [...]/source-gcc/gcc/optabs.cc:7785
    0xb1b0b3 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
            [...]/source-gcc/gcc/optabs.cc:7936
    0xb1b139 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
            [...]/source-gcc/gcc/optabs.cc:7955
    0xb1a8b8 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
            [...]/source-gcc/gcc/optabs.cc:7998
    0xb1a8b8 expand_insn(insn_code, unsigned int, expand_operand*)
            [...]/source-gcc/gcc/optabs.cc:8029
    0x95dcb3 expand_fn_using_insn
            [...]/source-gcc/gcc/internal-fn.cc:193
    0x6d3ee7 expand_call_stmt
            [...]/source-gcc/gcc/cfgexpand.cc:2737
    0x6d3ee7 expand_gimple_stmt_1
            [...]/source-gcc/gcc/cfgexpand.cc:3869

For extra entertainment: when running with '-wrapper "$GDB",-q,--args', we get
'[Inferior 1 (process [...]) exited normally]'...  (Maybe Valgrind could help? 
Unless someone directly pinpoints the issue, of course.)

I've not yet determined whether it's a latent problem just exposed by this
commit, or whether the commit itself has an issue.  It's not magically fixed by
the related subsequent commit
r13-1069-gf8baf4004ef965ce7a9edf6d2f5eb99adb15803a "Add a general mapping from
internal fns to target insns".

'gcc/internal-fn.cc':

    193    expand_insn (icode, opno, ops);

'gcc/optabs.cc':

    8026        expand_insn (enum insn_code icode, unsigned int nops,
    8027                     class expand_operand *ops)
    8028        {
    8029          if (!maybe_expand_insn (icode, nops, ops))

    7995        maybe_expand_insn (enum insn_code icode, unsigned int nops,
    7996                           class expand_operand *ops)
    7997        {
    7998          rtx_insn *pat = maybe_gen_insn (icode, nops, ops);

    7951        maybe_gen_insn (enum insn_code icode, unsigned int nops,
    7952                        class expand_operand *ops)
    7953        {
    7954          gcc_assert (nops == (unsigned int) insn_data[(int)
icode].n_generator_args);
    7955          if (!maybe_legitimize_operands (icode, 0, nops, ops))

    7935              /* Otherwise try legitimizing the operand on its own.  */
    7936              if (j == i && !maybe_legitimize_operand (icode, opno + i,
&ops[i]))

    7784            case EXPAND_OUTPUT:
    7785              gcc_assert (mode != VOIDmode);