[Bug libstdc++/97120] circular concept loops in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97120 --- Comment #2 from Avi Kivity --- This makes sense, according to my very limited ability to understand the standard. I reflected it to the clang bug here: https://bugs.llvm.org/show_bug.cgi?id=47509.
[Bug libstdc++/97120] New: circular concept loops in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97120
Bug ID: 97120
Summary: circular concept loops in
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
The following example compiles with gcc and fails with clang. I believe clang
is correct but can't prove it.
=== begin example =
#include
void foo() {
std::ranges::iota_view iota(2, 10);
iota.begin();
}
end example ==
Clang complains that iota_view doesn't have a begin() member (which it does). I
think the reason is that the constraint is evaluated before iota_view is fully
defined. gcc evaluates lazily so it doesn't stumble on the problem.
The circular chain is:
view_interface is instantiated as a base class of iota_view. Clearly
iota_view isn't defined at this stage, it's just a forward-declared name.
view_interface instantiates iterator_t, which is an alias to
std::__detail::__range_iter_t.
__range_iter_t instantiates __ranges_begin.
__ranges_begin requires that its template parameter is a __member_begin<>
(among other options, but this is the valid one here).
__member_begin requires that the type (iota_view) have a begin() function. But
the type isn't defined yet.
I believe clang is correct, mostly because I believe concept evaluation should
be eager and not lazy, not because I know it for a fact.
Apologies for posting a clang issue here, I wouldn't if gcc could get
asan+coroutines working. The problem will hit gcc if it implements eager
evaluation too.
[Bug c++/95895] internal compiler error: in captures_temporary, at cp/coroutines.cc:2717
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95895 Avi Kivity changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #6 from Avi Kivity --- Requesting a backport to gcc 10.
[Bug target/94087] std::random_device often fails when used from multiple threads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94087 --- Comment #25 from Avi Kivity --- Requesting a backport to gcc 10. We're hitting this even when not called in a loop.
[Bug c++/95457] New: Inadequate diagnostics on constrained coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95457 Bug ID: 95457 Summary: Inadequate diagnostics on constrained coroutines Product: gcc Version: 10.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- Created attachment 48651 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48651=edit test case If a coroutine_traits specialization fails, and if the constraints is not satisfied, gcc reports that it cannot find the promise type. However, it does not report on the constraint failure, as it usually does with concepts. The diagnostics for the attached test case are: g++ -std=c++20 -fcoroutinesconstrained-coroutine.cc -o constrained-coroutine constrained-coroutine.cc: In function ‘dummy_coroutine foo(int&&)’: constrained-coroutine.cc:31:5: error: unable to find the promise type for this coroutine 31 | co_return x; | ^ cc1plus: warning: control reaches end of non-void function [-Wreturn-type]
[Bug c++/95455] ICE in capture with initializer in requires block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95455
--- Comment #3 from Avi Kivity ---
Here's a valid version (which gcc accepts):
void f() {
int foo = 4;
auto lambda = [bar = foo] {};
static_assert(requires (decltype(lambda) x) {
x;
});
}
[Bug c++/95455] ICE in capture with initializer in requires block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95455 --- Comment #2 from Avi Kivity --- Appears to be invalid. Clang rejects it even after some massaging (lambda in unevaluated context).
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #22 from Avi Kivity --- @Iain: if you can publish your patches somewhere we can test them with our codebase and report. (if you can publish them on releases/gcc-10 that's even better).
[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95137 --- Comment #17 from Avi Kivity --- Is that the test were a lambda coroutine is called from future::then()? In that case it's a real use-after-free.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 Avi Kivity changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #23 from Avi Kivity --- The bug is in the C++ standard, not gcc.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #22 from Avi Kivity --- Certainly, closing as invalid.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #20 from Avi Kivity --- My coroutines do return suspend_never from initial_suspend(); so thanks for the workaround, I'll use it until we have a better fix.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #18 from Avi Kivity --- The work-around works if initial_suspend() returns suspend_never or similar. If the lambda is suspended before execution, the reference may dangle.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #15 from Avi Kivity ---
I believe that my suggestion works for mutable lambdas (and for any coroutine
called as a member function):
- if the object passeed to the member function is an lvalue, then the
coroutine captures a reference to the object
- if the object passed to the member function is an rvalue, then the coroutine
captures the object by copying it (typically using it move constructor).
Examples:
auto a = [blah] () mutable -> task<> { ... };
a(); // a is captured by reference
[blah] () mutable -> task<> { ... } (); // captured by value
my_class a;
a.some_coroutine(); // captured by reference
my_class a;
std::move(a).some_coroutine(); // captured by value
Currently, the "captured by value" cases are captured by reference, and cause a
use-after-free if the coroutine outlives the caller scope.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #13 from Avi Kivity --- Yes. gcc has a minor bug in that the lambda is reflected as a pointer instead of a reference in coroutine_traits. The major bug is in the standard.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #11 from Avi Kivity --- I started a conversation on the std-proposals list about this. Meanwhile, how about a -fnonstandard-coroutines-that-actually-work flag that captures the parameter to a non-static member function coroutine by value, if it is an rvalue when the call happens? Without it, lambda coroutines are useless for asynchronous coroutines.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
--- Comment #10 from Avi Kivity ---
Well, the standard is useless here.
In
[foo] () -> lazy { co_return foo; } ()
a temporary is clearly passed to the lambda body, yet the standard mandates
that we capture it by reference. As a result, a use-after-free is guaranteed.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #7 from Avi Kivity --- I have a simple reproducer. A lambda fails while a fake lambda using structs passes. I don't think gcc is at fault, but the standard is problematic here IMO.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #8 from Avi Kivity --- Created attachment 48526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48526=edit less lame testcase
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #5 from Avi Kivity --- This snippet from cppreference: If the coroutine is a non-static member function, such as task my_class::method1(int x) const;, its Promise type is std::coroutine_traits, const my_class&, int>::promise_type implies that both gcc and my interpretation are wrong. gcc passes a pointer for the lambda, and I'd like the lambda to be passed by value. The difference between gcc and cppreference is trivial, and both of them make coroutine lambdas unusable if they contain state and if the lambda is asynchronous.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #3 from Avi Kivity --- The test case I uploaded only shows the failure, it won't work if gcc worked as I expect it. I'll try to get a better testcase, unfortunately a small coroutine testcase is still some work.
[Bug c++/95111] coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111 --- Comment #2 from Avi Kivity --- Created attachment 48524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48524=edit lame testcase Lame testcase that shows that the lambda is passed as a pointer rather than by value, leading to a leak if the coroutine is suspended.
[Bug c++/95111] New: coroutines use-after-free with lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95111
Bug ID: 95111
Summary: coroutines use-after-free with lambdas
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
coroutines copy their input to the coroutine frame, so a coroutine like
future f(T x) {
co_await something();
co_return x;
}
will copy x back from the coroutine frame. However, lambdas are passed by
pointer, so something like
[x] () -> future {
co_await something();
co_return x;
}
will fail, it is translated as something like
struct lambda {
T x;
}
future lambda_operator_parens(const lambda* l) {
co_await something();
co_return l->x;
}
Since l is captured by value, *l is dangling and is leaked.
I think the following translation would be more useful:
future lambda_operator_parens_rref(const lambda l) {
co_await something();
co_return l.x;
}
l would be copied by value and would survive copying/moving into the coroutine
frame.
I don't know if the current behavior is mandated by the standard, but if it is,
it seems a serious defect.
[Bug target/94649] 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 --- Comment #2 from Avi Kivity --- Maybe we can have a new flag -mcx16all that assumes that all code using 16-byte CAS is compiled with the flag.
[Bug c++/94645] [10 Regression][concepts] incorrect concept evaluation with decltype, plus internal error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 --- Comment #4 from Avi Kivity --- Yes (at least mine, don't know about Rafael's)
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #25 from Avi Kivity --- PR 94649.
[Bug c++/94649] New: 16-byte aligned atomic_compare_exchange doesn not generate cmpxcg16b on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649
Bug ID: 94649
Summary: 16-byte aligned atomic_compare_exchange doesn not
generate cmpxcg16b on x86_64
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
The code
#include
struct alignas(16) a {
long x;
long y;
};
bool cmpxchg(std::atomic& data, a expected, a newval) {
return std::atomic_compare_exchange_weak(, , newval);
}
compiles with -O3 -mcx16 generates a "lock cmpxchg16b" instruction with clang,
but not with gcc, where it generates a library call to
__atomic_compare_exchange_16. This is a missed optimization.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #24 from Avi Kivity --- I'll file a new PR.
[Bug c++/94644] Wrong is_nothrow_move_constructible result if used in a template first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94644 Avi Kivity changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #2 from Avi Kivity --- PR 94033 is also related to constructibity trait testing with an inaccessible constructor. Looks like the intrinsic depends on where it was evaluated.
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #22 from Avi Kivity --- Perhaps PR 84522 should be reopened and unmarked as a duplicate. While the reproducer there is a C API, it is the C equivalent of ().
[Bug target/80878] -mcx16 (enable 128 bit CAS) on x86_64 seems not to work on 7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 --- Comment #20 from Avi Kivity --- Note that clang generates cmpxchg16b when the conditions are ripe: https://godbolt.org/z/j9Whgh
[Bug c++/94645] incorrect concecpt evaluation with decltype, plus internal erropr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645 --- Comment #1 from Avi Kivity --- Created attachment 48304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48304=edit reduced test case (after preprocessing) This is what the compiler spat out after it failed to compile the non-preprocessed test case.
[Bug c++/94645] New: incorrect concecpt evaluation with decltype, plus internal erropr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94645
Bug ID: 94645
Summary: incorrect concecpt evaluation with decltype, plus
internal erropr
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Created attachment 48303
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48303=edit
reduced test case (before preprocessing)
A concept involving decltype() fails to evaludate correctly in gcc 10, with
some indication the compiler has an internal error.
The same program compiles in gcc9 (with -fconcepts).
Reduced program and preprocessed output attached.
gcc 10 command line:
g++ -std=gnu++2a -Wall -Werror -c -o /dev/null reduced.cc
gcc 9 command line:
g++ -std=gnu++2a -fconcepts -Wall -Werror -c -o /dev/null reduced.cc
gcc 10 errors:
In file included from /usr/include/c++/10/bits/stl_algobase.h:71,
from /usr/include/c++/10/algorithm:61,
from reduced.cc:1:
/usr/include/c++/10/bits/predefined_ops.h: In instantiation of 'constexpr bool
__gnu_cxx::__ops::_Iter_pred<_Predicate>::operator()(_Iterator) [with _Iterator
= std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
operator<<(std::ostream&, l)::]':
/usr/include/c++/10/bits/stl_algobase.h:1906:42: required from 'constexpr
_InputIterator std::__find_if(_InputIterator, _InputIterator, _Predicate,
std::input_iterator_tag) [with _InputIterator =
std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
__gnu_cxx::__ops::_Iter_pred):: >]'
/usr/include/c++/10/bits/stl_algobase.h:1965:23: required from 'constexpr
_Iterator std::__find_if(_Iterator, _Iterator, _Predicate) [with _Iterator =
std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
__gnu_cxx::__ops::_Iter_pred):: >]'
/usr/include/c++/10/bits/stl_algo.h:3928:28: required from 'constexpr _IIter
std::find_if(_IIter, _IIter, _Predicate) [with _IIter =
std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
operator<<(std::ostream&, l)::]'
reduced.cc:12:7: recursively required from 'std::ostream&
operator<<(std::ostream&, std::vector) [with a = l; std::ostream =
std::basic_ostream]'
reduced.cc:12:7: required from 'std::ostream& operator<<(std::ostream&,
std::vector) [with a = std::vector >; std::ostream =
std::basic_ostream]'
reduced.cc:56:11: required from 'void e::h::g(const string_view&, const
string_view&) [with a = std::vector >; std::string_view =
std::basic_string_view]'
reduced.cc:23:10: required from here
/usr/include/c++/10/bits/predefined_ops.h:316:23: error: no match for call to
'(operator<<(std::ostream&, l)::) (const
std::pair, p::feature>&)'
316 | { return bool(_M_pred(*__it)); }
|~~~^~~
reduced.cc:37:17: note: candidate: 'operator<<(std::ostream&,
l)::'
37 | [opt](const typename m::value_type &) { return opt.n;
});
| ^
reduced.cc:37:17: note: constraints not satisfied
reduced.cc: In instantiation of 'operator<<(std::ostream&, l)::':
/usr/include/c++/10/bits/predefined_ops.h:316:23: required from 'constexpr
bool __gnu_cxx::__ops::_Iter_pred<_Predicate>::operator()(_Iterator) [with
_Iterator = std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
operator<<(std::ostream&, l)::]'
/usr/include/c++/10/bits/stl_algobase.h:1906:42: required from 'constexpr
_InputIterator std::__find_if(_InputIterator, _InputIterator, _Predicate,
std::input_iterator_tag) [with _InputIterator =
std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
__gnu_cxx::__ops::_Iter_pred):: >]'
/usr/include/c++/10/bits/stl_algobase.h:1965:23: required from 'constexpr
_Iterator std::__find_if(_Iterator, _Iterator, _Predicate) [with _Iterator =
std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
__gnu_cxx::__ops::_Iter_pred):: >]'
/usr/include/c++/10/bits/stl_algo.h:3928:28: required from 'constexpr _IIter
std::find_if(_IIter, _IIter, _Predicate) [with _IIter =
std::__detail::_Node_const_iterator, p::feature>, false, true>; _Predicate =
operator<<(std::ostream&, l)::]'
reduced.cc:12:7: recursively required from 'std::ostream&
operator<<(std::ostream&, std::vector) [with a = l; std::ostream =
std::basic_ostream]'
reduced.cc:12:7: required from 'std::ostream& operator<<(std::ostream&,
std::vector) [with a = std::vector >; std::ostream =
std::basic_ostream]'
reduced.cc:56:11: required from 'void e::h::g(const string_view&, const
string_view
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #16 from Avi Kivity --- I confirm this fixes my original problem, not just the reduced test case.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #13 from Avi Kivity --- Can you attach the patch here please? I'd like to test that this is the only blocker for adopting gcc 10 for us, so that we can adopt it as soon as it is released. I'm anxious to start using coroutines.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #9 from Avi Kivity --- Thanks. I'll test 9.3 as soon as it hits koji.
[Bug libstdc++/94033] [10 Regression] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #7 from Avi Kivity --- That commit is in gcc 9.3, so I'm guessing 9.3 is affected too. 5c7938eb3f1a116b1cf9a28090f2cc5e08814ce4 tags/releases/gcc-9.3.0~221
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #4 from Avi Kivity --- Type in build instructions, should be g++ -std=gnu++17 -c database.cc
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #3 from Avi Kivity --- Created attachment 47993 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47993=edit reduced test case Reduced test case, build with g++ -std=gnu++17 -c database works on gcc 9.2.1, fails on gcc 10.
[Bug libstdc++/94033] is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033 --- Comment #2 from Avi Kivity --- It does not look similar to 93923. There, there is an incomplete type. In my reproducer the type is complete but the default constructor is private. Note that for simple cases is_trivially_constructible works (and evaluates to false), both in gcc 9 and gcc 10. It is only in a few cases that it starts to fail. The errors are also very different from 93983.
[Bug libstdc++/94033] New: is_trivially_copy_constructible<> fails with compiler error on complicated object with private default constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94033
Bug ID: 94033
Summary: is_trivially_copy_constructible<> fails with compiler
error on complicated object with private default
constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
gcc 10 regression: the same source file builds in gcc 9. The preprocessed file
from gcc 10 fails on gcc 9 with the same error, so the bug is likely in
libstdc++.
Error trail:
g++ -MD -MT build/dev/database.o -MF build/dev/database.o.d
-I/home/avi/scylla/seastar/include
-I/home/avi/scylla/build/dev/seastar/gen/include -std=gnu++17 -U_FORTIFY_SOURCE
-Wno-maybe-uninitialized -Werror=unused-result -fstack-clash-protection
-fconcepts -DSEASTAR_API_LEVEL=2 -DSEASTAR_HAVE_GCC6_CONCEPTS
-DSEASTAR_USE_STD_OPTIONAL_VARIANT_STRINGVIEW -DSEASTAR_TYPE_ERASE_MORE
-DFMT_LOCALE -DFMT_SHARED -I/usr/include/p11-kit-1 -O1
-DSEASTAR_ENABLE_ALLOC_FAILURE_INJECTION -I. -I build/dev/gen -march=westmere
-DBOOST_TEST_DYN_LINK -fvisibility=hidden -Wall -Werror -Wno-mismatched-tags
-Wno-maybe-uninitialized -Wno-tautological-compare -Wno-missing-braces
-Wno-misleading-indentation -Wno-overflow -Wno-noexcept-type
-Wno-nonnull-compare -Wno-error=cpp -Wno-ignored-attributes
-Wno-overloaded-virtual -Wno-stringop-overflow
-Wno-error=deprecated-declarations -DXXH_PRIVATE_API -DSEASTAR_TESTING_MAIN
-DHAVE_LIBSYSTEMD=1 -DHAVE_LZ4_COMPRESS_DEFAULT -c -o build/dev/database.o
database.cc
In file included from /usr/include/c++/10/bits/move.h:57,
from /usr/include/c++/10/bits/stl_pair.h:59,
from /usr/include/c++/10/utility:70,
from
/home/avi/scylla/seastar/include/seastar/core/shared_ptr.hh:25,
from dht/i_partitioner.hh:43,
from database.hh:25,
from database.cc:22:
/usr/include/c++/10/type_traits: In instantiation of ‘struct
std::__is_nt_default_constructible_atom’:
/usr/include/c++/10/type_traits:976:12: required from ‘struct
std::__is_nt_default_constructible_impl’
/usr/include/c++/10/type_traits:138:12: required from ‘struct
std::__and_,
std::__is_nt_default_constructible_impl >’
/usr/include/c++/10/type_traits:987:12: required from ‘struct
std::is_nothrow_default_constructible’
/usr/include/c++/10/type_traits:133:12: required from ‘struct
std::__and_ >’
/usr/include/c++/10/tuple:623:2: required from ‘constexpr
std::tuple<_Elements>::tuple() [with _Dummy = void; typename
std::enable_if::value, _Elements
...>::__is_explicitly_default_constructible(), bool>::type = false;
_Elements = {mutation}]’
/usr/include/c++/10/type_traits:1183:30: required from ‘struct
std::is_trivially_constructible >’
/home/avi/scylla/seastar/include/seastar/core/future.hh:210:51: required from
‘constexpr const bool seastar::internal::can_inherit >’
/home/avi/scylla/seastar/include/seastar/core/future.hh:217:44: required from
‘struct seastar::internal::uninitialized_wrapper >’
/home/avi/scylla/seastar/include/seastar/core/future.hh:395:8: required from
‘struct seastar::future_state’
/home/avi/scylla/seastar/include/seastar/core/future.hh:962:24: required from
‘class seastar::future’
database.cc:45:126: required from here
/usr/include/c++/10/type_traits:962:47: error: ‘constexpr mutation::mutation()’
is private within this context
962 | : public integral_constant
| ^
In file included from database.hh:65,
from database.cc:22:
mutation.hh:49:5: note: declared private here
49 | mutation() = default;
| ^~~~
I have a reproducer, but it is 400k lines long after preprocessing. I'll spend
some time minimizing it and post it.
[Bug libstdc++/93502] std::regex_match uses stack space proportional to input string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93502 --- Comment #6 from Avi Kivity --- Even if match_results stores a copy of the matching string, it would be stored on the heap and only pointers would be stored on the stack. So the stack overflow comes from recursion, not because of the delegation to the overload that creates the match_results.
[Bug c++/92722] gcc considers "padding" byte of empty lambda to be uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92722 Avi Kivity changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #2 from Avi Kivity --- Maybe those 1-byte elements generated for empty structs should be considered padding. They certainly don't correspond to any member.
[Bug c++/78940] [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940 --- Comment #4 from Avi Kivity --- Since constexpr constructors do send the variable into the .data (or .tls) section, perhaps gcc can attempt to evaluate the initializer as if it (and any functions it calls) was marked constexpr. If it fails it can emit the guard and initialization calls, but if it succeeds, we save some runtime to check those guards.
[Bug c++/82380] [concepts] Error when using requires constraint with attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82380 Avi Kivity changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #1 from Avi Kivity --- Suffering from the same problem (but with [[deprecated]] instead).
[Bug target/86525] New: [missed-optimization] extraneous instruction emitted in switch converted to look-uptable load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86525
Bug ID: 86525
Summary: [missed-optimization] extraneous instruction emitted
in switch converted to look-uptable load
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
The code
enum xx { x1 = 1, x2 = 2, x3 = 3, x4, x5, x6 };
unsigned char f(xx x) {
switch (x) {
case xx::x1:
return 2;
case xx::x2:
return 2;
case xx::x3:
return 7;
case xx::x4:
return 7;
case xx::x5:
return 7;
case xx::x6:
return 9;
}
}
compiles to (thanks godbolt)
f(xx):
leal -1(%rdi), %eax
movzbl CSWTCH.1(%rax), %eax
ret
CSWTCH.1:
.byte 2
.byte 2
.byte 7
.byte 7
.byte 7
.byte 9
which is lovely, but the lea instruction can be folded into the movzbl
instruction:
movzbl CSWTCH.1 - 1(%rax), %eax
This assumes that CSWTCH.1 is placed at offset != 0.
[Bug middle-end/85516] [missed-optimization] gcc does not convert multiple compares against constants to a shift+bitmask test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85516 --- Comment #2 from Avi Kivity <a...@cloudius-systems.com> --- Interesting. Still missing optimizations - v cannot be larger than 9 (UB), and bt is faster than mov+shift+and.
[Bug middle-end/85516] New: [missed-optimization] gcc does not convert multiple compares against constants to a shift+bitmask test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85516
Bug ID: 85516
Summary: [missed-optimization] gcc does not convert multiple
compares against constants to a shift+bitmask test
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Consider
=== example starts ===
enum class E { a, b, c, d, e, f, g, h, i, j };
bool check_mask(E v) {
return v == E::b || v == E::e || v == E::f || v == E::j;
}
=== example ends ===
This can be compiled to just three instructions (x86):
mov $0x232, %eax
bt %edi, %eax
setc %al
but instead gcc compiles it to:
cmpl $1, %edi
sete %al
cmpl $4, %edi
sete %dl
orb %dl, %al
jne .L1
subl $5, %edi
andl $-5, %edi
sete %al
.L1:
which is three times as large and contains a possibly unpredictable branch.
More bits in the mask will presumably generate larger code.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #16 from Avi Kivity <a...@cloudius-systems.com> --- Sorry, of course the stores are not illegal.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #14 from Avi Kivity <a...@cloudius-systems.com> --- This is a common missed optimization. A container is cleared as part of destruction, but the stores are not eliminated, even though they are illegal. If you want to access members of an object, don't destroy it.
[Bug c++/61982] Optimizer does not eliminate stores to destroyed objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 --- Comment #8 from Avi Kivity <a...@cloudius-systems.com> --- Still unfixed in trunk.
[Bug target/84809] RFE: saveall attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84809 --- Comment #1 from Avi Kivity <a...@cloudius-systems.com> --- I think no_caller_saved_registers is very close to what I want, except for "Since GCC doesn't preserve MPX, SSE, MMX nor x87 states, the GCC option '-mgeneral-regs-only' should be used to compile functions with 'no_caller_saved_registers' attribute."
[Bug target/84809] New: RFE: saveall attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84809
Bug ID: 84809
Summary: RFE: saveall attribute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
A saveall function attribute, with the meaning that the function saves all
registers and therefore its caller does not need to save them, can be useful.
Two use cases:
- currently, debugging code dumps generated from assertion failures is
needlessly hard, because gcc clobbers most of the registers during
__assert_fail's execution. If __assert_fail were marked saveall, then the
frames that called __assert_fail would be able to recover their register values
- reducing the overhead of a cold function called from a hot inline
inline void hot_function(...) {
if (some_rare_condition) {
cold_function(...);
}
some more code
}
if cold_function() is marked saveall, then any registers used by hot_function()
(for example, its arguments) and its caller would be preserved and would not
need to be assumed clobbered.
The implementation would be similar to the interrupt attribute, except for the
return instruction. On x86 special care would be needed for the fpu registers
(would need alloca() since the size of the register stack is only known at
runtime, or perhaps saveall would still clobber fpu registers).
[Bug c++/80947] Different visibility for the lambda and its capture list members with -fvisibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80947 --- Comment #3 from Avi Kivity <a...@cloudius-systems.com> --- A gentle ping, in the unlikely case that this bug was forgotten.
[Bug target/46091] missed optimization: x86 bt/btc/bts instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091 --- Comment #9 from Avi Kivity <a...@cloudius-systems.com> --- I believe the comment is wrong. Here's what the manual says: "This instruction can be used with a LOCK prefix to allow the instruction to be executed atomically." Implying that without the LOCK prefix, it is not atomic. XCHG is the only instruction that asserts LOCK implicitly. Agner lists BTC reciprocal throughput as 1 for imm, mem case and 5 for reg, mem. The latter is slow, but perhaps still worthwhile as a replacement for the code in the first comment (but probably not when addressing a single word). Note there is also the BT instruction (with reciprocal throughput of 0.5!)
[Bug target/46091] missed optimization: x86 bt/btc/bts instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091 --- Comment #6 from Avi Kivity <a...@cloudius-systems.com> --- I believe bts/btc/btr can do more - they also calculate the word offset when addressing memory, see first comment.
[Bug target/46091] missed optimization: x86 bt/btc/bts instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46091
--- Comment #2 from Avi Kivity <a...@cloudius-systems.com> ---
Another instance:
unsigned long clear(unsigned long x) {
return x & ~ ((unsigned long)1 << 63);
}
This compiles to movabs+andq, while it could compile to a single btr
instruction.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #28 from Avi Kivity <a...@cloudius-systems.com> --- It's a combination of several things: 1. We use antlr to generate a parser. The generated code allocates many local variables in the same function 2. use-after-scope disabled -fstack-reuse=all 3. ASAN is quite liberal with stack padding 4. We also use user-level threads with just 128k of stack The combination of all four overflowed our poor stack.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #26 from Avi Kivity <a...@cloudius-systems.com> --- Thanks a lot for handling this issue.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #20 from Avi Kivity <a...@cloudius-systems.com> --- btw, you can try pulling from https://github.com/avikivity/scylla/tree/2546; it has some fixes (specifically https://github.com/avikivity/scylla/commit/408d540eda30b557ecc0ab07ac3d39b617b37c4c) that fixed failures in that area. They're not merged to master because I'm not sure whether they are bugs in the code or gcc.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #19 from Avi Kivity <a...@cloudius-systems.com> --- (In reply to Martin Liška from comment #18) > I can confirm I can reproduce it. Now with just AddressSanitizer I see: > > ==5488==ERROR: AddressSanitizer: unknown-crash on address 0x7fa04c0092e0 at > pc 0x05ee3108 bp 0x7fa04c0091b0 sp 0x7fa04c0091a0 > WRITE of size 32 at 0x7fa04c0092e0 thread T1 > > ... > > SUMMARY: AddressSanitizer: unknown-crash tests/cql_test_env.cc:247 in > single_node_cql_env::create_keyspace(seastar::basic_sstring<char, unsigned > int, 15u>) > Shadow bytes around the buggy address: > 0x0ff4897f9200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0ff4897f9210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0ff4897f9220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0ff4897f9230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x0ff4897f9240: f1 f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 00 00 f2 f2 > =>0x0ff4897f9250: f2 f2 f2 f2 00 00 00 00 f2 f2 f2 f2[00]00 f8 f8 > 0x0ff4897f9260: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 > > And I realized there's one interesting function in back-trace: > > 0x7fa04c0092e0 is located 119520 bytes inside of 131072-byte region > [0x7fa04bfec000,0x7fa04c00c000) > allocated by thread T1 here: > #0 0x7fa060d984a0 in posix_memalign (/lib64/libasan.so.4+0xdf4a0) > #1 0x7cef31 in operator new[](unsigned long, seastar::with_alignment) > core/memory.cc:1754 > #2 0x8a0704 in seastar::thread_context::make_stack() core/thread.cc:169 > #3 0x89ff7d in > seastar::thread_context::thread_context(seastar::thread_attributes, > std::function) core/thread.cc:153 > > Where in #2 there's a call of make_stack. Maybe that does some magic which > breaks a shadow stack? Can you please investigate that? The code uses user-level threads (makecontext/setcontext etc). It annotates the new stack during the switch, see for example https://github.com/scylladb/seastar/blob/master/core/thread.cc#L66. Supposedly it's correct, but perhaps something is missing.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #17 from Avi Kivity <a...@cloudius-systems.com> --- (In reply to Martin Liška from comment #16) > > Unfortunately I don't have any Fedora system to test it. Do you have any > experience using Docker? This can be good candidate to reproduce that? If you run these tree commands: docker pull fedora:rawhide docker run -it --rm fedora:rawhide bash dnf install -y git sudo then you can continue with the other commands in the container (in fact that's how I tested that build-dependencies.sh pulls in all dependencies).
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #15 from Avi Kivity <a...@cloudius-systems.com> --- Unfortunately, backporting your patch is not enough; it depends on another, and backporting the dependency generates many conflicts. There is now a ./install-dependencies.sh in the scylla repositories, so to get a reproducer, you can (on Fedora) git clone --recurse-submodules https://github.com/scylladb/scylla sudo ./install-dependencies.sh # just running yum, honest ./configure.py ninja build/debug/tests/view_schema_test_g # add -j smallnum if running out of memory build/debug/tests/view_schema_test_g -- --smp 1 -m1G # will reproduce the problem
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #13 from Avi Kivity <a...@cloudius-systems.com> --- Output: $ build/debug/tests/view_schema_test_g -- --smp 1 -m 1G WARNING: debug mode. Not for benchmarking or production Running 60 test cases... WARN 2017-07-10 11:41:14,955 seastar - Seastar compiled with default allocator, heap profiler not supported ==7130==WARNING: ASan doesn't fully support makecontext/swapcontext functions and may produce false positives in some cases! INFO 2017-07-10 11:41:15,021 [shard 0] messaging_service - Starting Messaging Service on port 7000 INFO 2017-07-10 11:41:15,026 [shard 0] database - Row: max_vector_size: 32, internal_count: 5 INFO 2017-07-10 11:41:15,113 [shard 0] database - Setting compaction strategy of system_schema.keyspaces to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,138 [shard 0] database - Setting compaction strategy of system_schema.tables to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,151 [shard 0] database - Setting compaction strategy of system_schema.columns to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,165 [shard 0] database - Setting compaction strategy of system_schema.dropped_columns to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,176 [shard 0] database - Setting compaction strategy of system_schema.triggers to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,200 [shard 0] database - Setting compaction strategy of system_schema.views to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,211 [shard 0] database - Setting compaction strategy of system_schema.indexes to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,225 [shard 0] database - Setting compaction strategy of system_schema.types to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,241 [shard 0] database - Setting compaction strategy of system_schema.functions to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,253 [shard 0] database - Setting compaction strategy of system_schema.aggregates to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,263 [shard 0] database - Setting compaction strategy of system.IndexInfo to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,275 [shard 0] database - Setting compaction strategy of system.hints to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,287 [shard 0] database - Setting compaction strategy of system.batchlog to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,301 [shard 0] database - Setting compaction strategy of system.paxos to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,323 [shard 0] database - Setting compaction strategy of system.local to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,341 [shard 0] database - Setting compaction strategy of system.peers to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,350 [shard 0] database - Setting compaction strategy of system.peer_events to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,360 [shard 0] database - Setting compaction strategy of system.range_xfers to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,373 [shard 0] database - Setting compaction strategy of system.compactions_in_progress to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,387 [shard 0] database - Setting compaction strategy of system.compaction_history to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,401 [shard 0] database - Setting compaction strategy of system.sstable_activity to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,412 [shard 0] database - Setting compaction strategy of system.size_estimates to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,426 [shard 0] database - Setting compaction strategy of system.schema_keyspaces to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,457 [shard 0] database - Setting compaction strategy of system.schema_columnfamilies to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,473 [shard 0] database - Setting compaction strategy of system.schema_columns to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,483 [shard 0] database - Setting compaction strategy of system.schema_triggers to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,497 [shard 0] database - Setting compaction strategy of system.schema_usertypes to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,512 [shard 0] database - Setting compaction strategy of system.schema_functions to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,529 [shard 0] database - Setting compaction strategy of system.schema_aggregates to SizeTieredCompactionStrategy INFO 2017-07-10 11:41:15,530 [shard 0] database - Populating Keyspace system_schema INFO 2017-07-10 11:41:15,531 [shard 0] database - Keyspace system_schema: Reading CF aggregates INFO 2017-07-10 11:41:15,572 [shard 0] database - Keyspace system_schema: Reading CF functions INFO 2017-07-10 11:41:15,615 [shard 0] database - Keyspace system_schema: Reading CF i
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #9 from Avi Kivity <a...@cloudius-systems.com> --- (In reply to Martin Liška from comment #8) > (In reply to Avi Kivity from comment #7) > > Hitting something similar-looking on Fedora 26's gcc 7.1.1. > > Can you please provide a test-case so that I can verify it's the same issue? It's https://github.com/scylladb/scylla (see HACKING.md for build instructions; easiest on Fedora 26). It needs tons of memory and cpu time to build; I'm also building gcc with the patch backported to test myself.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #10 from Avi Kivity <a...@cloudius-systems.com> --- Oh, and a binary that triggers it is build/release/tests/view_schema_test.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #7 from Avi Kivity <a...@cloudius-systems.com> --- Hitting something similar-looking on Fedora 26's gcc 7.1.1.
[Bug libstdc++/80493] std::experimental::optional::swap is ill formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80493 --- Comment #3 from Avi Kivity <a...@cloudius-systems.com> --- Please consider a backport to older branches (5, 6, 7).
[Bug libstdc++/80493] New: std::experimental::optional::swap is ill formed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80493
Bug ID: 80493
Summary: std::experimental::optional::swap is ill formed
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
From std::experimental::optional:
void
swap(optional& __other)
noexcept(is_nothrow_move_constructible<_Tp>()
&& noexcept(swap(declval<_Tp&>(), declval<_Tp&>(
{
The operand to the noexcept operator calls swap(T&, T&); but that is hidden by
optional::swap(optional&). Clang correctly rejects this code, but g++ accepts
it.
[Bug demangler/70909] Libiberty Demangler segfaults (4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909 --- Comment #46 from Avi Kivity <a...@cloudius-systems.com> --- Hopefully, the fix can be propagated to gdb's demangler soon.
[Bug c++/78940] New: [missed optimization] Useless guard variable in thread_local defaulted constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78940
Bug ID: 78940
Summary: [missed optimization] Useless guard variable in
thread_local defaulted constructor
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
If I write
extern thread_local std::atomic foo;
gcc will emit guard variables everywhere to ensure it is properly constructed
before use. The workaround is to wrap foo in an inline function, so the
compiler can see its definition. That doesn't work when the constructor is
defaulted:
begin example
// following libstdc++ std::atomic
template
struct my_atomic {
T n;
my_atomic() = default;
explicit constexpr my_atomic(T n) : n(n) {}
T load() const { return n; }
};
inline
my_atomic&
a1() {
static thread_local my_atomic v;
return v;
}
inline
my_atomic&
a2() {
static thread_local my_atomic v{0};
return v;
}
int foo() {
return a1().load() + a2().load();
}
end example //
This compiles to
<foo()>:
0: 64 80 3c 25 00 00 00cmpb $0x0,%fs:0x0
7: 00 00
4: R_X86_64_TPOFF32 guard variable for a1()::v
9: 75 09 jne14 <foo()+0x14>
b: 64 c6 04 25 00 00 00movb $0x1,%fs:0x0
12: 00 01
f: R_X86_64_TPOFF32 guard variable for a1()::v
14: 64 8b 04 25 00 00 00mov%fs:0x0,%eax
1b: 00
18: R_X86_64_TPOFF32a2()::v
1c: 64 03 04 25 00 00 00add%fs:0x0,%eax
23: 00
20: R_X86_64_TPOFF32a1()::v
24: c3 retq
The test for "guard variable for a1()::v" is clearly useless, since no
initialization of a1()::v takes place. gcc correctly omits the guard variable
for a2()::v.
[Bug libstdc++/78713] [missed optimization] gcc doesn't use clobbers to optimize constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78713 --- Comment #4 from Avi Kivity <a...@cloudius-systems.com> --- This bug has a cousin https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61982 where the optimizer doesn't eliminate a store to an object that is about to be destroyed. While for sure it is easier to implement in the library, I think there is a lot of potential for similar optimizations if the optimizer does get the information it craves.
[Bug libstdc++/78713] [missed optimization] gcc doesn't use clobbers to optimize constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78713
--- Comment #2 from Avi Kivity <a...@cloudius-systems.com> ---
I think the middle-end knows it is safe to write to *this, because this is
happening in a constructor, so all of the object's memory is known clobbered.
Similarly, if the assignment operator is written as
optional& optional::operator=(optional&& x) noexcept(...) {
if (this != ) {
this->~optional();
new (this) optional(std::move(x));
}
}
then it has the same information during assignment.
Implementation in the middle end is more useful, because then you don't need
very careful coding of the type, or to depend on is_trivial_foo<>; more user
code will benefit.
[Bug tree-optimization/78713] New: [missed optimization] gcc doesn't use clobbers to optimize constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78713
Bug ID: 78713
Summary: [missed optimization] gcc doesn't use clobbers to
optimize constructors
Product: gcc
Version: 6.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Consider the following code
=== begin code ===
#include
using namespace std::experimental;
struct array_of_optional {
optional v[100];
};
array_of_optional
f(const array_of_optional& a) {
return a;
}
=== end code ===
Compiling with -O3 (6.2.1), I get:
<f(array_of_optional const&)>:
0:48 8d 8f 20 03 00 00 lea0x320(%rdi),%rcx
7:48 89 f8 mov%rdi,%rax
a:48 89 fa mov%rdi,%rdx
d:0f 1f 00 nopl (%rax)
10:c6 42 04 00 movb $0x0,0x4(%rdx)
14:80 7e 04 00 cmpb $0x0,0x4(%rsi)
18:74 0aje 24 <f(array_of_optional const&)+0x24>
1a:44 8b 06 mov(%rsi),%r8d
1d:c6 42 04 01 movb $0x1,0x4(%rdx)
21:44 89 02 mov%r8d,(%rdx)
24:48 83 c2 08 add$0x8,%rdx
28:48 83 c6 08 add$0x8,%rsi
2c:48 39 ca cmp%rcx,%rdx
2f:75 dfjne10 <f(array_of_optional const&)+0x10>
31:f3 c3repz retq
However, because we're constructing into the return value, we're under no
obligation to leave the memory untouched (i.e. the memory can be considered
clobbered), so this can be optimized into a memcpy, which can be significantly
faster if the optionals are randomly engaged; but gcc doesn't notice that.
This is somewhat similar to using memcpy to copy a struct with holes.
[Bug middle-end/77295] missed optimisation when copying/moving union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295 --- Comment #3 from Avi Kivity <a...@cloudius-systems.com> --- If x->which is known then of course just that branch should be followed, and the others eliminated. I'm talking about the case where it isn't known (very common in my code).
[Bug middle-end/77295] missed optimisation when copying/moving union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295
--- Comment #2 from Avi Kivity <a...@cloudius-systems.com> ---
Typically, the code is a template:
template
struct discriminated_union {
unsigned which;
union {
T v1;
U v2;
};
};
If either T or U have non-trivial copy/move constructors, then you can't
copy/move the union; you have to copy/move a member.
I guess a template specialization for the case where both are PODs can be used
as a work-around.
[Bug middle-end/77295] New: missed optimisation when copying/moving union members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77295
Bug ID: 77295
Summary: missed optimisation when copying/moving union members
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Discriminated unions of class types are becoming popular; for example
std::variant<...> or std::future.
gcc doesn't optimize copies or moved of discriminated unions well:
// Will usually be a template with user-defined types
// as members of the union
struct discriminated_union {
unsigned which;
union {
int v1;
long v2;
};
discriminated_union(discriminated_union&&);
};
discriminated_union::discriminated_union(discriminated_union&& x) {
which = x.which;
switch (x.which) {
case 1:
v1 = x.v1;
break;
case 2:
v2 = x.v2;
break;
}
}
compiles into
0: 8b 06 mov(%rsi),%eax
2: 89 07 mov%eax,(%rdi)
4: 8b 06 mov(%rsi),%eax
6: 83 f8 01cmp$0x1,%eax
9: 74 1d je 28
<discriminated_union::discriminated_union(discriminated_union&&)+0x28>
b: 83 f8 02cmp$0x2,%eax
e: 75 10 jne20
<discriminated_union::discriminated_union(discriminated_union&&)+0x20>
10: 48 8b 46 08 mov0x8(%rsi),%rax
14: 48 89 47 08 mov%rax,0x8(%rdi)
18: c3 retq
19: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
20: f3 c3 repz retq
22: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1)
28: 8b 46 08mov0x8(%rsi),%eax
2b: 89 47 08mov%eax,0x8(%rdi)
2e: c3 retq
instead of just copying the 12 bytes from (%rsi) into (rdi); unconditionally
copying the long is cheaper than the branching.
[Bug c++/71147] [6 REGRESSION] Flexible array member wrongly rejected in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147 Avi Kivity <a...@cloudius-systems.com> changed: What|Removed |Added Attachment #38497|0 |1 is obsolete|| --- Comment #1 from Avi Kivity <a...@cloudius-systems.com> --- Created attachment 38498 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38498=edit Slightly simpler reproducer (no std::atomic)
[Bug c++/71147] New: [6 REGRESSION] Flexible array member wrongly rejected in template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147 Bug ID: 71147 Summary: [6 REGRESSION] Flexible array member wrongly rejected in template Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- Created attachment 38497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38497=edit Reproducer gcc (GCC) 6.1.1 20160510 (Red Hat 6.1.1-2) The attached code does not compile under g++ 6. It works fine under 5.3 (with -std=gnu++14). Removing "template , or converting the array to be an array of unsigned (instead of array of struct) hides the problem.
[Bug c++/68364] New: ICE in tree_check()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68364 Bug ID: 68364 Summary: ICE in tree_check() Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- Created attachment 36715 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36715=edit Test case (derived from ScyllaDB; AGPL) g++6 (GCC) 6.0.0 20151113 (experimental) Copyright (C) 2015 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. 5f3001a9d4fa4beb4418b8e7465a0f0f7349eaea In file included from ./exceptions/exceptions.hh:45:0, from ./compress.hh:24, from ./schema.hh:37, from ./cql3/selection/selectable.hh:45, from ./cql3/selection/writetime_or_ttl.hh:45, from build/release/gen/cql3/CqlParser.hpp:63, from build/release/gen/cql3/CqlParser.cpp:44: ./db/write_type.hh: In function ‘std::ostream& db::operator<<(std::ostream&, const db::write_type&)’: ./db/write_type.hh:58:19: internal compiler error: tree check: expected integer_cst, have nop_expr in get_len, at tree.h:5167 case write_type::SIMPLE: os << "SIMPLE"; break; ^~ 0xf366dc tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/tree.c:9587 0x825308 tree_check ../../gcc/tree.h:3212 0x825308 wi::extended_tree<192>::get_len() const ../../gcc/tree.h:5167 0x825308 wi::int_traits<generic_wide_int<wi::extended_tree<192> > >::decompose(long*, unsigned int, generic_wide_int<wi::extended_tree<192> > const&) ../../gcc/wide-int.h:898 0x825308 wide_int_ref_storage<generic_wide_int<wi::extended_tree<192> > > ../../gcc/wide-int.h:945 0x825308 generic_wide_int<generic_wide_int<wi::extended_tree<192> > > ../../gcc/wide-int.h:722 0x825308 cmps<generic_wide_int<wi::extended_tree<192> >, generic_wide_int<wi::extended_tree<192> > > ../../gcc/wide-int.h:1900 0x825308 tree_int_cst_compare ../../gcc/tree.h:5236 0x825308 c_add_case_label(unsigned int, splay_tree_s*, tree_node*, tree_node*, tree_node*, tree_node*, bool*) ../../gcc/c-family/c-common.c:6634 0x5b87e3 finish_case_label(unsigned int, tree_node*, tree_node*) ../../gcc/cp/decl.c:3417 0x6d202a cp_parser_label_for_labeled_statement ../../gcc/cp/parser.c:10259 0x6c0030 cp_parser_statement ../../gcc/cp/parser.c:10132 0x6c16ac cp_parser_statement_seq_opt ../../gcc/cp/parser.c:10456 0x6c180e cp_parser_compound_statement ../../gcc/cp/parser.c:10410 0x6ecaec cp_parser_implicitly_scoped_statement ../../gcc/cp/parser.c:11550 0x6c09af cp_parser_selection_statement ../../gcc/cp/parser.c:10632 0x6c09af cp_parser_statement ../../gcc/cp/parser.c:10040 0x6c16ac cp_parser_statement_seq_opt ../../gcc/cp/parser.c:10456 0x6c180e cp_parser_compound_statement ../../gcc/cp/parser.c:10410 0x6e4c5b cp_parser_function_body ../../gcc/cp/parser.c:20225 Please submit a full bug report, with preprocessed source if appropriate. Compile attached file with -std=gnu++1y -march=nehalem (needed due to intrinsics included)
[Bug sanitizer/67258] "invalid vptr" false positive from ubsan for virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67258 Avi Kivity <a...@cloudius-systems.com> changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #1 from Avi Kivity <a...@cloudius-systems.com> --- I bisected a similar problem (with boost unit-tests) to: commit 6365c92707e013c1bc7c262bd762ac8bfacbdda3 Author: hubicka <hubicka@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Thu Jan 15 23:11:49 2015 + PR ipa/64612 * ipa-inline-transform.c (can_remove_node_now_p): Fix handling of comdat locals. (inline_call): Fix removal of aliases. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@219696 138bc75d-0d04-0410-961f-82ee72b054a4 Strangely this is one commit after the commit that introduces -fsanitize=vptr, so maybe it's unrelated and the previous commit is guilty.
[Bug c++/66601] New: RFE: improve diagnostics for failure to deduce template parameter pack that is not in the last position in the parameter list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66601
Bug ID: 66601
Summary: RFE: improve diagnostics for failure to deduce
template parameter pack that is not in the last
position in the parameter list
Product: gcc
Version: 5.1.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Given the source
template typename... X, typename Y
void f(X... x, Y y) {
}
int main(int ac, char** av) {
f(1, 2, 3, 4);
return 0;
}
gcc (correctly) fails to deduce X as int, int, int.
However, the diagnostic is not very helpful:
./variadic-function-nonlast.cc: In function ‘int main(int, char**)’:
./variadic-function-nonlast.cc:9:15: error: no matching function for call to
‘f(int, int, int, int)’
f(1, 2, 3, 4);
^
./variadic-function-nonlast.cc:4:6: note: candidate: templateclass ... X,
class Y void f(X ..., Y)
void f(X... x, Y y) {
^
./variadic-function-nonlast.cc:4:6: note: template argument
deduction/substitution failed:
./variadic-function-nonlast.cc:9:15: note: candidate expects 1 argument, 4
provided
f(1, 2, 3, 4);
The user cannot understand from this why gcc is refusing to to deduce X, or
that explicitly specifying it (fint, int, int(1, 2, 3, 4)) would work.
If gcc would add an additional note:
./variadic-function-nonlast.cc:9:15: note: parameter pack 'X' in non-last
position not specified; deduced as empty parameter pack
then the user would understand exactly what happened here, and how to rectify
it.
The error message from clang 3.5 are not particularly helpful.
[Bug libstdc++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #14 from Avi Kivity a...@cloudius-systems.com --- Please consider backporting this to 5.2.
[Bug libstdc++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #10 from Avi Kivity a...@cloudius-systems.com --- Any chance that the fix can be committed? gcc 5 is useless for me without this.
[Bug c++/66034] New: Enhancement request: fiber-local storage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66034 Bug ID: 66034 Summary: Enhancement request: fiber-local storage Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com Target Milestone: --- As a complement to __thread and thread_local, add __fiber storage class which is local storage for user-level threads. User-level threads is a common technique in high performance storage, and compiler support would be beneficial. On x86_64, __fiber storage can be accessed via gs:, which can be set (on newer processors) via set setgsbase instruction in userspace.
[Bug libstdc++/65942] New: cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942
Bug ID: 65942
Summary: cannot use std::function as comparator in algorithms
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
Too much template magic causes gcc 5.1 to reject the following valid code:
#include experimental/optional
#include algorithm
#include functional
using T1 = int;
using T2 = std::vectorT1;
bool cmp1(const T1 a, const T1 b) { return a b; }
std::functionbool (const T1, const T1) cmp2 = cmp1;
int main(int ac, char** av) {
T2 v;
std::sort(v.begin(), v.end(), cmp1); // works
std::sort(v.begin(), v.end(), cmp2); // fails
}
Even though the two calls to sort() should be identical, the second one does
not compile.
This is a regression from 4.9
[Bug c++/65942] [5/6 Regression] [C++14] cannot use std::function as comparator in algorithms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65942 --- Comment #5 from Avi Kivity a...@cloudius-systems.com --- That's clang + libstdc++-5.1, so if the problem is in libstdc++, it's the same bug.
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #27 from Avi Kivity a...@cloudius-systems.com --- Patch fixes the problem for me (though the linker still fails)
[Bug debug/65549] [4.9/5/6 Regression] crash in htab_hash_string with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 --- Comment #25 from Avi Kivity a...@cloudius-systems.com --- It's not a latent bug for me: lto1: internal compiler error: Segmentation fault 0xa2f1af crash_signal ../../gcc/toplev.c:383 0x1129f20 htab_hash_string ../../libiberty/hashtab.c:839 0x6d264f external_ref_hasher::hash(external_ref const*) ../../gcc/dwarf2out.c:7763 0x6d264f hash_tableexternal_ref_hasher, xcallocator, false::find_slot(external_ref const*, insert_option) ../../gcc/hash-table.h:652 0x6d264f lookup_external_ref ../../gcc/dwarf2out.c:7791 0x6d26ed optimize_external_refs_1 ../../gcc/dwarf2out.c:7829 0x6d2718 optimize_external_refs_1 ../../gcc/dwarf2out.c:7833 0x6d2b56 optimize_external_refs ../../gcc/dwarf2out.c:7882 0x6d2d8d output_comp_unit ../../gcc/dwarf2out.c:9122 0x6f8c69 dwarf2out_finish ../../gcc/dwarf2out.c:24801 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: fatal error: /home/avi/gcc5/bin/g++5 returned 1 exit status compilation terminated. g++5 (GCC) 6.0.0 20150417 (experimental)
[Bug debug/47361] ICE: in build_abbrev_table, at dwarf2out.c:10477 with -g -feliminate-dwarf2-dups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47361 Avi Kivity a...@cloudius-systems.com changed: What|Removed |Added CC||a...@cloudius-systems.com --- Comment #3 from Avi Kivity a...@cloudius-systems.com --- Seeing this with 4.9.2.
[Bug debug/65549] New: crash in htab_hash_string with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65549 Bug ID: 65549 Summary: crash in htab_hash_string with -flto Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com lto1: internal compiler error: Segmentation fault 0xa283bf crash_signal ../../gcc/toplev.c:383 0x111c7b0 htab_hash_string ../../libiberty/hashtab.c:839 0x6d06bf external_ref_hasher::hash(external_ref const*) ../../gcc/dwarf2out.c:7763 0x6d06bf hash_tableexternal_ref_hasher, xcallocator, false::find_slot(external_ref const*, insert_option) ../../gcc/hash-table.h:652 0x6d06bf lookup_external_ref ../../gcc/dwarf2out.c:7791 0x6d075d optimize_external_refs_1 ../../gcc/dwarf2out.c:7829 0x6d0788 optimize_external_refs_1 ../../gcc/dwarf2out.c:7833 0x6d0bc6 optimize_external_refs ../../gcc/dwarf2out.c:7882 0x6d0dfd output_comp_unit ../../gcc/dwarf2out.c:9122 0x6f6cd9 dwarf2out_finish ../../gcc/dwarf2out.c:24800 Please submit a full bug report, g++5 (GCC) 5.0.0 20150324 (experimental) To reproduce, clone seastar (https://github.com/cloudius-systems/seastar) ./configure.py --compiler /path/to/g++5 --cflags='-flto -D_GLIBCXX_USE_CXX11_ABI=0' ninja build/release/tests/tcp_client # named ninja-build on Fedora)
[Bug c++/65433] New: ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433
Bug ID: 65433
Summary: ICE processing lambdas
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Processing some complex code involving lambdas in gnu++1y mode, the compiler
segfaults:
$ g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 fail.i
In file included from ./core/seastar.hh:26:0,
from ./core/reactor.hh:25,
from ./net/net.hh:25,
from net/native-stack.hh:25,
from net/native-stack.cc:22:
./core/future.hh: In instantiation of 'struct futureT::then_wrapped(Func)
[with Func = smp_message_queue::async_work_itemFunc::process() [with Func =
net::arp_learn(net::ethernet_address,
net::ipv4_address)::lambda()]::lambda(auto:8); T = {};
futurize_tstd::result_of_tFunc(futureT) = future]::lambda(struct
future_state)':
./core/future.hh:510:58: required from
'futurize_tstd::result_of_tFunc(futureT) futureT::then_wrapped(Func)
[with Func = smp_message_queue::async_work_itemFunc::process() [with Func =
net::arp_learn(net::ethernet_address,
net::ipv4_address)::lambda()]::lambda(auto:8); T = {};
futurize_tstd::result_of_tFunc(futureT) = future]'
./core/reactor.hh:454:18: required from 'future
smp_message_queue::async_work_itemFunc::process() [with Func =
net::arp_learn(net::ethernet_address, net::ipv4_address)::lambda()]'
net/native-stack.cc:338:1: required from here
./core/future.hh:510:86: internal compiler error: Segmentation fault
return
thenstd::result_of_tFunc(futureT...)(std::forwardFunc(func), []
(future_stateT... state) { return future(std::move(state)); });
^
This is using gcc 5.0.0 from Fedora 22 (5.0.0-0.17).
Full source available from https://github.com/cloudius-systems/seastar.
Preprocessed source attached.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #1 from Avi Kivity a...@cloudius-systems.com --- Created attachment 35038 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35038action=edit Preprocessed source triggering ICE (bzip2'ed)
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #3 from Avi Kivity a...@cloudius-systems.com --- Ok, will check with trunk. On Sun, Mar 15, 2015 at 9:48 PM, maltsevm at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #2 from Mikhail Maltsev maltsevm at gmail dot com --- Does not reproduce on trunk $ /opt/gcc-5.0.0/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc-5.0.0/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc-5.0.0/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/miyuki/gcc/src/configure --prefix=/opt/gcc-5.0.0 --enable-clocale=gnu --disable-nls --with-system-zlib --with-demangler-in-ld --enable-plugins --enable-shared --enable-bootstrap --with-fpmath=sse --enable-languages=c,c++,lto Thread model: posix gcc version 5.0.0 20150315 (experimental) (GCC) $ /opt/gcc-5.0.0/bin/g++ -std=gnu++1y -g -Wall -Werror -fvisibility=hidden -pthread -O2 -c fail.i -- You are receiving this mail because: You reported the bug.
[Bug c++/65433] ICE processing lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65433 --- Comment #4 from Avi Kivity a...@cloudius-systems.com --- I see the same crash on trunk, only now I get a stack trace: 0xca999f crash_signal ../../gcc/toplev.c:383 0x7f0b74 contains_struct_check ../../gcc/tree.h:2959 0x7f0b74 lambda_expr_this_capture(tree_node*, bool) ../../gcc/cp/lambda.c:752 0x7f12c7 maybe_resolve_dummy(tree_node*, bool) ../../gcc/cp/lambda.c:789 0x5f3cde build_new_method_call_1 ../../gcc/cp/call.c:8010 0x5f3cde build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc, vl_embed**, tree_node*, int, tree_node**, int) ../../gcc/cp/call.c:8258 0x5f5379 build_special_member_call(tree_node*, tree_node*, vectree_node*, va_gc, vl_embed**, tree_node*, int, int) ../../gcc/cp/call.c:7802 0x5ebac9 build_temp ../../gcc/cp/call.c:6039 0x5ebac9 convert_like_real ../../gcc/cp/call.c:6428 0x5ecbf1 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int) ../../gcc/cp/call.c:9405 0x73b4d6 check_return_expr(tree_node*, bool*) ../../gcc/cp/typeck.c:8708 0x77a0ae finish_return_stmt(tree_node*) ../../gcc/cp/semantics.c:887 0x7f2879 maybe_add_lambda_conv_op(tree_node*) ../../gcc/cp/lambda.c:1085 0x68e6cf instantiate_class_template_1 ../../gcc/cp/pt.c:9619 0x68e6cf instantiate_class_template(tree_node*) ../../gcc/cp/pt.c:9672 0x72bf73 complete_type(tree_node*) ../../gcc/cp/typeck.c:146 0x65f3b3 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:15673 0x660d6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:15050 0x64db96 tsubst_expr ../../gcc/cp/pt.c:14382 0x64f3dc tsubst_expr ../../gcc/cp/pt.c:13789 g++5 (GCC) 5.0.0 20150129 (experimental) Not bootstraped (built by gcc 4.9.2)
[Bug lto/63333] lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Avi Kivity a...@cloudius-systems.com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Avi Kivity a...@cloudius-systems.com --- 4.9.2 fixed this.
[Bug lto/63333] lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #5 from Avi Kivity a...@cloudius-systems.com --- Richard, may I send you the test case privately?
[Bug lto/63333] lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 --- Comment #2 from Avi Kivity a...@cloudius-systems.com --- I managed to narrow it down to 400 lines (before preprocessing), strangely in one file. Now, practically anything I touch turns the segfault into link errors. Is this useful? I could share it privately.
[Bug lto/63333] New: lto, 1to1 segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Bug ID: 6 Summary: lto, 1to1 segmentation fault Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: a...@cloudius-systems.com A random change (adding a new virtual function) in a program produced this. I realize this is not sufficient to reproduce, but maybe this can jog someone's memory. If not, I can try to minimize. (gdb) bt #0 0x7f2f900bd887 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7f2f900bef78 in __GI_abort () at abort.c:89 #2 0x009eed13 in real_abort () at ../../gcc/diagnostic.c:1200 #3 diagnostic_action_after_output (context=context@entry=0x167a700 global_diagnostic_context, diagnostic=0x7fffb8503f60) at ../../gcc/diagnostic.c:447 #4 0x00eede6e in diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) () at ../../gcc/diagnostic.c:804 #5 0x009eef5f in internal_error (gmsgid=gmsgid@entry=0xf8aafe %s) at ../../gcc/diagnostic.c:1136 #6 0x00697bdc in crash_signal (signo=11) at ../../gcc/toplev.c:339 #7 signal handler called #8 htab_hash_string (p=0x0) at ../../libiberty/hashtab.c:839 #9 0x00569f9d in hash (r=optimized out) at ../../gcc/dwarf2out.c:7501 #10 find_slot (insert=INSERT, value=0x7fffb8504650, this=0x7fffb8504648) at ../../gcc/hash-table.h:505 #11 lookup_external_ref (map=..., die=die@entry=0x7f2f897f70f0) at ../../gcc/dwarf2out.c:7529 #12 0x00569c44 in optimize_external_refs_1 (die=0x7f2f894957d0, map=map@entry=...) at ../../gcc/dwarf2out.c:7567 #13 0x00aa0eff in optimize_external_refs_1(die_struct*, hash_tableexternal_ref_hasher, xcallocator) () at ../../gcc/dwarf2out.c:7571 #14 0x00aa0eff in optimize_external_refs_1(die_struct*, hash_tableexternal_ref_hasher, xcallocator) () at ../../gcc/dwarf2out.c:7571 #15 0x00e634a2 in optimize_external_refs(die_struct*) () at ../../gcc/dwarf2out.c:7621 #16 0x00e63205 in output_comp_unit(die_struct*, int) () at ../../gcc/dwarf2out.c:8807 #17 0x00561d12 in dwarf2out_finish (filename=optimized out) at ../../gcc/dwarf2out.c:24252 #18 0x00e9664e in compile_file() () at ../../gcc/toplev.c:601 #19 0x00e960e6 in do_compile () at ../../gcc/toplev.c:1917 #20 toplev_main(int, char**) () at ../../gcc/toplev.c:1995 #21 0x7f2f900a9d65 in __libc_start_main (main=0xa1a5e0 main(int, char**), argc=25, argv=0x7fffb8504b88, init=optimized out, fini=optimized out, rtld_fini=optimized out, stack_end=0x7fffb8504b78) at libc-start.c:285 #22 0x00e1365c in _start () In frame 9, die-die_id is zeroed.
[Bug c++/63164] New: unnecessary calls to __dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63164
Bug ID: 63164
Summary: unnecessary calls to __dynamic_cast
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
The code
struct A {
virtual ~A() {}
};
struct B final : A {
virtual ~B() {}
};
B* dc(A* a) {
return dynamic_castB*(a);
}
compiles into the following assembly, which contains a call (jump) to
__dynamic_cast:
dc(A*):
0:48 85 ff test %rdi,%rdi
3:74 1bje 20 dc(A*)+0x20
5:31 c9xor%ecx,%ecx
7:ba 00 00 00 00 mov$0x0,%edx
8: R_X86_64_32typeinfo for B
c:be 00 00 00 00 mov$0x0,%esi
d: R_X86_64_32typeinfo for A
11:e9 00 00 00 00 jmpq 16 dc(A*)+0x16
12: R_X86_64_PC32__dynamic_cast-0x4
16:66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
1d:00 00 00
20:31 c0xor%eax,%eax
22:c3 retq
However, since B is declared final, a simple compare of a's typeinfo with B's
would suffice. This is a missed optimization opportunity.
