[Bug tree-optimization/109491] New: Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[Bug tree-optimization/109491] New: Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[pthaugen at gcc dot gnu.org]

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

            Bug ID: 109491
           Summary: Segfault in tree-ssa-sccvn.cc:expressions_equal_p()
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pthaugen at gcc dot gnu.org
                CC: bergner at gcc dot gnu.org, segher at kernel dot crashing.org
  Target Milestone: ---
              Host: powerpc64
            Target: powerpc64
             Build: powerpc64

Created attachment 54845
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54845&action=edit
Reduced testcase

Hitting the following segfault on the attached testcase (sorry for size, but it
is about 1% of original size). Appears to only happen with GCC 13, compiles
fine with GCC 12.

~/install/gcc/trunk/bin/g++ -mcpu=power8 -std=c++14 -S -O2 partial.ii 
(...misc warnings...)
during GIMPLE pass: fre
partial.ii: In function ‘void gemm_complex(const DataMapper&, const
complex<float>*, const complex<float>*, long int, long int, long int,
complex<float>, long int, long int, long int, long int) [with
<template-parameter-1-1> = complex<float>; <template-parameter-1-2> =
complex<float>; <template-parameter-1-3> = complex<float>;
<template-parameter-1-4> = float; Packet = __vector(4) float; Packetc =
Packet2cf; <template-parameter-1-7> = __vector(4) float; DataMapper =
blas_data_mapper; int accRows = 4; int accCols = 4; int ConjugateLhs = 0; int
ConjugateRhs = 0; int LhsIsReal = 0; int RhsIsReal = 0]’:
partial.ii:1096:6: internal compiler error: Segmentation fault
 1096 | void gemm_complex(const DataMapper &res, const complex<float> *blockAc,
      |      ^~~~~~~~~~~~
0x10f6fadb crash_signal
        /home/pthaugen/src/gcc/trunk/gcc/gcc/toplev.cc:314
0x11222818 expressions_equal_p(tree_node*, tree_node*, bool)
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:6411
0x112229a7 vn_reference_op_eq
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:216
0x11222bfb vn_reference_eq(vn_reference_s const*, vn_reference_s const*)
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:858
0x11243837 vn_reference_hasher::equal(vn_reference_s const*, vn_reference_s
const*)
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:250
0x11243837 hash_table<vn_reference_hasher, false,
xcallocator>::find_slot_with_hash(vn_reference_s* const&, unsigned int,
insert_option)
        /home/pthaugen/src/gcc/trunk/gcc/gcc/hash-table.h:1059
0x1122f43b vn_reference_lookup_2
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:2336
0x11101b8f walk_non_aliased_vuses(ao_ref*, tree_node*, bool, void* (*)(ao_ref*,
tree_node*, void*), void* (*)(ao_ref*, tree_node*, void*, translate_flags*),
tree_node* (*)(tree_node*), unsigned int&, void*)
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-alias.cc:3847
0x11233447 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool, tree_node**, tree_node*, bool)
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:3967
0x11238cc7 visit_reference_op_load
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:5683
0x11238cc7 visit_stmt
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:6187
0x1123986f process_bb
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:7918
0x1123bcdb do_rpo_vn_1
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:8518
0x1123db83 execute
        /home/pthaugen/src/gcc/trunk/gcc/gcc/tree-ssa-sccvn.cc:8676
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 tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0
            Summary|Segfault in                 |[13 Regression] Segfault in
                   |tree-ssa-sccvn.cc:expressio |tree-ssa-sccvn.cc:expressio
                   |ns_equal_p()                |ns_equal_p()
           Keywords|                            |ice-on-valid-code

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[pthaugen at gcc dot gnu.org]

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

--- Comment #1 from pthaugen at gcc dot gnu.org ---
Note this only happens on a BE system, compiles fine on LE.

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I should note while trying to test this on x86_64 (removing the altivec
specific intrinsics) the compile time was large even for -O0. It was ok with
-fsyntax-only though.

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 54846
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54846&action=edit
Removed altivec intrinsics

This changes the altivec intrinsics except for __builtin_vec_mergeh which I
just commented out. And the compile time seems really high.

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to pthaugen from comment #0)
> Created attachment 54845 [details]
> Reduced testcase
> 
> Hitting the following segfault on the attached testcase (sorry for size, but
> it is about 1% of original size). Appears to only happen with GCC 13,
> compiles fine with GCC 12.

Can you git bisect this to find the offending commit?

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[pthaugen at gcc dot gnu.org]

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

--- Comment #5 from pthaugen at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #4)
> 
> Can you git bisect this to find the offending commit?

Yes, I was going to start that.

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Doesn't happen with a cross from x86_64 to powerpc64-suse-linux.  I've just
used

./configure --target=powerpc64-suse-linux --enable-languages=c,c++,lto

and

./cc1plus -quiet -I include t.ii -mcpu=power8 -std=c++14 -O2

and yes, it's very slow.

I wonder if at the point of the crash e1 or e2 are NULL or whether we
have garbage and what the actual hashtable entry / lookup val are.

How did you configure?

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-04-13
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ah, the original reduced testcase reproduces the issue with a cross.  Let me
have a look.

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
So we have a NULL op, in this case

(gdb) p *vro1
$4 = {opcode = TARGET_MEM_REF, clique = 0, base = 0, reverse = 0, align = 0, 
  off = {coeffs = {-1}}, type = <real_type 0x7ffff7309930 float>, 
  op0 = <tree 0x0>, op1 = <tree 0x0>, op2 = <integer_cst 0x7ffff12cd138>}
(gdb) p *vro2
$5 = {opcode = TARGET_MEM_REF, clique = 0, base = 0, reverse = 0, align = 0, 
  off = {coeffs = {-1}}, type = <real_type 0x7ffff7309930 float>, 
  op0 = <ssa_name 0x7ffff656f120 8261>, op1 = <tree 0x0>, 
  op2 = <integer_cst 0x7ffff6119528>}

I think we're lucky to not hit this more often (good hash!) and unlucky
here (bad hash!).  We used to have

  /* If only one of them is null, they cannot be equal.  */
  if (!e1 || !e2)
    return false;

but r11-4982-g4d6b8d4213376e removed that.  r11-5047-gaaccdb9cec423e fixed
one case where that was previously needed.

Now, for TARGET_MEM_REF a NULL operand is different from an operand
with no effect (a zero) since the addressing mode is different.  So
canonicalization in copy_reference_ops_from_ref is unwanted (we'd use
that representation for PRE insertion for example).

The safest option is to restore the above check.

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note it's IPA consuming the most time for me, but it might be just another case
of always_inline abuse (having always_inline across a deep call stack can
exponentially increase compile-time)

[Bug tree-optimization/109491] [13 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r13-7166-ga37783de23c067d6a26374ff29c014e49604035c
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Apr 13 14:09:30 2023 +0200

    tree-optimization/109491 - ICE in expressions_equal_p

    At some point I elided the NULL pointer check in expressions_equal_p
    because it shouldn't be necessary not realizing that for example
    TARGET_MEM_REF has optional operands we cannot substitute with
    something non-NULL with the same semantics.  The following does the
    simple thing and restore the check removed in r11-4982.

            PR tree-optimization/109491
            * tree-ssa-sccvn.cc (expressions_equal_p): Restore the
            NULL operands test.

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|13.0                        |11.4
            Summary|[13 Regression] Segfault in |[11/12 Regression] Segfault
                   |tree-ssa-sccvn.cc:expressio |in
                   |ns_equal_p()                |tree-ssa-sccvn.cc:expressio
                   |                            |ns_equal_p()

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk, the issue is latent though.

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[chip.kerchner at ibm dot com]

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

--- Comment #12 from Chip Kerchner <chip.kerchner at ibm dot com> ---
> having always_inline across a deep call stack can exponentially increase compile-time

Do you think it would be worth requesting a feature to reduce the compilation
times in situations like this?  Ideally exponentially is not a good thing.

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Chip Kerchner from comment #12)
> > having always_inline across a deep call stack can exponentially increase compile-time
> 
> Do you think it would be worth requesting a feature to reduce the
> compilation times in situations like this?  Ideally exponentially is not a
> good thing.

Well, suppose you have

static __attribute__((always_inline)) inline void large_leaf () { /* large */ }

static __attribute__((always_inline)) inline void inter1 () { large_leaf (); }

static __attribute__((always_inline)) inline void inter2 () { inter1 (); inter1
(); }

static __attribute__((always_inline)) inline void inter3 () { inter2 (); inter2
(); }

void final () { inter3 (); inter3 (); }

then of course you end up with 8 copies of large_leaf in 'final' (you asked
for it).  Now, implementation wise it gets worse because we also fully
materialize the intermediate inter1, inter2 and inter3 with one and two
and four copies.  That's "only" double of the work but if it's single
call chains the overhead is larger.

There are specific cases where we could do better and IIRC some intermediate
updating of the costs blows up here as well (we build a "fat" callgraph
with inlined edges and inlined node clones).

In the end it requires somebody to sit down and see where to improve things
algorithmically - eventually eschewing the simple topological processing
for all inline candidates in favor of first resolving always-inlines in
the most optimal way, taking advantage of the fact that in principle
we do not need their bodies anymore.

I wasn't able to find a bug tracking this very specific issue so I created
one.  I have opened PR109509 for this.

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[chip.kerchner at ibm dot com]

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

--- Comment #14 from Chip Kerchner <chip.kerchner at ibm dot com> ---
Just one more question and then I'll switch to the new bug.

Would it help any if the functions that are "always_inline" be changed from
non-static to static?

Eigen's approach (where this code originally came from - yes, it could be
definite be better) is to use non-static inlined function.

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenther at suse dot de]

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

--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 14 Apr 2023, chip.kerchner at ibm dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
> 
> --- Comment #14 from Chip Kerchner <chip.kerchner at ibm dot com> ---
> Just one more question and then I'll switch to the new bug.
> 
> Would it help any if the functions that are "always_inline" be changed from
> non-static to static?
> 
> Eigen's approach (where this code originally came from - yes, it could be
> definite be better) is to use non-static inlined function.

I don't think so, you'd have to try.  The compile-time issues usually
show up when you have a multi-level call chain all being always-inline
as we then repeatedly early-optimize the same code over and over.
Usually we do that so functions become smaller for the inline heuristics
but for always-inlines that wouldn't matter (but of course making the
body smaller if there's more than one caller can still pay off).

It really depends on the actual callgraph and code which is also
why it is hard to improve.

Another probably more common with C++ code issue would be that we
inline into not optimized callers which means calls that are
almost trivially unreachable have not been eliminated yet but
get inlined.  Usual heuristics would only inline small functions
at this level and defer inlining of larger functions to IPA time
at which point the calls might be eliminated already.  Likewise
calls attributed const or pure might be subject to CSE but
always-inline forces them to be inlined before CSE.

So what you could try is instead of always_inline use
__attribute__((flatten)) on the functions containing the
loop kernels for example and then disable early inlining
(otherwise flatten is applied there as well) with -fno-early-inlining.

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Just to make the point, for the testcase when compiling with -O -g I see

> grep 'INLINE_ENTRY' t.ii.031t.einline | wc -l 
16976
> grep 'INLINE_ENTRY' t.ii.034t.ccp1 | wc -l
15530
> grep 'INLINE_ENTRY' t.ii.043t.cddce1 | wc -l
14180

so there's some (not the majority) of inlined bodies removed by the first
constant propagation pass and more at the end of the early optimization
phase.  It's a bit unreliable since not all inlines result in a INLINE_ENTRY
debug stmt.  It also shows this likely isn't the biggest issue.

A factor of two compared to clang can be easily attributed to bigger
IL representation as well.

For me the testcase with -O2 builds in 17s with release checking enabled
so that's not too bad (on a fast x86 machine).  The most expensive pass
is RTL PRE, accounting for 1/4 of the compile-time.  With -O3 it's even
faster.

With -Dalways_inline=user the compile time reduces to 3s though.

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #17 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
With a cross on znver3 machine I get with ./xgcc -B ./ -mcpu=power8 -std=c++14
-O2 tt.cc --verbose -Q :

 phase opt and generate             :  13.19 ( 99%)   0.35 ( 95%)  13.53 ( 99%)
  408M ( 94%)
 callgraph functions expansion      :  10.19 ( 77%)   0.15 ( 41%)  10.33 ( 76%)
  193M ( 45%)
 callgraph ipa passes               :   2.97 ( 22%)   0.20 ( 54%)   3.17 ( 23%)
  203M ( 47%)
 df live regs                       :   0.65 (  5%)   0.00 (  0%)   0.62 (  5%)
    0  (  0%)
 alias stmt walking                 :   1.19 (  9%)   0.03 (  8%)   1.25 (  9%)
 6915k (  2%)
 tree Early VRP                     :   0.63 (  5%)   0.01 (  3%)   0.58 (  4%)
   16M (  4%)
 PRE                                :   2.81 ( 21%)   0.01 (  3%)   2.83 ( 21%)
  349k (  0%)
 scheduling                         :   1.00 (  8%)   0.00 (  0%)   0.99 (  7%)
 1997k (  0%)


inliner is:
 ipa inlining heuristics            :   0.49 (  4%)   0.00 (  0%)   0.47 (  3%)
 4429k (  1%)
 integration                        :   0.19 (  1%)   0.04 ( 11%)   0.28 (  2%)
  117M ( 27%)

So inlining itself seems to be in control.

With RTL SSA we may be able to replace RTL PRE with GVN-PRE :)

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[cvs-commit at gcc dot gnu.org]

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

--- Comment #18 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

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

commit r12-9413-gba02c6706cc502ee64b9c5d32b08409c44fe967d
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Apr 13 14:09:30 2023 +0200

    tree-optimization/109491 - ICE in expressions_equal_p

    At some point I elided the NULL pointer check in expressions_equal_p
    because it shouldn't be necessary not realizing that for example
    TARGET_MEM_REF has optional operands we cannot substitute with
    something non-NULL with the same semantics.  The following does the
    simple thing and restore the check removed in r11-4982.

            PR tree-optimization/109491
            * tree-ssa-sccvn.cc (expressions_equal_p): Restore the
            NULL operands test.

    (cherry picked from commit a37783de23c067d6a26374ff29c014e49604035c)

[Bug tree-optimization/109491] [11 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-10629-gbb400f9916beab1a650d59c73672ef48aaf71b11
Author: Richard Biener <rguenther@suse.de>
Date:   Thu Apr 13 14:09:30 2023 +0200

    tree-optimization/109491 - ICE in expressions_equal_p

    At some point I elided the NULL pointer check in expressions_equal_p
    because it shouldn't be necessary not realizing that for example
    TARGET_MEM_REF has optional operands we cannot substitute with
    something non-NULL with the same semantics.  The following does the
    simple thing and restore the check removed in r11-4982.

            PR tree-optimization/109491
            * tree-ssa-sccvn.c (expressions_equal_p): Restore the
            NULL operands test.

    (cherry picked from commit a37783de23c067d6a26374ff29c014e49604035c)

[Bug tree-optimization/109491] [11 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to fail|                            |11.3.0
         Resolution|---                         |FIXED
      Known to work|                            |11.3.1

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.