https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103554
--- Comment #5 from Avi Kivity ---
Here's some big-picture data. Compiled with clang, which seems to ignore these
STLF issues.
no-slp:
42641.91 tps ( 75.1 allocs/op, 12.1 tasks/op, 44929 insns/op)
42446.41 tps ( 75.1 allocs/op, 12.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103554
--- Comment #7 from Avi Kivity ---
Sorry, I was unclear. That's the entire program with a huge number of slp
opportunities. Each iteration in the program is ~40k instructions. It's not
directly related to the test case, which is artificial, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103554
Bug ID: 103554
Summary: -mavx generates worse code on scalar code
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103319
--- Comment #2 from Avi Kivity ---
A gentle ping, can we backport this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103554
--- Comment #3 from Avi Kivity ---
> _Note_ that likely the suboptimal solution presented here is faster because
> it avoids STLF penalties from the calls stack setup which very likely uses
> scalar or differently aligned vector moves.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85516
--- Comment #6 from Avi Kivity ---
gcc 11.2 produces optimized code with the original example:
check_mask(E):
cmpl $9, %edi
ja .L3
movl %edi, %ecx
movl $562, %eax
shrq %cl, %rax
andl $1, %eax
ret
.L3:
xorl %eax, %eax
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85516
Avi Kivity changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97848
Avi Kivity changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104484
Bug ID: 104484
Summary: -freorder-block-and-partition not splitting into
sections with __builin_expect()
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104484
--- Comment #2 from Avi Kivity ---
(In reply to Andrew Pinski from comment #1)
> But the assembly output does not make sense to the code you gave either.
Apart from the missing .section directives, I didn't notice anything odd. Maybe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328
--- Comment #21 from Avi Kivity ---
Benno, many thanks for the fix. Please consider posting it to gcc-patches as
that may speed up review and merging.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104484
--- Comment #4 from Avi Kivity ---
gcc could infer that the check for f2 and the call to very_heavy are cold, and
move that little block to a .cold section, whether or not very_heavy is cold.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137
--- Comment #50 from Avi Kivity ---
Your reproducer does pass in trunk. So perhaps just a missing backport.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328
--- Comment #24 from Avi Kivity ---
Many thanks for the patch and the commit. Can we have it backported to 11.x?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328
--- Comment #22 from Avi Kivity ---
Maintainers, please review the patch posted in [1].
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591907.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104292
--- Comment #1 from Avi Kivity ---
btw, I see that the equivalent bool_and generates optimal code.
bool_and(bool, bool):
movl%esi, %eax
andl%edi, %eax
ret
Perhaps bool is written with the expectation that any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104292
Bug ID: 104292
Summary: [missed optimization] boolean addition generates
suboptimal code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103328
--- Comment #27 from Avi Kivity ---
Wonderful, thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
Bug ID: 105336
Summary: truncated address sanitizer stack traces
Product: gcc
Version: 11.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #1 from Avi Kivity ---
I guess I should mention the programs uses C++20 coroutines, and it could be
the case that debug information for coroutines is generated incorrectly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #3 from Avi Kivity ---
I have a multi-gigabyte reproducer. Unfortunately it's part of a huge program
that didn't build with gcc until very recently. It will be quite a task to
reduce it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #4 from Avi Kivity ---
Created attachment 52856
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52856=edit
intentionally buggy reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #5 from Avi Kivity ---
I reduced it to a few lines (attached, intentionally triggers use-after-free).
The culprit is -Og.
With
g++ coroutine-asan.cc -o coroutine-asan --std=c++20 -fsanitize=address -Og
I see
READ of size 8 at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105336
--- Comment #6 from Avi Kivity ---
(the reproducer was executed by gcc 12 prerelease, not gcc 11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #5 from Avi Kivity ---
Can you confirm my suspicion about the copying of __old4 in gimple? If that's
the culprit I believe I can mechanically reduce the reproducer to something
easily manageable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #6 from Avi Kivity ---
Some more findings: if I replace the lambda (which is not a coroutine, but is
contained in a coroutine lambda) with an equivalent struct, the problem goes
away, both at runtime and in terms of an __old4 copy.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #7 from Avi Kivity ---
To give more context:
struct ._anon_973 D.2159793 [value-expr: frame_ptr->D.2159793_4_7];
struct lw_shared_ptr D.2159792 [value-expr: frame_ptr->D.2159792_4_7];
(I determined that _anon_973 is the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #1 from Avi Kivity ---
I randomly looked at 023t.ssa (mainly because I recognized the acronym).
_45 = frame_ptr_182(D)->__closure;
_46 = _45->__this;
frame_ptr_182(D)->D.2159984_4_7 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #2 from Avi Kivity ---
I see it in 006t.gimple too:
try
{
_50 = frame_ptr->__closure;
_51 = _50->__this;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
Bug ID: 105373
Summary: miscompile involving lambda coroutines and an object
bitwise copied instead of via the copy constructor
Product: gcc
Version: 11.3.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #3 from Avi Kivity ---
I see this alleged copy in gcc 10.2.1 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #14 from Avi Kivity ---
Do you confirm that my observation about the generated gimple corresponds to
the bug?
If so, is there a central point where this anonymous variables are named?
Perhaps we can breakpoint on D.2741 and see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104020
Avi Kivity changed:
What|Removed |Added
CC||avi at scylladb dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #15 from Avi Kivity ---
I see that both sides of the assignment are created in flatten_await_stmt, case
case TARGET_EXPR.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #3 from Avi Kivity ---
I have something like this:
│ 2680 future<> system_keyspace_make(distributed&
dist_db, distributed& dist_ss,
sharded& dist_gossiper, db::config& cfg) { │
│ 2681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #8 from Avi Kivity ---
Hoping this is a duplicate of PR105287. Checking.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #10 from Avi Kivity ---
I have something like this:
│ 2680 future<> system_keyspace_make(distributed&
dist_db, distributed& dist_ss,
sharded& dist_gossiper, db::config& cfg) { │
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #11 from Avi Kivity ---
Created attachment 52899
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52899=edit
simple(r) reproducer
I was able to reduce it to something simple (102 lines), but I was only able to
verify that wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #9 from Avi Kivity ---
I think it makes it worse, now seeing similar crashes, but earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105287
Avi Kivity changed:
What|Removed |Added
CC||avi at scylladb dot com
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #6 from Avi Kivity ---
I already owe you many beers, but this one is special.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105426
Bug ID: 105426
Summary: [wrong-code][regression][coroutines] range-for
temporaries are not persisted in coroutines
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105426
--- Comment #1 from Avi Kivity ---
Created attachment 52898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52898=edit
reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
--- Comment #4 from Avi Kivity ---
Oops, last comment intended for a separate bug. Curse the bug list thing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106847
Bug ID: 106847
Summary: deprecated class data member makes the class generate
diagnostics even when the member is not used
Product: gcc
Version: 13.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106847
--- Comment #1 from Avi Kivity ---
Clang equivalent: https://github.com/llvm/llvm-project/issues/55774
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106847
--- Comment #3 from Avi Kivity ---
But I need it to be copied. It's a struct of options:
struct options {
bool frob = false;
[[derecated]] bool quux = false; // will be removed soon
bool grue = false;
};
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #17 from Avi Kivity ---
This was apparently fixed by 58a7b1e354530d8dfe7d8fb859c8b8b5a9140f1f. At
least, I no longer observe copying of __old4 in gimple. Instead, I see
addresses taken, and if I squint I can see that object properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
Bug ID: 107772
Summary: [missed optimization] function prologue generated even
though it's only needed in an unlikely path
Product: gcc
Version: 13.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105373
--- Comment #16 from Avi Kivity ---
Bug hasn't fixed itself as of ccb9c7b129206209cfc315ab1a0432b5f517bdd9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
--- Comment #5 from Avi Kivity ---
It indeed generates better code. However, it requires that I duplicate the
function body, which can be hard at times (consider f == std::transform and "if
(*b != 0) { *b = g(*b); }" as a lambda input.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107772
--- Comment #2 from Avi Kivity ---
I expect something like this:
f(int*, int*):
cmp rdi, rsi
je .L10
.L4:
cmp DWORD PTR [rsi], 0
jne .L14
.L3
add rsi, 4
cmp rsi, rdi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105204
--- Comment #3 from Avi Kivity ---
Does one have to declare all preconditions? I happen to know that shared_ptr
with a reference count of zero is impossible, and I can understand the compiler
not being able to infer it, but just because it's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056
--- Comment #22 from Avi Kivity ---
This is wonderful, thank you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109053
Bug ID: 109053
Summary: [missed optimization] value-range tracking fails in
simple case with __builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109227
--- Comment #1 from Avi Kivity ---
Did you forget to attach bad.cc?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960
Avi Kivity changed:
What|Removed |Added
CC||avi at scylladb dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103960
--- Comment #6 from Avi Kivity ---
Ah! thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66034
--- Comment #3 from Avi Kivity ---
Yes, this is relevant to user-level threads, not coroutines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611
--- Comment #8 from Avi Kivity ---
Congratulations on getting the account!
The bug is fixed though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100611
--- Comment #9 from Avi Kivity ---
At least, on 13.2.1. Maybe a backport is required.
61 matches
Mail list logo
