[Bug target/108240] New: ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[Bug target/108240] New: ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[marxin at gcc dot gnu.org]

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

            Bug ID: 108240
           Summary: ICE in emit_library_call_value_1 at gcc/calls.cc:4181
                    since r13-4894-gacc727cf02a144
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: linkw at gcc dot gnu.org
  Target Milestone: ---

Since the revision, I see:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/minloc_string_1.f90
-mmodulo -mcpu=401
during RTL pass: expand
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/minloc_string_1.f90:21:16:

   21 |   a = int(r*100)
      |                ^
internal compiler error: Segmentation fault
0x11c81f8 crash_signal
        /home/marxin/Programming/gcc2/gcc/toplev.cc:314
0x7ffff78d18df ???
       
/usr/src/debug/glibc-2.36/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xe00886 aggregate_value_p(tree_node const*, tree_node const*)
        /home/marxin/Programming/gcc2/gcc/function.cc:2056
0xc442d3 emit_library_call_value_1(int, rtx_def*, rtx_def*, libcall_type,
machine_mode, int, std::pair<rtx_def*, machine_mode>*)
        /home/marxin/Programming/gcc2/gcc/calls.cc:4181
0xda7819 emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, rtx_def*, machine_mode)
        /home/marxin/Programming/gcc2/gcc/rtl.h:4399
0xda7819 convert_mode_scalar
        /home/marxin/Programming/gcc2/gcc/expr.cc:529
0xda8c30 convert_modes(machine_mode, machine_mode, rtx_def*, int)
        /home/marxin/Programming/gcc2/gcc/expr.cc:931
0x107f7ab expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*,
int, optab_methods)
        /home/marxin/Programming/gcc2/gcc/optabs.cc:1671
0xd8c0a7 expand_mult(machine_mode, rtx_def*, rtx_def*, rtx_def*, int, bool)
        /home/marxin/Programming/gcc2/gcc/expmed.cc:3600
0xc5b080 expand_gimple_stmt_1
        /home/marxin/Programming/gcc2/gcc/cfgexpand.cc:3983
0xc5b080 expand_gimple_stmt
        /home/marxin/Programming/gcc2/gcc/cfgexpand.cc:4044
0xc605be expand_gimple_basic_block
        /home/marxin/Programming/gcc2/gcc/cfgexpand.cc:6096
0xc61ec6 execute
        /home/marxin/Programming/gcc2/gcc/cfgexpand.cc:6822
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

while the code was rejected before the revision with:
f951: Error: ‘-m64’ requires a PowerPC64 cpu

[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |13.0
   Last reconfirmed|                            |2022-12-28

[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[linkw at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Keywords|                            |ice-on-valid-code
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org

--- Comment #1 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for reporting!  Confirmed.

[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[linkw at gcc dot gnu.org]

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

--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Well, there are two issues here:

1) the ICE itself, it's independent of option powerpc64 handling, without the
culprit commit r13-4894 but with an explicit option -m64, the ICE is still
reproducible. So this exposes one latent bug.

When specifying -mcpu=401, it uses the default flag OPTION_MASK_SOFT_FLOAT
(soft-float), it means there is no hard-float support. But specifying the
undocumented option -mmodulo, it means to act like power9 (setting all ISA3.0
flags excepting for some -mno-xxx) as the code:

  if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_MISC)
    rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~ignore_masks);

It results in one unexpected state that we don't have hard-float support but we
still have P9 vector supports (of coz. VSX). Later when expanding SFmode smul,
it tries to use wider mode KFmode for the multiplication then ICE.

Currently we have some checks on the co-existence between TARGET_VSX and
!TARGET_HARD_FLOAT, I think we also need to extend it to cover those options
which can enable VSX later:

  if (TARGET_P9_VECTOR || TARGET_MODULO || TARGET_P9_MISC)
    rs6000_isa_flags |= (ISA_3_0_MASKS_SERVER & ~ignore_masks);
  else if (TARGET_P9_MINMAX)
    {
...
      else
        rs6000_isa_flags |= ISA_3_0_MASKS_SERVER;
    }
  else if (TARGET_P8_VECTOR || TARGET_DIRECT_MOVE || TARGET_CRYPTO)
    rs6000_isa_flags |= (ISA_2_7_MASKS_SERVER & ~ignore_masks);
  else if (TARGET_VSX)
    rs6000_isa_flags |= (ISA_2_6_MASKS_SERVER & ~ignore_masks);

If we have !TARGET_HARD_FLOAT and any of TARGET_P9_VECTOR, TARGET_MODULO,
TARGET_P9_MISC, TARGET_P9_MINMAX, TARGET_P8_VECTOR, TARGET_DIRECT_MOVE,
TARGET_CRYPTO, we are pretending there is one explicit -mno-vsx:
      rs6000_isa_flags &= ~ OPTION_MASK_VSX;
      rs6000_isa_flags_explicit |= OPTION_MASK_VSX;

[Bug target/108240] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[linkw at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|poiwerpc                    |powerpc
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org

--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
2) before the culprit commit r13-4894, if there is an explicit -m64, it does
set powerpc64 (as it's set explicitly), while if there is no explicit -m64, it
does nothing. The implicit 64 bit setting would always implicitly enable
powerpc64 initially, so it's fine. As this case shows, it's possible that the
used cpu would unset powerpc64 later if it's not default.

With the culprit commit r13-4894, we always implicitly enable powerpc64 for
both explicit and implicit 64 bit, it's the same as before for the explicit 64
bit case, but for the implicit 64 bit case, there is no chance for the used cpu
to unset powerpc64 (like this case). To keep it consistent with the previous,
the fix can be to only enable powerpc64 implicitly for explicit 64 bit, while
let it be for implicit 64 bit.

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in                      |[13 Regression] ICE in
                   |emit_library_call_value_1   |emit_library_call_value_1
                   |at gcc/calls.cc:4181 since  |at gcc/calls.cc:4181 since
                   |r13-4894-gacc727cf02a144    |r13-4894-gacc727cf02a144
           Priority|P3                          |P1

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #3)
> With the culprit commit r13-4894, we always implicitly enable powerpc64 for
> both explicit and implicit 64 bit, it's the same as before for the explicit
> 64 bit case, but for the implicit 64 bit case, there is no chance for the
> used cpu to unset powerpc64 (like this case). To keep it consistent with the
> previous, the fix can be to only enable powerpc64 implicitly for explicit 64
> bit, while let it be for implicit 64 bit.

No?  If the user says to use a CPU without 64-bit instructions, while the
user also says we require 64-bit insns (via -m64), we should just error.
Not hide the problem (and cause many more problems!)

We used to do that:

f951: Error: ‘-m64’ requires a PowerPC64 cpu

We can do such a check again, just in a bit different spot probably.

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[linkw at gcc dot gnu.org]

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

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #4)
> (In reply to Kewen Lin from comment #3)
> > With the culprit commit r13-4894, we always implicitly enable powerpc64 for
> > both explicit and implicit 64 bit, it's the same as before for the explicit
> > 64 bit case, but for the implicit 64 bit case, there is no chance for the
> > used cpu to unset powerpc64 (like this case). To keep it consistent with the
> > previous, the fix can be to only enable powerpc64 implicitly for explicit 64
> > bit, while let it be for implicit 64 bit.
> 
> No?  If the user says to use a CPU without 64-bit instructions, while the
> user also says we require 64-bit insns (via -m64), we should just error.

But both the previous behavior (before r13-4894) and the current behavior
(starting from r13-4894) honour the given explicit -m64, it would always enable
-mpowerpc64 at the same time without any errors/warnings.

> Not hide the problem (and cause many more problems!)
> 

The behavior change is for the case without any explicit -m64 but the
TARGET_DEFAULT has 64 bit set (implicit -m64).  And yes, different from the
previous behavior, the current behavior hides the error/warning and force the
-mpower64, so I posted one patch at:

https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609492.html

It would allow that powerpc64 gets unset if the user says to use a CPU without
64-bit instructions and with implicit 64 bit.

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[linkw at gcc dot gnu.org]

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

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > (In reply to Kewen Lin from comment #3)
> > > With the culprit commit r13-4894, we always implicitly enable powerpc64 for
> > > both explicit and implicit 64 bit, it's the same as before for the explicit
> > > 64 bit case, but for the implicit 64 bit case, there is no chance for the
> > > used cpu to unset powerpc64 (like this case). To keep it consistent with the
> > > previous, the fix can be to only enable powerpc64 implicitly for explicit 64
> > > bit, while let it be for implicit 64 bit.
> > 
> > No?  If the user says to use a CPU without 64-bit instructions, while the
> > user also says we require 64-bit insns (via -m64), we should just error.
> 
> But both the previous behavior (before r13-4894) and the current behavior
> (starting from r13-4894) honour the given explicit -m64, it would always
> enable -mpowerpc64 at the same time without any errors/warnings.
> 

It's implied that when the user explicitly specify -m64, the handlings would
neglect the impact of CPU, I'm not sure if it's intentional but the reason
probably is that the underlying CPU is actually 64 bit in most cases, so make
-m64 win and the compilation can go forward.

If we change the behavior to error for both explicit and implicit 64 bit, some
compilations which worked in the past can start to fail (though it's arguable
that it's expected). Note that for implicit 64 bit and no powerpc64, we gets
errors on Linux but just warnings on darwin/aix (maybe more fallouts come out
on them). So considering the current release phase, I'm inclined to just make
it consistent with the previous, and try to adjust the behavior (as Segher's
proposal) in next release.

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> ---
-m64 requires 64-bit instructions.  We will ICE if we try to generate code
for -m64 without support for 64-bit insns enabled in the compiler.  For
example, the stdu insn is required to implement the ABI sanely.

If the user said they want a -mcpu= for a CPU that has no 64-bit insns,
but also wants to use -m64, we should just say sorry, that won't fly.

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[linkw at gcc dot gnu.org]

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

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #7)
> -m64 requires 64-bit instructions.  We will ICE if we try to generate code
> for -m64 without support for 64-bit insns enabled in the compiler.  For
> example, the stdu insn is required to implement the ABI sanely.
> 

The current behavior for one explicit command line option -m64 doesn't violate
the comment, the explicitly given -m64 will enable powerpc64 all the time, it
makes -m64 compilation always have 64-bit insns enabled. It's the same for both
cases before and after r13-4894.

> If the user said they want a -mcpu= for a CPU that has no 64-bit insns,
> but also wants to use -m64, we should just say sorry, that won't fly.

I agree that this is a sensible thing to look into and make. But to change the
behavior like this fully (on Linux, aix and darwin, 64 bit env w/ or w/o
explicit -m64) is a big adjustment comparing with the previous behaviors.

Since for the case that "the explicit option -m64 + cpu without 64-bit insn +
Linux/aix/darwin" it doesn't emit errors before, for the cases that "no
explicit option -m64 + cpu without 64-bit insn + aix/darwin" it only emits
warnings before. Only for the case "no explicit option -m64 + cpu without
64-bit insn + Linux", it emits error before r13-4894. After the culprit commit
it changes to not emit errors, this part is a regression, the proposed patch
can fix it.
But for the others in which cases we don't emit error before (for both cases
before and after r13-4894), to make them to emit errors is new behavior, it
could cost non-trivial efforts (at least on testing and some fixing on possible
fallouts).

[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144

[linkw at gcc dot gnu.org]

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

--- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
I filed one new bug PR108415 for the ICE itself to avoid the confusion here.

This ICE is not a regression, it's a latent bug, because:

1) Without the culprit commit r13-4894 (like using r13-4893 or reverting it),
if we specify one more explicit option -m64, we can see the exactly same ICE.
It's just concealed as we emit error first on Linux without -m64. (r13-4894
changed it not to emit error any more so no error to conceal then).

2) It's even nothing to do with powerpc64 handling, this ICE can be produced
on ppc64 Linux with options "-m32 -mcpu=401 -mmodulo", so it's not 64 bit
specific (so not powerpc64 handling related either).

I put one comment about root cause of this ICE in PR108415.

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

[linkw at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[13 Regression] ICE in      |[13 Regression] Error
                   |emit_library_call_value_1   |message missing since
                   |at gcc/calls.cc:4181 since  |r13-4894-gacc727cf02a144
                   |r13-4894-gacc727cf02a144    |(then make concealed ICE
                   |                            |exposed)
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-January
                   |                            |/609492.html

--- Comment #10 from Kewen Lin <linkw at gcc dot gnu.org> ---
Put the ICE aside, the actual regression here is that for the given option set
the expected error message below is missing:

  f951: Error: ‘-m64’ requires a PowerPC64 cpu

But note that we only emit this error message when there is no explicit -m64.
The ICE shows up with an explicit option -m64 given without r13-4894 also
proves this (since otherwise we see error message first instead of ICE).

So to fix the regression itself, we only need to consider the case without any
explicit -m64, that's what the proposed patch aims to fix.

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
One more test-case that started to ICE with the same revision:

./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
-mcpu=e300c2 -mmodulo -c
during RTL pass: reload
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:
In function ‘test_mult’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:74:1:
internal compiler error: maximum number of generated reload insns per insn
achieved (90)
   74 | }
      | ^
0x7ffff78bb5af __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x7ffff78bb678 __libc_start_main_impl
        ../csu/libc-start.c:381
0xb648e4 _start
        ../sysdeps/x86_64/start.S:115
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool <segher at gcc dot gnu.org> ---
We really really REALLY should neuter -mmodulo.  It is counter-productive
to have command-line flags for separate instructions at all (as opposed to
facilities), and it is downright destructive to have sneaky ways to enable
most (but not all!) of what -mcpu= does via other options.

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

[linkw at gcc dot gnu.org]

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

--- Comment #13 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #11)
> One more test-case that started to ICE with the same revision:
> 
> ./xgcc -B.
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c
> -mcpu=e300c2 -mmodulo -c
> during RTL pass: reload
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:
> In function ‘test_mult’:
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-2.c:
> 74:1: internal compiler error: maximum number of generated reload insns per
> insn achieved (90)
>    74 | }
>       | ^
> 0x7ffff78bb5af __libc_start_call_main
> 	../sysdeps/nptl/libc_start_call_main.h:58
> 0x7ffff78bb678 __libc_start_main_impl
> 	../csu/libc-start.c:381
> 0xb648e4 _start
> 	../sysdeps/x86_64/start.S:115
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See <https://gcc.gnu.org/bugs/> for instructions.

I think it has the same root cause as PR108415:

RS6000_CPU ("e300c2", PROCESSOR_PPCE300C2, OPTION_MASK_SOFT_FLOAT)

and also expected this ICE can be reproduced with explicit -m64 at r13-4893
(before the culprit commit r13-4894).

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:392f399ae0595e6b4433c18900cc67991fb140f4

commit r13-6383-g392f399ae0595e6b4433c18900cc67991fb140f4
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Tue Feb 28 23:17:48 2023 -0600

    rs6000: Allow powerpc64 to be unset for implicit 64 bit [PR108240]

    Before r13-4894, if 64 bit is explicitly specified, option
    powerpc64 is explicitly enabled too; while if 64 bit is
    implicitly enabled and there is no explicit setting for
    option powerpc64, option powerpc64 is eventually enabled
    or not would rely on the default value of the used cpu.
    It's initially set as the setting for 64 bit, but later if
    the used cpu doesn't have powerpc64 supported by default,
    it gets cleared.

    To keep it consistent with before (also the relevant error/
    warning messages), this patch is to allow that powerpc64
    can be unset if 64 bit is enabled implicitly, and only stop
    it from being unset if 64 bit is enabled explicitly.

    Note that since the behaviors are different for implicit
    and explicit 64 bit, I failed to construct one solid test
    case since it becomes fragile once RUNTESTFLAGS specifying
    -m64 explicitly.

            PR target/108240

    gcc/ChangeLog:

            * config/rs6000/rs6000.cc (rs6000_option_override_internal): Allow
            implicit powerpc64 setting to be unset if 64 bit is enabled
implicitly.

[Bug target/108240] [13 Regression] Error message missing since r13-4894-gacc727cf02a144 (then make concealed ICE exposed)

[linkw at gcc dot gnu.org]

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

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

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

--- Comment #15 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed on trunk, the latent ICE is tracked by PR108415, further
improvement would be tracked by PR108981.