[Bug c++/114841] [P0522R0] partial ordering of template template parameters

2024-05-24 Thread mizvekov at gmail dot com via Gcc-bugs
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.

2021-05-02 Thread mizvekov at gmail dot com via Gcc-bugs
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

2021-01-18 Thread mizvekov at gmail dot com via Gcc-bugs
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

2021-01-13 Thread mizvekov at gmail dot com via Gcc-bugs
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

2021-01-12 Thread mizvekov at gmail dot com via Gcc-bugs
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

2021-01-09 Thread mizvekov at gmail dot com via Gcc-bugs
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

2021-01-08 Thread mizvekov at gmail dot com via Gcc-bugs
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;
```