[Bug c++/100305] New: ICE in output_operand_lossage with -march=armv8.2-a -O3

[Bug c++/100305] New: ICE in output_operand_lossage with -march=armv8.2-a -O3

[gilles.gouaillardet at gmail dot com]

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

            Bug ID: 100305
           Summary: ICE in output_operand_lossage with -march=armv8.2-a
                    -O3
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 50696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50696&action=edit
a (compressed) preprocessed reproducer

This is a new bug with the g++ compiler I found when building GROMACS on
aarch64 with -O3.

-O2 works fine, and so does x86_64. I was only able to reproduce the issue on
aarch64 (initially with SVE, but same outcome without it)

The compiler crashed with the following stack trace:

$ ~/local/gcc-latest/bin/g++ -c -O3 -march=armv8.2-a readpull.i 
during RTL pass: final
readpull.cpp: In function 'std::vector<std::__cxx11::basic_string<char> >
read_pullparams(std::vector<t_inpfile>*, pull_params_t*, warninp_t)':
readpull.cpp:96:1: internal compiler error: output_operand: invalid expression
as operand
   96 | }
      | ^
0xc66ab7 output_operand_lossage(char const*, ...)
        ../../../src/gcc-latest/gcc/final.c:3627
0xc67283 output_addr_const(_IO_FILE*, rtx_def*)
        ../../../src/gcc-latest/gcc/final.c:4184
0xc66d0f output_address(machine_mode, rtx_def*)
        ../../../src/gcc-latest/gcc/final.c:4085
0xc66c4b output_operand(rtx_def*, int)
        ../../../src/gcc-latest/gcc/final.c:4069
0xc6769f output_asm_insn(char const*, rtx_def**)
        ../../../src/gcc-latest/gcc/final.c:3981
0xc6b84f output_asm_insn(char const*, rtx_def**)
        ../../../src/gcc-latest/gcc/final.c:3858
0xc6b84f final_scan_insn_1
        ../../../src/gcc-latest/gcc/final.c:3125
0xc6be43 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
        ../../../src/gcc-latest/gcc/final.c:3171
0xc6bf63 final_1
        ../../../src/gcc-latest/gcc/final.c:2022
0xc6cc0b rest_of_handle_final
        ../../../src/gcc-latest/gcc/final.c:4676
0xc6cc0b execute
        ../../../src/gcc-latest/gcc/final.c:4754
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/100305] ICE in output_operand_lossage with -march=armv8.2-a -O3

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acoplan at gcc dot gnu.org

--- Comment #1 from Alex Coplan <acoplan at gcc dot gnu.org> ---
*** Bug 100306 has been marked as a duplicate of this bug. ***

[Bug c++/100305] ICE in output_operand_lossage with -march=armv8.2-a -O3

[acoplan at gcc dot gnu.org]

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

Alex Coplan <acoplan at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |12.0
   Last reconfirmed|                            |2021-04-28
     Ever confirmed|0                           |1

--- Comment #2 from Alex Coplan <acoplan at gcc dot gnu.org> ---
Here is a reduced testcase:

typedef double c[3];
typedef int d[3];
typedef struct {
  d e;
} f;
typedef struct {
  f g;
  f h;
} i;
i j;
double k;
int l;
void w(void *);
void x(char);
void u(void *, void *);
void m() {
  char a[4096], n[4096], b[4096], o[4096], p[4096], s[4096], r[4096], t[4096];
  w(t);
  w(p);
  w(n);
  w(b);
  u(a, s);
  char v = r[0];
  c g;
  {
    int q[4096];
    w(q);
    w(o);
  }
  x(v);
  l = 0;
  for (; l < 3; l++) {
    j.g.e[l] = g[l];
    j.h.e[l] = k;
  }
}

[Bug c++/100305] ICE in output_operand_lossage with -march=armv8.2-a -O3

[acoplan at gcc dot gnu.org]

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

--- Comment #3 from Alex Coplan <acoplan at gcc dot gnu.org> ---
The above ICEs with just -O3 or -O2 -ftree-vectorize

[Bug target/100305] [11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[gilles.gouaillardet at gmail dot com]

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

--- Comment #4 from Gilles Gouaillardet <gilles.gouaillardet at gmail dot com> ---
Thanks Alex for the more minimal reproducer.

Sadly, the just released GCC 11.1.0 crashed with this code.

[Bug target/100305] [11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.2

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is the cause here:
(insn:TI 39 32 34 (set (reg:V2DF 34 v2 [118])
        (vec_concat:V2DF (mem/c:DF (plus:DI (reg/f:DI 31 sp)
                    (const_int 32800 [0x8020])) [2 MEM[(double[3] *)_19][0]+0
S8 A128])
            (mem/c:DF (plus:DI (reg:DI 2 x2 [140])
                    (const_int 40 [0x28])) [2 MEM[(double[3] *)_19][1]+0 S8
A64]))) "t88.cc":33:14 2479 {load_pair_lanesdf}
     (expr_list:REG_DEAD (reg:DI 2 x2 [140])
        (nil)))

That mem RTL is not valid.

This instruction is valid before "reload":
t88.cc.291r.ira-(insn 39 32 57 2 (set (reg:V2DF 118)
t88.cc.291r.ira-        (vec_concat:V2DF (mem/c:DF (plus:DI (reg/f:DI 64 sfp)
t88.cc.291r.ira-                    (const_int -16384 [0xffffffffffffc000])) [2
MEM[(double[3] *)_19][0]+0 S8 A128])
t88.cc.291r.ira-            (mem/c:DF (plus:DI (reg/f:DI 64 sfp)
t88.cc.291r.ira:                    (const_int -16376 [0xffffffffffffc008])) [2
MEM[(double[3] *)_19][1]+0 S8 A64]))) "t88.cc":33:14 2479 {load_pair_lanesdf}
t88.cc.291r.ira-     (nil))

But after we get:
t88.cc.292r.reload-(insn 39 65 57 2 (set (reg:V2DF 34 v2 [118])
t88.cc.292r.reload-        (vec_concat:V2DF (mem/c:DF (plus:DI (reg/f:DI 31 sp)
t88.cc.292r.reload-                    (const_int 32800 [0x8020])) [2
MEM[(double[3] *)_19][0]+0 S8 A128])
t88.cc.292r.reload-            (mem/c:DF (plus:DI (reg:DI 2 x2 [140])
t88.cc.292r.reload:                    (const_int 40 [0x28])) [2 MEM[(double[3]
*)_19][1]+0 S8 A64]))) "t88.cc":33:14 2479 {load_pair_lanesdf}
t88.cc.292r.reload-     (nil))

[Bug target/100305] [11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is one slightly more reduced testcase:typedef struct {
  int g[3];
  int h[3];
} i;
i j;
double k;
int l;
void w(void *);
void x(char);
void u(void *, void *);
void m() {
  char a[4096], o[4096], s[4096], r[4096], t[4*4096];
  w(a);
  u(t, s);
  char v = r[0];
  double g[3];
  {
    int q[4096];
    w(q);
    w(o);
  }
  x(v);
  l = 0;
  for (; l < 3; l++) {
    j.g[l] = g[l];
    j.h[l] = k;
  }
}

----- CUT ----
For some reason removing the typedef and just using the struct directly causes
slightly different behavior.

[Bug target/100305] [11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |rsandifo at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |rsandifo at gcc dot gnu.org

--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Here's another reproducer (compile at -O):

typedef double v2df __attribute__((vector_size(16)));

#define N 4096
void consume (void *);
v2df
foo (void)
{
  double x[N+2];
  consume (x);
  return (v2df) { x[N], x[N + 1] };
}

The x[N] address is valid for V2DF but not DF.

I think there's also a latent problem with the way that aarch64 handles
paired memory accesses in general.  Even if the rtx_equal_p conditions
are separated by the right constant amount before RA, there's no guarantee
that they'll remain that way after RA, since the two addresses can be
reloaded differently.  We just get lucky that nothing rechecks the
rtx_equal_p condition after RA (even though in principle any post-RA
pass would be entitled to assume that the condition is true).

[Bug target/100305] [11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:668df9e769e7d89bcefa07f72b68dcae9a8f3970

commit r12-219-g668df9e769e7d89bcefa07f72b68dcae9a8f3970
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Wed Apr 28 17:54:52 2021 +0100

    aarch64: Fix address mode for vec_concat pattern [PR100305]

    The load_pair_lanes<mode> patterns match a vec_concat of two
    adjacent 64-bit memory locations as a single 128-bit load.
    The Utq constraint made sure that the address was suitable
    for a 128-bit vector, but this meant that it allowed some
    addresses that aren't valid for the 64-bit element mode.

    Two obvious fixes were:

    (1) Continue to accept addresses that aren't valid for the element
        modes.  This would mean changing the mode of operands[1] before
        printing it.  It would also mean using a custom predicate instead
        of the current memory_operand.

    (2) Restrict addresses to the intersection of those that are valid
        element and vector addresses.

    The problem with (1) is that, as well as being more complicated,
    it doesn't deal with the fact that we still have a memory_operand
    for the second element.  If we encourage the first operand to be
    outside the range of a normal element memory_operand, we'll have
    to reload the second operand to make it valid.  This reload will
    often be dead code, but will be kept around because the RTL
    pattern makes it look as though the second element address
    is still needed.

    This patch therefore does (2) instead.

    As mentioned in the PR notes, I think we have a general problem
    with the way that the aarch64 port deals with paired addresses.
    There's nothing to guarantee that the two addresses will be
    reloaded in a way that keeps them âobviouslyâ adjacent, so the
    rtx_equal_p conditions could fail if something rechecked them
    later.

    For this particular pattern, I think it would be better to teach
    simplify-rtx.c to fold the vec_concat to a normal vector memory
    reference, to remove any suggestion that targets should try to
    match the unsimplified form.  That obviously wouldn't be suitable
    for backports though.

    gcc/
            PR target/100305
            * config/aarch64/constraints.md (Utq): Require the address to
            be valid for both the element mode and for V2DImode.

    gcc/testsuite/
            PR target/100305
            * gcc.c-torture/compile/pr100305.c: New test.

[Bug target/100305] [10/11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression] aarch64: |[10/11/12 Regression]
                   |ICE in                      |aarch64: ICE in
                   |output_operand_lossage with |output_operand_lossage with
                   |-O3                         |-O3

--- Comment #9 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed on trunk so far.  The reproducer in comment 7 is a regression
in GCC 10+, so I'll backport to GCC 11 and GCC 10 in the coming days.

[Bug target/100305] [10/11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:cd0a059bd384da58d43674496a79ecb7de610800

commit r11-8323-gcd0a059bd384da58d43674496a79ecb7de610800
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Thu Apr 29 09:27:52 2021 +0100

    aarch64: Fix address mode for vec_concat pattern [PR100305]

    The load_pair_lanes<mode> patterns match a vec_concat of two
    adjacent 64-bit memory locations as a single 128-bit load.
    The Utq constraint made sure that the address was suitable
    for a 128-bit vector, but this meant that it allowed some
    addresses that aren't valid for the 64-bit element mode.

    Two obvious fixes were:

    (1) Continue to accept addresses that aren't valid for the element
        modes.  This would mean changing the mode of operands[1] before
        printing it.  It would also mean using a custom predicate instead
        of the current memory_operand.

    (2) Restrict addresses to the intersection of those that are valid
        element and vector addresses.

    The problem with (1) is that, as well as being more complicated,
    it doesn't deal with the fact that we still have a memory_operand
    for the second element.  If we encourage the first operand to be
    outside the range of a normal element memory_operand, we'll have
    to reload the second operand to make it valid.  This reload will
    often be dead code, but will be kept around because the RTL
    pattern makes it look as though the second element address
    is still needed.

    This patch therefore does (2) instead.

    As mentioned in the PR notes, I think we have a general problem
    with the way that the aarch64 port deals with paired addresses.
    There's nothing to guarantee that the two addresses will be
    reloaded in a way that keeps them âobviouslyâ adjacent, so the
    rtx_equal_p conditions could fail if something rechecked them
    later.

    For this particular pattern, I think it would be better to teach
    simplify-rtx.c to fold the vec_concat to a normal vector memory
    reference, to remove any suggestion that targets should try to
    match the unsimplified form.  That obviously wouldn't be suitable
    for backports though.

    gcc/
            PR target/100305
            * config/aarch64/constraints.md (Utq): Require the address to
            be valid for both the element mode and for V2DImode.

    gcc/testsuite/
            PR target/100305
            * gcc.c-torture/compile/pr100305.c: New test.

    (cherry picked from commit 668df9e769e7d89bcefa07f72b68dcae9a8f3970)

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:62a44a9797edce11b1f7051ea0016ee975d41233

commit r12-283-g62a44a9797edce11b1f7051ea0016ee975d41233
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 29 11:42:08 2021 +0200

    testsuite: Remove dg-options from pr100305.c [PR100305]

    The test FAILs on i?86-linux (due to -Wpsabi warnings).  But, on closer
    inspection it seems there is another problem, the dg-options in the
testcase
    means that the test is compiled with -O0 -O, -O1 -O, -O2 -O, -O3 -O, -Os -O
    etc. options, so effectively is tested multiple times with the same
options.

    Fixed by dropping the dg-options line, then we have -w by default and
iterate
    over all the optimization levels (including the -O).

    2021-04-29  Jakub Jelinek  <jakub@redhat.com>

            PR target/100305
            * gcc.c-torture/compile/pr100305.c: Remove dg-options.  Add PR
line.

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:a515ce926b9d779922debc33ecad424c9ac22c65

commit r11-8327-ga515ce926b9d779922debc33ecad424c9ac22c65
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 29 11:42:08 2021 +0200

    testsuite: Remove dg-options from pr100305.c [PR100305]

    The test FAILs on i?86-linux (due to -Wpsabi warnings).  But, on closer
    inspection it seems there is another problem, the dg-options in the
testcase
    means that the test is compiled with -O0 -O, -O1 -O, -O2 -O, -O3 -O, -Os -O
    etc. options, so effectively is tested multiple times with the same
options.

    Fixed by dropping the dg-options line, then we have -w by default and
iterate
    over all the optimization levels (including the -O).

    2021-04-29  Jakub Jelinek  <jakub@redhat.com>

            PR target/100305
            * gcc.c-torture/compile/pr100305.c: Remove dg-options.  Add PR
line.

    (cherry picked from commit 62a44a9797edce11b1f7051ea0016ee975d41233)

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[gilles.gouaillardet at gmail dot com]

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

--- Comment #13 from Gilles Gouaillardet <gilles.gouaillardet at gmail dot com> ---
Thanks Richard for the quick fix.

I am happy to confirm that the latest trunk passes the three reproducers
included in this ticket.

However, the latest gcc-11 branch only passes the mini reproducer you posted
(and crashes with a similar stack trace with Andrew's reproducer and the one I
trimmed from GROMACS)

FWIW, I am still unable to build GROMACS 2021.1 with the latest trunk (both
neon and SVE, now checking x86_64), but this is a different issue (looks like a
C++ frontend issue, unless this is a legit error in the application).

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[rsandifo at gcc dot gnu.org]

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

--- Comment #14 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Gilles Gouaillardet from comment #13)
> Thanks Richard for the quick fix.
> 
> I am happy to confirm that the latest trunk passes the three reproducers
> included in this ticket.
> 
> However, the latest gcc-11 branch only passes the mini reproducer you posted
> (and crashes with a similar stack trace with Andrew's reproducer and the one
> I trimmed from GROMACS)
Hmm, those also pass for me on the branch (after
g:cd0a059bd384da58d43674496a79ecb7de610800).  However, it's certainly
possible that some of the other patterns have a similar bug.  I'll try
a few variations to see if I can reproduce.

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |11.3

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #16 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:3e44c89e672ec18ce31edecf5b5bac980ce411e5

commit r10-10040-g3e44c89e672ec18ce31edecf5b5bac980ce411e5
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Aug 17 15:14:22 2021 +0100

    aarch64: Fix address mode for vec_concat pattern [PR100305]

    The load_pair_lanes<mode> patterns match a vec_concat of two
    adjacent 64-bit memory locations as a single 128-bit load.
    The Utq constraint made sure that the address was suitable
    for a 128-bit vector, but this meant that it allowed some
    addresses that aren't valid for the 64-bit element mode.

    Two obvious fixes were:

    (1) Continue to accept addresses that aren't valid for the element
        modes.  This would mean changing the mode of operands[1] before
        printing it.  It would also mean using a custom predicate instead
        of the current memory_operand.

    (2) Restrict addresses to the intersection of those that are valid
        element and vector addresses.

    The problem with (1) is that, as well as being more complicated,
    it doesn't deal with the fact that we still have a memory_operand
    for the second element.  If we encourage the first operand to be
    outside the range of a normal element memory_operand, we'll have
    to reload the second operand to make it valid.  This reload will
    often be dead code, but will be kept around because the RTL
    pattern makes it look as though the second element address
    is still needed.

    This patch therefore does (2) instead.

    As mentioned in the PR notes, I think we have a general problem
    with the way that the aarch64 port deals with paired addresses.
    There's nothing to guarantee that the two addresses will be
    reloaded in a way that keeps them âobviouslyâ adjacent, so the
    rtx_equal_p conditions could fail if something rechecked them
    later.

    For this particular pattern, I think it would be better to teach
    simplify-rtx.c to fold the vec_concat to a normal vector memory
    reference, to remove any suggestion that targets should try to
    match the unsimplified form.  That obviously wouldn't be suitable
    for backports though.

    gcc/
            PR target/100305
            * config/aarch64/constraints.md (Utq): Require the address to
            be valid for both the element mode and for V2DImode.

    gcc/testsuite/
            PR target/100305
            * gcc.c-torture/compile/pr100305.c: New test.

    (cherry picked from commit 668df9e769e7d89bcefa07f72b68dcae9a8f3970)

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #17 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
Fixed for GCC 10+.