[Bug c++/114841] [P0522R0] partial ordering of template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114841 --- Comment #2 from Matheus Izvekov --- I published https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3310r0.html to address this problem, it has the most up-to-date wording. FYI the inconsistent deduction examples from problem #1 crash GCC.
[Bug c++/100385] New: overload resolution for function call expression on object selects `operator auto` conversion candidate.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100385 Bug ID: 100385 Summary: overload resolution for function call expression on object selects `operator auto` conversion candidate. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mizvekov at gmail dot com Target Milestone: --- The following program compiles successfully, but should be rejected: ``` template struct constant { constexpr operator auto () const noexcept { return V; } }; void myfree(void*); void test() { constant{}(nullptr); } ``` According to `[over.call.object]/2`: ``` ..., and where conversion-type-id denotes the type “pointer to function of (P1,…,Pn) returning R”, or the type “reference to pointer to function of (P1,…,Pn) returning R”, or the type “reference to function of (P1,…,Pn) returning R”, a surrogate call function with the unique name call-function and having the form R call-function ( conversion-type-id F, P1 a1, …, Pn an) { return F (a1, …, an); } is also considered as a candidate function. ... ``` But here `auto` is neither pointer, reference, nor reference to pointer to function. So I think the GCC behavior here is non-conformant, though it does look useful to accept it. Here is a workspace showing that Clang and MSVC reject this: https://godbolt.org/z/aT6TrPz1h The above workspace also is a double whammy in that it shows that libstdc++'s unique_ptr implementation somehow hides this problem from Clang.
[Bug target/79437] Redundant move instruction when getting sign bit of double on 32-bit architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79437 --- Comment #5 from Matheus Izvekov --- Issue is still present on 10.2 and trunk. Workspace for reference: https://godbolt.org/z/EYhaaW I believe this issue should have already been transitioned to CONFIRMED.
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #12 from Matheus Izvekov --- Thank you!!!
[Bug libstdc++/98605] [8/9/10 Regression] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #6 from Matheus Izvekov --- What clang-tidy version? From the date of the commit, it was probably no older than 6, probably 4 or 5. If that is too old and probably considered unsupported, I think that is fine. But even if in the end it was a false positive, the warning seemed to me to be of high quality, ie to some standard of coding practice, it would be advised to document this somewhat subtle assumption. Not sure that applies to libstdc++ standards :) But if you cannot reproduce the original warning anyway, then I guess it's better to just remove it than make some change that can't even be tested.
[Bug libstdc++/98605] clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 --- Comment #1 from Matheus Izvekov --- By the way, FYII it is also possible to suppress clang-tidy specific diagnostics on specific lines with a "comment pragma", like so (untested): // NOLINT(bugprone-dangling-handle) // NOLINTNEXTLINE(bugprone-dangling-handle) This might be better than having the linter parse different code than the real compiler, while avoiding these kinds of problems where its hard to test every define combination.
[Bug libstdc++/98605] New: clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605 Bug ID: 98605 Summary: clang-tidy error parsing on libstdc++-v3 Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mizvekov at gmail dot com Target Milestone: --- clang-tidy errors parsing `#include ` when _GLIBCXX_HAVE_TLS is not defined, with the following message: ``` include/c++/mutex:738:7: error: use of undeclared identifier '__once_callable'; did you mean '__callable'? [clang-diagnostic-error] __once_callable = nullptr; ^ include/c++/mutex:716:12: note: '__callable' declared here auto __callable = [&] { ^ include/c++/mutex:739:7: error: use of undeclared identifier '__once_call' [clang-diagnostic-error] __once_call = nullptr; ^ ``` This was caused by the following commit: ``` commit 018813c8994b7dceab1b7d999e9c09654a22ef50 Author: Jonathan Wakely Date: Fri Oct 13 12:56:07 2017 +0100 PR libstdc++/82481 Suppress clang-tidy warnings PR libstdc++/82481 * include/std/mutex (call_once): Suppress clang-tidy warnings about dangling references. diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex index 8c692a88ffd..50420ee22d4 100644 --- a/libstdc++-v3/include/std/mutex +++ b/libstdc++-v3/include/std/mutex @@ -688,6 +688,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION __set_once_functor_lock_ptr(0); #endif +#ifdef __clang_analyzer__ + // PR libstdc++/82481 + __once_callable = nullptr; + __once_call = nullptr; +#endif + if (__e) __throw_system_error(__e); } ``` The problem is that __once_callable et al are only declared when _GLIBCXX_HAVE_TLS is defined. A simple patch like this would fix it: ``` --- a/libstdc++-v3/include/std/mutex +++ b/libstdc++-v3/include/std/mutex @@ -731,9 +731,7 @@ #ifndef _GLIBCXX_HAVE_TLS if (__functor_lock) __set_once_functor_lock_ptr(0); -#endif - -#ifdef __clang_analyzer__ +#elif defined(__clang_analyzer__) // PR libstdc++/82481 __once_callable = nullptr; __once_call = nullptr; ```