[Bug libstdc++/105562] New: [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std:regex move with -fno-strict-aliasing

[Bug libstdc++/105562] New: [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std:regex move with -fno-strict-aliasing

[andrey.vihrov at gmail dot com]

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

            Bug ID: 105562
           Summary: [12 Regression] std::function<bool(char)>::_M_invoker
                    may be used uninitialized in std:regex move with
                    -fno-strict-aliasing
           Product: gcc
           Version: 12.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andrey.vihrov at gmail dot com
  Target Milestone: ---

Consider the following sample:

  #include <regex>

  int main()
  {
    std::regex a(".");
    std::regex b(std::move(a));
  }

Since GCC 12.1, compiling this code with "g++ -Wall -O1 -fno-strict-aliasing
x.cpp" gives

In file included from /usr/include/c++/12.1.0/regex:48,
                 from x.cpp:1:
In constructor 'std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {char}]',
    inlined from
'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&)
[with _Char_type = char]' at
/usr/include/c++/12.1.0/bits/regex_automaton.h:149:4,
    inlined from 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits<char>]' at
/usr/include/c++/12.1.0/bits/regex_automaton.h:290:24:
/usr/include/c++/12.1.0/bits/std_function.h:405:42: warning:
'*(std::function<bool(char)>*)((char*)&__tmp + offsetof(std::__detail::_StateT,
std::__detail::_State<char>::<unnamed>.std::__detail::_State_base::<unnamed>)).std::function<bool(char)>::_M_invoker'
may be used uninitialized [-Wmaybe-uninitialized]
  405 |       : _Function_base(), _M_invoker(__x._M_invoker)
      |                                      ~~~~^~~~~~~~~~
In file included from /usr/include/c++/12.1.0/regex:63:
/usr/include/c++/12.1.0/bits/regex_automaton.h: In member function
'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits<char>]':
/usr/include/c++/12.1.0/bits/regex_automaton.h:287:17: note: '__tmp' declared
here
  287 |         _StateT __tmp(_S_opcode_subexpr_end);
      |                 ^~~~~
In member function 'bool std::_Function_base::_M_empty() const',
    inlined from 'std::function<_Res(_ArgTypes ...)>::operator bool() const
[with _Res = bool; _ArgTypes = {char}]' at
/usr/include/c++/12.1.0/bits/std_function.h:574:25,
    inlined from 'std::function<_Res(_ArgTypes
...)>::function(std::function<_Res(_ArgTypes ...)>&&) [with _Res = bool;
_ArgTypes = {char}]' at /usr/include/c++/12.1.0/bits/std_function.h:407:6,
    inlined from
'std::__detail::_State<_Char_type>::_State(std::__detail::_State<_Char_type>&&)
[with _Char_type = char]' at
/usr/include/c++/12.1.0/bits/regex_automaton.h:149:4,
    inlined from 'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits<char>]' at
/usr/include/c++/12.1.0/bits/regex_automaton.h:290:24:
/usr/include/c++/12.1.0/bits/std_function.h:247:37: warning: '*(const
std::_Function_base*)((char*)&__tmp + offsetof(std::__detail::_StateT,
std::__detail::_State<char>::<unnamed>.std::__detail::_State_base::<unnamed>)).std::_Function_base::_M_manager'
may be used uninitialized [-Wmaybe-uninitialized]
  247 |     bool _M_empty() const { return !_M_manager; }
      |                                     ^~~~~~~~~~
/usr/include/c++/12.1.0/bits/regex_automaton.h: In member function
'std::__detail::_StateIdT
std::__detail::_NFA<_TraitsT>::_M_insert_subexpr_end() [with _TraitsT =
std::__cxx11::regex_traits<char>]':
/usr/include/c++/12.1.0/bits/regex_automaton.h:287:17: note: '__tmp' declared
here
  287 |         _StateT __tmp(_S_opcode_subexpr_end);
      |                 ^~~~~


There are no warnings with -fstrict-aliasing. Related resources:
* https://gcc.gnu.org/pipermail/gcc/2021-July/236851.html
* https://gcc.gnu.org/g:c22bcfd2f7dc9bb5ad394720f4a612327dc898ba

[Bug libstdc++/105562] [12/13 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing since r12-6216-g5a431b60d1f22199

[marxin at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[12 Regression]             |[12/13 Regression]
                   |std::function<bool(char)>:: |std::function<bool(char)>::
                   |_M_invoker may be used      |_M_invoker may be used
                   |uninitialized in std::regex |uninitialized in std::regex
                   |move with                   |move with
                   |-fno-strict-aliasing        |-fno-strict-aliasing since
                   |                            |r12-6216-g5a431b60d1f22199
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2022-05-11
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |msebor at gcc dot gnu.org

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-6216-g5a431b60d1f22199.

[Bug libstdc++/105562] [12/13 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing since r12-6216-g5a431b60d1f22199

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |12.2
           Keywords|                            |diagnostic

[Bug libstdc++/105562] [12/13 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing since r12-6216-g5a431b60d1f22199

[andrey.vihrov at gmail dot com]

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

--- Comment #2 from Andrey Vihrov <andrey.vihrov at gmail dot com> ---
Sorry, even

  std::regex a(".");

alone is enough to trigger the warnings.

[Bug libstdc++/105562] [12/13 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing since r12-6216-g5a431b60d1f22199

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Since r12-2468 it should be impossible for those members to be uninitialized,
and valgrind shows no uninitialized data. I think this is a compiler bug.

(In reply to Martin Liška from comment #1)
> Started with r12-6216-g5a431b60d1f22199.

That only changed how -Wsystem-headers affects warnings (and not an improvement
IMHO).

The bogus warning was already present before then if you use -Wsystem-headers

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Looks like it started with r11-2238

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The fact that -fno-lifetime-dse silences the warning seems to confirm it's that
commit.

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 52953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52953&action=edit
Precompiled testcase

This .ii is based on the gcc-12 code, but with some tweaks to compile with
gcc-10.

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #6)
> Created attachment 52953 [details]
> Precompiled testcase
> 
> This .ii is based on the gcc-12 code, but with some tweaks to compile with
> gcc-10.

This a-re.ii warns with:

g++ a-re.ii -O1 -fno-strict-aliasing -Wsystem-headers -Wmaybe-uninitialized

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>From what I can see, the warning is on dead code.
  <bb 2> [local count: 1073741824]:
  MEM[(struct _State_base *)&__tmp] ={v} {CLOBBER};
  MEM[(struct _State_base *)&__tmp]._M_opcode = 9;
  MEM[(struct _State_base *)&__tmp]._M_next = -1;
  _12 = MEM[(long unsigned int * const &)this_3(D) + 8];
  _1 = MEM[(value_type &)_12 + 18446744073709551608];
  __tmp.D.93077.D.69952._M_subexpr = _1;
  _11 = _12 + 18446744073709551608;
  MEM[(struct vector *)this_3(D)].D.71153._M_impl.D.70460._M_finish = _11;
  MEM[(struct _State *)&D.93141] ={v} {CLOBBER};
  MEM[(struct _State *)&D.93141].D.93077 = MEM[(struct _State
&)&__tmp].D.93077;
  _43 = MEM[(const struct _State *)&__tmp].D.93077._M_opcode;
  if (_43 == 11)
    goto <bb 3>; [34.00%]
  else
    goto <bb 23>; [66.00%]

  <bb 23> [local count: 708669600]:
  goto <bb 5>; [100.00%]

  <bb 3> [local count: 365072224]:
  MEM[(struct function *)&D.93141 + 16B] ={v} {CLOBBER};
  MEM[(struct function *)&D.93141 + 16B].D.69910 = {};
  _44 = MEM[(struct function &)&__tmp + 16]._M_invoker;
  MEM[(struct function *)&D.93141 + 16B]._M_invoker = _44;

__tmp has:
  struct _State_base
  {
  protected:
    _Opcode      _M_opcode;           // type of outgoing transition

  public:
    _StateIdT    _M_next;             // outgoing transition
    union // Since they are mutually exclusive.
    {
      size_t _M_subexpr;        // for _S_opcode_subexpr_*
      size_t _M_backref_index;  // for _S_opcode_backref
      struct
      {
        // for _S_opcode_alternative, _S_opcode_repeat and
        // _S_opcode_subexpr_lookahead
        _StateIdT  _M_alt;
        // for _S_opcode_word_boundary or _S_opcode_subexpr_lookahead or
        // quantifiers (ungreedy if set true)
        bool       _M_neg;
      };
      // For _S_opcode_match
      __gnu_cxx::__aligned_membuf<_Matcher<char>> _M_matcher_storage;
    };
type where _StateIdT is some pointer and _M_matcher_storage is 32 bytes large,
the union is at offset 16.
Now, bb 2 initializes it to be _M_opcode 9 (aka _S_opcode_subexpr_end) with the
_M_subexpr as active
union field (so everything but the first 8 bytes of the union are
uninitialized).
But at the end of the bb we test _M_opcode against 11 (aka _S_opcode_match) and
if it is that
value, we extract std::function's _M_invoker (which is a pointer at offset 16
bytes into the union).
So obviously it is uninitialized but dead.
At -O1 we don't do PRE, but I wonder why fre3 doesn't optimize this.
  <bb 2> [local count: 1073741824]:
  MEM[(struct _State_base *)&__tmp] ={v} {CLOBBER};
  MEM[(struct _State_base *)&__tmp]._M_opcode = 9;
  MEM[(struct _State_base *)&__tmp]._M_next = -1;
  _12 = MEM[(long unsigned int * const &)this_3(D) + 8];
  _1 = MEM[(value_type &)_12 + 18446744073709551608];
  __tmp.D.93077.D.69952._M_subexpr = _1;
  _11 = _12 + 18446744073709551608;
  MEM[(struct vector *)this_3(D)].D.71153._M_impl.D.70460._M_finish = _11;
  MEM[(long unsigned int *)_12 + -8B] ={v} {CLOBBER};
  MEM[(struct _State *)&D.93141] ={v} {CLOBBER};
  MEM[(struct _State *)&D.93141].D.93077 = MEM[(struct _State
&)&__tmp].D.93077;
  _43 = MEM[(const struct _State *)&__tmp].D.93077._M_opcode;
  if (_43 == 11)
there are 3 stores into __tmp, one to offset 0 4 bytes _M_opcode = 9, one to
offset 8 8 bytes _M_next = -1 and one to offset 16 8 bytes _M_subexpr = _1,
it doesn't seem like other stores could alias with that, so why don't we
optimize _43 = 9; ?

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Perhaps with -fno-strict-aliasing we think the store to *this might alias with
it?  Though, that shouldn't be about TBAA but simple points-to analysis, where
obviously this as function argument can't point to a local var in the function.

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> Perhaps with -fno-strict-aliasing we think the store to *this might alias
> with it?  Though, that shouldn't be about TBAA but simple points-to
> analysis, where obviously this as function argument can't point to a local
> var in the function.

It's the

  MEM[(long unsigned int *)_12 + -8B] ={v} {CLOBBER};

store, __tmp escapes in the indirect call

     _48 (&MEM[(struct _Function_base *)&__tmp + 16B]._M_functor,   
          &MEM[(struct _Function_base *)&__tmp + 16B]._M_functor, 3);

and _12 points to escaped (its loaded from this).

I guess since a CLOBBER isn't technically a "store" we could ignore it
and continue looking for data to load.  If it would alias then we'd
access (partly) 'uninitialized' memory which would invoke undefined
behavior.

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index d4d0aba880c..9f7f12846cb 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -2593,6 +2593,11 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
   bool lhs_ref_ok = false;
   poly_int64 copy_size;

+  /* We can optimistically disambiguate against CLOBBERs, when there
+     is any overlap it would be undefined behavior.  */
+  if (gimple_clobber_p (def_stmt))
+    return NULL;
+
   /* First try to disambiguate after value-replacing in the definitions LHS. 
*/
   if (is_gimple_assign (def_stmt))
     {


avoids the diagnostics.

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm going to test this.

diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index d4d0aba880c..c9965549fce 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -2620,6 +2620,16 @@ vn_reference_lookup_3 (ao_ref *ref, tree vuse, void
*data_,
          return NULL;
        }

+      /* When the def is a CLOBBER we can optimistically disambiguate
+        against it since any overlap it would be undefined behavior.
+        Avoid this for obvious must aliases to save compile-time though.  */
+      if (gimple_clobber_p (def_stmt)
+         && !operand_equal_p (ao_ref_base (&lhs_ref), base, OEP_ADDRESS_OF))
+       {
+         *disambiguate_only = TR_DISAMBIGUATE;
+         return NULL;
+       }
+
       /* Besides valueizing the LHS we can also use access-path based
          disambiguation on the original non-valueized ref.  */
       if (!ref->ref

[Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 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:94b8a37fa16f7638cc1965718f4ec71719506743

commit r13-340-g94b8a37fa16f7638cc1965718f4ec71719506743
Author: Richard Biener <rguenther@suse.de>
Date:   Thu May 12 12:13:29 2022 +0200

    tree-optimization/105562 - avoid uninit diagnostic with better FRE

    We can avoid some uninit diagnostics by making FRE disambiguate
    against CLOBBERs since any aliasing there would invoke undefined
    behavior for a read we are looking up.

    2022-05-12  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/105562
            * tree-ssa-sccvn.cc (vn_reference_lookup_3): Disambiguate
            against all CLOBBER defs if there's not an obvious must-alias
            and we are not doing redundant store elimination.
            (vn_walk_cb_data::redundant_store_removal_p): New field.
            (vn_reference_lookup_pieces): Initialize it.
            (vn_reference_lookup): Add argument to specify if we are
            doing redundant store removal.
            (eliminate_dom_walker::eliminate_stmt): Specify we do.
            * tree-ssa-sccvn.h (vn_reference_lookup): Adjust.

            * g++.dg/warn/uninit-pr105562.C: New testcase.

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |12.1.0
      Known to work|                            |11.3.0, 13.0
            Summary|std::function<bool(char)>:: |[12 Regression]
                   |_M_invoker may be used      |std::function<bool(char)>::
                   |uninitialized in std::regex |_M_invoker may be used
                   |move with                   |uninitialized in std::regex
                   |-fno-strict-aliasing        |move with
                   |                            |-fno-strict-aliasing

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 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:844a5c8ca768dc0cc90c1a943756610832d686a8

commit r12-8400-g844a5c8ca768dc0cc90c1a943756610832d686a8
Author: Richard Biener <rguenther@suse.de>
Date:   Thu May 12 12:13:29 2022 +0200

    tree-optimization/105562 - avoid uninit diagnostic with better FRE

    We can avoid some uninit diagnostics by making FRE disambiguate
    against CLOBBERs since any aliasing there would invoke undefined
    behavior for a read we are looking up.

    2022-05-12  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/105562
            * tree-ssa-sccvn.cc (vn_reference_lookup_3): Disambiguate
            against all CLOBBER defs if there's not an obvious must-alias
            and we are not doing redundant store elimination.
            (vn_walk_cb_data::redundant_store_removal_p): New field.
            (vn_reference_lookup_pieces): Initialize it.
            (vn_reference_lookup): Add argument to specify if we are
            doing redundant store removal.
            (eliminate_dom_walker::eliminate_stmt): Specify we do.
            * tree-ssa-sccvn.h (vn_reference_lookup): Adjust.

            * g++.dg/warn/uninit-pr105562.C: New testcase.

    (cherry picked from commit 94b8a37fa16f7638cc1965718f4ec71719506743)

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |12.1.1
         Resolution|---                         |FIXED

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

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vincent.lextrait at gmail dot com

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

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[urisimchoni at gmail dot com]

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

Uri Simchoni <urisimchoni at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |urisimchoni at gmail dot com

--- Comment #21 from Uri Simchoni <urisimchoni at gmail dot com> ---
(In reply to Richard Biener from comment #18)
> (In reply to Sven Hesse from comment #17)
> > I still get this with gcc 12.2.0 (Gentoo 12.2.0 p9), but only when compiling
> > with (at least with) -O1 -fsanitize=address, in addition to any warning flag
> > that enables -Wmaybe-uninitialized (like -Wall, -Wextra or -Wuninitialized).
> > 
> > -O0 and/or no ASan, and the offending code compiles cleanly without any
> > warnings. Somehow, the combination of enabling ASan and optimization
> > (anything > -O0, but not -Os) triggers it again, it seems?
> > 
> > I can observe this with the testcase attached here in this bug report.
> 
> -fsanitize=address is likely to derail optimization enough to make such
> occurences more likely, I think we have plenty of duplicate bugreports
> for this.

So it seems this is still hapening with -O1 -fsanitize=address (occurring for
me too with GCC 13.1.0), yet this specific bug is marked as "fixed" and there's
a mention of duplicate bugreports (I can see one unconfirmed pointed-to by this
issue). Is opening of another bug, focusing on -O1 -fsanitize=address, going to
help get this fixed?

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[jakub1miernik at gmail dot com]

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

Jakub Miernik <jakub1miernik at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub1miernik at gmail dot com

--- Comment #22 from Jakub Miernik <jakub1miernik at gmail dot com> ---
(In reply to Uri Simchoni from comment #21)
> (In reply to Richard Biener from comment #18)
> > (In reply to Sven Hesse from comment #17)
> > > I still get this with gcc 12.2.0 (Gentoo 12.2.0 p9), but only when compiling
> > > with (at least with) -O1 -fsanitize=address, in addition to any warning flag
> > > that enables -Wmaybe-uninitialized (like -Wall, -Wextra or -Wuninitialized).
> > > 
> > > -O0 and/or no ASan, and the offending code compiles cleanly without any
> > > warnings. Somehow, the combination of enabling ASan and optimization
> > > (anything > -O0, but not -Os) triggers it again, it seems?
> > > 
> > > I can observe this with the testcase attached here in this bug report.
> > 
> > -fsanitize=address is likely to derail optimization enough to make such
> > occurences more likely, I think we have plenty of duplicate bugreports
> > for this.
> 
> So it seems this is still hapening with -O1 -fsanitize=address (occurring
> for me too with GCC 13.1.0), yet this specific bug is marked as "fixed" and
> there's a mention of duplicate bugreports (I can see one unconfirmed
> pointed-to by this issue). Is opening of another bug, focusing on -O1
> -fsanitize=address, going to help get this fixed?


I can confirm this is still valid.
Build with flags '-O1 -fsanitize=address -Wall -Werror' is still failing.
Tested for version 12.1, 12.2, 12.3, 13.1, 13.2

Shouldn't it be reopen?
If there is some other ticket related to it, could someone link it here?

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[romain.geissler at amadeus dot com]

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

Romain Geissler <romain.geissler at amadeus dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |romain.geissler at amadeus dot com

--- Comment #23 from Romain Geissler <romain.geissler at amadeus dot com> ---
Hi,

We have also hit an occurence of this bug while using address sanitizer and gcc
13.

I see in comment #22 Jakub proposes to re-open this ticket, but I can re-create
a dedicated one just for the ASAN related issue if you prefer.

I don't know if the proposal to silence this warning made by Jonathan in #19 is
considered a "long term fix" for this or just a temporary solution until the
internal compiler bug is fixed.

Cheers,
Romain

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
The bug wasn't about uninit diagnostics with ASAN but without.  There are
plenty of diagnostic "bugs" when sanitizing is enabled and those are really
hard to fix since plenty of diagnostics rely on optimization to avoid false
positives which ASAN and friends prohibit.

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[romain.geissler at amadeus dot com]

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

--- Comment #25 from Romain Geissler <romain.geissler at amadeus dot com> ---
So it means we should rather go for "silencing" workaround from comment #19 ?

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[rguenther at suse dot de]

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

--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 6 Dec 2023, romain.geissler at amadeus dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105562
> 
> --- Comment #25 from Romain Geissler <romain.geissler at amadeus dot com> ---
> So it means we should rather go for "silencing" workaround from comment #19 ?

No, I think people shouldn't care for warnings with -fsanitize=...
(or not use -Wall).

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is just a very partial solution.  As mentioned in lots of other
bugreports, one should simply ignore or take with a grain of salt  warnings
from the instrumented builds (whether it is -fsanitize=undefined,
-fsanitize=address, -fsanitize=thread or I think -fprofile-generate or similar
as well).  Any such instrumentation significantly modifies the intermediate
language and prevents various optimizations which necessarily lead to more
false positives in the non-frontend warnings.
So, best similarly to what libtool does when compiling a file twice, once with
-fpic, once without, redirects diagnostics of one to /dev/null, go with 2
builds, one sanitized/instrumented with -w, another non-instrumented with full
warnings.
The big question is if the compiler should do that by default (simply ignore
all middle-end warnings in instrumented functions), or if we should provide
some support in the driver for building stuff twice, once instrumented without
middle-end warnings, once non-instrumented with warnings.  We already have
-fcompare-debug which does something similar (build normally and -gtoggle -w.

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[romain.geissler at amadeus dot com]

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

--- Comment #28 from Romain Geissler <romain.geissler at amadeus dot com> ---
Ok it's clear. I haven't really played yet with sanitizers, I didn't know it
had these well known "issue" with creating more middle end false positive
warnings (I am used to them in LTO mode).

So I will advise that we relax warning severity/disable some warnings in my
company when using sanitizers.

Thanks !

[Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing

[sjames at gcc dot gnu.org]

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

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

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

--- Comment #29 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Romain Geissler from comment #28)
> Ok it's clear. I haven't really played yet with sanitizers, I didn't know it
> had these well known "issue" with creating more middle end false positive
> warnings (I am used to them in LTO mode).
> 
> So I will advise that we relax warning severity/disable some warnings in my
> company when using sanitizers.
> 
> Thanks !

See also
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fsanitize_003dbuiltin.

"Note that sanitizers tend to increase the rate of false positive warnings,
most notably those around -Wmaybe-uninitialized. We recommend against combining
-Werror and [the use of] sanitizers."