[Bug libstdc++/101049] New: std::variant: missed optimization in std::visit() on more than one variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101049
Bug ID: 101049
Summary: std::variant: missed optimization in std::visit() on
more than one variant
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vermaelen.wouter at gmail dot com
Target Milestone: ---
// https://godbolt.org/z/T8f89fq1z
// --
#include
struct Base {};
struct A : Base { int a; };
struct B : Base {};
struct C : Base {};
struct D : Base {};
using V = std::variant;
template struct overloaded : Ts... { using Ts::operator()...; };
bool operator==(const V& v1, const V& v2)
{
return std::visit(overloaded{
[](const A& x, const A& y) { return x.a == y.a; },
[&](const Base&, const Base&) { return v1.index() == v2.index(); }
}, v1, v2);
}
// --
The call to std::visit() is implemented using a table containing 4x4 = 16
function pointers. However 15 out of these 16 sub-functions are identical. It
would be nice if these would be shared.
Also (before sharing) in these 16 sub-functions the value of a sub-expression
like 'v1.index()' could be known during compile-time. It would also be nice if
the compiler could exploit this knowledge.
So ideally I'd like the compiler to produce only 3 different sub-functions:
[](const A& x, const A& y) { return x.a == y.a; },
[]() { return true; }
[]() { return false; }
And then fill-in the table with 16 function-pointers to the appropriate of
these 3 functions.
Thanks.
[Bug tree-optimization/118557] New: -Wstringop-overflow false positive for span on array/string_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118557 Bug ID: 118557 Summary: -Wstringop-overflow false positive for span on array/string_view Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: vermaelen.wouter at gmail dot com Target Milestone: --- Hi, I am aware of bug#88443 which tracks a lot of other reports about Wstringop-overflow false positives. I checked several (but not all) of the linked bugs, but I couldn't decide if my report is a duplicate or not. I'll report it anyway. Feel free to dismiss if it is a duplicate. I did make some effort to make the test case as small as possible (while still keeping the origin recognizable). See here: https://godbolt.org/z/s3v8bMEoE The warning is triggered by the 2 calls to copy() on line 63 and 64. All other code is just support code. I'm reasonably sure this code is correct: * Line 63 copies at most 8 bytes from 'part1' into the first 8 bytes of 'array a', so the destination is valid and larger or equal to the source size. * Line 64 copies at most 3 bytes from 'part2' into the last 3 bytes of 'array a', so again the destination buffer is valid and large enough to hold the source. Lines 55-60 and 65 don't fundamentally change the copy behavior, but are somehow needed to trigger the problem. The warning message "warning: writing 8 bytes into a region of size 3" seems wrong to me. We never copy 8 bytes into a region of size 3. Could it be that the sizes of both copies somehow get mixed up?
