[Bug target/115069] New: 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[Bug target/115069] New: 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com]

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

            Bug ID: 115069
           Summary: 8 bit integer vector performance regression, x86,
                    between gcc-14 and gcc-13 using avx2 target clones on
                    skylake platform
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: colin.king at intel dot com
  Target Milestone: ---

Created attachment 58188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58188&action=edit
reproducer source code

I'm seeing a ~12-14% performance regression in gcc-14 compared to gcc-13, using
gcc on Ubuntu 24.04:

Versions:
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) 
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1) 

cking@skylake:~$ gcc-13 reproducer-vecmath.c -O2
cking@skylake:~$ ./a.out 
13540.16 vec8 ops per sec, duration = 14.77 secs

cking@skylake:~$ gcc-14 reproducer-vecmath.c -O2
cking@skylake:~$ ./a.out 
11720.25 vec8 ops per sec, duration = 17.06 secs

The original issue appeared when regression testing stress-ng vecmath stressor
[1]. I've managed to extract the attached reproducer from the original code
(see attached).

Salient point to focus on:

1. The issue is also dependant on the TARGET_CLONES macro being defined as
__attribute__((target_clones("mmx,avx,avx2,default")))  - the avx2 target
clones seems to be an issue in reproducing this problem, remove it for gcc-14
and the performance regression is reduced.

Attached are the reproducer C source and disassembled object code. 

References: [1]
https://github.com/ColinIanKing/stress-ng/blob/master/stress-vecmath.c

[Bug target/115069] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com]

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

--- Comment #1 from Colin Ian King <colin.king at intel dot com> ---
Created attachment 58189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58189&action=edit
gcc-13 disassembly

[Bug target/115069] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com]

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

--- Comment #2 from Colin Ian King <colin.king at intel dot com> ---
Created attachment 58190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58190&action=edit
gcc-14 disassembly

[Bug target/115069] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

Haochen Jiang <haochen.jiang at intel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |haochen.jiang at intel dot com

--- Comment #3 from Haochen Jiang <haochen.jiang at intel dot com> ---
From my investigation, GCC14 generates some perm instructions, which caused
data dependency.

Going to bisect which commit caused this issue.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.2

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[kkanas at fastmail dot com]

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

Krzysztof Kanas <kkanas at fastmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkanas at fastmail dot com

--- Comment #4 from Krzysztof Kanas <kkanas at fastmail dot com> ---
I bisected the issue and it seems that commit
0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[liuhongt at gcc dot gnu.org]

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

--- Comment #5 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Krzysztof Kanas from comment #4)
> I bisected the issue and it seems that commit
> 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.

I guess the real guilty commit is 

commit 52ff3f7b863da1011b73c0ab3b11f6c78b6451c7
Author: Uros Bizjak <ubizjak@gmail.com>
Date:   Thu May 25 19:40:26 2023 +0200

    i386: Use 2x-wider modes when emulating QImode vector instructions

    Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI ->
V16HImode)
    instructions when available.  Currently, the compiler generates following
    assembly for V16QImode multiplication (-mavx2):

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

--- Comment #6 from Haochen Jiang <haochen.jiang at intel dot com> ---
(In reply to Hongtao Liu from comment #5)
> (In reply to Krzysztof Kanas from comment #4)
> > I bisected the issue and it seems that commit
> > 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.
> 
> I guess the real guilty commit is 
> 
> commit 52ff3f7b863da1011b73c0ab3b11f6c78b6451c7
> Author: Uros Bizjak <ubizjak@gmail.com>
> Date:   Thu May 25 19:40:26 2023 +0200
>  
>     i386: Use 2x-wider modes when emulating QImode vector instructions
>  
>     Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI ->
> V16HImode)
>     instructions when available.  Currently, the compiler generates following
>     assembly for V16QImode multiplication (-mavx2):

Yes, since 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d only fixed a typo in that
patch.

Original thread: https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619745.html

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Hongtao Liu from comment #5)
> (In reply to Krzysztof Kanas from comment #4)
> > I bisected the issue and it seems that commit
> > 0368fc54bc11f15bfa0ed9913fd0017815dfaa5d introduces regression.
> 
> I guess the real guilty commit is 
> 
> commit 52ff3f7b863da1011b73c0ab3b11f6c78b6451c7
> Author: Uros Bizjak <ubizjak@gmail.com>
> Date:   Thu May 25 19:40:26 2023 +0200
>  
>     i386: Use 2x-wider modes when emulating QImode vector instructions
>  
>     Rewrite ix86_expand_vecop_qihi2 to expand fo 2x-wider (e.g. V16QI ->
> V16HImode)
>     instructions when available.  Currently, the compiler generates following
>     assembly for V16QImode multiplication (-mavx2):

The patch is at:

https://gcc.gnu.org/pipermail/gcc-patches/2023-May/619715.html

As mentioned in Comment #3, it looks that VPERMQ is a problematic insn. This
should be reflected in some cost function. Alternatively, we can simply change
the first line in:

+  if ((qimode == V16QImode && !TARGET_AVX2)
+      || (qimode == V32QImode && !TARGET_AVX512BW)
+      /* There are no V64HImode instructions.  */
+      || qimode == V64QImode)
+     return false;

to check "qimode == V16QImode && !TARGET_AVX512VL" to avoid VPERMQ:

diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 4e16aedc5c1..450035ea9e6 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -24493,7 +24493,7 @@ ix86_expand_vecop_qihi2 (enum rtx_code code, rtx dest,
rtx op1, rtx op2)
   bool op2vec = GET_MODE_CLASS (GET_MODE (op2)) == MODE_VECTOR_INT;
   bool uns_p = code != ASHIFTRT;

-  if ((qimode == V16QImode && !TARGET_AVX2)
+  if ((qimode == V16QImode && !TARGET_AVX512VL)
       || (qimode == V32QImode && (!TARGET_AVX512BW || !TARGET_EVEX512))
       /* There are no V64HImode instructions.  */
       || qimode == V64QImode)

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com]

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

Uroš Bizjak <ubizjak at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-05-17

--- Comment #8 from Uroš Bizjak <ubizjak at gmail dot com> ---
A better patch:

--cut here--
diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index 4e16aedc5c1..88bfc43201b 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -24493,6 +24493,10 @@ ix86_expand_vecop_qihi2 (enum rtx_code code, rtx dest,
rtx op1, rtx op2)
   bool op2vec = GET_MODE_CLASS (GET_MODE (op2)) == MODE_VECTOR_INT;
   bool uns_p = code != ASHIFTRT;

+  /* ??? VPERMQ is slow and VPMOWVB is only available under AVX512BW.  */
+  if (!TARGET_AVX512BW)
+    return false;
+
   if ((qimode == V16QImode && !TARGET_AVX2)
       || (qimode == V32QImode && (!TARGET_AVX512BW || !TARGET_EVEX512))
       /* There are no V64HImode instructions.  */
--cut here--

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com]

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

--- Comment #9 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Uroš Bizjak from comment #8)
> A better patch:

The real issue is that the following permutation (truncation):

+      for (i = 0; i < d.nelt; ++i)
+       d.perm[i] = i * 2;
+
+      ok = ix86_expand_vec_perm_const_1 (&d);

results in a slow code involving VPERMQ. Ideally, ix86_expand_vec_perm_const_1
should emit faster code for truncation, because this will benefit other code as
well.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

--- Comment #10 from Haochen Jiang <haochen.jiang at intel dot com> ---
A patch like Comment 8 could definitely solve the problem. But I need to test
more benchmarks to see if there is surprise.

But, yes, as Uros said in Comment 9, maybe there is a chance we could do it
better.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[liuhongt at gcc dot gnu.org]

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

--- Comment #11 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Haochen Jiang from comment #10)
> A patch like Comment 8 could definitely solve the problem. But I need to
> test more benchmarks to see if there is surprise.
> 
> But, yes, as Uros said in Comment 9, maybe there is a chance we could do it
> better.

Could you add "arch=skylake-avx512" to target_clones and try disable whole
ix86_expand_vecop_qihi2 to see if there's any performance improvement?
For x86, cross-lane permutation(truncation) is not very efficient(3-4 cycles
for both vpermq and vpmovwb).

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

--- Comment #12 from Haochen Jiang <haochen.jiang at intel dot com> ---
(In reply to Hongtao Liu from comment #11)
> (In reply to Haochen Jiang from comment #10)
> > A patch like Comment 8 could definitely solve the problem. But I need to
> > test more benchmarks to see if there is surprise.
> > 
> > But, yes, as Uros said in Comment 9, maybe there is a chance we could do it
> > better.
> 
> Could you add "arch=skylake-avx512" to target_clones and try disable whole
> ix86_expand_vecop_qihi2 to see if there's any performance improvement?
> For x86, cross-lane permutation(truncation) is not very efficient(3-4 cycles
> for both vpermq and vpmovwb).

When I disable/enable ix86_expand_vecop_qihi2 with arch=skylake-avx512 on
trunk, there is no performance regression comparing to GCC13 + avx2.

It seems that the regression only happens when GCC14 + avx2.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com]

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

--- Comment #13 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Haochen Jiang from comment #12)
> (In reply to Hongtao Liu from comment #11)
> > (In reply to Haochen Jiang from comment #10)
> > > A patch like Comment 8 could definitely solve the problem. But I need to
> > > test more benchmarks to see if there is surprise.
> > > 
> > > But, yes, as Uros said in Comment 9, maybe there is a chance we could do it
> > > better.
> > 
> > Could you add "arch=skylake-avx512" to target_clones and try disable whole
> > ix86_expand_vecop_qihi2 to see if there's any performance improvement?
> > For x86, cross-lane permutation(truncation) is not very efficient(3-4 cycles
> > for both vpermq and vpmovwb).
> 
> When I disable/enable ix86_expand_vecop_qihi2 with arch=skylake-avx512 on
> trunk, there is no performance regression comparing to GCC13 + avx2.
> 
> It seems that the regression only happens when GCC14 + avx2.

This is what the patch in Comment #8 prevents. skylake-avx512 enables
TARGET_AVX512BW, so VPMOVB is emitted instead of problematic VPERMQ.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[liuhongt at gcc dot gnu.org]

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

--- Comment #14 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
(In reply to Uroš Bizjak from comment #13)
> (In reply to Haochen Jiang from comment #12)
> > (In reply to Hongtao Liu from comment #11)
> > > (In reply to Haochen Jiang from comment #10)
> > > > A patch like Comment 8 could definitely solve the problem. But I need to
> > > > test more benchmarks to see if there is surprise.
> > > > 
> > > > But, yes, as Uros said in Comment 9, maybe there is a chance we could do it
> > > > better.
> > > 
> > > Could you add "arch=skylake-avx512" to target_clones and try disable whole
> > > ix86_expand_vecop_qihi2 to see if there's any performance improvement?
> > > For x86, cross-lane permutation(truncation) is not very efficient(3-4 cycles
> > > for both vpermq and vpmovwb).
> > 
> > When I disable/enable ix86_expand_vecop_qihi2 with arch=skylake-avx512 on
> > trunk, there is no performance regression comparing to GCC13 + avx2.
> > 
> > It seems that the regression only happens when GCC14 + avx2.
> 
> This is what the patch in Comment #8 prevents. skylake-avx512 enables
> TARGET_AVX512BW, so VPMOVB is emitted instead of problematic VPERMQ.
Yes, the patch looks good to me.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

--- Comment #15 from Haochen Jiang <haochen.jiang at intel dot com> ---
I am doing like this way. Suppose should be same as Comment 8.

diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
index a6132911e6a..1e8334877d6 100644
--- a/gcc/config/i386/i386-expand.cc
+++ b/gcc/config/i386/i386-expand.cc
@@ -24323,8 +24323,8 @@ ix86_expand_vecop_qihi2 (enum rtx_code code, rtx dest,
rtx op1, rtx op2)
   bool op2vec = GET_MODE_CLASS (GET_MODE (op2)) == MODE_VECTOR_INT;
   bool uns_p = code != ASHIFTRT;

-  if ((qimode == V16QImode && !TARGET_AVX2)
-      || (qimode == V32QImode && (!TARGET_AVX512BW || !TARGET_EVEX512))
+  if (!TARGET_AVX512BW
+      || (qimode == V32QImode && !TARGET_EVEX512)
       /* There are no V64HImode instructions.  */
       || qimode == V64QImode)

Should we also run a SPEC on with -O2 -mtune=generic -march=x86-64-v3 to see if
there is any surprise?

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[liuhongt at gcc dot gnu.org]

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

--- Comment #16 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
> Should we also run a SPEC on with -O2 -mtune=generic -march=x86-64-v3 to see
> if there is any surprise?

Sure, I guess no.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[ubizjak at gmail dot com]

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

--- Comment #17 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Haochen Jiang from comment #15)
> I am doing like this way. Suppose should be same as Comment 8.

Yes, but IMO the patch in Comment #8 better describes where the problem is.

Please note that without VPMOVWB we fall-back to the original
ix86_expand_vecop_qihi, where the expansion is implemented in a different way.

(BTW: If there is a better way to emulate VPMOVWB, it should be implemented in
vec-perm routines, it will universally benefit this permutation. In this case,
early exit, as introduced in the mentioned patch, could be removed.)

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

--- Comment #18 from Haochen Jiang <haochen.jiang at intel dot com> ---
SPEC

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

--- Comment #19 from Haochen Jiang <haochen.jiang at intel dot com> ---
(In reply to Haochen Jiang from comment #18)
> SPEC

SPEC seems all same binary to me. So there is no surprise.

I suppose let's go with patch from Uros to just emphasize the problem.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[cvs-commit at gcc dot gnu.org]

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

--- Comment #20 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Haochen Jiang <jianghc@gcc.gnu.org>:

https://gcc.gnu.org/g:73a167cfa225d5ee7092d41596b9fea1719898ff

commit r15-764-g73a167cfa225d5ee7092d41596b9fea1719898ff
Author: Haochen Jiang <haochen.jiang@intel.com>
Date:   Tue May 21 14:10:43 2024 +0800

    i386: Disable ix86_expand_vecop_qihi2 when !TARGET_AVX512BW

    Since vpermq is really slow, we should avoid using it for permutation
    when vpmovwb is not available (needs AVX512BW) for ix86_expand_vecop_qihi2
    and fall back to ix86_expand_vecop_qihi.

    gcc/ChangeLog:

            PR target/115069
            * config/i386/i386-expand.cc (ix86_expand_vecop_qihi2):
            Do not enable the optimization when AVX512BW is not enabled.

    gcc/testsuite/ChangeLog:

            PR target/115069
            * gcc.target/i386/pr115069.c: New.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Haochen Jiang
<jianghc@gcc.gnu.org>:

https://gcc.gnu.org/g:1ad5c9d524d8fa99773045e75da04ae958012085

commit r14-10229-g1ad5c9d524d8fa99773045e75da04ae958012085
Author: Haochen Jiang <haochen.jiang@intel.com>
Date:   Tue May 21 14:10:43 2024 +0800

    i386: Disable ix86_expand_vecop_qihi2 when !TARGET_AVX512BW

    Since vpermq is really slow, we should avoid using it for permutation
    when vpmovwb is not available (needs AVX512BW) for ix86_expand_vecop_qihi2
    and fall back to ix86_expand_vecop_qihi.

    gcc/ChangeLog:

            PR target/115069
            * config/i386/i386-expand.cc (ix86_expand_vecop_qihi2):
            Do not enable the optimization when AVX512BW is not enabled.

    gcc/testsuite/ChangeLog:

            PR target/115069
            * gcc.target/i386/pr115069.c: New.

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[haochen.jiang at intel dot com]

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

--- Comment #22 from Haochen Jiang <haochen.jiang at intel dot com> ---
Fixed in GCC14 and GCC15

[Bug target/115069] [14/15 regression] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[liuhongt at gcc dot gnu.org]

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

Hongtao Liu <liuhongt at gcc dot gnu.org> changed:

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

--- Comment #23 from Hongtao Liu <liuhongt at gcc dot gnu.org> ---
Fixed in GCC15 and GCC14.2