[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time

2023-06-26 Thread anthony.ajw at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110380

Anthony Williams  changed:

   What|Removed |Added

 CC||anthony.ajw at gmail dot com

--- Comment #5 from Anthony Williams  ---
Yes, we have this problem too. In some cases we've explicitly duplicated tests
in static_assert and runtime-assert in order to convince gcov that the
functions are tested, but things like "std::is_constant_evaluated()" mean that
there might be different branches in runtime vs compile time cases, so
"-fprofile-constexpr" would be really useful

[Bug libstdc++/106183] std::atomic::wait might fail to be unblocked by notify_one/all on platforms without platform_wait()

2022-07-25 Thread anthony.ajw at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106183

Anthony Williams  changed:

   What|Removed |Added

 CC||anthony.ajw at gmail dot com

--- Comment #3 from Anthony Williams  ---
This is one of the common mistakes I mention when teaching people about
condition variables. Just because the data being waited for is atomic, doesn't
guarantee that the condition variable state is updated: you need the mutex to
synchronize that.

In current libstdc++ trunk libstdc++-v3/include/bits/atomic_wait.h insert a
line in _M_notify at line 235:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/atomic_wait.h;h=125b1cad88682384737c048ac236af9c4deab957;hb=refs/heads/trunk

  void
  _M_notify(const __platform_wait_t* __addr, bool __all, bool __bare)
noexcept
  {
if (!(__bare || _M_waiting()))
  return;

#ifdef _GLIBCXX_HAVE_PLATFORM_WAIT
__platform_notify(__addr, __all);
#else
/// INSERT HERE
{ std::lock_guard __lock(_M_mtx); }
/// END INSERT
if (__all)
  _M_cv.notify_all();
else
  _M_cv.notify_one();
#endif
  }

The lock/unlock here ensures that the notify is correctly synchronized with the
wait.