[Bug target/108415] New: ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[Bug target/108415] New: ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[linkw at gcc dot gnu.org]

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

            Bug ID: 108415
           Summary: ICE in emit_library_call_value_1 at gcc/calls.cc:4181
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: linkw at gcc dot gnu.org
                CC: bergner at gcc dot gnu.org, linkw at gcc dot gnu.org,
                    marxin at gcc dot gnu.org, segher at gcc dot gnu.org
        Depends on: 108240
  Target Milestone: ---
            Target: powerpc

+++ This bug was initially created as a clone of Bug #108240 +++

For the case
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/minloc_string_1.f90,

with options:

  -mmodulo -mcpu=401 -m64 (Linux and the default cpu power8)

Or options:

  -m32 -mcpu=401 -mmodulo (Linux BE and the default cpu power8)

we can see the ICE which is exactly as that in PR108240.

This bug is separated from PR108240, as it's a latent bug, the ICE itself is
actually nothing to do with r13-4894 which rework powerpc64 handling.

The root cause is that -mcpu=401 implies soft float and -mmodulo implies
ISA_3_0_MASKS_SERVER
(VSX), they conflicts very much, but this check is too early:

if (!TARGET_HARD_FLOAT)
  {
    if (rs6000_isa_flags_explicit & OPTION_MASK_VSX)
      msg = N_("%<-mvsx%> requires hardware floating point");
    else
      {
        rs6000_isa_flags &= ~ OPTION_MASK_VSX;
        rs6000_isa_flags_explicit |= OPTION_MASK_VSX;
      }
  }


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240
[Bug 108240] [13 Regression] ICE in emit_library_call_value_1 at
gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[linkw at gcc dot gnu.org]

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

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-January
                   |                            |/609724.html
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-01-16
   Target Milestone|---                         |13.0
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Soft float does not conflict with anything (anything that does not need
FP registers that is).  But yes, we really should neuter -mmodulo.

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[linkw at gcc dot gnu.org]

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

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #1)
> Soft float does not conflict with anything (anything that does not need
> FP registers that is).  But yes, we really should neuter -mmodulo.

The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
(!TARGET_HARD_FLOAT) together with the proposed option combination. :)

I agree that we should neuter -mmodulo, but note that this ICE isn't -mmodulo
specific.

With some more testings on those flags which the proposed patch (as field URL)
tries to take care of, the ICE can be reproduced with any one of below:

  -mcpu=401 -m64 -mmodulo
  -mcpu=401 -m64 -mpower9-vector
  -mcpu=401 -m64 -mpower9-misc
  -mcpu=401 -m64 -mpower8-vector
  -mcpu=401 -m64 -mcrypto

For -mcpu=401 -m64 -mpower9-minmax, it has the below error instead of ICE:

  f951: Error: power9 target option is incompatible with ‘-mcpu=<xxx>’ for
<xxx> less than power9

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #2)
> The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> (!TARGET_HARD_FLOAT) together with the proposed option combination. :)

I'm not sure what you mean with this comment, but just to be clear, we should
not allow TARGET_VSX and TARGET_SFT_FLOAT (!TARGET_HARD_FLOAT) at the same
time.

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[linkw at gcc dot gnu.org]

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

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #3)
> (In reply to Kewen Lin from comment #2)
> > The contradictory thing is that we can have TARGET_VSX and TARGET_SOFT_FLOAT
> > (!TARGET_HARD_FLOAT) together with the proposed option combination. :)
> 
> I'm not sure what you mean with this comment, but just to be clear, we
> should not allow TARGET_VSX and TARGET_SFT_FLOAT (!TARGET_HARD_FLOAT) at the
> same time.

Sorry for the confusion and thanks for clarifying, I meant the similar meaning
that: the given option combination, like

  -mmodulo -mcpu=401 or -mcpu=401 -mpower9-vector or ...

makes us to have both TARGET_VSX and TARGET_SOFT_FLOAT at the same time, it's
contradictory (shouldn't be allowed as you noted).

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415
Bug 108415 depends on bug 108240, which changed state.

Bug 108240 Summary: [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug target/108415] ICE in emit_library_call_value_1 at gcc/calls.cc:4181

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.