[Bug c++/119898] New: constexpr expansion of array null pointer check fails with `-fno-delete-null-pointer-checks`

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119898 Bug ID: 119898 Summary: constexpr expansion of array null pointer check fails with `-fno-delete-null-pointer-checks` Product: gcc Version: 16.0 Status: UNCONFIRMED

[Bug c++/119895] New: List initialization of bitfield enum class member fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119895 Bug ID: 119895 Summary: List initialization of bitfield enum class member fails Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Prior

[Bug c++/119890] New: Add `__builtin_structured_binding_size` (useful and for compatibility with Clang)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119890 Bug ID: 119890 Summary: Add `__builtin_structured_binding_size` (useful and for compatibility with Clang) Product: gcc Version: unknown Status: UNCONFIRMED Sev

[Bug c++/109387] New: "definition of explicitly-defaulted" error with explicit template instantiation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109387 Bug ID: 109387 Summary: "definition of explicitly-defaulted" error with explicit template instantiation Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severi

[Bug target/109380] inline member function symbol not exported with explicit template instantiation declaration on MinGW

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 --- Comment #2 from Vittorio Romeo --- Hmm, you might be correct. Seeing that the issue has not been looked at since 2017, are you aware of any workaround besides `-Wl,--export-all-symbols`? The issue is preventing me from applying explicit te

[Bug c++/109380] New: inline member function symbol not exported with explicit template instantiation declaration on MinGW

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109380 Bug ID: 109380 Summary: inline member function symbol not exported with explicit template instantiation declaration on MinGW Product: gcc Version: 12.2.0 Status: UNCONFI

[Bug c++/89088] Dllexport for explicit template instantiation missing inline methods

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 Vittorio Romeo changed: What|Removed |Added CC||vittorio.romeo at outlook dot com ---

[Bug c++/107105] New: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107105 Bug ID: 107105 Summary: Consider folding `__and_`, `__or_`, and `__not_` at the front-end level Product: gcc Version: unknown Status: UNCONFIRMED Severity: nor

[Bug c++/100157] Support `__type_pack_element` like Clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157 --- Comment #9 from Vittorio Romeo --- (In reply to Jonathan Wakely from comment #8) > (In reply to Vittorio Romeo from comment #6) > > worthwhile to keep the same name as Clang for compatibility, > > No, that's not an option. Clang's is a buil

[Bug c++/100157] Support `__type_pack_element` like Clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157 --- Comment #6 from Vittorio Romeo --- Thank you, Jonathan, for looking into this. I feel like it might be worthwhile to keep the same name as Clang for compatibility, or maybe talk to some Clang developers and see if there can be an agreement o

[Bug c++/96780] debuginfo for std::move and std::forward isn't useful

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780 --- Comment #7 from Vittorio Romeo --- > As discussed on IRC, we might not want to do this folding at -O0 (although > I'd personally be happy with it unconditionally). I think you should reconsider this as discussed in these places: - https://g

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #9 from Vittorio Romeo --- I have done some benchmarking for three use cases, both with `-O0` and `-Og`, hacking my `libstdc++` headers to add `[[gnu::always_inline]]` where deemed appropriate. --- The use cases were: 1. `operato

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #6 from Vittorio Romeo --- > The request is to replace it with some kind of magic that does the same as > std::move without actually writing std::move. More generally speaking, ensure that function such as `std::move`, `std::forwar

[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #4 from Vittorio Romeo --- I see that `std::move` is indeed inlined with `-Og`, my apologies on not noticing that. I like the idea of having the compiler itself fold calls to things like `std::move` and `std::forward` as suggested

[Bug libstdc++/104719] New: Use of `std::move` in libstdc++ leads to worsened debug performance

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 Bug ID: 104719 Summary: Use of `std::move` in libstdc++ leads to worsened debug performance Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal

[Bug c++/100157] New: Support `__type_pack_element` like Clang

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100157 Bug ID: 100157 Summary: Support `__type_pack_element` like Clang Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/100008] New: std::clamp generates suboptimal assembly for primitive types

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18 Bug ID: 18 Summary: std::clamp generates suboptimal assembly for primitive types Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal