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

2025-06-05 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

--- Comment #9 from Segher Boessenkool  ---
What is the current state here?

We should simply not allow -mmodulo at all if we do not generate such
insns (we do not have a -mcpu= that allows those).  We do not want
multiple ways to do thing, certainly not where way A then overrides
way B, and no one knows which will win!

To enable or disable certain parts of the instruction set, the only
thing that matters is -mcpu=.  But we *do* want to be able to disable
all FP or vector insns, importantly everything that touches the
corresponding register files!

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

2025-06-05 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|13.4|13.5

--- Comment #8 from Jakub Jelinek  ---
GCC 13.4 is being released, retargeting bugs to GCC 13.5.

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

2024-05-21 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|13.3|13.4

--- Comment #7 from Jakub Jelinek  ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.

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

2023-07-27 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.2|13.3

--- Comment #6 from Richard Biener  ---
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

2023-04-26 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #5 from Richard Biener  ---
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

2023-02-28 Thread linkw at gcc dot gnu.org via Gcc-bugs
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

2023-01-17 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

--- Comment #4 from Kewen Lin  ---
(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

2023-01-17 Thread bergner at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

--- Comment #3 from Peter Bergner  ---
(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

2023-01-17 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

--- Comment #2 from Kewen Lin  ---
(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=’ for
 less than power9

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

2023-01-17 Thread segher at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

--- Comment #1 from Segher Boessenkool  ---
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

2023-01-15 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108415

Kewen Lin  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