[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.