* [Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
@ 2023-01-11 18:19 ` romain.geissler at amadeus dot com
2023-01-12 9:43 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: romain.geissler at amadeus dot com @ 2023-01-11 18:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
--- Comment #1 from Romain Geissler <romain.geissler at amadeus dot com> ---
I forgot to mention: this happens on x86-64 with -O1.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
2023-01-11 18:19 ` [Bug tree-optimization/108374] " romain.geissler at amadeus dot com
@ 2023-01-12 9:43 ` rguenth at gcc dot gnu.org
2023-01-12 9:57 ` redi at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-12 9:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |diagnostic
Status|UNCONFIRMED |NEW
Priority|P3 |P2
Target Milestone|--- |12.3
Last reconfirmed| |2023-01-12
Ever confirmed|0 |1
Version|unknown |12.2.0
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We now say
cc1plus: note: destination object is likely at address zero
<bb 2> [local count: 1073741824]:
_9 = MEM[(const struct __shared_ptr &)pointer_2(D)]._M_ptr;
_10 = MEM[(const struct __shared_count &)pointer_2(D) + 8]._M_pi;
if (_10 != 0B)
goto <bb 4>; [53.47%]
else
goto <bb 3>; [46.53%]
<bb 3> [local count: 499612072]:
__atomic_load_8 (16B, 5); [tail call]
D.37576 ={v} {CLOBBER};
D.37576 ={v} {CLOBBER(eol)};
goto <bb 19>; [100.00%] (leads straight to return)
so we have __shared_count of pointer _M_pi == 0 here, whatever that means
and not sure why we atomically load here.
Confirmed.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
2023-01-11 18:19 ` [Bug tree-optimization/108374] " romain.geissler at amadeus dot com
2023-01-12 9:43 ` rguenth at gcc dot gnu.org
@ 2023-01-12 9:57 ` redi at gcc dot gnu.org
2023-01-12 10:00 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-01-12 9:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Romain Geissler from comment #0)
> std::weak_ptr<A> weakPointer(pointer);
>
> [[maybe_unused]] const unsigned int aAttr = weakPointer.lock()->_attr;
If pointer == nullptr then weakPointer.lock() is also null, and so
dereferencing it to access the attr member is undefined, and does indeed
perform an atomic load at address 0.
Instead of complaining about it, I would expect GCC to treat that undefined
condition as unreachable and optimize it away.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
` (2 preceding siblings ...)
2023-01-12 9:57 ` redi at gcc dot gnu.org
@ 2023-01-12 10:00 ` rguenth at gcc dot gnu.org
2023-01-12 10:10 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-01-12 10:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Romain Geissler from comment #0)
> > std::weak_ptr<A> weakPointer(pointer);
> >
> > [[maybe_unused]] const unsigned int aAttr = weakPointer.lock()->_attr;
>
> If pointer == nullptr then weakPointer.lock() is also null, and so
> dereferencing it to access the attr member is undefined, and does indeed
> perform an atomic load at address 0.
>
> Instead of complaining about it, I would expect GCC to treat that undefined
> condition as unreachable and optimize it away.
Hmm, but then the program is bogus, no? And a diagnostic warranted.
At least if it is well-defined to have a nullptr == pointer.
So I'd be inclined to close as INVALID?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
` (3 preceding siblings ...)
2023-01-12 10:00 ` rguenth at gcc dot gnu.org
@ 2023-01-12 10:10 ` redi at gcc dot gnu.org
2023-01-12 11:34 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2023-01-12 10:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Hmm, but then the program is bogus, no? And a diagnostic warranted.
No.
> At least if it is well-defined to have a nullptr == pointer.
It's well defined, but that doesn't mean the program is bogus. It just means
you can't call that function with such a value.
> So I'd be inclined to close as INVALID?
No, I don't think so. It would only be invalid if you called f(nullptr) or
similar.
The code is basically doing something like:
int f(const A* p, bool is_valid)
{
const A* q = is_valid ? p : nullptr;
return *q;
}
Instead of complaining that q might be null, we can optimize that to return *p.
It might be nicer to optimize it to:
if (!p)
__builtin_trap();
return *p;
but either way, we can't just declare the whole program to be invalid because
it's possible to call the function incorrectly.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/108374] [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
` (4 preceding siblings ...)
2023-01-12 10:10 ` redi at gcc dot gnu.org
@ 2023-01-12 11:34 ` jakub at gcc dot gnu.org
2023-05-08 12:26 ` [Bug tree-optimization/108374] [12/13/14 " rguenth at gcc dot gnu.org
2024-06-20 9:11 ` [Bug tree-optimization/108374] [12/13/14/15 " rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-01-12 11:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The warning is simply badly designed like most of the middle-end warnings.
As has been discussed, we should have some switch to decide what to do when we
have such provable UB, and the possibilities should be turn it into
__builtin_unreachable (), turn it into __builtin_trap () or for users who don't
mind seeing lots of false positives keep the warning. Though perhaps now that
we have -funreachable-traps the option could be just 2 possibilities,
unreachable vs. (useless) warnings, with the default of the former.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/108374] [12/13/14 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
` (5 preceding siblings ...)
2023-01-12 11:34 ` jakub at gcc dot gnu.org
@ 2023-05-08 12:26 ` rguenth at gcc dot gnu.org
2024-06-20 9:11 ` [Bug tree-optimization/108374] [12/13/14/15 " rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-05-08 12:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|12.3 |12.4
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug tree-optimization/108374] [12/13/14/15 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr
2023-01-11 18:18 [Bug tree-optimization/108374] New: [12/13 Regression] unexpected -Wstringop-overflow when using std::atomic and std::shared_ptr romain.geissler at amadeus dot com
` (6 preceding siblings ...)
2023-05-08 12:26 ` [Bug tree-optimization/108374] [12/13/14 " rguenth at gcc dot gnu.org
@ 2024-06-20 9:11 ` rguenth at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-06-20 9:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108374
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|12.4 |12.5
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.4 is being released, retargeting bugs to GCC 12.5.
^ permalink raw reply [flat|nested] 9+ messages in thread