* [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
2022-05-11 10:48 [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
@ 2022-05-11 10:55 ` marxin at gcc dot gnu.org
2022-05-11 11:05 ` rguenth at gcc dot gnu.org
` (25 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: marxin at gcc dot gnu.org @ 2022-05-11 10:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [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
2022-05-11 10:48 [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
2022-05-11 10:55 ` [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
@ 2022-05-11 11:05 ` rguenth at gcc dot gnu.org
2022-05-11 11:32 ` andrey.vihrov at gmail dot com
` (24 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-11 11:05 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [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
2022-05-11 10:48 [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
2022-05-11 10:55 ` [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
2022-05-11 11:05 ` rguenth at gcc dot gnu.org
@ 2022-05-11 11:32 ` andrey.vihrov at gmail dot com
2022-05-11 11:54 ` redi at gcc dot gnu.org
` (23 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: andrey.vihrov at gmail dot com @ 2022-05-11 11:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [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
2022-05-11 10:48 [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
` (2 preceding siblings ...)
2022-05-11 11:32 ` andrey.vihrov at gmail dot com
@ 2022-05-11 11:54 ` redi at gcc dot gnu.org
2022-05-11 12:44 ` [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
` (22 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2022-05-11 11:54 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (3 preceding siblings ...)
2022-05-11 11:54 ` redi at gcc dot gnu.org
@ 2022-05-11 12:44 ` redi at gcc dot gnu.org
2022-05-11 12:56 ` redi at gcc dot gnu.org
` (21 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2022-05-11 12:44 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (4 preceding siblings ...)
2022-05-11 12:44 ` [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
@ 2022-05-11 12:56 ` redi at gcc dot gnu.org
2022-05-11 12:57 ` redi at gcc dot gnu.org
` (20 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2022-05-11 12:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (5 preceding siblings ...)
2022-05-11 12:56 ` redi at gcc dot gnu.org
@ 2022-05-11 12:57 ` redi at gcc dot gnu.org
2022-05-11 12:59 ` redi at gcc dot gnu.org
` (19 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2022-05-11 12:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (6 preceding siblings ...)
2022-05-11 12:57 ` redi at gcc dot gnu.org
@ 2022-05-11 12:59 ` redi at gcc dot gnu.org
2022-05-12 9:27 ` jakub at gcc dot gnu.org
` (18 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2022-05-11 12:59 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (7 preceding siblings ...)
2022-05-11 12:59 ` redi at gcc dot gnu.org
@ 2022-05-12 9:27 ` jakub at gcc dot gnu.org
2022-05-12 9:35 ` jakub at gcc dot gnu.org
` (17 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-12 9:27 UTC (permalink / raw)
To: gcc-bugs
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; ?
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (8 preceding siblings ...)
2022-05-12 9:27 ` jakub at gcc dot gnu.org
@ 2022-05-12 9:35 ` jakub at gcc dot gnu.org
2022-05-12 9:54 ` rguenth at gcc dot gnu.org
` (16 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-05-12 9:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (9 preceding siblings ...)
2022-05-12 9:35 ` jakub at gcc dot gnu.org
@ 2022-05-12 9:54 ` rguenth at gcc dot gnu.org
2022-05-12 9:57 ` rguenth at gcc dot gnu.org
` (15 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-12 9:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (10 preceding siblings ...)
2022-05-12 9:54 ` rguenth at gcc dot gnu.org
@ 2022-05-12 9:57 ` rguenth at gcc dot gnu.org
2022-05-12 10:07 ` rguenth at gcc dot gnu.org
` (14 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-12 9:57 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (11 preceding siblings ...)
2022-05-12 9:57 ` rguenth at gcc dot gnu.org
@ 2022-05-12 10:07 ` rguenth at gcc dot gnu.org
2022-05-12 11:27 ` cvs-commit at gcc dot gnu.org
` (13 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-12 10:07 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (12 preceding siblings ...)
2022-05-12 10:07 ` rguenth at gcc dot gnu.org
@ 2022-05-12 11:27 ` cvs-commit at gcc dot gnu.org
2022-05-12 11:28 ` [Bug libstdc++/105562] [12 Regression] " rguenth at gcc dot gnu.org
` (12 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-12 11:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (13 preceding siblings ...)
2022-05-12 11:27 ` cvs-commit at gcc dot gnu.org
@ 2022-05-12 11:28 ` rguenth at gcc dot gnu.org
2022-05-19 12:47 ` cvs-commit at gcc dot gnu.org
` (11 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-12 11:28 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (14 preceding siblings ...)
2022-05-12 11:28 ` [Bug libstdc++/105562] [12 Regression] " rguenth at gcc dot gnu.org
@ 2022-05-19 12:47 ` cvs-commit at gcc dot gnu.org
2022-05-19 12:50 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-05-19 12:47 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (15 preceding siblings ...)
2022-05-19 12:47 ` cvs-commit at gcc dot gnu.org
@ 2022-05-19 12:50 ` rguenth at gcc dot gnu.org
2022-10-22 0:50 ` pinskia at gcc dot gnu.org
` (9 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-05-19 12:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (16 preceding siblings ...)
2022-05-19 12:50 ` rguenth at gcc dot gnu.org
@ 2022-10-22 0:50 ` pinskia at gcc dot gnu.org
2023-05-26 21:40 ` urisimchoni at gmail dot com
` (8 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-10-22 0:50 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (17 preceding siblings ...)
2022-10-22 0:50 ` pinskia at gcc dot gnu.org
@ 2023-05-26 21:40 ` urisimchoni at gmail dot com
2023-09-12 12:04 ` jakub1miernik at gmail dot com
` (7 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: urisimchoni at gmail dot com @ 2023-05-26 21:40 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (18 preceding siblings ...)
2023-05-26 21:40 ` urisimchoni at gmail dot com
@ 2023-09-12 12:04 ` jakub1miernik at gmail dot com
2023-12-06 10:03 ` romain.geissler at amadeus dot com
` (6 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: jakub1miernik at gmail dot com @ 2023-09-12 12:04 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (19 preceding siblings ...)
2023-09-12 12:04 ` jakub1miernik at gmail dot com
@ 2023-12-06 10:03 ` romain.geissler at amadeus dot com
2023-12-06 10:26 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: romain.geissler at amadeus dot com @ 2023-12-06 10:03 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (20 preceding siblings ...)
2023-12-06 10:03 ` romain.geissler at amadeus dot com
@ 2023-12-06 10:26 ` rguenth at gcc dot gnu.org
2023-12-06 10:35 ` romain.geissler at amadeus dot com
` (4 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-12-06 10:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (21 preceding siblings ...)
2023-12-06 10:26 ` rguenth at gcc dot gnu.org
@ 2023-12-06 10:35 ` romain.geissler at amadeus dot com
2023-12-06 10:43 ` rguenther at suse dot de
` (3 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: romain.geissler at amadeus dot com @ 2023-12-06 10:35 UTC (permalink / raw)
To: gcc-bugs
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 ?
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (22 preceding siblings ...)
2023-12-06 10:35 ` romain.geissler at amadeus dot com
@ 2023-12-06 10:43 ` rguenther at suse dot de
2023-12-06 10:50 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: rguenther at suse dot de @ 2023-12-06 10:43 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (23 preceding siblings ...)
2023-12-06 10:43 ` rguenther at suse dot de
@ 2023-12-06 10:50 ` jakub at gcc dot gnu.org
2023-12-06 11:13 ` romain.geissler at amadeus dot com
2023-12-06 11:16 ` sjames at gcc dot gnu.org
26 siblings, 0 replies; 28+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-12-06 10:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (24 preceding siblings ...)
2023-12-06 10:50 ` jakub at gcc dot gnu.org
@ 2023-12-06 11:13 ` romain.geissler at amadeus dot com
2023-12-06 11:16 ` sjames at gcc dot gnu.org
26 siblings, 0 replies; 28+ messages in thread
From: romain.geissler at amadeus dot com @ 2023-12-06 11:13 UTC (permalink / raw)
To: gcc-bugs
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 !
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/105562] [12 Regression] std::function<bool(char)>::_M_invoker may be used uninitialized in std::regex move with -fno-strict-aliasing
2022-05-11 10:48 [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
` (25 preceding siblings ...)
2023-12-06 11:13 ` romain.geissler at amadeus dot com
@ 2023-12-06 11:16 ` sjames at gcc dot gnu.org
26 siblings, 0 replies; 28+ messages in thread
From: sjames at gcc dot gnu.org @ 2023-12-06 11:16 UTC (permalink / raw)
To: gcc-bugs
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."
^ permalink raw reply [flat|nested] 28+ messages in thread