[Bug libstdc++/114153] std::less<> prefers operator const void*() over operator<=>() in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
--- Comment #1 from Marc Mutz ---
It's only the C++14 "diamond"/is_transparent version of std::less/greater_equal
that is affected. If you replace the return from main with greater_equal{},
then it calls op<=>, too:
// https://godbolt.org/z/cnjssh3ss
return std::greater_equal{}(arr[0], arr[1]) ? 0 : 1;
//^ added
[Bug libstdc++/114153] New: std::less prefers operator const void*() over operator<=>() in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114153
Bug ID: 114153
Summary: std::less prefers operator const void*() over
operator<=>() in C++20 mode
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: marc.mutz at hotmail dot com
Target Milestone: ---
std::less (and other related types like std::greater_equal, etc) is implemented
in the following way:
* if `operator<(T, U)` is defined for the argument types, it is called.
* otherwise, if the argument types are convertible to `const volatile void *`,
such conversion is performed, and it boils down to comparing the pointers.
Now, assume a type which has an `operator const void *() const`, and provides
`operator==()` and `operator<=>()` to generate all relational operators, the
same way the std types do.
So std::less will not use `operator<=>()`, but cast to `const void *` and
compare pointers.
This is wrong, because `operator<=>()` implies all relational operators, so it
can be used to do the proper comparison. libc++ gets this right:
// https://godbolt.org/z/E55eeosP9
// Courtesy of Ivan Solovev
#include
#include
#include
struct S
{
int val;
S(int v) : val(v) {}
operator const void *() const { std::cout << "cast\n"; return }
friend bool operator==(S lhs, S rhs) noexcept
{ std::cout << "op==\n"; return lhs.val == rhs.val; }
friend std::strong_ordering operator<=>(S lhs, S rhs) noexcept
{ std::cout << "op<=>\n"; return lhs.val <=> rhs.val; }
};
int main()
{
const S arr[] = {S{2}, S{1}};
// In C++20 mode it compares pointers, and so considers that arr[1] >
arr[0],
// which is wrong!
return std::greater_equal<>{}(arr[0], arr[1]) ? 0 : 1;
}
[Bug libstdc++/100903] Bogus "zero as null pointer constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100903 Marc Mutz changed: What|Removed |Added CC||marc.mutz at hotmail dot com --- Comment #7 from Marc Mutz --- In Qt, we still only require C++17, but we want to write our relational operators as-if we already had C++20 and use macros to paper over the difference. This requires us to write our own C++17 versions of std::_*ordering (called Qt:*_ordering). Whatever you do to fix the issue, please don't only fix it for libstdc++, but also for user code.
[Bug sanitizer/80578] -fsanitize=undefined report yields memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80578 --- Comment #5 from Marc Mutz --- Still in GCC 11 and GCC 13.
[Bug sanitizer/110704] When ubsan reports an error, asan reports a leak in cp-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110704 --- Comment #1 from Marc Mutz --- GCC self-compiled, line numbers should be as at 275820c09e5: $ g++ --version g++ (GCC) 13.0.1 20230124 (experimental) $ (cd ~/C++/gcc; git log -1 --oneline) 275820c09e5 (HEAD, origin/trunk, origin/master, origin/HEAD) arm: Fix inclusion of arm-mlib.h header more than once (pr108505).
[Bug sanitizer/110704] New: When ubsan reports an error, asan reports a leak in cp-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110704 Bug ID: 110704 Summary: When ubsan reports an error, asan reports a leak in cp-demangle.c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: marc.mutz at hotmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- When, in a combined asan+ubsan build, ubsan reports an error, then I consistently see a follow-up asan error. Example: 1: tests/auto/corelib/kernel/qobject/tst_qobject.cpp:8324:25: runtime error: downcast of address 0x7f3dd6cfe4e0 which does not point to an object of type 'Object' 1: 0x7f3dd6cfe4e0: note: object is of type 'QObject' 1: 00 00 00 00 80 3e d2 e1 3d 7f 00 00 c0 f5 e5 01 c0 60 00 00 00 00 20 00 00 00 00 00 00 00 00 00 1: ^~~ 1: vptr for 'QObject' 1: PASS : tst_QObject::declarativeData() 1: PASS : tst_QObject::asyncCallbackHelper() 1: PASS : tst_QObject::cleanupTestCase() 1: Totals: 114 passed, 0 failed, 0 skipped, 0 blacklisted, 3081ms 1: * Finished testing of tst_QObject * 1: 1: = 1: ==2734888==ERROR: LeakSanitizer: detected memory leaks 1: 1: Direct leak of 192 byte(s) in 8 object(s) allocated from: 1: #0 0x7f3de9bbd685 in __interceptor_realloc ../../../../gcc/libsanitizer/asan/asan_malloc_linux.cpp:85 1: #1 0x7f3ddc4be8fa in d_growable_string_resize x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4277 1: #2 0x7f3ddc4be8fa in d_growable_string_append_buffer x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4301 1: #3 0x7f3ddc4be8fa in d_growable_string_callback_adapter x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4318 1: 1: SUMMARY: AddressSanitizer: 192 byte(s) leaked in 8 allocation(s). I can reproduce this on GCC 11 and GCC 13.0.1. It always seems to be 8 objects and 192 bytes. I can't remember another instance with different numbers. Expected behaviour: ubsan does not introduce asan leaks.
[Bug c++/92562] Allow [[maybe_unused]] in class member declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92562 Marc Mutz changed: What|Removed |Added CC||marc.mutz at hotmail dot com --- Comment #2 from Marc Mutz --- Isn't this fixed meanwhile? I don't remember seeing this on GCC 11.
[Bug libstdc++/108820] New: vector::resize(n, v) requires copy_assignable, which is not part of the CopyInsertable concept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108820
Bug ID: 108820
Summary: vector::resize(n, v) requires copy_assignable, which
is not part of the CopyInsertable concept
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: marc.mutz at hotmail dot com
Target Milestone: ---
The following should work (and does, on MCVS and libc++), because S is
copy_constructible, just not copy_assignable. In particular, S is
CopyInsertable:
// https://godbolt.org/z/61ffqMj8n
#include
struct S { const int n; };
static_assert(std::is_copy_constructible_v);
static_assert(std::is_nothrow_move_constructible_v);
void test(std::vector )
{
v.resize(15, S{42});
}
The libstdc++ implementation tries to instantiate the copy-assignment operator,
though.
[Bug target/105416] arm_acle.h is missing __yield()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105416 --- Comment #3 from Marc Mutz --- It's both: aarch64 is here: https://gcc.gnu.org/legacy-ml/gcc-patches/2019-01/msg00570.html
[Bug c/105416] New: arm_acle.h is missing __yield()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105416 Bug ID: 105416 Summary: arm_acle.h is missing __yield() Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marc.mutz at hotmail dot com Target Milestone: --- [sorry, didn't know which component gcc/config/* belongs to, so just picked "c"] LLVM has __yield() in its arm_acle.h. MSVC, too, it seems (at least their YieldProcessor() is defined to __yield, didn't check their arm_acle.h). GCC is missing it, even in GCC 11.
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 --- Comment #7 from Marc Mutz --- Fantastic! Thanks for the tip!
[Bug c++/86974] Support Clang's require_constant_initialization attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86974 Marc Mutz changed: What|Removed |Added CC||marc.mutz at hotmail dot com --- Comment #5 from Marc Mutz --- Not really superseded by constinit. constinit is only available in C++20. If you want constinit, you get all of C++20. OTOH, [[clang::require_constant_initialization]] works all the way back to C++11.
[Bug tree-optimization/104480] [12 Regression] Combining stores across memory locations might violate [intro.memory]/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480 Marc Mutz changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Marc Mutz --- Thanks, that makes sense. It's a data race if it's not synchronized. And if I write to only one of the members, then GCC uses movw like everyone else: https://gcc.godbolt.org/z/9rsK5osaM So, GCC _is_ the clever kid! Sorry for the noise, then.
[Bug c++/104480] New: [trunk] Combining stores across memory locations might violate [intro.memory]/3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104480
Bug ID: 104480
Summary: [trunk] Combining stores across memory locations might
violate [intro.memory]/3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marc.mutz at hotmail dot com
Target Milestone: ---
I'm not sure whether GCC trunk just became much smarter, or introduced a
regresssion. Sorry if it's the former.
Consider:
// https://gcc.godbolt.org/z/ch8rTob7c
struct S1
{
int a1 : 16;
int a2 : 16;
};
struct S2
{
short a1;
short a2;
};
extern char x;
template void f(T ) {
t.a1 = x;
t.a2 = x + 1;
}
template void f(S1 &);
template void f(S2 &);
All GCC version up to 11.2 will use two movw to implement both f()
instantiations. GCC trunk now uses one movl in both instantiations. That's
clearly allowed for f() by [intro.memory]/3, but it's less clear that it's
an allowed optimisation for S2, because a1, s2 are two separate memory
locations there. Clang, in fact, produces different code for the two
instantiations.
Of course, GCC might be the clever kid here and realize that it can combine the
writes, because that's a valid observable sequence, but an object of type S2,
having alignment 2, may cross a cacheline-boundary, in which case the movl
might not be atomic, even on x86, and then a different core may observe the
writes out of order, which probably shouldn't happen.
[Bug libstdc++/100415] runtime error: reference binding to null pointer of type 'const struct __forced_unwind'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100415 --- Comment #2 from Marc Mutz --- Confirmed with $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/d/gcc/11/libexec/gcc/x86_64-pc-linux-gnu/11.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/d/gcc/11 --enable-languages=c,c++,objc,fortran,obj-c++ --enable-release --disable-multilib --program-suffix=-11 : (reconfigured) ../gcc/configure --prefix=/d/gcc/11 --enable-languages=c,c++,objc,fortran,obj-c++ --enable-release --disable-multilib --program-suffix=-11 Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.1 20211211 (GCC) Work-around: https://stackoverflow.com/questions/70378204/how-to-catch-abi-forced-unwind-while-keeping-ubsan-happy
