2020-04-30 Jakub Jelinek <jakub@redhat.com> * BASE-VER: Set to 11.0.0.
Template headers are not incrementally updated as we parse its parameters. We maintain a dummy level until the closing > when we replace the dummy with a real parameter set. requires processing was expecting a properly populated arg_vec in current_template_parms, and then creates a self-mapping of parameters from that. But we don't need to do that, just teach map_arguments to look at TREE_VALUE when args is NULL. * constraint.cc (map_arguments): If ARGS is null, it's a self-mapping of parms. (finish_nested_requirement): Do not pass argified current_template_parms to normalization. (tsubst_nested_requirement): Don't assert no template parms.
This fixes a regression due to the conditional noexcept-specifier on std::allocator::construct and std::allocator::destroy, as well as the corresponding members of new_allocator, malloc_allocator, and allocator_traits. Those noexcept-specifiers were using expressions which might be ill-formed, which caused errors outside the immediate context when checking for the presence of construct and destroy in SFINAE contexts. The fix is to use the is_nothrow_constructible and is_nothrow_destructible type traits instead, because those traits are safe to use even when the construction/destruction itself is not valid. The is_nothrow_constructible trait will be false for a type that is not also nothrow-destructible, even if the new-expression used in the construct function body is actually noexcept. That's not the correct answer, but isn't a problem because providing a noexcept-specifier on these functions is not required by the standard anyway. If the answer is false when it should be true, that's suboptimal but OK (unlike giving errors for valid code, or giving a true answer when it should be false). PR libstdc++/89510 * include/bits/alloc_traits.h (allocator_traits::_S_construct) (allocator_traits::_S_destroy) (allocator_traits<allocator<T>>::construct): Use traits in noexcept-specifiers. * include/bits/allocator.h (allocator<void>::construct) (allocator<void>::destroy): Likewise. * include/ext/malloc_allocator.h (malloc_allocator::construct) (malloc_allocator::destroy): Likewise. * include/ext/new_allocator.h (new_allocator::construct) (new_allocator::destroy): Likewise. * testsuite/20_util/allocator/89510.cc: New test. * testsuite/ext/malloc_allocator/89510.cc: New test. * testsuite/ext/new_allocator/89510.cc: New test.
The testcase ICEs because the range-based for generates three artificial variables that need to be allocated to the coroutine frame but, when walking the BIND_EXR that contains these, the DECL_INITIAL for one of them refers to an entry appearing later, which means that the frame entry hasn't been allocated when that INITIAL is walked. The solution is to defer walking the DECL_INITIAL/SIZE etc. until all the BIND_EXPR vars have been processed. gcc/cp/ChangeLog: 2020-04-30 Iain Sandoe <iain@sandoe.co.uk> PR c++/94886 * coroutines.cc (transform_local_var_uses): Defer walking the DECL_INITIALs of BIND_EXPR vars until all the frame allocations have been made. gcc/testsuite/ChangeLog: 2020-04-30 Iain Sandoe <iain@sandoe.co.uk> PR c++/94886 * g++.dg/coroutines/pr94886-folly-3.C: New test.
The problem here is that target cleanup expressions have been added to the initialisers for the awaitable (and returns of non-trivial values from await_suspend() calls. This is because the expansion of the co_await into its control flow is not apparent to the machinery adding the target cleanup expressions. The solution being tested is simply to recreate target expressions as the co_awaits are lowered. Teaching the machinery to handle walking co_await expressions in different ways at different points (outside the coroutine transformation) seems overly complex. gcc/cp/ChangeLog: 2020-04-30 Iain Sandoe <iain@sandoe.co.uk> PR c++/94883 * coroutines.cc (register_awaits): Update target expressions for awaitable and suspend handle initializers. gcc/testsuite/ChangeLog: 2020-04-30 Iain Sandoe <iain@sandoe.co.uk> PR c++/94883 * g++.dg/coroutines/pr94883-folly-2.C: New test.
There are several places where the handling of a variable declaration depends on whether it corresponds to a compiler temporary, or to some other entity. We were testing that var decls were artificial in determining this. However, proxy vars are also artificial so that this is not sufficient. The solution is to exclude variables with a DECL_VALUE_EXPR as well, since the value variable will not be a temporary. gcc/cp/ChangeLog: 2020-04-30 Iain Sandoe <iain@sandoe.co.uk> PR c++/94879 * coroutines.cc (build_co_await): Account for variables with DECL_VALUE_EXPRs. (captures_temporary): Likewise. (register_awaits): Likewise. gcc/testsuite/ChangeLog: 2020-04-30 Iain Sandoe <iain@sandoe.co.uk> PR c++/94879 * g++.dg/coroutines/pr94879-folly-1.C: New test.
gcc/ChangeLog: * pretty-print.c (pp_take_prefix): Fix spelling in comment.
Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1. When we strip_typedefs the element of the array "const d", we see it's a typedef_variant_p, so we look at its DECL_ORIGINAL_TYPE, which is char, but we need to add the const qualifier, so we call cp_build_qualified_type -> build_qualified_type where get_qualified_type checks to see if we already have such a type by walking the variants list, which in this case is: char -> c -> const char -> const char -> d -> const d Because check_base_type only checks TYPE_ALIGN and not TYPE_USER_ALIGN, we choose the first const char, which has TYPE_USER_ALIGN set. If the element type of an array has TYPE_USER_ALIGN, the array type gets it too. So we can make check_base_type stricter. I was afraid that it might make us reuse types less often, but measuring showed that we build the same amount of types with and without the patch, while bootstrapping. PR c++/94775 * tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match. (check_aligned_type): Check if TYPE_USER_ALIGN match. * g++.dg/warn/Warray-bounds-10.C: New test.
2020-04-30 Kyrylo Tkachov <kyrylo.tkachov@arm.com> * config/aarch64/aarch64.h (TARGET_OUTLINE_ATOMICS): Define. * config/aarch64/aarch64.opt (moutline-atomics): Change to Int variable. * doc/invoke.texi (moutline-atomics): Document as on by default.
It was previously discussed that indirect branches cannot go to
NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html
Before the patch a bti j was inserted after the label in
__attribute__((target("branch-protection=bti")))
int foo (void)
{
label:
return 0;
}
This is not necessary and weakens the security protection.
gcc/ChangeLog:
PR target/94748
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove
the check for NOTE_INSN_DELETED_LABEL.
gcc/testsuite/ChangeLog:
PR target/94748
* gcc.target/aarch64/pr94748.c: New test.