[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;
```
