[Bug c++/110380] [feature request] "-pg-constexpr=coverage-output" emit coverage metrics for constexpr code evaluated at compile time
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()
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.
[Bug libstdc++/92616] Inconsistency in time between system_clock::now() and time(nullptr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92616 --- Comment #7 from Anthony Williams --- Reported as ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/linux-signed-oem/+bug/1853807
[Bug libstdc++/92616] Inconsistency in time between system_clock::now() and time(nullptr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92616 --- Comment #5 from Anthony Williams --- Where can I file a bug in the vDSO?
[Bug libstdc++/92616] New: Inconsistency in time between system_clock::now() and time(nullptr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92616 Bug ID: 92616 Summary: Inconsistency in time between system_clock::now() and time(nullptr) Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: anthony.ajw at gmail dot com Target Milestone: --- Created attachment 47321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47321=edit system_clock::now vs time(nullptr) inconsistency I have some code which uses std::this_thread::sleep_until to wait until a specific time The target time is set from a time_t value using std::chrono::system_clock::from_time_t(). Consistently, after waking, the value returned by time(nullptr) is less than the target time. However, the time returned by std::chrono::system_clock::now() is greater than the current time. e.g. the attached code creates the following output: Now (sc) time is 1574342217233406476 (system clock) =>1574342217(time_t) =>13:16:57 Now (time(nullptr)) time is 1574342217(time_t) =>13:16:57 Now (sc) time is 1574342219000231775 (system clock) =>1574342219(time_t) =>13:16:59 Now (time(nullptr)) time is 1574342218(time_t) =>13:16:58 As you can see, when woken, the time return by time(nullptr) is earlier than the corresponding time_t conversion from system_clock::now(). FYI, this is compiled using the g++-8.3.0 from the ubuntu 18.04 repos. g++ --version outputs: g++ (Ubuntu 8.3.0-6ubuntu1~18.04.1) 8.3.0
[Bug c++/79686] New: Variadic template expansion into concept with leading parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79686
Bug ID: 79686
Summary: Variadic template expansion into concept with leading
parameters
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anthony.ajw at gmail dot com
Target Milestone: ---
If I declare a concept that takes a fixed argument and then a variadic
argument, I cannot use it in a function that passes a variadic parameter pack
to the concept. The following code fails to compile:
template
concept bool X=true;
template
void foo(Args&& ...) requires X{}
int main(){
foo(3);
}
Output of g++ -fconcepts t.cpp
t.cpp:5:31: error: invalid reference to concept ‘X’
void foo(Args&& ...) requires X{}
^~
t.cpp: In function ‘int main()’:
t.cpp:8:10: error: cannot call function ‘void foo(Args&& ...) requires
[with Args = {int}]’
foo(3);
^
t.cpp:5:6: note: constraints not satisfied
void foo(Args&& ...) requires X{}
^~~
t.cpp:8:10: note: ill-formed constraint
foo(3);
^
g++ --version
g++ (Ubuntu 6.2.0-3ubuntu11~16.04) 6.2.0 20160901
I get the same errors from my build of gcc 7:
g++-7 --version
g++-7 (GCC) 7.0.0 20170115 (experimental)
[Bug libstdc++/70298] New: std::call_once hangs on second call if first threw an exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70298 Bug ID: 70298 Summary: std::call_once hangs on second call if first threw an exception Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: anthony.ajw at gmail dot com Target Milestone: --- Created attachment 38026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38026=edit call_once_bug.cpp The attached code will hang on the second call to std::call_once.
[Bug libstdc++/66146] call_once not C++11-compliant on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66146 --- Comment #16 from Anthony Williams --- Would it be worth ignoring pthread_once and using an implementation of call_once based on Mike Burrows' algorithm? http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2444.html
[Bug libstdc++/69354] New: std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354
Bug ID: 69354
Summary: std::thread doesn't support move-only callable objects
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: anthony.ajw at gmail dot com
Target Milestone: ---
Created attachment 37390
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37390=edit
move_only_thread.cpp
Trying to construct a std::thread with a move-only function object produces a
compilation failure in tuple. This should compile OK.
The attached example fails with the error message below:
In file included from /usr/include/c++/5/functional:55:0,
from /usr/include/c++/5/thread:39,
from move_only_thread.cpp:1:
/usr/include/c++/5/tuple: In instantiation of ‘struct std::_Head_base<0ul,
MoveOnly, true>’:
/usr/include/c++/5/tuple:339:12: required from ‘struct std::_Tuple_impl<0ul,
MoveOnly>’
/usr/include/c++/5/tuple:463:11: required from ‘class std::tuple’
/usr/include/c++/5/functional:1534:39: required from ‘struct
std::_Bind_simple<MoveOnly()>’
/usr/include/c++/5/thread:137:59: required from
‘std::thread::thread(_Callable&&, _Args&& ...) [with _Callable = MoveOnly;
_Args = {}]’
move_only_thread.cpp:16:31: required from here
/usr/include/c++/5/tuple:64:17: error: ‘constexpr std::_Head_base<_Idx, _Head,
true>::_Head_base(const std::_Head_base<_Idx, _Head, true>&) [with long
unsigned int _Idx = 0ul; _Head = MoveOnly]’ declared to take const reference,
but implicit declaration would take non-const
constexpr _Head_base(const _Head_base&) = default;
[Bug libstdc++/69354] std::thread doesn't support move-only callable objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69354 --- Comment #3 from Anthony Williams --- I hadn't noticed I had omitted the const! Surely the intent of 12.8p11.2 is that if you can't actually copy the bases and/or members with the specified signature then the defaulted copy constructor is deleted? Are you going to file the DR or shall I? Potential core defect aside, I still think this class should work with std::thread, as it fits the MoveConstructible requirement.
[Bug libstdc++/69301] New: std::atomic::load() won't compile if T doesn't have a default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69301
Bug ID: 69301
Summary: std::atomic::load() won't compile if T doesn't have
a default constructor
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: anthony.ajw at gmail dot com
Target Milestone: ---
Created attachment 37360
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37360=edit
atomic_no_default_constructor.cpp
The attached simple code fails to compile with g++ 5.3 in C++1y mode because
NoDefaultConstructor doesn't have a default constructor. The error message is
quoted below.
g++-5 -std=c++1y atomic_no_default_constructor.cpp
In file included from atomic_no_default_constructor.cpp:1:0:
/usr/include/c++/5/atomic: In instantiation of ‘_Tp
std::atomic<_Tp>::load(std::memory_order) const [with _Tp =
NoDefaultConstructor; std::memory_order = std::memory_order]’:
atomic_no_default_constructor.cpp:11:12: required from here
/usr/include/c++/5/atomic:234:13: error: no matching function for call to
‘NoDefaultConstructor::NoDefaultConstructor()’
_Tp tmp;
^
atomic_no_default_constructor.cpp:5:15: note: candidate: constexpr
NoDefaultConstructor::NoDefaultConstructor(int)
constexpr NoDefaultConstructor(int i_) noexcept : i(i_) {}
^
atomic_no_default_constructor.cpp:5:15: note: candidate expects 1 argument, 0
provided
atomic_no_default_constructor.cpp:3:8: note: candidate: constexpr
NoDefaultConstructor::NoDefaultConstructor(const NoDefaultConstructor&)
struct NoDefaultConstructor{
^
atomic_no_default_constructor.cpp:3:8: note: candidate expects 1 argument, 0
provided
atomic_no_default_constructor.cpp:3:8: note: candidate: constexpr
NoDefaultConstructor::NoDefaultConstructor(NoDefaultConstructor&&)
atomic_no_default_constructor.cpp:3:8: note: candidate expects 1 argument, 0
provided
[Bug c++/60272] New: atomic::compare_exchange_weak has spurious store and can cause race conditions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60272
Bug ID: 60272
Summary: atomic::compare_exchange_weak has spurious store and
can cause race conditions
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: anthony.ajw at gmail dot com
Created attachment 32170
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32170action=edit
Sample code that demonstrates the problem
G++ 4.8.1 is producing incorrect code for std::atomic::compare_exchange_weak
on x86-64 linux.
In particular, if the exchange succeeds, then there is an additional spurious
store to the expected parameter after the exchange, which may race with other
threads and cause problems.
e.g.
#include atomic
struct Node { Node* next; };
void Push(std::atomicNode* head, Node* node)
{
node-next = head.load();
while(!head.compare_exchange_weak(node-next, node))
;
}
When compiled with
g++-4.8 -S -std=c++11 -pthread -O3 t.cpp
the generated code is:
movq(%rdi), %rax
movq%rax, (%rsi)
movq(%rsi), %rax
.p2align 4,,10
.p2align 3
.L3:
lock; cmpxchgq%rsi, (%rdi)
movq%rax, (%rsi) ***
jne.L3
rep; ret
The line marked *** is an unconditional store to node-next in this
example, and will be executed even if the exchange is successful.
This will cause a race with code that uses the compare-exchange to order memory
operations.
e.g.
void Pop(std::atomicNode* head){
for(;;){
Node* value=head.exchange(nullptr);
if(value){
delete value;
break;
}
}
}
If the exchange successfully retrieves a non-null value, it should be OK to
delete it (assuming the node was allocated with new). However, if one thread is
calling Push() and is suspended after the CMPXCHG and before the line marked
*** is executed then another thread running Pop() can successfully complete
the exchange and call delete. When the first thread is resumed, the line marked
*** will then store to deallocated memory.
This is in contradiction to 29.6.5p21 of the C++ Standard, which states that
expected is only updated in the case of failure.
[Bug libstdc++/53202] New: Copy constructor not called when starting a thread
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53202 Bug #: 53202 Summary: Copy constructor not called when starting a thread Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: anthony@gmail.com Created attachment 27291 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27291 Simple test program When compiling and running the attached program the copy constructor for background_hello should be called at least once. It is not being called at all, but the function call operator is showing a different this pointer, and the destructor is called 3 times. ~$ g++ --version g++ (Ubuntu/Linaro 4.7.0-7ubuntu1) 4.7.0 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ~$ g++ -std=c++0x -pthread t.cpp ./a.out default ctor called, this=0x7fffc2b05bdf destructor called, this=0x7fffc2b05b8f void background_hello::operator()() called, this=0x922040 destructor called, this=0x922040 destructor called, this=0x7fffc2b05bdf
[Bug libstdc++/52612] New: std::tr1::bind doesn't work with placeholders
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52612
Bug #: 52612
Summary: std::tr1::bind doesn't work with placeholders
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: anthony@gmail.com
Created attachment 26913
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26913
Example code that fails
The following simple code doesn't compile:
#include tr1/functional
int return_int2(int,int)
{
return 42;
}
int main(){
std::tr1::bind(return_int2,32,std::tr1::placeholders::_1)(5);
}
Compiler output:
$g++ t2.cpp
t2.cpp: In function ‘int main()’:
t2.cpp:9:64: error: no match for call to ‘(std::tr1::_Bindint (*(int,
std::tr1::_Placeholder1))(int, int)) (int)’
/usr/include/c++/4.6/tr1/functional:1134:11: note: candidates are:
/usr/include/c++/4.6/tr1/functional:1205:9: note: typename
std::tr1::result_of_Functor(typename
std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor(_Bound_args ...)::operator()(_Args ...) [with _Args
= {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder1}, typename std::tr1::result_of_Functor(typename
std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type = int]
/usr/include/c++/4.6/tr1/functional:1205:9: note: no known conversion for
argument 1 from ‘int’ to ‘int’
/usr/include/c++/4.6/tr1/functional:1216:9: note: typename
std::tr1::result_ofconst _Functor(typename
std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor(_Bound_args ...)::operator()(_Args ...) const [with
_Args = {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder1}, typename std::tr1::result_ofconst
_Functor(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type = int]
/usr/include/c++/4.6/tr1/functional:1216:9: note: no known conversion for
argument 1 from ‘int’ to ‘int’
/usr/include/c++/4.6/tr1/functional:1228:9: note: typename
std::tr1::result_ofvolatile _Functor(typename
std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor(_Bound_args ...)::operator()(_Args ...) volatile
[with _Args = {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder1}, typename std::tr1::result_ofvolatile
_Functor(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type = int]
/usr/include/c++/4.6/tr1/functional:1228:9: note: no known conversion for
argument 1 from ‘int’ to ‘int’
/usr/include/c++/4.6/tr1/functional:1241:9: note: typename
std::tr1::result_ofconst volatile _Functor(typename
std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type
std::tr1::_Bind_Functor(_Bound_args ...)::operator()(_Args ...) const
volatile [with _Args = {int}, _Functor = int (*)(int, int), _Bound_args = {int,
std::tr1::_Placeholder1}, typename std::tr1::result_ofconst volatile
_Functor(typename std::tr1::result_ofstd::tr1::_Mu_Bound_args(_Bound_args,
std::tr1::tuple_UElements ...)::type ...)::type = int]
/usr/include/c++/4.6/tr1/functional:1241:9: note: no known conversion for
argument 1 from ‘int’ to ‘int’
$ g++ --version
g++ (Ubuntu 4.6.0-3~ppa1) 4.6.1 20110409 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug libstdc++/52612] std::tr1::bind doesn't work with placeholders
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52612 --- Comment #3 from Anthony Williams anthony.ajw at gmail dot com 2012-03-19 11:15:45 UTC --- It's frustrating that the TR1 spec specifies lvalues (I assumed it was the same as std::bind). This came up in supposedly-portable code that works with MSVC's TR1 bind. Good thing it's fixed for std::bind.
