[Bug libstdc++/100889] Wrong param type for std::atomic_ref<_Tp*>::wait

[richardpku at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889

--- Comment #1 from Richard Li  ---
Created attachment 50917
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50917=edit
Proposed patch

This patch fixes the problem.

[Bug libstdc++/100889] New: Wrong param type for std::atomic_ref<_Tp*>::wait

[richardpku at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100889

Bug ID: 100889
   Summary: Wrong param type for std::atomic_ref<_Tp*>::wait
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richardpku at gmail dot com
  Target Milestone: ---

/tmp % cat a.cpp
#include 
void* p;
void foo() { std::atomic_ref(p).store(nullptr); }

/tmp % g++-11.1.0 -c -std=gnu++20 a.cpp
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/atomic:41,
 from a.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h: In
instantiation of 'struct std::__atomic_ref':
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/atomic:1618:12:  
required from 'struct std::atomic_ref'
a.cpp:3:31:   required from here
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h:1873:7:
error: invalid parameter type 'void'
 1873 |   wait(_Tp __old, memory_order __m = memory_order_seq_cst) const
noexcept
  |   ^~~~
/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/g++-v11/bits/atomic_base.h:1873:7:
error: in declaration 'void std::__atomic_ref<_Tp*, false, false>::wait(_Tp,
std::memory_order) const'


Apparently, the first param of std::atomic<_Tp*>::wait should be _Tp* instead
of _Tp.

It appears this bug has existed since GCC 11, when __cpp_lib_atomic_wait was
implemented.

[Bug c++/100588] New: Destroying delete shouldn't be called if constructor throws

[richardpku at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100588

Bug ID: 100588
   Summary: Destroying delete shouldn't be called if constructor
throws
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richardpku at gmail dot com
  Target Milestone: ---

Consider this program:


#include 
#include 

class A {
 public:
  A() { throw 42; }
  ~A() { puts("A::~A"); }

  void operator delete(void* p) {
puts("regular delete invoked");
::operator delete(p);
  }

  void operator delete(A* p, std::destroying_delete_t) {
puts("destroying delete invoked");
p->~A();
::operator delete(p);
  }
};

int main() {
  try {
new A;
  } catch (int) {
  }
}


Output compiled with GCC:

destroying delete invoked
A::~A


Output compiled with Clang:

regular delete invoked


I believe clang has the correct behavior.

A destroying delete function is expected to invoke the destructor explicitly. 
As a result, the current GCC implementation would indirectly invoke the
destructor on an instance that wasn't successfully constructed, which obviously
isn't the intended behavior.

It is even worse if class A has a base class, in which case the destructor of
the base class is called twice if an exception is thrown in A's constructor.

[Bug libstdc++/99181] New: char_traits (and thus string_view) compares strings differently in constexpr and non-constexpr contexts

[richardpku at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99181

Bug ID: 99181
   Summary: char_traits (and thus string_view) compares
strings differently in constexpr and non-constexpr
contexts
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richardpku at gmail dot com
  Target Milestone: ---

Minimal program to produce bug (run it on a platform where char is a signed
type, such as i386/x86-64):

/tmp % cat a.cpp
#include 
#include 

using namespace std;

int main() {
// constexpr
constexpr bool i = ("\xff"sv > "aaa"sv);
cout << i << ",";

// not constexpr
auto a = "\xff"sv, b = "aaa"sv;
cout << (a > b) << endl;

return 0;
}
/tmp % g++ -std=gnu++2a a.cpp && ./a.out
0,1

The expected result is "1,1".


In a non-constexpr context, std::char_traits::compare invokes
__builtin_memcmp, which is required by C standard to interpret characters as
unsigned char.

In a constexpr context, however, std::char_traits::compare invokes
__gnu_cxx::char_traits::compare, which in turn calls
__gnu_cxx::char_traits::lt to compare chars.
__gnu_cxx::char_traits::lt (unlike std::char_traits::lt) is not
specialized to compare chars as unsigned char.