[Bug libstdc++/112089] New: std::shared_lock::unlock should throw operation_not_permitted instead resource_deadlock_would_occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089 Bug ID: 112089 Summary: std::shared_lock::unlock should throw operation_not_permitted instead resource_deadlock_would_occur Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: d at ilvokhin dot com Target Milestone: --- Based on C++ standard wording, when we call unlock and don't own anything we should throw operation_not_permitted. Sec 33.6.5.5.3 from here (https://eel.is/c++draft/thread.lock.shared.locking#25.1): > void unlock(); > <...> > Error conditions: > operation_not_permitted — if on entry owns is false. But current implementation throws resource_deadlock_would_occur instead: https://github.com/gcc-mirror/gcc/blob/458db9b6149b2e9bef94ab76909eb914ed9f675a/libstdc%2B%2B-v3/include/std/shared_mutex#L823 It doesn't change much, just a little inconsistency.
[Bug target/94972] New: Function multi-versioning binary may crash dynamic linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94972 Bug ID: 94972 Summary: Function multi-versioning binary may crash dynamic linker Product: gcc Version: 9.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: d at ilvokhin dot com Target Milestone: --- Created attachment 48468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48468&action=edit Simplified version of function multi-versioning example I compiled simple binary (a simplified version of function multi-versioning example from gcc.gnu.org) and do ldd -u -r on result. This leads to ldd segfault in __cpu_indicator_init from libgcc_s.so. Behaviour is observed at least for GCC 9.1.1 and 7.3.1 (both from Red Hat devtoolset). $ g++ --version g++ (GCC) 9.1.1 20190605 (Red Hat 9.1.1-2) Copyright (C) 2019 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++ tt.cpp -o cpp $ ldd -u -r ./cpp /usr/bin/ldd: line 116: 6148 Segmentation fault (core dumped) LD_TRACE_LOADED_OBJECTS=1 LD_WARN=yes LD_BIND_NOW=yes LD_LIBRARY_VERSION=$verify_out LD_VERBOSE= LD_DEBUG="unused" "$@ Backtrace is looks like that: (gdb) bt #0 0x7efccf094c87 in __cpu_indicator_init () from /lib64/libgcc_s.so.1 #1 0x00401178 in ?? () #2 0x7fff5f97e220 in ?? () #3 0x7efccf8bce5f in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2 (gdb) disass Dump of assembler code for function __cpu_indicator_init: 0x7efccf094c70 <+0>: push %r15 0x7efccf094c72 <+2>: push %r14 0x7efccf094c74 <+4>: push %r13 0x7efccf094c76 <+6>: push %r12 0x7efccf094c78 <+8>: push %rbp 0x7efccf094c79 <+9>: xor%ebp,%ebp 0x7efccf094c7b <+11>:push %rbx 0x7efccf094c7c <+12>:sub$0x18,%rsp 0x7efccf094c80 <+16>:mov0x212351(%rip),%rax# 0x7efccf2a6fd8 => 0x7efccf094c87 <+23>:mov(%rax),%eax 0x7efccf094c89 <+25>:test %eax,%eax
[Bug libstdc++/86537] New: std::less specialization for std::shared_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86537 Bug ID: 86537 Summary: std::less specialization for std::shared_ptr Product: gcc Version: 4.8.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: d at ilvokhin dot com Target Milestone: --- Created attachment 44401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44401&action=edit problem demonstration There is a specialization for std::less for std::shared_ptr in bits/shared_ptr.h. I'm not sure it is really should be there. If user defines operator < for std::shared_ptr some inconsistent behaviour may occurs depending on is operator < uses directly or through std::less. There is a reference to 20.8.13.2.7 in this header file, but I can't found nothing about std::less specialization for std::shared_ptr in standart. I attach a simple example.cpp file, which illustrates problem. (I use pretty old gcc version, but this behaviour persist in most recent versions as well)
