I implicitly assumed that programs using pmr::synchronized_pool_resource
would also be using multiple threads, and so the weak symbols in
gthr-posix.h would be resolved by linking to libpthread. If that isn't
true then it crashes when trying to use pthread_key_create.
This commit makes the pool resource check __gthread_active_p() before
using thread-specific data, and just use a single set of memory pools
when there's only a single thread.
PR libstdc++/94936
* src/c++17/memory_resource.cc (synchronized_pool_resource::_TPools):
Add comment about single-threaded behaviour.
(synchronized_pool_resource::_TPools::move_nonempty_chunks()): Hoist
class member access out of loop.
(synchronized_pool_resource::synchronized_pool_resource())
(synchronized_pool_resource::~synchronized_pool_resource())
(synchronized_pool_resource::release()): Check __gthread_active_p
before creating and/or deleting the thread-specific data key.
(synchronized_pool_resource::_M_thread_specific_pools()): Adjust
assertions.
(synchronized_pool_resource::do_allocate(size_t, size_t)): Add fast
path for single-threaded case.
(synchronized_pool_resource::do_deallocate(void*, size_t, size_t)):
Likewise. Return if unable to find a pool that owns the allocation.
* testsuite/20_util/synchronized_pool_resource/allocate_single.cc:
New test.
* testsuite/20_util/synchronized_pool_resource/cons_single.cc: New
test.
* testsuite/20_util/synchronized_pool_resource/release_single.cc: New
test.
Currently store-motion emits a load of the value in the loop
preheader even when the original loop does not contain any read
of the reference. This avoids doing this. In the conditional
store-motion case we need to mark the sunk stores with no-warning
since the control dependence is too tricky to figure out for
the uninit warning.
2020-05-04 Richard Biener <rguenther@suse.de>
PR tree-optimization/39612
* tree-ssa-loop-im.c (im_mem_ref::loaded): New member.
(set_ref_loaded_in_loop): New.
(mark_ref_loaded): Likewise.
(gather_mem_refs_stmt): Call mark_ref_loaded for loads.
(execute_sm): Avoid issueing a load when it was not there.
(execute_sm_if_changed): Avoid issueing warnings for the
conditional store.
* gcc.dg/tree-ssa/pr39612.c: New testcase.
when callers and callees do not quite agree on the type of a
parameter, usually with ill-defined K&R or with smilarly wrong LTO
input, IPA-CP can attempt to try and substitute a wrong type for a
parameter (see e.g. gcc.dg/torture/pr48063.c). Function
tree_function_versioning attempts to handle this in order not to
create invalid gimple but it then creates the mapping using
setup_one_parameter which also handles the same situation to avoid
similar problems when inlining and in more defined way.
So this patch simply removes the conversion attempts in
tree_function_versioning itself. It is helpful for my upcoming fix of
PR 93385 because then I do not need to teach
ipa_param_body_adjustments to distinguish between successful and
unsuccessful mappings - setup_one_parameter uses force_value_to_type
for conversions which simly maps the worst cases to zero.
2020-05-04 Martin Jambor <mjambor@suse.cz>
PR ipa/93385
* tree-inline.c (tree_function_versioning): Leave any type conversion
of replacements to setup_one_parameter and its friend
force_value_to_type.
Convert unsigned compares where
m >= LARGE_POWER_OF_TWO
and LARGE_POWER_OF_TWO represent an immediate where bit 33+ is set to use
a SHR instruction and compare the result to 0. This avoids loading a
large immediate with MOVABS insn.
movabsq $1099511627775, %rax
cmpq %rax, %rdi
ja .L5
gets converted to:
shrq $40, %rdi
jne .L5
PR target/94650
* config/i386/predicates.md (shr_comparison_operator): New predicate.
* config/i386/i386.md (compare->shr splitter): New splitters.
testsuite/ChangeLog:
PR target/94650
* gcc.targeti/i386/pr94650.c: New test.
The following patch (on top of the two other PR94718 patches) performs the
actual optimization requested in the PR.
2020-05-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94718
* match.pd ((X < 0) != (Y < 0) into (X ^ Y) < 0): New simplification.
* gcc.dg/tree-ssa/pr94718-4.c: New test.
* gcc.dg/tree-ssa/pr94718-5.c: New test.
On the following testcase, there are in *.optimized dump 14 nop conversions
(from signed to unsigned and back), while this patch decreases that number
to just 4; for bitwise ops it really doesn't matter if they are performed in
signed or unsigned, so the patch (in GIMPLE only, there are some comments
about it being undesirable during GENERIC earlier), if it sees both
bitop operands nop converted from the same types performs the bitop in their
non-converted type and converts the result (i.e. 2 conversions into 1),
similarly, if a bitop has one operand nop converted from something, the
other not and the result is converted back to the type of the nop converted
operand before conversion, it is possible to replace those 2 conversions
with just a single conversion of the other operand.
2020-05-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94718
* match.pd (bitop (convert @0) (convert? @1)): For GIMPLE, if we can,
replace two nop conversions on bit_{and,ior,xor} argument
and result with just one conversion on the result or another argument.
* gcc.dg/tree-ssa/pr94718-3.c: New test.
This patch moves this optimization from fold-const.c to match.pd where it
is actually much shorter to do and lets optimize even code not seen together
in a single expression in the source, as the first step towards fixing the
PR.
2020-05-04 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/94718
* fold-const.c (fold_binary_loc): Move (X & C) eqne (Y & C)
-> (X ^ Y) & C eqne 0 optimization to ...
* match.pd ((X & C) op (Y & C) into (X ^ Y) & C op 0): ... here.
* gcc.dg/tree-ssa/pr94718-1.c: New test.
* gcc.dg/tree-ssa/pr94718-2.c: New test.
While testing the --with-documentation-root-url= changes, I run into
[Wreturn-type] URL pointing to gfortran documentation where it obviously
isn't documented. The following patch updates the list of options to match
reality (on the other side -Wconversion-extra is gfortran only option
documented in gfortran.texi).
Or, perhaps better use the attached patch instead, which doesn't have a
hardcoded list and instead uses the flags? I went through options.c
and the updated list of options matches exactly the cases where CL_Fortran
is set for "-W*" options together with CL_C and/or CL_CXX (ok, there is also
-Wall and -Wextra, but hopefully we don't emit [Wall] or [Wextra] for
anything).
2020-05-04 Jakub Jelinek <jakub@redhat.com>
* opts.c (get_option_html_page): Instead of hardcoding a list of
options common between C/C++ and Fortran only use gfortran/
documentation for warnings that have CL_Fortran set but not
CL_C or CL_CXX.
The overload for byte types uses memset and isn't constexpr. This adds
the specifier and uses std::is_constant_evaluated() to provide a
compile-time alternative.
PR libstdc++/94933
* include/bits/stl_algobase.h (__fill_a1): Make overload for byte types
usable in constant expressions.
* testsuite/25_algorithms/fill_n/constexpr.cc: Test with bytes and
non-scalars.
Update gfortran_target_compile to get the newly built asan library from
TEST_ALWAYS_FLAGS to avoid:
/usr/bin/ld: cannot find libasan_preinit.o: No such file or directory
/usr/bin/ld: cannot find -lasan
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O0 (test for excess errors)
PR fortran/94788
* lib/gfortran.exp (gfortran_target_compile): Get asan library
from TEST_ALWAYS_FLAGS.
Add a missing '-' to a diagnostic.
gcc/ChangeLog:
2020-05-02 Iain Sandoe <iain@sandoe.co.uk>
PR translation/93861
* config/darwin-driver.c (darwin_driver_init): Adjust spelling in
a warning.
Because the test case for PR 94788 requires -fsanitize=address to expose
the double free, I have created a subdirectory under gfortran.dg
where such test cases can go.
I have tested this with
make check-fortran RUNTESTFLAGS="asan.exp=*"
and it works; with a compiler that introduces the double free bug
into the test case, the result is as expected
2020-05-02 Thomas Koenig <tkoenig@gcc.gnu.org>
PR fortran/94788
* gfortran.dg/asan: New directory.
* gfortran.dg/asan/asan.exp: New file.
* gfortran.dg/asan/pointer_assign_16.f90: New test case.
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '1' (via 'I124MODE:n') or '4' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '1' (via 'I124MODE:n') or '' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '2' (via 'I124MODE:n') or '4' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '2' (via 'I124MODE:n') or '' (via 'I48MODE:n')
../../gcc/config/tilegx/tilegx.md:4109:1: ambiguous attribute 'n'; could be '4' (via 'I124MODE:n') or '' (via 'I48MODE:n')
The insn name already uses <I124MODE:n> explicitly, just the preparation
stmts don't, and as it creates a I124MODE lowpart subreg of a word mode
register, <I124MODE:n> seems obviously correct.
2020-05-02 Jakub Jelinek <jakub@redhat.com>
* config/tilegx/tilegx.md
(insn_stnt<I124MODE:n>_add<I48MODE:bitsuffix>): Use <I124MODE:n>
rather than just <n>.
Currently patchable area is at the wrong place. It is placed immediately
after function label and before .cfi_startproc. A backend should be able
to add a pseudo patchable area instruction durectly into RTL. This patch
adds patch_area_size and patch_area_entry to crtl so that the patchable
area info is available in RTL passes.
It also limits patch_area_size and patch_area_entry to 65535, which is
a reasonable maximum size for patchable area.
gcc/
PR target/93492
* cfgexpand.c (pass_expand::execute): Set crtl->patch_area_size
and crtl->patch_area_entry.
* emit-rtl.h (rtl_data): Add patch_area_size and patch_area_entry.
* opts.c (common_handle_option): Limit
function_entry_patch_area_size and function_entry_patch_area_start
to USHRT_MAX. Fix a typo in error message.
* varasm.c (assemble_start_function): Use crtl->patch_area_size
and crtl->patch_area_entry.
* doc/invoke.texi: Document the maximum value for
-fpatchable-function-entry.
gcc/c-family/
PR target/93492
* c-attribs.c (handle_patchable_function_entry_attribute): Limit
value to USHRT_MAX (65535).
gcc/testsuite/
PR target/93492
* c-c++-common/patchable_function_entry-error-1.c: New test.
* c-c++-common/patchable_function_entry-error-2.c: Likewise.
* c-c++-common/patchable_function_entry-error-3.c: Likewise.
This is a missing SFINAE issue when verifying the accessibility of a
static data member.
The cause is that check_accessibility_of_qualified_id unconditionally
passes tf_warning_or_error to perform_or_defer_access_check, even when
called from tsubst_qualified_id(..., complain=tf_none).
This patch fixes this by plumbing 'complain' from tsubst_qualified_id
through check_accessibility_of_qualified_id to reach
perform_or_defer_access_check, and by giving
check_accessibility_of_qualified_id the appropriate return value.
gcc/cp/ChangeLog:
PR c++/90880
* cp-tree.h (check_accessibility_of_qualified_id): Add
tsubst_flags_t parameter and change return type to bool.
* parser.c (cp_parser_lookup_name): Pass tf_warning_to_error to
check_accessibility_of_qualified_id.
* pt.c (tsubst_qualified_id): Return error_mark_node if
check_accessibility_of_qualified_id returns false.
* semantics.c (check_accessibility_of_qualified_id): Add
complain parameter. Pass complain instead of
tf_warning_or_error to perform_or_defer_access_check. Return
true unless perform_or_defer_access_check returns false.
gcc/testsuite/ChangeLog:
PR c++/90880
* g++.dg/template/sfinae29.C: New test.
Here we have (conceptually *) something like
struct B { };
struct D : B { };
D(0); // invalid
and in C++20 the ()-initialization has created a { 0 } constructor that
it tries to initialize an object of type D with. We should reject
initializing an object of type B from 0, but we wrongly accept it because
process_init_constructor_record skips initializers for empty bases/fields:
if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))
&& !TREE_SIDE_EFFECTS (next))
/* Don't add trivial initialization of an empty base/field to the
constructor, as they might not be ordered the way the back-end
expects. */
continue;
but here 'next' was error_mark_node, returned by massage_elt_init, so we
wound up with { } which would validly value-initialize the object.
[*] Usually digest_init in build_new_method_call_1 would detect this,
but in this case the instance is is_dummy_object and we don't call
digest just yet.
PR c++/94885
* typeck2.c (process_init_constructor_record): Return PICFLAG_ERRONEOUS
if an initializer element was erroneous.
* g++.dg/cpp2a/paren-init26.C: New test.
The recent libsanitizer change seems to have had a corrupt
chunk, that caused it to apply a change part way through the
SUBTARGET_INIT_BUILTINS macro, leading to a bootstrap fail
in stage1.
gcc/ChangeLog:
2020-05-01 Iain Sandoe <iain@sandoe.co.uk>
* config/i386/darwin.h: Repair SUBTARGET_INIT_BUILTINS.
Override SUBTARGET_SHADOW_OFFSET macro.
For default member initializers in templates it's important to push into the
right context during get_nsdmi. But for a local class that's not possible,
and trying leaves the function context we need to be in, so don't try.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/90479
* init.c (get_nsdmi): Don't push_to_top_level for a local class.
cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that
have non-constant construction or destruction, but -fmerge-all-constants was
converting an automatic variable to static while leaving TREE_READONLY set.
Fixed by clearing the flag in cp_finish_decl in the presence of
-fmerge-all-constants.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/91529
* decl.c (cp_finish_decl): Also clear TREE_READONLY if
-fmerge-all-constants.
Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR
which is a NOP_EXPR to the VLA type of the proxy. The problem here was that
when instantiating we were tsubsting that type twice, once for the type of
the DECL and once for the type of the NOP_EXPR, and getting two
different (though equivalent) types. Then gimplify_type_sizes fixed up the
type of the DECL, but that didn't affect the type of the NOP_EXPR, leading
to sadness.
Fixed by directly reusing the type from the DECL.
gcc/cp/ChangeLog
2020-05-01 Jason Merrill <jason@redhat.com>
PR c++/93822
* pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have
the same type as the variable.
Introduce math_force_eval to evaluate generic division to generate
INVALID and DIVZERO exceptions.
libgcc/ChangeLog:
* config/i386/sfp-exceptions.c (__math_force_eval): New define.
(__sfp_handle_exceptions): Use __math_force_eval to evaluete
generic division to generate INVALID and DIVZERO exceptions.
libatomic/ChangeLog:
* config/x86/fenv.c (__math_force_eval): New define.
(__atomic_feraiseexcept): Use __math_force_eval to evaluete
generic division to generate INVALID and DIVZERO exceptions.
libgfortran/ChangeLog:
* config/fpu-387.h (__math_force_eval): New define.
(local_feraiseexcept): Use __math_force_eval to evaluete
generic division to generate INVALID and DIVZERO exceptions.
In the last import the sanitizer_platform_limits_freebsd.cpp got
forgotten. Fix this.
libsanitizer/sanitizer_common:
* Makefile.am: Add sanitizer_platform_limits_freebsd.cpp.
* Makefile.in: Regenerate.
The deduced return type causes the instantiation of the function body,
which can then require the instantiation of std::projected::operator*
which is intentionally not defined.
This patch uses a helper trait to define the return type, so that the
function body doesn't need to be instantiated. That helper trait can
then also be used in other places that currently check the return type
of ranges::iter_move (iter_rvalue_reference_t and indirectly_readable).
2020-05-01 Jonathan Wakely <jwakely@redhat.com>
Patrick Palka <ppalka@redhat.com>
PR libstdc++/92894
* include/bits/iterator_concepts.h (ranges::__cust_imove::_IMove):
Add trait to determine return type and an alias for it.
(ranges::__cust_imove::_IMove::operator()): Use __result instead of
deduced return type.
(iter_rvalue_reference_t): Use _IMove::__type instead of checking
the result of ranges::iter_move.
(__detail::__indirectly_readable_impl): Use iter_rvalue_reference_t
instead of checking the result of ranges::iter_move.
* testsuite/24_iterators/customization_points/92894.cc: New test.
* testsuite/24_iterators/indirect_callable/92894.cc: New test.
The libstdc++ manual documents that _T can not be used, because it's a
macro in system headers on some targets.
PR libstdc++/94901
* include/std/type_traits (__is_complete_or_unbounded): Replace
BADNAME _T with _Tp.
* testsuite/17_intro/badnames.cc: New test.
check_effective_target_fileio was added to
gcc/testsuite/lib/target-supports.exp the other day, without
documentation.
This patch adds the corresponding documentation.
for gcc/ChangeLog
* doc/sourcebuild.texi (Effective-Target Keywords): Document
the newly-introduced fileio effective target.
If there are _Atomic side-effects in the parameter declarations
of non-nested function, when they are parsed, current_function_decl is
NULL, the create_artificial_label created labels during build_atomic* are
then adjusted by store_parm_decls through set_labels_context_r callback.
Unfortunately, if such thing happens in nested function parameter
declarations, while those decls are parsed current_function_decl is the
parent function (and am not sure it is a good idea to temporarily clear it,
some code perhaps should be aware it is in a nested function, or it can
refer to variables from the parent function etc.) and that means
store_param_decls through set_labels_context_r doesn't adjust anything.
As those labels are emitted in the nested function body rather than in the
parent, I think it is ok to override the context in those cases.
2020-04-30 Jakub Jelinek <jakub@redhat.com>
PR c/94842
* c-decl.c (set_labels_context_r): In addition to context-less
LABEL_DECLs adjust also LABEL_DECLs with context equal to
parent function if any.
(store_parm_decls): Adjust comment.
* gcc.dg/pr94842.c: New test.
cse_process_notes did a very simple substitution, which in the wrong
circumstances could create non-canonical RTL and invalid MEMs.
Various sticking plasters have been applied to cse_process_notes_1
to handle cases like ZERO_EXTEND, SIGN_EXTEND and UNSIGNED_FLOAT,
but I think this PR is a plaster too far.
The code is trying hard to avoid creating unnecessary rtl, which of
course is a good thing. If we continue to do that, then we can end
up changing subexpressions while keeping the containing rtx.
This in turn means that validate_change will be a no-op on the
containing rtx, even if its contents have changed. So in these
cases we have to apply validate_change to the individual subexpressions.
On the other hand, if we always apply validate_change to the
individual subexpressions, we'll end up calling validate_change
on something before it has been simplified and canonicalised.
And that's one of the situations we're trying to avoid.
There might be a middle ground in which we queue the validate_changes
as part of a group, and so can cancel the pending validate_changes
for subexpressions if there's a change in the outer expression.
But that seems even more ad-hoc than the current code.
It would also be quite an invasive change.
I think the best thing is just to hook into the existing
simplify_replace_fn_rtx function, keeping the REG and MEM handling
from cse_process_notes_1 essentially unchanged. It can generate
more redundant rtl when a simplification takes place, but it has
the advantage of being relative well-used code (both directly
and via simplify_replace_rtx).
2020-04-30 Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR rtl-optimization/94740
* cse.c (cse_process_notes_1): Replace with...
(cse_process_note_1): ...this new function, acting as a
simplify_replace_fn_rtx callback to process_note. Handle only
REGs and MEMs directly. Validate the MEM if cse_process_note
changes its address.
(cse_process_notes): Replace with...
(cse_process_note): ...this new function.
(cse_extended_basic_block): Update accordingly, iterating over
the register notes and passing individual notes to cse_process_note.
PR 94856 is a call graph verifier error. We have a method which (in
the course of IPA-CP) loses its this pointer because it is unused and
the pass then does not clone all the this adjusting thunks and just
makes the calls go straight to the new clone - and then the verifier
complains that the edge does not seem to point to a clone of what it
used to. This looked weird because the verifier actually has logic
detecting this case but it turns out that it is confused by inliner
body-saving mechanism which invents a new decl for the base function.
Making the inlining body-saving mechanism to correctly set
former_clone_of allows us to detect this case too. Then we pass this
particular round of verification but the subsequent one fails because
we have inlined the function into its former thunk - which
subsequently does not have any callees, but the verifier still access
them and segfaults. Therefore the patch also adds a test whether the
a former hunk even has any call.
2020-04-30 Martin Jambor <mjambor@suse.cz>
PR ipa/94856
* cgraph.c (clone_of_p): Also consider thunks whih had their bodies
saved by the inliner and thunks which had their call inlined.
* ipa-inline-transform.c (save_inline_function_body): Fill in
former_clone_of of new body holders.
PR ipa/94856
* g++.dg/ipa/pr94856.C: New test.
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.
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.
