[Bug driver/115990] Consider deprecating -Ofast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990 --- Comment #16 from gnzlbg --- Maybe if it was called "-Ounsafe-fast" people may end up reading the docs to find out what that unsafe means. If we had that option as an alias to "-Ofast", then maybe -Ofast could just warn with: > -Ofast is

[Bug driver/115990] Consider deprecating -Ofast

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115990 gnzlbg changed: What|Removed |Added CC||gonzalo.gadeschi at gmail dot com ---

[Bug c++/112789] Missing clang __builtin_ctzs for short

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #9 from gnzlbg --- > > Look at that part where __builtin_ctzs is mentioned there. > It just says it is valid inside a constexpr and nothing else about the > builtin. Yes, seems like a bug / pr should be opened in the llvm project

[Bug c++/112789] Missing clang __builtin_ctzs for short

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #8 from gnzlbg --- Oh! Sorry! I see this was resolved as WONTFIX. Does that mean that GCC, in contrast with the LLVM community - which is always super helpful and friendly when it comes to trying to enable their toolchains to

[Bug c++/112789] Missing clang __builtin_ctzs for short

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #6 from gnzlbg --- Thanks for all the quick feedback! > Also clang does not even document __builtin_ctzs anywhere ... This builtin is documented in the list of clang bultins. You can find it by using CTRL+F for the builtin, in

[Bug c++/112789] New: Missing clang __builtin_ctzs for short

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 Bug ID: 112789 Summary: Missing clang __builtin_ctzs for short Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/111516] New: parameter passing note is not actionable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111516 Bug ID: 111516 Summary: parameter passing note is not actionable Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug libstdc++/107761] Implement C++23

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 --- Comment #2 from gnzlbg --- Update: the reference implementation is now merged into libc++ and will release with LLVM 17.

[Bug target/111047] Un-silenceable note for ABI parameters 64-byte alignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111047 --- Comment #3 from gnzlbg --- Thank you both. > should probably output "[-Wpsabi]" to make this clear. +1

[Bug c++/111047] New: Un-silenceable note for ABI parameters 64-byte alignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111047 Bug ID: 111047 Summary: Un-silenceable note for ABI parameters 64-byte alignment Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/110512] C++20 random access iterators run sequentially with PSTL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512 --- Comment #5 from gnzlbg --- The patch for this bug in libc++ has been reviewed: https://reviews.llvm.org/D154305 I've submitted a patch for the same issue to libstdc++: https://gcc.gnu.org/pipermail/libstdc++/2023-July/056266.html

[Bug libstdc++/110512] C++20 random access iterators run sequentially with PSTL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512 --- Comment #3 from gnzlbg --- @Jonathan What is missing in https://wg21.link/p2408 to enable the PSTL to use the iterator concept for the iota_view::iterator such that the PSTL may run the above in parallel?

[Bug libstdc++/110512] New: C++20 random access iterators run sequentially with PSTL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110512 Bug ID: 110512 Summary: C++20 random access iterators run sequentially with PSTL Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal

[Bug libstdc++/106793] New: std::barrier missing default template argument?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106793 Bug ID: 106793 Summary: std::barrier missing default template argument? Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component:

[Bug c++/103732] Incorrect constexpr evaluation of runtime expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103732 --- Comment #2 from gnzlbg --- > ICC and MSVC both accept it like GCC That's correct, please feel free to report the bug to them as well.

[Bug c++/103732] New: Incorrect constexpr evaluation of runtime expression

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103732 Bug ID: 103732 Summary: Incorrect constexpr evaluation of runtime expression Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3

[Bug c++/96593] No "declaration changes meaning" diagnostic for alias templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96593 --- Comment #3 from gnzlbg --- >From 102444 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102444): See http://eel.is/c++draft/class.member.lookup#6 [class.member.lookup]/p6: "If it [the result of the search] differs from the result of a

[Bug c++/96593] No "declaration changes meaning" diagnostic for alias templates

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96593 gnzlbg changed: What|Removed |Added CC||gonzalo.gadeschi at gmail dot com --- Comment

[Bug c++/102444] class definition not allowed to change meaning of previously used name

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102444 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/102444] New: class definition not allowed to change meaning of previously used name

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102444 Bug ID: 102444 Summary: class definition not allowed to change meaning of previously used name Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal

[Bug c++/100700] -Wreturn-type has many false positives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/100700] -Wreturn-type has many false positives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #2 from gnzlbg --- > in a call to f(-1) the function falls off the end, Indeed, thanks. Using <= in the condition removes the warning. > and ditto in a call to h ((enum E)2) Until C++17, creating an enum value that's out-of-range

[Bug c++/100700] New: -Wreturn-type has many false positives

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 Bug ID: 100700 Summary: -Wreturn-type has many false positives Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++

[Bug c++/100443] member using declaration of function templates with different return types does not bring base class overload into derived class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443 --- Comment #6 from gnzlbg --- >From [basic.scope.scope]/p3.3.2 http://eel.is/c++draft/basic.scope.scope#3.3.2 I think that A::f and B::f don't correspond because they are function templates but their return types differ. Since they don't

[Bug c++/100443] member using declaration of function templates with different return types does not bring base class overload into derived class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443 --- Comment #5 from gnzlbg --- > There is still no mention of signatures, which is why I wondered why you're > talking about them. Re-reading that part, you are correct that it does not mention signatures. I misunderstood it. Reading

[Bug c++/100443] member using declaration of function templates with different return types does not bring base class overload into derived class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443 --- Comment #3 from gnzlbg --- http://eel.is/c++draft/namespace.udecl#11 > The set of declarations named by a using-declarator that inhabits a class C > does not include member functions and member function templates of a base > class that

[Bug c++/100443] New: member using declaration of function templates with different return types does not bring base class overload into derived class

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100443 Bug ID: 100443 Summary: member using declaration of function templates with different return types does not bring base class overload into derived class Product: gcc

[Bug c++/100185] transparent_union fails when the union has a destructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100185 --- Comment #5 from gnzlbg --- Thank you for the clarification! Will map Rust repr(transparent) to clang's [[clang::trivial_abi]] then and will gracefully #pragma error to prevent users from shooting themselves in the foot with GCC.

[Bug c++/100185] transparent_union fails when the union has a destructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100185 --- Comment #3 from gnzlbg --- @Jakub, is there a GCC equivalent to `[[clang::trivial_abi]]` that one can use instead ?