[Bug libstdc++/88466] New: Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466
Bug ID: 88466
Summary: Support std::hardware_destructive_interference_size
and std:: hardware_constructive_interference_size
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: duarte at scylladb dot com
Target Milestone: ---
The following should compile:
#include
struct x {
alignas(std::hardware_destructive_interference_size) int y;
alignas(std::hardware_constructive_interference_size) int z;
};
It seems, however, that neither std::hardware_destructive_interference_size nor
std::hardware_constructive_interference_size have been included in libstdc++.
[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466 --- Comment #2 from Duarte --- I don't think it should be the min size. For example, architectures with 64bit cache lines can have prefetchers that immediately fetch adjacent cache lines, in which case the value should be 128. One option could be to just use whatever values linux uses :)
[Bug libstdc++/88466] [C++17] Support std::hardware_destructive_interference_size and std:: hardware_constructive_interference_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88466 --- Comment #4 from Duarte --- Oh, I see; thanks for pointing that out.
[Bug c++/80947] [6/7 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947 Duarte changed: What|Removed |Added CC||duarte at scylladb dot com --- Comment #16 from Duarte --- This is happening again in g++ (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20).
[Bug libstdc++/84769] variant::get(): unscoped call to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84769 --- Comment #6 from Duarte --- I think that calls to get<0> should be scoped, for example in visit().
[Bug libstdc++/84769] variant::get(): unscoped call to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84769 --- Comment #8 from Duarte --- I tried to go ahead and send a patch for this (should be on the gcc-patches and libstdc++ lists).
[Bug libstdc++/84769] variant::get(): unscoped call to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84769 --- Comment #13 from Duarte --- Awesome, thank you!
[Bug c++/80947] [6/7 Regression] Different visibility for the lambda and its capture list members with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947
--- Comment #17 from Duarte ---
It also fails on GCC 8.1. This is the reproducer:
template
void foo() {
struct inner {
inner() {
([this] { });
}
};
}
int main() { foo(); }
It fails when compiled with -fvisibility=hidden, but succeeds with
-fvisibility=default.
It also compiles fine without the template.
[Bug c++/85642] New: Wrong implicit exception-specification with std::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85642
Bug ID: 85642
Summary: Wrong implicit exception-specification with
std::optional
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: duarte at scylladb dot com
Target Milestone: ---
Apologies if this has already been reported, but I couldn't find a matching
report.
Consider the following program:
#include
struct Y {
int i;
Y() noexcept = default;
Y(Y&&) noexcept = default;
};
class X final {
std::optional _permit;
X() noexcept = default;
public:
static X make() {
return X();
}
};
int main() {
X::make();
return 1;
}
It fails with the following error message on GCC 8.0.1 and GCC 8.1:
: In static member function 'static X X::make()':
:14:18: error: use of deleted function 'constexpr X::X()'
return X();
^
:11:5: note: 'constexpr X::X() noexcept' is implicitly deleted because
its exception-specification does not match the implicit exception-specification
''
X() noexcept = default;
^
Compiler returned: 1
It compiles fine on GCC 7.3, which I believe is the correct result.
Godbolt: https://godbolt.org/g/Y2hCHZ
[Bug c++/85646] New: Incorrect lambda visibility with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646
Bug ID: 85646
Summary: Incorrect lambda visibility with -fvisibility=hidden
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: duarte at scylladb dot com
Target Milestone: ---
Consider the following program:
template
void foo() {
struct inner {
inner() {
(void)([this] { });
}
};
}
int main() { foo(); }
Compiles fine on 6.3, but fails on 7.1, 7.2, 7.3, 8.0.1 and 8.1, with
:5:13: error: 'foo()::inner::inner() [with T = int]::'
declared with greater visibility than the type of its field
'foo()::inner::inner() [with T = int]'
[-Werror=attributes]
Godbolt: https://godbolt.org/g/aGaVgd
[Bug c++/85646] [7/8/9 Regression] Incorrect lambda visibility with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85646 --- Comment #2 from Duarte --- I forgot to add that it compiles successfully without -fvisibility=hidden, and without the template.
[Bug libstdc++/84769] New: variant::get(): unscoped call to get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84769 Bug ID: 84769 Summary: variant::get(): unscoped call to get Product: gcc Version: 7.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: duarte at scylladb dot com Target Milestone: --- In the implementation of T& get(variant& v) and friends, the calls to the size_t-templated overloads of get is unscoped, like in [1]. This can lead to surprising situations if a similar function is available in the current namespace (say, to provide a common interface between and ). I'm not aware of the standard requiring get() to be an extension point, so maybe the calls should be scoped? [1] https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/include/std/variant#L922
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #12 from Duarte --- (In reply to Avi Kivity from comment #10) > Oh, and a binary that triggers it is build/release/tests/view_schema_test. Should be build/debug/tests/view_schema_test. For reference, other binaries affected by this issue are build/debug/tests/mutation_test and build/debug/tests/schema_change_test.
