[Bug middle-end/113585] New: Poor codegen turning int compare into -1,0,1

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:

[Bug other/113682] New: Branches in branchless binary search rather than cmov/csel/csinc

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

[Bug middle-end/113682] Branches in branchless binary search rather than cmov/csel/csinc

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

[Bug target/113723] New: -freorder-blocks-and-partition emits bogus asm directives on aarch64

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

[Bug target/113723] -freorder-blocks-and-partition emits bogus asm directives on aarch64

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.

[Bug libstdc++/104223] New: GCC unable to inline trivial functions passed to views::filter and transform unless lifted into types

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

[Bug tree-optimization/59429] Missed optimization opportunity in qsort-style comparison functions

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

[Bug libstdc++/111588] New: Provide opt-out of shared_ptr single-threaded optimization

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

[Bug libstdc++/111589] New: Use relaxed atomic increment (but not decrement!) in shared_ptr

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

[Bug target/104611] memcmp/strcmp/strncmp can be optimized when the result is tested for [in]equality with 0 on aarch64

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104611 Mathias Stearn changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comm

[Bug other/111976] New: Large constant zero-valued objects should go in .bss rather than .rodata

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

[Bug other/111976] Large constant zero-valued objects should go in .bss rather than .rodata

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

[Bug libstdc++/111588] Provide opt-out of shared_ptr single-threaded optimization

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

[Bug libstdc++/111588] Provide opt-out of shared_ptr single-threaded optimization

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

[Bug c++/89997] Garbled expression in error message with -fconcepts

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

[Bug c++/89997] Garbled expression in error message with -fconcepts

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

[Bug c++/102363] New: source_location in await_transform has function_name referring to internal coroutine funclet rather than source-level function

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

[Bug web/102365] New: Function attribute docs should have an anchor or id on each attribute.

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

[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100493 Mathias Stearn changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comm

[Bug c++/100493] Lambda default copy capture that captures "this" cannot be used in both C++17 and C++20 modes

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

[Bug c++/102528] New: Unable to inline even trivial coroutines

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++

[Bug c++/102528] Unused out-of-line functions emitted for trivial coroutines

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

[Bug ipa/102528] Unused out-of-line functions emitted for trivial coroutines

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

[Bug c++/102876] New: GCC fails to use constant initialization even when it knows the value to initialize

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

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

[Bug c++/102876] GCC fails to use constant initialization even when it knows the value to initialize

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

[Bug libstdc++/99979] New: condition_variable_any has wrong behavior if Lock::lock() throws

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

[Bug c++/98639] GCC accepts cast from Base to Derived in C++20 mode

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98639 Mathias Stearn changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comme

[Bug libstdc++/99021] New: coroutine_handle<_Promise>::from_address() should be noexcept

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

[Bug libstdc++/99021] coroutine_handle<_Promise>::from_address() should be noexcept

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

[Bug libstdc++/99021] coroutine_handle<_Promise>::from_address() should be noexcept

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

[Bug c++/99047] New: ICE on simple task coroutine example

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++

[Bug c/99339] New: Poor codegen with simple varargs

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

[Bug middle-end/99339] Poor codegen with simple varargs

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 ;)

[Bug libstdc++/95079] unorderd_map::insert_or_assign and try_emplace should only hash and mod once unless there is a rehash.

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

[Bug middle-end/99339] Poor codegen with simple varargs

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

[Bug c++/99470] New: Convert fixed index addition to array address offset

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

[Bug rtl-optimization/99470] Convert fixed index addition to array address offset

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99470 Mathias Stearn changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID

[Bug target/105496] New: Comparison optimizations result in unnecessary cmp instructions

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

[Bug c++/105534] New: -Wmaybe-uninitialized shouldn't suppress -Wuninitialized warnings

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

[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

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

[Bug c++/105534] -Wmaybe-uninitialized cases shouldn't suppress -Wuninitialized warnings

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

[Bug c++/105560] New: Spurious -Wunused-local-typedefs warning on a typedef used on returned type

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:

[Bug target/105661] New: Comparisons to atomic variables generates less efficient code

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

[Bug c++/105397] Cannot export module initializer symbols with `-fvisibility=hidden`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397 Mathias Stearn changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comm

[Bug c++/100876] New: -Wmismatched-new-delete should either look through or ignore placement new

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

[Bug c++/114357] Add a way to not call deconstructors for non-auto decls, like clang's no_destroy attribute

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114357 Mathias Stearn changed: What|Removed |Added CC||redbeard0531 at gmail dot com --- Comm

[Bug middle-end/116383] New: Value from __atomic_store not forwarded to non-atomic load at same address

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: