https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117655
--- Comment #2 from Mathias Stearn ---
It looks like a similar optimization would make sense for operator=(string&&):
https://godbolt.org/z/Wo19fjKeK. It might also make sense to just copy the
whole buffer for the local case in operator=(const s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117655
Bug ID: 117655
Summary: std::string::swap() could be much faster and smaller
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117650
Bug ID: 117650
Summary: __glibcxx_assert_fail should be marked
__attribute__((cold))
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116383
Bug ID: 116383
Summary: Value from __atomic_store not forwarded to non-atomic
load at same address
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
--- Comment #16 from Mathias Stearn ---
Trunk still generates different code for all cases (in some cases subtly so)
for both aarch64 and x86_64: https://www.godbolt.org/z/1s6sxrMWq. For both
arches, it seems like LE and LG generate the best code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723
--- Comment #1 from Mathias Stearn ---
As a workaround sticking [[gnu::optimize("no-reorder-blocks-and-partition")]]
on each function that triggers this seems to work. But that is obviously not a
scalable solution.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113723
Bug ID: 113723
Summary: -freorder-blocks-and-partition emits bogus asm
directives on aarch64
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
--- Comment #5 from Mathias Stearn ---
(In reply to Andrew Pinski from comment #2)
> I should note that on x86, 2 cmov in a row might be an issue and worse than
> branches. There is a cost model and the x86 backend rejects that.
>
> There are s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113682
Bug ID: 113682
Summary: Branches in branchless binary search rather than
cmov/csel/csinc
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113585
Bug ID: 113585
Summary: Poor codegen turning int compare into -1,0,1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588
--- Comment #5 from Mathias Stearn ---
Mea culpa. The difference between boost and std was due to the code to
fast-path shared_ptrs that aren't actually shared:
https://github.com/gcc-mirror/gcc/blob/be34a8b538c0f04b11a428bd1a9340eb19dec13f/libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588
--- Comment #4 from Mathias Stearn ---
So even though I already knew in the back of my mind about how this can affect
benchmark results, I *still* got burned by it! I was benchmarking a simple
hazard pointer implementation against shared ptrs by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976
--- Comment #1 from Mathias Stearn ---
Just to be clear, I think we should only do this for "large" objects or
collections of objects. If you did it for small objects in general, there is a
risk that they will spread out mutable data that is wri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111976
Bug ID: 111976
Summary: Large constant zero-valued objects should go in .bss
rather than .rodata
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111589
Bug ID: 111589
Summary: Use relaxed atomic increment (but not decrement!) in
shared_ptr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111588
Bug ID: 111588
Summary: Provide opt-out of shared_ptr single-threaded
optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997
--- Comment #6 from Mathias Stearn ---
> I think this is probably not concepts-specific, and just another variant of
> PR 49152.
Perhaps the busted pretty printer is a general problem, but at least in this
case I think the fix may be in concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89997
--- Comment #3 from Mathias Stearn ---
Please reopen. It still seems to be broken with -std=c++20 as the only flag:
https://godbolt.org/z/bWMq4s6xb (trunk) https://godbolt.org/z/W3xWjWaGe (12.2)
Output:
: In function 'void test()':
:16:15: erro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105661
Bug ID: 105661
Summary: Comparisons to atomic variables generates less
efficient code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105560
Bug ID: 105560
Summary: Spurious -Wunused-local-typedefs warning on a typedef
used on returned type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105534
--- Comment #4 from Mathias Stearn ---
(In reply to Richard Biener from comment #2)
> Note there's
>
> _2 = value_1(D) * x_2;
>
> where _2 might be effectively uninitialized iff x_2 is not zero. When x_2
> is zero then _2 has a well-defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105534
--- Comment #3 from Mathias Stearn ---
One slightly confusing aspect is that the wording of the flag implies that the
variable may or may not be uninitialzied (because in -Wmaybe-uninitialized
maybe binds directly to uninitialized), while phrasi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105534
Bug ID: 105534
Summary: -Wmaybe-uninitialized shouldn't suppress
-Wuninitialized warnings
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105496
Bug ID: 105496
Summary: Comparison optimizations result in unnecessary cmp
instructions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104223
Bug ID: 104223
Summary: GCC unable to inline trivial functions passed to
views::filter and transform unless lifted into types
Product: gcc
Version: unknown
Status: UNCON
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #12 from Mathias Stearn ---
(In reply to Jakub Jelinek from comment #10)
> So we'd just punt at optimizing that, we don't know if b is read or written
> by foo (and, note, it doesn't have to be just the case of explicitly being
> pas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
--- Comment #3 from Mathias Stearn ---
> Why not just make the function constexpr though?
That isn't always possible. Sometimes the initializer may call a third-party
function that is inline, but not yet marked constexpr (it may need to support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102876
Bug ID: 102876
Summary: GCC fails to use constant initialization even when it
knows the value to initialize
Product: gcc
Version: unknown
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528
--- Comment #8 from Mathias Stearn ---
Sorry again about the confusion caused by my typo. I am not able to edit the
comment to make it clear that the comment#0 should be ignored. If that happens
again, would it be better for me to close the tick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528
--- Comment #1 from Mathias Stearn ---
Sorry, there was a typo in the initial code. I forgot the trivial
implementation of await_resume(). (D'oh!)
Now I can see that test() is just a ret instruction, but there is still a lot
of dead code emitte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528
Bug ID: 102528
Summary: Unable to inline even trivial coroutines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493
--- Comment #3 from Mathias Stearn ---
When reading https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82611, I noticed that
C++17 actually requires the warning on [=, this] from a conforming
implementation:
https://timsong-cpp.github.io/cppwp/n4659/e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102365
Bug ID: 102365
Summary: Function attribute docs should have an anchor or id on
each attribute.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102363
Bug ID: 102363
Summary: source_location in await_transform has function_name
referring to internal coroutine funclet rather than
source-level function
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876
Bug ID: 100876
Summary: -Wmismatched-new-delete should either look through or
ignore placement new
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99979
Bug ID: 99979
Summary: condition_variable_any has wrong behavior if
Lock::lock() throws
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470
Mathias Stearn changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470
Bug ID: 99470
Summary: Convert fixed index addition to array address offset
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339
--- Comment #6 from Mathias Stearn ---
> The question is how common in the wild it is and if it is worth the work.
I'm not sure how common it is, but this is my use case. The code in the bug
report is a slightly simplified example from some Real
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95079
--- Comment #5 from Mathias Stearn ---
@François Dumont: Sorry I didn't see your question earlier. The reason that
unordered_map perf hurts on 64-bit platforms is because it is designed to do a
size_t modulus-by-prime on every lookup, and on most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339
--- Comment #5 from Mathias Stearn ---
I filed a related bug with clang right after this one if anyone want to follow
along https://bugs.llvm.org/show_bug.cgi?id=49395.
Just because clang does worse doesn't mean gcc shouldn't do better ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99339
Bug ID: 99339
Summary: Poor codegen with simple varargs
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99047
Bug ID: 99047
Summary: ICE on simple task coroutine example
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99021
--- Comment #3 from Mathias Stearn ---
Thanks for the quick fix!
Any chance of a backport of this and
https://github.com/gcc-mirror/gcc/commit/f1b6e46c417224887c2f21baa6d4c538a25fe9fb#diff-ed08df78eba81189642b4e8d670a0adb4b377db6846aecb090b4dce5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99021
--- Comment #1 from Mathias Stearn ---
clang bug for reference https://bugs.llvm.org/show_bug.cgi?id=49109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99021
Bug ID: 99021
Summary: coroutine_handle<_Promise>::from_address() should be
noexcept
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98639
Mathias Stearn changed:
What|Removed |Added
CC||redbeard0531 at gmail dot com
--- Comme
51 matches
Mail list logo
