[Bug c++/107411] New: trivial-auto-var-init=zero invalid uninitialized variable warning

[Bug c++/107411] New: trivial-auto-var-init=zero invalid uninitialized variable warning

[davidwelch158 at hotmail dot com]

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

            Bug ID: 107411
           Summary: trivial-auto-var-init=zero invalid uninitialized
                    variable warning
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: davidwelch158 at hotmail dot com
  Target Milestone: ---

Created attachment 53774
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53774&action=edit
preprocessed reproduction case

Compiling this file 

#include <cstdio>

class HostLayer 
{
public:
        int getError();

};  

void queryString(HostLayer& m_host)
{
        const auto& error = m_host.getError();
        printf("%d\n", error);
}

with the command line on x86-64 Ubuntu 22.04

g++ -Werror=uninitialized -ftrivial-auto-var-init=zero   -c OverrideLayer.cpp

and the latest gcc trunk (GCC12 is also affected) produces the warning.

OverrideLayer.cpp: In function ‘void queryString(HostLayer&)’:
OverrideLayer.cpp:12:45: error: ‘D.2933’ is used uninitialized
[-Werror=uninitialized]
   12 |         const auto& error = m_host.getError();
      |                                             ^
OverrideLayer.cpp:12:45: note: ‘D.2933’ was declared here
   12 |         const auto& error = m_host.getError();
      | 

which seems to be invalid and also doesn't identify the problem variable.

Compiling with 

/home/dw/devel/gcc/install/bin/g++ -Werror=uninitialized    -c
OverrideLayer.cpp

finishes without error.

g++ -v
Using built-in specs.
COLLECT_GCC=/home/dw/devel/gcc/install/bin/g++
COLLECT_LTO_WRAPPER=/home/dw/devel/gcc/install/libexec/gcc/x86_64-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../configure --enable-languages=c,c++
--prefix=/home/dw/devel/gcc/install --enable-shared --enable-linker-build-id
--without-included-gettext --enable-threads=posix --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --enable-offload-defaulted
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221025 (experimental) (GCC) 

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:        22.04
Codename:       jammy

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-10-26

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. reduced testcase:
int t();
void f(int);

void j()
{
        const int& e = t();
        f(e);
}

Someone who understands the uininit pass should look into this but the IR at
that point we get is (with -fno-exceptions due to extra clobbers otherwise
which don't make a difference):
  _1 = .DEFERRED_INIT (4, 2, &"D.2374"[0]);
  D.2374 = _1;
  e_6 = .DEFERRED_INIT (8, 2, &"e"[0]);
  _2 = t ();
  D.2374 = _2;
  e_9 = &D.2374;
  _3 = *e_9;
  f (_3);
  D.2374 ={v} {CLOBBER(eol)};

There is no read from D.2374 in the call to t at all and then we do a full
write after the call.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |24639
                 CC|                            |qing.zhao at oracle dot com,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. reduced testcase:
> int t();
> void f(int);
>   
> void j()
> {
> 	const int& e = t();
> 	f(e);
> }
> 
> Someone who understands the uininit pass should look into this but the IR at
> that point we get is (with -fno-exceptions due to extra clobbers otherwise
> which don't make a difference):
>   _1 = .DEFERRED_INIT (4, 2, &"D.2374"[0]);
>   D.2374 = _1;
>   e_6 = .DEFERRED_INIT (8, 2, &"e"[0]);
>   _2 = t ();
>   D.2374 = _2;
>   e_9 = &D.2374;
>   _3 = *e_9;
>   f (_3);
>   D.2374 ={v} {CLOBBER(eol)};
> 
> There is no read from D.2374 in the call to t at all and then we do a full
> write after the call.

We diagnose the

  D.2374 = _1;

store which uses uninitialized _1.  The FE emits

  <<cleanup_point <<< Unknown tree: expr_stmt
    (void) (e = D.2389 = t ();, (const int &) &D.2389;) >>>>>;
  <<cleanup_point <<< Unknown tree: expr_stmt
    f ((int) *e) >>>>>;

note that without -ftrivial-auto-var-init=zero we see

  <bb 2> :
  _6 = t ();

  <bb 3> :
  _1 = _6;
  D.2389 = _1;
  e_8 = &D.2389;
  _2 = *e_8;
  f (_2);

  <bb 4> :
  D.2389 ={v} {CLOBBER(eol)};
  return;

  <bb 5> :
<L0>:
  D.2389 ={v} {CLOBBER(eol)};
  resx 1

while with the flag we have

  <bb 2> :
  _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
  D.2389 = _1;
  e_7 = .DEFERRED_INIT (8, 2, &"e"[0]);
  _9 = t ();

  <bb 3> :
  _2 = _9;
  D.2389 = _2;
  e_11 = &D.2389;
  _3 = *e_11;
  f (_3);

  <bb 4> :
  D.2389 ={v} {CLOBBER(eol)};
  return;

  <bb 5> :
<L0>:
  D.2389 ={v} {CLOBBER(eol)};
  resx 1

The gimplifier instead of

      _1 = t ();
      D.2389 = _1;
      e = &D.2389;
      _2 = *e;
      f (_2);

produces

      _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
      D.2389 = _1;
      e = .DEFERRED_INIT (8, 2, &"e"[0]);
      _2 = t ();
      D.2389 = _2;
      e = &D.2389;
      _3 = *e;
      f (_3);

which is odd and sub-optimal at least.  Doing such things makes us rely
on DSE to elide the uninit "inits".


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> 
> The gimplifier instead of
> 
>       _1 = t ();
>       D.2389 = _1;
>       e = &D.2389;
>       _2 = *e;
>       f (_2);
> 
> produces
> 
>       _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
>       D.2389 = _1;
>       e = .DEFERRED_INIT (8, 2, &"e"[0]);
>       _2 = t ();
>       D.2389 = _2;
>       e = &D.2389;
>       _3 = *e;
>       f (_3);
> 
> which is odd and sub-optimal at least.  Doing such things makes us rely
> on DSE to elide the uninit "inits".

Looks like that "_1 = t ()" was not treated as an initializer, therefore "_1"
was identified as an uninitialized var. "e = &D.2389" has the same issue. 
should "_1 = t ()" be treated as an initializer to _1?

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |larsbj at gullik dot org

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 107793 has been marked as a duplicate of this bug. ***

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trprince at synopsys dot com

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 108780 has been marked as a duplicate of this bug. ***

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qinzhao at gcc dot gnu.org]

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

--- Comment #6 from qinzhao at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> 
> The gimplifier instead of
> 
>       _1 = t ();
>       D.2389 = _1;
>       e = &D.2389;
>       _2 = *e;
>       f (_2);
> 
> produces
> 
>       _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
>       D.2389 = _1;
>       e = .DEFERRED_INIT (8, 2, &"e"[0]);
>       _2 = t ();
>       D.2389 = _2;
>       e = &D.2389;
>       _3 = *e;
>       f (_3);
> 
> which is odd and sub-optimal at least.  Doing such things makes us rely
> on DSE to elide the uninit "inits".

actually, this is because, The simplifier sees the following  IR from FE
(.original)

    const int D.2768;
    const int & e;
  <<cleanup_point <<< Unknown tree: expr_stmt
    (void) (e = D.2768 = t ();, (const int &) &D.2768;) >>>>>;
  <<cleanup_point <<< Unknown tree: expr_stmt
    f ((int) *e) >>>>>;
}

i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization first,
and then see the "CLEANUP_POINT_EXPR" which include the initializations to "e"
and "D.2768". since it doesn't see any connections between these two DECL_EXPRs
and the initializations inside "CLEANUP_POINT_EXPR", it just treats the two
DECL_EXPRs as not initialized, therefore add the .DEFERED_INIT to them.

the best approach to resolve this issue is:

if there is any connection  between DECL_EXPR "D.2768","e" and their
initializations inside "CLEANUP_POINT_EXPR" that can be checked from IR, then
during "gimplify_decl_expr", we can avoid generating .DEFERRED_INIT to them;

my question is: in the current IR from C++ FE, is there any bit I can check to
make sure that the DECL_EXPR "D.2768" and "e" already have initialization
inside "CLEANUP_POINT_EXPR"?

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
> 
> --- Comment #6 from qinzhao at gcc dot gnu.org ---
> (In reply to Richard Biener from comment #2)
> > 
> > The gimplifier instead of
> > 
> >       _1 = t ();
> >       D.2389 = _1;
> >       e = &D.2389;
> >       _2 = *e;
> >       f (_2);
> > 
> > produces
> > 
> >       _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
> >       D.2389 = _1;
> >       e = .DEFERRED_INIT (8, 2, &"e"[0]);
> >       _2 = t ();
> >       D.2389 = _2;
> >       e = &D.2389;
> >       _3 = *e;
> >       f (_3);
> > 
> > which is odd and sub-optimal at least.  Doing such things makes us rely
> > on DSE to elide the uninit "inits".
> 
> actually, this is because, The simplifier sees the following  IR from FE
> (.original)
> 
>     const int D.2768;
>     const int & e;
>   <<cleanup_point <<< Unknown tree: expr_stmt
>     (void) (e = D.2768 = t ();, (const int &) &D.2768;) >>>>>;
>   <<cleanup_point <<< Unknown tree: expr_stmt
>     f ((int) *e) >>>>>;
> }
> 
> i.e, it sees two DECL_EXPR "D.2768" and "e" without any initialization first,
> and then see the "CLEANUP_POINT_EXPR" which include the initializations to "e"
> and "D.2768". since it doesn't see any connections between these two DECL_EXPRs
> and the initializations inside "CLEANUP_POINT_EXPR", it just treats the two
> DECL_EXPRs as not initialized, therefore add the .DEFERED_INIT to them.
> 
> the best approach to resolve this issue is:
> 
> if there is any connection  between DECL_EXPR "D.2768","e" and their
> initializations inside "CLEANUP_POINT_EXPR" that can be checked from IR, then
> during "gimplify_decl_expr", we can avoid generating .DEFERRED_INIT to them;
> 
> my question is: in the current IR from C++ FE, is there any bit I can check to
> make sure that the DECL_EXPR "D.2768" and "e" already have initialization
> inside "CLEANUP_POINT_EXPR"?

Hmm, I don't think so.  So this is indeed expected behavior since the
frontend IL doesn't have variable definitions with initializers but
instead just (immediately following) assignments.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qing.zhao at oracle dot com]

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

--- Comment #8 from Qing Zhao <qing.zhao at oracle dot com> ---
> On Feb 16, 2023, at 2:35 AM, rguenther at suse dot de <gcc-bugzilla@gcc.gnu.org> wrote:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
> 
> --- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
> On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote:
> 
> 
> Hmm, I don't think so.  So this is indeed expected behavior since the
> frontend IL doesn't have variable definitions with initializers but
> instead just (immediately following) assignments.

Then, if that’s the case, it also is correct to add the .DEFERRED_INIT to them
during gimplification?

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qinzhao at gcc dot gnu.org]

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

--- Comment #9 from qinzhao at gcc dot gnu.org ---
it's a bug in tree-ssa-uninit.cc actually.

when doing the following:

          /* Ignore the call to .DEFERRED_INIT that define the original
             var itself as the following case:
                temp = .DEFERRED_INIT (4, 2, “alt_reloc");
                alt_reloc = temp;
             In order to avoid generating warning for the fake usage
             at alt_reloc = temp.
          */

we need to compare the var name inside the .DEFERRED_INIT call (the 3nd
argument) and the name for the left side variable. if they are the same, we
will NOT report the warning. 

there is one issue when we get the name for the left side variable. when the
variable doesn't have a DECL_NAME (it's not a user declared variable, which is
the case for this bug):

>       _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
>       D.2389 = _1;

(in the above example, D.2389 is a variable that doesn't have a DECL_NAME.)

the current checking just ignores this case, and still report the warning. this
is incorrect.

The fix is very simple, when get the var name for the left side variable, we
should consider this case and come up with the name the same way as we
construct the 3rd argument for the call to .DEFERRED_INIT (please refer to the
routine "gimple_add_init_for_auto_var")

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qinzhao at gcc dot gnu.org]

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
the following patch fixed this issue:
diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index c555cf5cd50..eca727b010a 100644
--- a/gcc/tree-ssa-uninit.cc
+++ b/gcc/tree-ssa-uninit.cc
@@ -113,6 +113,18 @@ uninit_undefined_value_p (tree t)
   return !get_no_uninit_warning (SSA_NAME_VAR (t));
 }

+
+/* Get the name string for the VAR that defined with a call to .DEFERRED_INIT.
+ * Refer to routine gimple_add_init_for_auto_var.  */
+static const char *
+get_var_name (tree var)
+{
+  const char *var_name_str
+    = DECL_NAME (var) ? IDENTIFIER_POINTER (DECL_NAME (var))
+      : xasprintf ("D.%u", DECL_UID (var));
+  return var_name_str;
+}
+
 /* Emit warnings for uninitialized variables.  This is done in two passes.

    The first pass notices real uses of SSA names with undefined values.
@@ -224,8 +236,6 @@ warn_uninit (opt_code opt, tree t, tree var, gimple
*context,
             at alt_reloc = temp.
          */
          tree lhs_var = NULL_TREE;
-         tree lhs_var_name = NULL_TREE;
-         const char *lhs_var_name_str = NULL;

          /* Get the variable name from the 3rd argument of call.  */
          tree var_name = gimple_call_arg (var_def_stmt, 2);
@@ -239,11 +249,12 @@ warn_uninit (opt_code opt, tree t, tree var, gimple
*context,
              else if (TREE_CODE (gimple_assign_lhs (context)) == SSA_NAME)
                lhs_var = SSA_NAME_VAR (gimple_assign_lhs (context));
            }
-         if (lhs_var
-             && (lhs_var_name = DECL_NAME (lhs_var))
-             && (lhs_var_name_str = IDENTIFIER_POINTER (lhs_var_name))
-             && (strcmp (lhs_var_name_str, var_name_str) == 0))
-           return;
+         if (lhs_var)
+           {
+             const char *lhs_var_name_str = get_var_name (lhs_var);
+             if (strcmp (lhs_var_name_str, var_name_str) == 0)
+               return;
+           }
          gcc_assert (var_name_str && var_def_stmt);
        }
     }

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to qinzhao from comment #10)
> the following patch fixed this issue:

This would leak memory.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qinzhao at gcc dot gnu.org]

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

--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to qinzhao from comment #10)
> > the following patch fixed this issue:
> 
> This would leak memory.

thank you, I will fix the memory leak issue in the patch.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 16 Feb 2023, qing.zhao at oracle dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
> 
> --- Comment #8 from Qing Zhao <qing.zhao at oracle dot com> ---
> > On Feb 16, 2023, at 2:35 AM, rguenther at suse dot de <gcc-bugzilla@gcc.gnu.org> wrote:
> > 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107411
> > 
> > --- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
> > On Wed, 15 Feb 2023, qinzhao at gcc dot gnu.org wrote:
> > 
> > 
> > Hmm, I don't think so.  So this is indeed expected behavior since the
> > frontend IL doesn't have variable definitions with initializers but
> > instead just (immediately following) assignments.
> 
> Then, if that’s the case, it also is correct to add the .DEFERRED_INIT to them
> during gimplification?

Yes.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r13-6379-gafe6cea4489846aa8585f3c045d16cdaa08cc6cd
Author: Qing Zhao <qing.zhao@oracle.com>
Date:   Tue Feb 28 17:11:05 2023 +0000

    Fixing PR107411

    This is a bug in tree-ssa-uninit.cc.
    When doing the following:

      /* Ignore the call to .DEFERRED_INIT that define the original
         var itself as the following case:
           temp = .DEFERRED_INIT (4, 2, âalt_reloc");
           alt_reloc = temp;
         In order to avoid generating warning for the fake usage
         at alt_reloc = temp.
      */

    We need to compare the var name inside the .DEFERRED_INIT call
    (the 3rd argument) and the name for the LHS variable. if they are the same,
    we will NOT report the warning.

    There is one issue when we get the name for the LHS variable. when the
    variable doesn't have a DECL_NAME (it's not a user declared variable,
    which is the case for this bug):

      _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
      D.2389 = _1;

    The current checking just ignores this case, and still report the warning.

    The fix is very simple, when getting the name for the LHS variable, we
should
    consider this case and come up with the name the same way as we construct
the
    3rd argument for the call to .DEFERRED_INIT (please refer to the routine
    "gimple_add_init_for_auto_var")

            PR middle-end/107411

    gcc/ChangeLog:

            PR middle-end/107411
            * gimplify.cc (gimple_add_init_for_auto_var): Use sprintf to
replace
            xasprintf.
            * tree-ssa-uninit.cc (warn_uninit): Handle the case when the
            LHS varaible of a .DEFERRED_INIT call doesn't have a DECL_NAME.

    gcc/testsuite/ChangeLog:

            PR middle-end/107411
            * g++.dg/pr107411.C: New test.

[Bug middle-end/107411] trivial-auto-var-init=zero invalid uninitialized variable warning

[qinzhao at gcc dot gnu.org]

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

qinzhao at gcc dot gnu.org changed:

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

--- Comment #15 from qinzhao at gcc dot gnu.org ---
resolved in GCC13