* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
@ 2020-08-20 8:10 ` redi at gcc dot gnu.org
2020-08-20 8:14 ` redi at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-20 8:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 49085
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49085&action=edit
Preprocessed source for a.cc
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
2020-08-20 8:10 ` [Bug c++/96717] " redi at gcc dot gnu.org
@ 2020-08-20 8:14 ` redi at gcc dot gnu.org
2020-08-20 9:19 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-20 8:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> Created attachment 49085 [details]
> Preprocessed source for a.cc
This was prepared on x86_64-pc-linux-gnu.
Compile it with -O2 to see the ud2 insn in the .s output.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
2020-08-20 8:10 ` [Bug c++/96717] " redi at gcc dot gnu.org
2020-08-20 8:14 ` redi at gcc dot gnu.org
@ 2020-08-20 9:19 ` jakub at gcc dot gnu.org
2020-08-20 9:31 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-08-20 9:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2020-08-20
CC| |jakub at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The __builtin_trap is there because of:
if (isEmptyBucket(oldEntry)) {
do { if (!(std::addressof(oldEntry) != entry)) {
WTFReportAssertionFailure("WTF/wtf/HashTable.h", 1337, __PRETTY_FUNCTION__,
"std::
oldTable[i].~ValueType();
continue;
}
where the type of oldTable[i] and oldEntry is struct Thread *, isEmptyBucket is
== NULL check and invoking a pseudo-destructor.
Playing with this, I've come up with:
typedef int *T;
void
foo (T a)
{
if (a)
return;
a.~T ();
}
int
main ()
{
int p;
foo (&p);
foo (nullptr);
return 0;
}
testcase.
Starting with r11-2238-ge443d8213864ac337c29092d4767224f280d2062 we emit:
if (a != 0B) goto <D.2343>; else goto <D.2344>;
<D.2343>:
// predicted unlikely by early return (on trees) predictor.
return;
<D.2344>:
*a = {CLOBBER};
which doesn't look right to me, that is as if the (pseudo)destructor is run on
what the pointer points to (so if the testcase is changed to also have typedef
int V; and use a->~V (); rather than a.~T ();).
That is one thing, but I'd say in that case it ought to crash only if a is
NULL, because the pseudo destructor is invoked only in that case.
With that we have:
if (a_2(D) != 0B)
goto <bb 3>; [INV]
else
goto <bb 4>; [INV]
<bb 3> :
// predicted unlikely by early return (on trees) predictor.
goto <bb 5>; [INV]
<bb 4> :
MEM[(int *)0B] ={v} {CLOBBER};
<bb 5> :
return;
before cddce1, but we then "optimize" it into:
<bb 2> :
MEM[(int *)0B] ={v} {CLOBBER};
return;
So, I'd say we have two bugs here, one is that the FE since r1-2238 mishandles
pseudo-destructors of pointer types, for that use the above testcase, and then
that we mishandle clobbers in DCE or so, for which the testcase is:
struct S { int s; ~S () {} };
void
foo (S *a)
{
if (a)
return;
a->~S ();
}
int
main ()
{
S s;
foo (&s);
foo ((S *) 0);
}
which started to be really miscompiled with r249450, but had the questionable
unconditional
MEM[(struct S *)0B] ={v} {CLOBBER};
as first stmt in main already since r197375.
So, in addition to fixing the C++ FE, I think we either shall declare that
clobbers never trap even if invoked with NULL pointers, then cddce can do the
optimization it does, but we shouldn't turn it into __builtin_trap later, or we
disable the optimization that happens during dce if the pointer in MEM_REF lhs
of a clobber is or might be NULL.
Now, whether fixing this (both or just one) fixes the above reported bug is
unclear.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
` (2 preceding siblings ...)
2020-08-20 9:19 ` jakub at gcc dot gnu.org
@ 2020-08-20 9:31 ` jakub at gcc dot gnu.org
2022-02-15 10:41 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-08-20 9:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've moved the #c3 issues into PR96721 and PR96722 as they are separate. And
either this bug turns a dup of the former, or not.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
` (3 preceding siblings ...)
2020-08-20 9:31 ` jakub at gcc dot gnu.org
@ 2022-02-15 10:41 ` redi at gcc dot gnu.org
2022-02-15 10:47 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2022-02-15 10:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
#include <vector>
void pop_many(std::vector<int>& v, unsigned n) {
for (unsigned i = 0; i < n; ++i) {
v.pop_back();
}
}
With GCC 10 at -O2 and above this was optimized to simply subtract n from the
v.end() pointer:
_Z8pop_manyRSt6vectorIiSaIiEEm:
.LFB883:
testq %rsi, %rsi
je .L1
salq $2, %rsi
subq %rsi, 8(%rdi)
.L1:
ret
But since r11-2238 it decrements the pointer n times:
_Z8pop_manyRSt6vectorIiSaIiEEm:
.LFB883:
testq %rsi, %rsi
je .L1
movq 8(%rdi), %rdx
xorl %eax, %eax
.p2align 4,,10
.p2align 3
.L4:
subq $4, %rdx
addq $1, %rax
movq %rdx, 8(%rdi)
cmpq %rax, %rsi
jne .L4
.L1:
ret
This regression is still present after the fixes for PR96721 and PR96722.
Should it be marked as [11/12 Regression] ?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
` (4 preceding siblings ...)
2022-02-15 10:41 ` redi at gcc dot gnu.org
@ 2022-02-15 10:47 ` redi at gcc dot gnu.org
2022-02-15 10:50 ` pinskia at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2022-02-15 10:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reduced:
template<typename T>
struct vector
{
using pointer = T*;
pointer begin, end, end_of_storage;
void pop_back()
{
(end--)->~T();
}
};
using size_t = decltype(sizeof(0));
void pop_many(vector<int>& v, size_t n) {
for (size_t i = 0; i < n; ++i) {
v.pop_back();
}
}
With -O2 -fno-lifetime-dse we get the expected code back.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
` (5 preceding siblings ...)
2022-02-15 10:47 ` redi at gcc dot gnu.org
@ 2022-02-15 10:50 ` pinskia at gcc dot gnu.org
2022-02-15 11:01 ` jakub at gcc dot gnu.org
2022-02-15 11:46 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-02-15 10:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #6)
>
> With -O2 -fno-lifetime-dse we get the expected code back.
I just saw another bug report filed about code quality with lifetime dse
enabled in the last week.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
` (6 preceding siblings ...)
2022-02-15 10:50 ` pinskia at gcc dot gnu.org
@ 2022-02-15 11:01 ` jakub at gcc dot gnu.org
2022-02-15 11:46 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-02-15 11:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
PR104515 ?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/96717] -flifetime-dse=2 breaks webkit-gtk-2.28.4
2020-08-19 22:25 [Bug c++/96717] New: -flifetime-dse=2 breaks webkit-gtk-2.28.4 slyfox at gcc dot gnu.org
` (7 preceding siblings ...)
2022-02-15 11:01 ` jakub at gcc dot gnu.org
@ 2022-02-15 11:46 ` redi at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: redi at gcc dot gnu.org @ 2022-02-15 11:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96717
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=104515
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes indeed, somebody on reddit just pointed me to that. It's the same as
comment 6.
^ permalink raw reply [flat|nested] 10+ messages in thread