Add asan subdirectory for gfortran.dg.

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.

tilegx: Unbreak build

../../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>.

Add patch_area_size and patch_area_entry to crtl

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.

Daily bump.

c++: Missing SFINAE with inaccessible static data member [PR90880]

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.

c++: Parenthesized-init of aggregates accepts invalid code [PR94885]

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.

Darwin: Fix bootstrap break from libsanitizer changes.

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.

testsuite: Enable asan tests on FreeBSD x86_64

Enable asan tests on FreeBSD x86_64.

testsuite:

* gcc.dg/asan/pr87930.c: Enable on x86_64 FreeBSD.
* c-c++-common/asan/asan-interface-1.c: Likewise.
* c-c++-common/asan/clone-test-1.c: Likewise.
* c-c++-common/asan/no-asan-stack.c: Likewise.
* c-c++-common/asan/pr59063-1.c: Likewise.
* c-c++-common/asan/pr59063-2.c: Likewise.
* g++.dg/asan/asan_test.C: Likewise.
* g++.dg/asan/asan_test_utils.h: Likewise.
* g++.dg/asan/interception-failure-test-1.C: Likewise.
* g++.dg/asan/interception-malloc-test-1.C: Likewise.

c++: Local class DMI using local static [PR90479]

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.

c++: -fmerge-all-constants vs. destructors [PR91529]

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.

c++: generic lambda and -fsanitize=vla-bound [PR93822]

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.

i386: Use generic division to generate INVALID and DIVZERO exceptions

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.

gcc: Enable bits for sanitizer support on FreeBSD x86_64

This patch add the necessary bits to suport libasan on FreeBSD x86_64.

gcc
* config/i386/i386.h: Define a new macro: SUBTARGET_SHADOW_OFFSET.
* config/i386/i386.c (ix86_asan_shadow_offset): Use this macro.
* config/i386/darwin.h: Override the SUBTARGET_SHADOW_OFFSET macro.
* config/i386/freebsd.h: Likewise.
* config/freebsd.h (LIBASAN_EARLY_SPEC): Define.
LIBTSAN_EARLY_SPEC): Likewise. (LIBLSAN_EARLY_SPEC): Likewise.

libsanitizer:

* configure.tgt: Add x86_64- and i?86-*-freebsd* targets.

libsanitizer: Add missing file and regen Makefile.in

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.

libstdc++: Add more tests for _E10, _E11 etc. (PR 94901)

PR libstdc++/94901
* testsuite/17_intro/badnames.cc: Test values between _E9 and _E24 too.

libstdc++: Replace deduced return type in ranges::iter_move (PR 92894)

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.

libstdc++: Replace reserved identifier _T with _Tp (PR 94901)

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.

document effective target fileio

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.

Daily bump.

cse: Add test case. [PR94740]

PR rtl-optimization/94740
* gcc.target/powerpc/pr94740.c: New test.

c: Fix ICE with _Atomic side-effect in nested fn param decls [PR94842]

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: Use simplify_replace_fn_rtx to process notes [PR94740]

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.

rs6000, Fix header comment for intrinsic function _mm_movemask_epi8

gcc/ChangeLog

2020-04-30  Carl Love  <cel@us.ibm.com>

* config/rs6000/emmintrin.h (_mm_movemask_epi8): Fix comment.

Adjust crontab.

2020-04-30  Jakub Jelinek  <jakub@redhat.com>

* crontab: Snapshots from trunk are now GCC 11 related.
Add GCC 10 snapshots from the respective branch.

ipa: Cgraph verification fix (PR 94856)

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.

Bump BASE-VER.

2020-04-30  Jakub Jelinek  <jakub@redhat.com>

* BASE-VER: Set to 11.0.0.

c++ ICE with nested requirement as default tpl parm[PR94827]

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.

libstdc++: Avoid errors in allocator's noexcept-specifier (PR 89510)

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.

coroutines: Fix handling of artificial vars [PR94886]

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.

coroutines: Fix handling of target cleanup exprs [PR94883]

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.

coroutines: Fix cases where proxy variables are used [PR94879]

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.

diagnostics: Fix spelling in comment

gcc/ChangeLog:

* pretty-print.c (pp_take_prefix): Fix spelling in comment.

tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

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.

[AArch64] Make -moutline-atomics on by default

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.

aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748]

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.

d: Fix documentation of -defaultlib= and -debuglib=

From the generated manpages, it was not clear that its usage is
'-debuglib=<libname>'.

gcc/d/ChangeLog:

* gdc.texi (Options for Linking): Clarify usage of -defaultlib= and
-debuglib= options.

Add missing ChangeLog entry

d: Merge upstream dmd 934df6f8c, druntime 7bdd83d7

Corrects a previous change made to the SPARC stdc bindings, and
backports PPC-related fixes.  The library and language testsuite now
passes fully on powerpc64le-linux-gnu.

Fixes: PR d/90719
Fixes: PR d/94825
Reviewed-on: https://github.com/dlang/dmd/pull/11079
     https://github.com/dlang/druntime/pull/3078
     https://github.com/dlang/druntime/pull/3083

libphobos/ChangeLog:

PR d/94825
* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Remove
config/powerpc/switchcontext.S
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/powerpc/callwithstack.S: Remove.
* libdruntime/config/powerpc/switchcontext.S: Fix symbol name of
fiber_switchContext.
* libdruntime/core/thread.d: Disable fiber migration tests on PPC.
* testsuite/libphobos.thread/fiber_guard_page.d: Set guardPageSize
same as stackSize.

--with-{documentation,changes}-root-url tweaks

>   , CHANGES_URL ("gcc-10/changes.html#empty_base");
>
> where the macro would just use preprocessor string concatenation?

Ok, the following patch implements it (doesn't introduce a separate
macro and just uses CHANGES_ROOT_URL "gcc-10/changes.html#empty_base"),
in addition adds the documentation Joseph requested.

2020-04-30  Jakub Jelinek  <jakub@redhat.com>

* configure.ac (--with-documentation-root-url,
--with-changes-root-url): Diagnose URL not ending with /,
use AC_DEFINE_UNQUOTED instead of AC_SUBST.
* opts.h (get_changes_url): Remove.
* opts.c (get_changes_url): Remove.
* Makefile.in (CFLAGS-opts.o): Don't add -DDOCUMENTATION_ROOT_URL
or -DCHANGES_ROOT_URL.
* doc/install.texi (--with-documentation-root-url,
--with-changes-root-url): Document.
* config/arm/arm.c (aapcs_vfp_is_call_or_return_candidate): Don't call
get_changes_url and free, change url variable type to const char * and
set it to CHANGES_ROOT_URL "gcc-10/changes.html#empty_base".
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Likewise.
* config/aarch64/aarch64.c (aarch64_vfp_is_call_or_return_candidate):
Likewise.
* config/rs6000/rs6000-call.c (rs6000_discover_homogeneous_aggregate):
Likewise.
* config.in: Regenerate.
* configure: Regenerate.

PR94725 - deleting gfortran.dg/dtio_5.f90 and pdt_5.f03

arm: Remove duplicate entries in isr_attribute_args [PR target/57002]

Remove two duplicate entries in isr_attribute_args ("abort" and
"ABORT").

2020-04-30  Christophe Lyon  <christophe.lyon@linaro.org>

PR target/57002
gcc/
* config/arm/arm.c (isr_attribute_args): Remove duplicate entries.

IBM Z: vec_store_len_r/vec_load_len_r fix

This fixes a problem with the vec_store_len_r intrinsic.  The macros
mapping the intrinsic to a GCC builtin had the wrong signature.

With the patch an immediate length operand of vlrl/vstrl is handled
the same way as if it was passed in a register to vlrlr/vstrlr.
Values bigger than 15 always load the full vector.  If it can be
recognized that it is in effect a full vector register load or store
it is now implemented with vl/vst instead.

gcc/ChangeLog:

2020-04-30  Andreas Krebbel  <krebbel@linux.ibm.com>

* config/s390/constraints.md ("j>f", "jb4"): New constraints.
* config/s390/vecintrin.h (vec_load_len_r, vec_store_len_r): Fix
macro definitions.
* config/s390/vx-builtins.md ("vlrlrv16qi", "vstrlrv16qi"): Add a
separate expander.
("*vlrlrv16qi", "*vstrlrv16qi"): Add alternative for vl/vst.
Change constraint for vlrl/vstrl to jb4.

gcc/testsuite/ChangeLog:

2020-04-30  Andreas Krebbel  <krebbel@linux.ibm.com>

* gcc.target/s390/zvector/vec_load_len_r.c: New test.
* gcc.target/s390/zvector/vec_store_len_r.c: New test.

var-tracking.c: Fix possible use of uninitialized variable pre

While bootstrapping GCC on S/390 the following warning/error is raised:

gcc/var-tracking.c:10239:34: error: 'pre' may be used uninitialized in this function [-Werror=maybe-uninitialized]
10239 |       VTI (bb)->out.stack_adjust += pre;
      |                                  ^

The lines of interest are:

  HOST_WIDE_INT pre, post = 0;
  // ...
  if (!frame_pointer_needed)
    {
      insn_stack_adjust_offset_pre_post (insn, &pre, &post);
      // ...
    }

  // ...
  adjust_insn (bb, insn);

  if (!frame_pointer_needed && pre)
    VTI (bb)->out.stack_adjust += pre;

Both if statements depend on global variable frame_pointer_needed.  In function
insn_stack_adjust_offset_pre_post local variable pre is initialized.  The
problematic part is the function call between both if statements.  Since
adjust_insn also calls functions which are defined in a different compilation
unit, we are not able to prove that global variable frame_pointer_needed is not
altered by adjust_insn and its siblings.  Thus we must assume that
frame_pointer_needed may be true before the call and false afterwards which
renders the warning true (admitted the location hint is not totally perfect).
By initialising pre we silence the warning.

gcc/ChangeLog:

2020-04-30  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

        * var-tracking.c (vt_initialize): Move variables pre and post
        into inner block and initialize both in order to fix warning
        about uninitialized use.  Remove unnecessary checks for
        frame_pointer_needed.

toplev.c: Check for null argument to fprintf

Ensure that CF does not equal NULL in function output_stack_usage_1
before calling fprintf.  This fixes the following warning/error:

gcc/toplev.c:976:13: error: argument 1 null where non-null expected [-Werror=nonnull]
  976 |     fprintf (cf, "\\n" HOST_WIDE_INT_PRINT_DEC " bytes (%s)",
      |     ~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  977 |       stack_usage,
      |       ~~~~~~~~~~~~
  978 |       stack_usage_kind_str[stack_usage_kind]);

An example call side where CF is NULL is in function output_stack_usage.

gcc/ChangeLog:

2020-04-30  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

* toplev.c (output_stack_usage_1): Ensure that first
argument to fprintf is not null.

Daily bump.

diagnostics: Add %{...%} pretty-format support for URLs and use it in -Wpsabi diagnostics

The following patch attempts to use the diagnostics URL support if available
to provide more information about the C++17 empty base and C++20
[[no_unique_address]] empty class ABI changes in -Wpsabi diagnostics.

in GCC 10.1 at the end of the diagnostics is then in some terminals
underlined with a dotted line and points to a (to be written) anchor in
gcc-10/changes.html which we need to write anyway.

2020-04-29  Jakub Jelinek  <jakub@redhat.com>

* configure.ac (-with-changes-root-url): New configure option,
defaulting to https://gcc.gnu.org/.
* Makefile.in (CFLAGS-opts.o): Define CHANGES_ROOT_URL for
opts.c.
* pretty-print.c (get_end_url_string): New function.
(pp_format): Handle %{ and %} for URLs.
(pp_begin_url): Use pp_string instead of pp_printf.
(pp_end_url): Use get_end_url_string.
* opts.h (get_changes_url): Declare.
* opts.c (get_changes_url): New function.
* config/rs6000/rs6000-call.c: Include opts.h.
(rs6000_discover_homogeneous_aggregate): Use %{in GCC 10.1%} instead
of just in GCC 10.1 in diagnostics and add URL.
* config/arm/arm.c (aapcs_vfp_is_call_or_return_candidate): Likewise.
* config/aarch64/aarch64.c (aarch64_vfp_is_call_or_return_candidate):
Likewise.
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Likewise.
* configure: Regenerated.

* c-format.c (PP_FORMAT_CHAR_TABLE): Add %{ and %}.

s390: Fix up -Wpsabi diagnostics + [[no_unique_address]] empty member fix [PR94704]

So, based on the yesterday's discussions, similarly to powerpc64le-linux
I've done some testing for s390x-linux too.

First of all, I found a bug in my patch from yesterday, it was printing
the wrong type like 'double' etc. rather than the class that contained such
the element.  Fix below.

For s390x-linux, I was using
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { double a; };
struct B : public X { double a; };
struct C : public Y { double a; };
struct D : public Z { double a; };
struct E : public U { double a; };
struct F { [[no_unique_address]] X x; double a; };
struct G { [[no_unique_address]] Y y; double a; };
struct H { [[no_unique_address]] Z z; double a; };
struct I { [[no_unique_address]] U u; double a; };
struct J { double a; [[no_unique_address]] X x; };
struct K { double a; [[no_unique_address]] Y y; };
struct L { double a; [[no_unique_address]] Z z; };
struct M { double a; [[no_unique_address]] U u; };
 #define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s (s); return 0; }
T (A, a)
T (B, b)
T (C, c)
T (D, d)
T (E, e)
T (F, f)
T (G, g)
T (H, h)
T (I, i)
T (J, j)
T (K, k)
T (L, l)
T (M, m)
as testcase and looking for "\tld\t%f0,".
While g++ 9 with -std=c++17 used to pass in fpr just
A, g++ 9 -std=c++14, as well as current trunk -std=c++14 & 17
and clang++ from today -std=c++14 & 17 all pass A, B, C
in fpr and nothing else.  The intent stated by Jason seems to be
that A, B, C, F, G, J, K should all be passed in fpr.

Attached are two (updated) versions of the patch on top of the
powerpc+middle-end patch just posted.

The first one emits two separate -Wpsabi warnings like powerpc, one for
the -std=c++14 vs. -std=c++17 ABI difference and one for GCC 9 vs. 10
[[no_unique_address]] passing changes, the other one is silent about the
second case.

2020-04-29  Jakub Jelinek  <jakub@redhat.com>

PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Use DECL_FIELD_ABI_IGNORED instead of
cxx17_empty_base_field_p.  In -Wpsabi diagnostics use the type
passed to the function rather than the type of the single element.
Rename cxx17_empty_base_seen variable to empty_base_seen, change
type to int, and adjust diagnostics depending on if the field
has [[no_unique_attribute]] or not.

* g++.target/s390/s390.exp: New file.
* g++.target/s390/pr94704-1.C: New test.
* g++.target/s390/pr94704-2.C: New test.
* g++.target/s390/pr94704-3.C: New test.
* g++.target/s390/pr94704-4.C: New test.

libstdc++: Fix outdated comment about std::string instantiations (PR 94854)

PR libstdc++/94854
* include/bits/basic_string.tcc: Update comment about explicit
instantiations.

x86: Fix -O0 remaining intrinsic macros [PR94832]

A few other macros seem to suffer from the same issue.  What I've done was:
cat gcc/config/i386/*intrin.h | sed -e ':x /\\$/ { N; s/\\\n//g ; bx }' \
| grep '^[[:blank:]]*#[[:blank:]]*define[[:blank:]].*(' | sed 's/[  ]\+/ /g' \
> /tmp/macros
and then looking for regexps:
)[a-zA-Z]
) [a-zA-Z]
[a-zA-Z][-+*/%]
[a-zA-Z] [-+*/%]
[-+*/%][a-zA-Z]
[-+*/%] [a-zA-Z]
in the resulting file.

2020-04-29  Jakub Jelinek  <jakub@redhat.com>

PR target/94832
* config/i386/avx512bwintrin.h (_mm512_alignr_epi8,
_mm512_mask_alignr_epi8, _mm512_maskz_alignr_epi8): Wrap macro operands
used in casts into parens.
* config/i386/avx512fintrin.h (_mm512_cvt_roundps_ph, _mm512_cvtps_ph,
_mm512_mask_cvt_roundps_ph, _mm512_mask_cvtps_ph,
_mm512_maskz_cvt_roundps_ph, _mm512_maskz_cvtps_ph,
_mm512_mask_cmp_epi64_mask, _mm512_mask_cmp_epi32_mask,
_mm512_mask_cmp_epu64_mask, _mm512_mask_cmp_epu32_mask,
_mm512_mask_cmp_round_pd_mask, _mm512_mask_cmp_round_ps_mask,
_mm512_mask_cmp_pd_mask, _mm512_mask_cmp_ps_mask): Likewise.
* config/i386/avx512vlbwintrin.h (_mm256_mask_alignr_epi8,
_mm256_maskz_alignr_epi8, _mm_mask_alignr_epi8, _mm_maskz_alignr_epi8,
_mm256_mask_cmp_epu8_mask): Likewise.
* config/i386/avx512vlintrin.h (_mm_mask_cvtps_ph, _mm_maskz_cvtps_ph,
_mm256_mask_cvtps_ph, _mm256_maskz_cvtps_ph): Likewise.
* config/i386/f16cintrin.h (_mm_cvtps_ph, _mm256_cvtps_ph): Likewise.
* config/i386/shaintrin.h (_mm_sha1rnds4_epu32): Likewise.

x86: Fix -O0 intrinsic *gather*/*scatter* macros [PR94832]

As reported in the PR, while most intrinsic -O0 macro argument uses
are properly wrapped in ()s or used in context where having a complex
expression passed as the argument doesn't pose a problem (e.g. when
macro argument use is in between commas, or between ( and comma, or
between comma and ) etc.), especially the gather/scatter macros don't do
this and if one passes to some macro e.g. x + y as argument, the
corresponding inline function would do cast on the argument, but
the macro does (int) ARG, then it is (int) x + y rather than (int) (x + y).

The following patch fixes those issues in *gather/*scatter*; additionally,
the AVX2 macros were passing incorrect mask of e.g.
(__v2df)_mm_set1_pd((double)(long long int) -1)
which is IMHO equivalent to
(__v2df){-1.0, -1.0}
when it really wants to pass __v2df vector with all bits set.
I've used what the inline functions use for those cases.

2020-04-29  Jakub Jelinek  <jakub@redhat.com>

PR target/94832
* config/i386/avx2intrin.h (_mm_mask_i32gather_pd,
_mm256_mask_i32gather_pd, _mm_mask_i64gather_pd,
_mm256_mask_i64gather_pd, _mm_mask_i32gather_ps,
_mm256_mask_i32gather_ps, _mm_mask_i64gather_ps,
_mm256_mask_i64gather_ps, _mm_i32gather_epi64,
_mm_mask_i32gather_epi64, _mm256_i32gather_epi64,
_mm256_mask_i32gather_epi64, _mm_i64gather_epi64,
_mm_mask_i64gather_epi64, _mm256_i64gather_epi64,
_mm256_mask_i64gather_epi64, _mm_i32gather_epi32,
_mm_mask_i32gather_epi32, _mm256_i32gather_epi32,
_mm256_mask_i32gather_epi32, _mm_i64gather_epi32,
_mm_mask_i64gather_epi32, _mm256_i64gather_epi32,
_mm256_mask_i64gather_epi32): Surround macro parameter uses with
parens.
(_mm_i32gather_pd, _mm256_i32gather_pd, _mm_i64gather_pd,
_mm256_i64gather_pd, _mm_i32gather_ps, _mm256_i32gather_ps,
_mm_i64gather_ps, _mm256_i64gather_ps): Likewise.  Don't use
as mask vector containing -1.0 or -1.0f elts, but instead vector
with all bits set using _mm*_cmpeq_p? with zero operands.
* config/i386/avx512fintrin.h (_mm512_i32gather_ps,
_mm512_mask_i32gather_ps, _mm512_i32gather_pd,
_mm512_mask_i32gather_pd, _mm512_i64gather_ps,
_mm512_mask_i64gather_ps, _mm512_i64gather_pd,
_mm512_mask_i64gather_pd, _mm512_i32gather_epi32,
_mm512_mask_i32gather_epi32, _mm512_i32gather_epi64,
_mm512_mask_i32gather_epi64, _mm512_i64gather_epi32,
_mm512_mask_i64gather_epi32, _mm512_i64gather_epi64,
_mm512_mask_i64gather_epi64, _mm512_i32scatter_ps,
_mm512_mask_i32scatter_ps, _mm512_i32scatter_pd,
_mm512_mask_i32scatter_pd, _mm512_i64scatter_ps,
_mm512_mask_i64scatter_ps, _mm512_i64scatter_pd,
_mm512_mask_i64scatter_pd, _mm512_i32scatter_epi32,
_mm512_mask_i32scatter_epi32, _mm512_i32scatter_epi64,
_mm512_mask_i32scatter_epi64, _mm512_i64scatter_epi32,
_mm512_mask_i64scatter_epi32, _mm512_i64scatter_epi64,
_mm512_mask_i64scatter_epi64): Surround macro parameter uses with
parens.
* config/i386/avx512pfintrin.h (_mm512_prefetch_i32gather_pd,
_mm512_prefetch_i32gather_ps, _mm512_mask_prefetch_i32gather_pd,
_mm512_mask_prefetch_i32gather_ps, _mm512_prefetch_i64gather_pd,
_mm512_prefetch_i64gather_ps, _mm512_mask_prefetch_i64gather_pd,
_mm512_mask_prefetch_i64gather_ps, _mm512_prefetch_i32scatter_pd,
_mm512_prefetch_i32scatter_ps, _mm512_mask_prefetch_i32scatter_pd,
_mm512_mask_prefetch_i32scatter_ps, _mm512_prefetch_i64scatter_pd,
_mm512_prefetch_i64scatter_ps, _mm512_mask_prefetch_i64scatter_pd,
_mm512_mask_prefetch_i64scatter_ps): Likewise.
* config/i386/avx512vlintrin.h (_mm256_mmask_i32gather_ps,
_mm_mmask_i32gather_ps, _mm256_mmask_i32gather_pd,
_mm_mmask_i32gather_pd, _mm256_mmask_i64gather_ps,
_mm_mmask_i64gather_ps, _mm256_mmask_i64gather_pd,
_mm_mmask_i64gather_pd, _mm256_mmask_i32gather_epi32,
_mm_mmask_i32gather_epi32, _mm256_mmask_i32gather_epi64,
_mm_mmask_i32gather_epi64, _mm256_mmask_i64gather_epi32,
_mm_mmask_i64gather_epi32, _mm256_mmask_i64gather_epi64,
_mm_mmask_i64gather_epi64, _mm256_i32scatter_ps,
_mm256_mask_i32scatter_ps, _mm_i32scatter_ps, _mm_mask_i32scatter_ps,
_mm256_i32scatter_pd, _mm256_mask_i32scatter_pd, _mm_i32scatter_pd,
_mm_mask_i32scatter_pd, _mm256_i64scatter_ps,
_mm256_mask_i64scatter_ps, _mm_i64scatter_ps, _mm_mask_i64scatter_ps,
_mm256_i64scatter_pd, _mm256_mask_i64scatter_pd, _mm_i64scatter_pd,
_mm_mask_i64scatter_pd, _mm256_i32scatter_epi32,
_mm256_mask_i32scatter_epi32, _mm_i32scatter_epi32,
_mm_mask_i32scatter_epi32, _mm256_i32scatter_epi64,
_mm256_mask_i32scatter_epi64, _mm_i32scatter_epi64,
_mm_mask_i32scatter_epi64, _mm256_i64scatter_epi32,
_mm256_mask_i64scatter_epi32, _mm_i64scatter_epi32,
_mm_mask_i64scatter_epi32, _mm256_i64scatter_epi64,
_mm256_mask_i64scatter_epi64, _mm_i64scatter_epi64,
_mm_mask_i64scatter_epi64): Likewise.

fortran/io.c: Fix use of uninitialized variable num [PR94769]

While bootstrapping GCC on S/390 the following warning occurs:

gcc/fortran/io.c: In function 'bool gfc_resolve_dt(gfc_code*, gfc_dt*, locus*)':
gcc/fortran/io.c:3857:7: error: 'num' may be used uninitialized in this function [-Werror=maybe-uninitialized]
 3857 |       if (num == 0)
      |       ^~
gcc/fortran/io.c:3843:11: note: 'num' was declared here
 3843 |       int num;

Since gfc_resolve_dt is a non-static function we cannot assume anything about
argument DT.  Argument DT gets passed to function check_io_constraints which
passes values depending on DT, namely dt->asynchronous->value.character.string
to function compare_to_allowed_values as well as argument warn which is true as
soon as DT->dterr is true.  Thus both arguments depend on DT.

If function compare_to_allowed_values is called with
dt->asynchronous->value.character.string not being an allowed value, and
ALLOWED_F2003 as well as ALLOWED_GNU being NULL (which is the case at the
particular call side), and WARN equals true, then the function returns with a
non-zero value and leaves num uninitialized which renders the warning true.

Initialized num to -1 and added an assert statement.

gcc/fortran/ChangeLog:

2020-04-29  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

        PR fortran/94769
        * io.c (check_io_constraints): Initialize local variable num to
        -1 and assert that it receives a meaningful value by function
        compare_to_allowed_values.

Fix some testsuite failures for H8/SX multilibs where short branches where used when long branches were necessary.

* config/h8300/h8300.md (H8/SX div patterns): All H8/SX specific
division instructions are 4 bytes long.

rs6000: Fix rs6000_atomic_assign_expand_fenv [PR94826]

This is the rs6000 version of the earlier committed x86, aarch64 and arm
fixes, as create_tmp_var_raw is used because the C FE can call this outside
of function context, we need to make sure the first references to those
VAR_DECLs are through a TARGET_EXPR, so that it gets gimple_add_tmp_var
marked in whatever function it gets expanded in.  Without that DECL_CONTEXT
is NULL and the vars aren't added as local decls of the containing function.

2020-04-29  Jakub Jelinek  <jakub@redhat.com>

PR target/94826
* config/rs6000/rs6000.c (rs6000_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for first assignment to
fenv_var, fenv_clear and old_fenv variables.  For fenv_addr
take address of TARGET_EXPR of fenv_var with void_node initializer.
Formatting fixes.

tree-optimization: Fix use of uninitialized variable [PR94774]

Array retval is not necessarily initialized by function is_call_safe and
may be used afterwards.  Thus, initialize it explicitly.

gcc/ChangeLog:

2020-04-29  Stefan Schulze Frielinghaus  <stefansf@linux.ibm.com>

PR tree-optimization/94774
* gimple-ssa-sprintf.c (try_substitute_return_value): Initialize
variable retval.

c++: Nondeterministic concepts diagnostics [PR94830]

This patch makes the order in which template parameters appear in the
TREE_LIST returned by find_template_parameters deterministic between
runs.

The current nondeterminism is semantically harmless, but it has the
undesirable effect of causing some concepts diagnostics which print a
constraint's parameter mapping via pp_cxx_parameter_mapping to also be
nondeterministic, as in the testcases below.

gcc/cp/ChangeLog:

PR c++/94830
* pt.c (find_template_parameter_info::parm_list): New field.
(keep_template_parm): Use the new field to build up the
parameter list here instead of ...
(find_template_parameters): ... here.  Return ftpi.parm_list.

gcc/testsuite/ChangeLog:

PR c++/94830
* g++.dg/concepts/diagnostics12.C: Clarify the dg-message now
that the corresponding diagnostic is deterministic.
* g++.dg/concepts/diagnostics13.C: New test.

calls: Remove FIXME for cxx17_empty_base_field_p

This predicate is now used by aarch64 targets.

2020-04-29  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* calls.h (cxx17_empty_base_field_p): Turn into a function declaration.
* calls.c (cxx17_empty_base_field_p): New function.  Check
DECL_ARTIFICIAL and RECORD_OR_UNION_TYPE_P in addition to the
previous checks.

x86: Allow -fcf-protection with external thunk

Allow -fcf-protection with external thunk since the external thunk can be
made compatible with -fcf-protection.

gcc/

PR target/93654
* config/i386/i386-options.c (ix86_set_indirect_branch_type):
Allow -fcf-protection with -mindirect-branch=thunk-extern and
-mfunction-return=thunk-extern.
* doc/invoke.texi: Update notes for -fcf-protection=branch with
-mindirect-branch=thunk-extern and -mindirect-return=thunk-extern.

gcc/testsuite/

PR target/93654
* gcc.target/i386/pr93654.c: New test.

doc: Add missing arm_arch_v8a_hard_ok anchor

2020-04-29  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* doc/sourcebuild.texi: Add missing arm_arch_v8a_hard_ok anchor.

arm: Extend the PR94780 fix to arm

Essentially the same fix as for x86.

2020-04-29  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* config/arm/arm-builtins.c (arm_atomic_assign_expand_fenv): Use
TARGET_EXPR instead of MODIFY_EXPR for the first assignments to
fenv_var and new_fenv_var.

arm: Fix parameter passing for [[no_unique_address]]

This patch makes the ABI code ignore zero-sized [[no_unique_address]]
fields when deciding whether something is a HFA or HVA.

For the tests, I wanted an -march setting that was stable enough
to use check-function-bodies and also wanted to force -mfloat-abi=hard.
I couldn't see any existing way of doing both together, since most
arm-related effective-target keywords are agnostic about the choice
between -mfloat-abi=softfp and -mfloat-abi=hard.  I therefore added
a new effective-target keyword for this combination.

I used the arm_arch_* framework for the effective-target rather than
writing a new set of custom Tcl routines.  This has the nice property
of separating the "compile and assemble" cases from the "link and run"
cases.  I only need compilation to work for the new tests, so requiring
linking to work would be an unnecessary restriction.

However, including an ABI requirement is arguably stretching what the
list was originally intended to handle.  The name arm_arch_v8a_hard
doesn't fit very naturally with some of the NEON-based tests.
On the other hand, the naming convention isn't entirely consistent,
so any choice would be inconsistent with something.

2020-04-29  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* doc/sourcebuild.texi (arm_arch_v8a_hard_ok): Document new
effective-target keyword.
(arm_arch_v8a_hard_multilib): Likewise.
(arm_arch_v8a_hard): Document new dg-add-options keyword.
* config/arm/arm.c (arm_return_in_memory): Note that the APCS
code is deprecated and has not been updated to handle
DECL_FIELD_ABI_IGNORED.
(WARN_PSABI_EMPTY_CXX17_BASE): New constant.
(WARN_PSABI_NO_UNIQUE_ADDRESS): Likewise.
(aapcs_vfp_sub_candidate): Replace the boolean pointer parameter
avoid_cxx17_empty_base with a pointer to a bitmask.  Ignore fields
whose DECL_FIELD_ABI_IGNORED bit is set when determining whether
something actually is a HFA or HVA.  Record whether we see a
[[no_unique_address]] field that previous GCCs would not have
ignored in this way.
(aapcs_vfp_is_call_or_return_candidate): Update the calls to
aapcs_vfp_sub_candidate and report a -Wpsabi warning for the
[[no_unique_address]] case.  Use TYPE_MAIN_VARIANT in the
diagnostic messages.
(arm_needs_doubleword_align): Add a comment explaining why we
consider even zero-sized fields.

gcc/testsuite/
* lib/target-supports.exp: Add v8a_hard to the list of arm_arch_*
targets.
* g++.target/arm/no_unique_address_1.C: New test.
* g++.target/arm/no_unique_address_2.C: Likewise.

lto/94822 - fix ICE in component_ref_size

This ICE appears because gcc will stream it to the function_body section
when processing the variable with the initial value of the constructor
type, and the error_mark_node to the decls section.
When recompiling, the value obtained with DECL_INITIAL will be error_mark.

2020-04-29  Richard Biener  <rguenther@suse.de>
    Li Zekun  <lizekun1@huawei.com>

PR lto/94822
* tree.c (component_ref_size): Guard against error_mark_node
DECL_INITIAL as it happens with LTO.

* gcc.dg/lto/pr94822_0.c: New testcase.
* gcc.dg/lto/pr94822_1.c: Alternate file.
* gcc.dg/lto/pr94822.h: Likewise.

aarch64: Fix parameter passing for [[no_unique_address]]

This patch makes the ABI code ignore zero-sized [[no_unique_address]]
fields when deciding whether something is a HFA or HVA.

As things stood, we'd get two sets of -Wpsabi warnings, one when
trying to decide whether something was an SVE function, and another
when actually processing the function definition or function call.
The patch therefore makes aapcs_vfp_sub_candidate honour the
CUMULATIVE_ARGS "silent_p" flag where applicable.

This doesn't stop all duplicate warnings for parameters, and I suspect
we'll get duplicate warnings for return values too, but it should be
better than nothing.

2020-04-29  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
* config/aarch64/aarch64.c (aarch64_function_arg_alignment): Add a
comment explaining why we consider even zero-sized fields.
(WARN_PSABI_EMPTY_CXX17_BASE): New constant.
(WARN_PSABI_NO_UNIQUE_ADDRESS): Likewise.
(aapcs_vfp_sub_candidate): Replace the boolean pointer parameter
avoid_cxx17_empty_base with a pointer to a bitmask.  Ignore fields
whose DECL_FIELD_ABI_IGNORED bit is set when determining whether
something actually is a HFA or HVA.  Record whether we see a
[[no_unique_address]] field that previous GCCs would not have
ignored in this way.
(aarch64_vfp_is_call_or_return_candidate): Add a parameter to say
whether diagnostics should be suppressed.  Update the calls to
aapcs_vfp_sub_candidate and report a -Wpsabi warning for the
[[no_unique_address]] case.
(aarch64_return_in_msb): Update call accordingly, never silencing
diagnostics.
(aarch64_function_value): Likewise.
(aarch64_return_in_memory_1): Likewise.
(aarch64_init_cumulative_args): Likewise.
(aarch64_gimplify_va_arg_expr): Likewise.
(aarch64_pass_by_reference_1): Take a CUMULATIVE_ARGS pointer and
use it to decide whether arch64_vfp_is_call_or_return_candidate
should be silent.
(aarch64_pass_by_reference): Update calls accordingly.
(aarch64_vfp_is_call_candidate): Use the CUMULATIVE_ARGS argument
to decide whether arch64_vfp_is_call_or_return_candidate should be
silent.

gcc/testsuite/
* g++.target/aarch64/no_unique_address_1.C: New test.
* g++.target/aarch64/no_unique_address_2.C: Likewise.

testsuite: Save dg-do-what-default in mve.exp

mve.exp changed the default dg-do action to "assemble", but then
left it like that for later exp files.  This meant that in a
two-multilib test run, the first arm.exp run would have a default
of "dg-do compile" and the second would have a default of
"dg-do assemble".

2020-04-29  Richard Sandiford  <richard.sandiford@arm.com>

gcc/testsuite/
* g++.target/arm/mve.exp: Restore the original dg-do-what-default
before finishing.

libphobos: Fix KERNEL_VERSION condition in libphobos testsuite

A typo in the macro call meant that the #error always triggered.

libphobos/ChangeLog:

* testsuite/lib/libphobos.exp (check_effective_target_linux_pre_2639):
Fix KERNEL_VERSION condition.

d: Merge bug fix from upstream dmd 06160ccae

Adds classKind information to the front-end AST, which in turn allows us
to fix code generation of type names for extern(C) and extern(C++)
structs and classes.  Inspecting such types inside a debugger now just
works without the need to 'cast(module_name.cxx_type)'.

gcc/d/ChangeLog:

* d-codegen.cc (d_decl_context): Don't include module in the name of
class and struct types that aren't extern(D).

pr94780.c fails with ICE on aarch64 [PR94820]

This is a simple fix for pr94820.
The PR was only fixed on i386, the same error was also reported on aarch64.
This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var.
But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification
the var gets the right DECL_CONTEXT and is added to local decls. Without that, e.g. tree-nested.c ICEs on those.

2020-04-29  Haijian Zhang  <z.zhanghaijian@huawei.com>

PR target/94820
* config/aarch64/aarch64-builtins.c
(aarch64_atomic_assign_expand_fenv): Use TARGET_EXPR instead of
MODIFY_EXPR for first assignment to fenv_cr, fenv_sr and
new_fenv_var.

[OpenACC] Set 'acc_device_current = -1'

There's no point in using value '-3', and even though not directly related,
value '-1' does match 'GOMP_DEVICE_ICV'.

libgomp/
* config/accel/openacc.f90 (acc_device_current): Set to '-1'.
* openacc.f90 (acc_device_current): Likewise.
* openacc.h (acc_device_current): Likewise.
* openacc_lib.h (acc_device_current): Likewise.

Harden and adjust 'gcc/configure' parsing of '--enable-offload-targets'

Fix-up for commit d228ee80f8578be474595a517a228111fac26c5e "re PR
bootstrap/92314 (missing omp-device-properties', needed by
's-omp-device-properties-h')".

gcc/
* configure.ac <$enable_offload_targets>: Do parsing as done
elsewhere.
* configure: Regenerate.

[gcn] Fix 'omp-device-properties-gcn' handling

Fix-up for commit 955cd057454b323419e06affa7df7d59dc3cd1fb "Add
gcc/config/gcn/t-omp-device for OpenMP declare variant kind/arch/isa".

With AMD GCN offloading configured, I'm seeing occasional GCC build hangs.
I've now captured and analyzed one of them:

    $ ps -f
    UID        PID  PPID  C STIME TTY          TIME CMD
    [...]
    tschwing  5113  4508  0 20:24 pts/5    00:00:00 /bin/sh -c rm -f tmp-omp-device-properties.h; \ for kind in kind arch isa; do \   echo 'const char omp_offload_device_'${kind}'[] = ' \     >> tmp-omp-device-properties.h; \   for prop in no
    tschwing  5126  5113  0 20:24 pts/5    00:00:00 sed -n s/^kind: //p
    tschwing  5127  5113  0 20:24 pts/5    00:00:00 sed s/[[:blank:]]/ /g;s/  */ /g;s/^ //;s/ $//;s/ /\\0/g;s/^/"/;s/$/\\0\\0"/
    [...]
    $ pstree -p $$
    [...]---sh(5113)-+-sed(5126)
                     `-sed(5127)
    $ ls -lrt build-gcc/gcc/*omp-device*
    -rw-r--r-- 1 tschwing eeg  39 Apr 23 20:24 build-gcc/gcc/omp-device-properties-nvptx
    -rw-r--r-- 1 tschwing eeg 634 Apr 23 20:24 build-gcc/gcc/omp-device-properties-i386
    -rw-r--r-- 1 tschwing eeg  58 Apr 23 20:24 build-gcc/gcc/tmp-omp-device-properties.h

Notably missing is the 'omp-device-properties-gcn' file...

    $ grep ^ build-gcc/gcc/*omp-device*
    build-gcc/gcc/omp-device-properties-i386:kind: cpu
    build-gcc/gcc/omp-device-properties-i386:arch: x86 x86_64 i386 i486 i586 i686 ia32
    build-gcc/gcc/omp-device-properties-i386:isa: sse4 cx16 [...]
    build-gcc/gcc/omp-device-properties-nvptx:kind: gpu
    build-gcc/gcc/omp-device-properties-nvptx:arch: nvptx
    build-gcc/gcc/omp-device-properties-nvptx:isa: sm_30 sm_35
    build-gcc/gcc/tmp-omp-device-properties.h:const char omp_offload_device_kind[] =
    build-gcc/gcc/tmp-omp-device-properties.h:"amdgcn-amdhsa\0"

..., which we here seem to be intending to fill into
'tmp-omp-device-properties.h'.

    $ grep ^omp_device_properties\ = build-gcc/gcc/Makefile
    omp_device_properties =  amdgcn-amdhsa= nvptx-none=omp-device-properties-nvptx x86_64-intelmicemul-linux-gnu=omp-device-properties-i386

Given the 's-omp-device-properties-h' Makefile rule, indeed there is an
unescaped '$${props}', which is meant to be the filename following the equals
sign -- but there is none for 'amdgcn-amdhsa=', so this tries to read from
'stdin'!

The real problem of course is elsewhere.

gcc/
* configure.ac <$enable_offload_targets>: 'amdgcn' is 'gcn'.
* configure: Regenerate.

[rtl] Harden 'set_noop_p' for non-constant selectors [PR94279]

... given that the GCN target did away with the constant 'vec_select'
restriction.

gcc/
PR target/94279
* rtlanal.c (set_noop_p): Handle non-constant selectors.

[gcn] Set 'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282]

In libgomp offloading testing, this resolves all the 'ld: error: undefined
symbol: __gxx_personality_v0' FAILs.

gcc/
PR target/94282
* common/config/gcn/gcn-common.c (gcn_except_unwind_info): New
function.
(TARGET_EXCEPT_UNWIND_INFO): Define.
libgomp/
PR target/94282
* testsuite/libgomp.c-c++-common/function-not-offloaded.c: Remove
'dg-allow-blank-lines-in-output'.

[gcn] Fix build with RTL checking [PR94248]

Building (for offloading) a '--target=amdgcn-amdhsa' GCC with
'--enable-checking=yes,extra,rtl' fails:

    during RTL pass: split2
    [...]/source-gcc/libgcc/libgcc2.c: In function '__absvdi2':
    [...]/source-gcc/libgcc/libgcc2.c:271:1: internal compiler error: RTL check: expected code 'reg', have 'const_int' in rhs_regno, at rtl.h:1923
      271 | }
  | ^
    0x565847 ???
    [...]/source-gcc/gcc/rtl.c:881
    0x59a8a4 ???
    [...]/source-gcc/gcc/rtl.h:1923
    0x12e3a5c ???
    [...]/source-gcc/gcc/config/gcn/gcn.md:631
    [...]
    Makefile:501: recipe for target '_absvdi2.o' failed
    make[4]: *** [_absvdi2.o] Error 1
    make[4]: Leaving directory '[...]/build-gcc-offload-amdgcn-amdhsa/amdgcn-amdhsa/gfx900/libgcc'

gcc/
PR target/94248
* config/gcn/gcn.md (*mov<mode>_insn): Use
'reg_overlap_mentioned_p' to check for overlap.

Tested-by: Thomas Schwinge <thomas@codesourcery.com>

[gcn] Don't default to building target-libstdc++-v3 [PR92713]

... which hasn't been ported/fails to build when using newlib (with GCC commit
b73f69020f08208d2d969fcf8879bd294a6e3596 sources, and newlib commit
6d79e0a58866548f435527798fbd4a6849d05bc7, tag: newlib-3.3.0 sources):

    In file included from [...]/build-gcc-offload-amdgcn-amdhsa/amdgcn-amdhsa/libstdc++-v3/include/csetjmp:42,
                     from [...]/source-gcc/libstdc++-v3/include/precompiled/stdc++.h:42:
    [...]/source-gcc/newlib/libc/include/setjmp.h:15:6: error: variable or field 'longjmp' declared void
       15 | void longjmp (jmp_buf __jmpb, int __retval)
          |      ^~~~~~~
    [...]
    Makefile:1824: recipe for target 'amdgcn-amdhsa/bits/stdc++.h.gch/O2ggnu++0x.gch' failed
    make[3]: *** [amdgcn-amdhsa/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1

PR target/92713
* configure.ac ["${ENABLE_LIBSTDCXX}" = "default" && amdgcn*-*-*]
(noconfigdirs): Add 'target-libstdc++-v3'.
* configure: Regenerate.

[gcn] Use 'radeon' for the environment variable 'ACC_DEVICE_TYPE'

..., per OpenACC 3.0, A.1.2. "AMD GPU Targets".

This complements commit 6687d13a87c42dddc7d1c7adade38d31ba0d1401 "Rename
acc_device_gcn to acc_device_radeon".

libgomp/
* oacc-init.c (get_openacc_name): Handle 'gcn'.
* testsuite/lib/libgomp.exp
(offload_target_to_openacc_device_type) [amdgcn*]: Return
'radeon'.  Adjust all users.
(check_effective_target_openacc_amdgcn_accel_present): Rename
to...
(check_effective_target_openacc_radeon_accel_present): ... this.
Adjust all users.
(check_effective_target_openacc_amdgcn_accel_selected): Rename to...
(check_effective_target_openacc_radeon_accel_selected): ... this.
Adjust all users.

Torture testing: 'libgomp.fortran/use_device_ptr-optional-2.f90'

Fix-up for commit a2c26c50310a336361d8129ecdd43d3001d6cb3a (r278046) "Fortran]
Support absent optional args with use_device_{ptr,addr}".

libgomp/
* testsuite/libgomp.fortran/use_device_ptr-optional-2.f90: Add
'dg-do run'.

ia64: Adjust the C++14 vs. C++17 ABI thing for [[no_unique_address]] too [PR94706]

2020-04-29  Jakub Jelinek  <jakub@redhat.com>

PR target/94706
* config/ia64/ia64.c (hfa_element_mode): Use DECL_FIELD_ABI_IGNORED
instead of cxx17_empty_base_field_p.

c++, middle-end, rs6000: Fix C++17 ABI incompatibilities during class layout and [[no_unique_address]] handling [PR94707]

As reported by Iain and David, powerpc-darwin and powerpc-aix* have C++14
vs. C++17 ABI incompatibilities which are not fixed by mere adding of
cxx17_empty_base_field_p calls.  Unlike the issues that were seen on other
targets where the artificial empty base field affected function argument
passing or returning of values, on these two targets the difference is
during class layout, not afterwards (e.g.
struct empty_base {};
struct S : public empty_base { unsigned long long l[2]; };
will have different __alignof__ (S) between C++14 and C++17 (or possibly
with double instead of unsigned long long too)).

I've tried:
struct X { };
struct Y { int : 0; };
struct Z { int : 0; Y y; };
struct U : public X { X q; };
struct A { float a, b, c, d; };
struct B : public X { float a, b, c, d; };
struct C : public Y { float a, b, c, d; };
struct D : public Z { float a, b, c, d; };
struct E : public U { float a, b, c, d; };
struct F { [[no_unique_address]] X x; float a, b, c, d; };
struct G { [[no_unique_address]] Y y; float a, b, c, d; };
struct H { [[no_unique_address]] Z z; float a, b, c, d; };
struct I { [[no_unique_address]] U u; float a, b, c, d; };
struct J { float a, b; [[no_unique_address]] X x; float c, d; };
struct K { float a, b; [[no_unique_address]] Y y; float c, d; };
struct L { float a, b; [[no_unique_address]] Z z; float c, d; };
struct M { float a, b; [[no_unique_address]] U u; float c, d; };
 #define T(S, s) extern S s; extern void foo##s (S); int bar##s () { foo##s (s); return 0; }
T (A, a)
T (B, b)
T (C, c)
T (D, d)
T (E, e)
T (F, f)
T (G, g)
T (H, h)
T (I, i)
T (J, j)
T (K, k)
T (L, l)
T (M, m)
testcase on powerpc64-linux.  Results:
G++ 9 -std=c++14                A, B, C passed in fprs, the rest in gprs
G++ 9 -std=c++17                A passed in fprs, the rest in gprs
current trunk -std=c++14 & 17   A, B, C passed in fprs, the rest in gprs
patched trunk -std=c++14 & 17   A, B, C, F, G, J, K passed in fprs, the rest in gprs
clang++ [*] -std=c++14 & 17     A, B, C, F, G, J, K passed in fprs, the rest in gprs
[*] clang version 11.0.0 (git@github.com:llvm/llvm-project.git 5c352e69e76a26e4eda075e20aa6a9bb7686042c)

Is that what we want?  I think it matches the stated intent of P0840R2 or
what Jason/Jonathan said, and doing something different like e.g. not
treating C, G and K as homogenous because of the int : 0 in empty bases
or in zero sized [[no_unique_address] fields would be quite hard to
implement (because for C++14 the FIELD_DECL just isn't there).

2020-04-29  Jakub Jelinek  <jakub@redhat.com>

PR target/94707
* tree-core.h (tree_decl_common): Note decl_flag_0 used for
DECL_FIELD_ABI_IGNORED.
* tree.h (DECL_FIELD_ABI_IGNORED): Define.
* calls.h (cxx17_empty_base_field_p): Change into a temporary
macro, check DECL_FIELD_ABI_IGNORED flag with no "no_unique_address"
attribute.
* calls.c (cxx17_empty_base_field_p): Remove.
* tree-streamer-out.c (pack_ts_decl_common_value_fields): Handle
DECL_FIELD_ABI_IGNORED.
* tree-streamer-in.c (unpack_ts_decl_common_value_fields): Likewise.
* lto-streamer-out.c (hash_tree): Likewise.
* config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Rename
cxx17_empty_base_seen to empty_base_seen, change type to int *,
adjust recursive calls, use DECL_FIELD_ABI_IGNORED instead of
cxx17_empty_base_field_p, if "no_unique_address" attribute is
present, propagate that to the caller too.
(rs6000_discover_homogeneous_aggregate): Adjust
rs6000_aggregate_candidate caller, emit different diagnostics
when c++17 empty base fields are present and when empty
[[no_unique_address]] fields are present.
* config/rs6000/rs6000.c (rs6000_special_round_type_align,
darwin_rs6000_special_round_type_align): Skip DECL_FIELD_ABI_IGNORED
fields.

* class.c (build_base_field): Set DECL_FIELD_ABI_IGNORED on C++17 empty
base artificial FIELD_DECLs.
(layout_class_type): Set DECL_FIELD_ABI_IGNORED on empty class
field_poverlapping_p FIELD_DECLs.

* lto-common.c (compare_tree_sccs_1): Handle DECL_FIELD_ABI_IGNORED.

* g++.target/powerpc/pr94707-1.C: New test.
* g++.target/powerpc/pr94707-2.C: New test.
* g++.target/powerpc/pr94707-3.C: New test.
* g++.target/powerpc/pr94707-4.C: New test.
* g++.target/powerpc/pr94707-5.C: New test.
* g++.target/powerpc/pr94707-4.C: New test.

fix regression with MEM commoning

This fixes a regression when canonicalizing refs for LIM PR84362.
This possibly unshares and rewrites the refs in the internal data
and thus pointer equality no longer works in ref_always_accessed
computation.

2020-04-29  Richard Biener  <rguenther@suse.de>

* tree-ssa-loop-im.c (ref_always_accessed::operator ()):
Just check whether the stmt stores.

c++: Satisfaction caching of inherited ctor [PR94819]

As observed in PR94719, an inherited constructor for an instantiation of
a constructor template confusingly has as its DECL_INHERITED_CTOR the
TEMPLATE_DECL of the constructor template rather than the particular
instantiation of the template.

This means two inherited constructors for two different instantiations
of the same constructor template have the same DECL_INHERITED_CTOR.  And
since in satisfy_declaration_constraints our decl satisfaction cache is
keyed off of the result of strip_inheriting_ctors, we may end up
conflating the satisfaction values of the two inherited constructors'
constraints.

This patch fixes this issue by using the original tree, not the result
of strip_inheriting_ctors, as the key to the decl satisfaction cache.

gcc/cp/ChangeLog:

PR c++/94819
* constraint.cc (satisfy_declaration_constraints): Use saved_t
instead of t as the key to decl_satisfied_cache.

gcc/testsuite/ChangeLog:

PR c++/94819
* g++.dg/cpp2a/concepts-inherit-ctor10.C: New test.
* g++.dg/cpp2a/concepts-inherit-ctor11.C: New test.

c++: Parameter pack in requires parameter list [PR94808]

When printing the substituted parameter list of a requires-expression as
part of the "in requirements with ..." context line during concepts
diagnostics, we weren't considering that substitution into a parameter
pack can yield zero or multiple parameters.

This patch changes the way we print the parameter list of a
requires-expression in print_requires_expression_info.  We now print the
dependent form of the parameter list (along with its template parameter
mapping) instead of printing its substituted form.  Besides being an
improvement in its own, this also sidesteps the substitution issue in the
PR altogether.

gcc/cp/ChangeLog:

PR c++/94808
* error.c (print_requires_expression_info): Print the dependent
form of the parameter list with its template parameter mapping,
rather than printing the substituted form.

gcc/testsuite/ChangeLog:

PR c++/94808
* g++.dg/concepts/diagnostic12.C: New test.
* g++.dg/concepts/diagnostic5.C: Adjust dg-message.

Daily bump.

libstdc++: Fixes for feature test macros (PR 91480)

Remove the non-standard __cpp_lib_allocator_is_always_equal macro and
add the missing macros for P1032R1.

PR libstdc++/91480
* include/bits/allocator.h (__cpp_lib_allocator_is_always_equal):
Remove non-standard macro.
* include/bits/stl_iterator.h (__cpp_lib_constexpr_iterator): Define
to indicate P1032R1 support.
* include/bits/stl_pair.h (__cpp_lib_constexpr_utility): Likewise.
* include/std/string_view (__cpp_lib_constexpr_string_view): Likewise.
* include/std/tuple (__cpp_lib_constexpr_tuple): Likewise.
* include/std/version (__cpp_lib_allocator_is_always_equal): Remove.
(__cpp_lib_constexpr_iterator, __cpp_lib_constexpr_string_view)
(__cpp_lib_constexpr_tuple, __cpp_lib_constexpr_utility): Define.
* testsuite/20_util/function_objects/constexpr_searcher.cc: Check
feature test macro.
* testsuite/20_util/tuple/cons/constexpr_allocator_arg_t.cc: Likewise.
* testsuite/21_strings/basic_string_view/operations/copy/char/
constexpr.cc: Likewise.
* testsuite/24_iterators/insert_iterator/constexpr.cc: Likewise.

libstdc++: Fix regression in std::_Construct (PR 94831)

By trying to reuse the existing std::_Construct function as a wrapper
for std::construct_at I introduced regressions, because changing
std::_Construct to return non-void made it ill-formed for array types.

The solution is to revert _Construct to its former state, and change
allocator_traits::construct to explicitly call construct_at instead.
This decouples all the existing callers of _Construct from the new
construct_at requirements.

PR libstdc++/94831
* include/bits/alloc_traits.h (_S_construct): Restore placement
new-expression for C++11/14/17 and call std::construct_at directly
for C++20.
* include/bits/stl_construct.h (_Construct): Revert to non-constexpr
function returning void.
* testsuite/20_util/specialized_algorithms/
uninitialized_value_construct/94831.cc: New test.
* testsuite/23_containers/vector/cons/94831.cc: New test.

[rs6000] fix mffsl emulation

The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going
through the motions, but not storing the result in the given
operands[0]; it rather modifies operands[0] without effect.  It also
creates a DImode pseudo that it doesn't use, overwriting subregs
instead.

The patch below fixes all of these, the indentation and a typo.

I'm concerned about several issues in the mffsl testcase.  First, I
don't see that comparing the values as doubles rather than as long
longs is desirable.  These are FPSCR bitfields, not FP numbers.  I
understand mffs et al use double because they output to FP registers,
and the bit patterns are subnormal FP numbers, so it works, but given
the need for bit masking of at least one side, I'm changing the
compare to long longs.

Another issue with the test is that, if the compare fails, it calls
mffsl again to print the value, as if it would yield the same result.
But part of the FPSCR that mffsl (emulated with mffs or not) copies to
the output FP register is the FPCC, so the fcmpu used to compare the
result of the first mffsl will modify FPSCR and thus the result of the
second mffsl call.  After changing the compare, this is no longer the
case, but I still think it's better to make absolutely sure what we
print is what we compared.

Yet another issue is that the test assumed the mffs bits that are not
to be extracted by mffsl to be already zero, instead of masking them
out explicitly.  This is not about the mffs emulation in the mffsl
implementation, but about the mffs use in the test proper.  The bits
appear to be zero indeed, as the bits left out are for sticky
exceptions, but there are reserved parts of FPSCR that might turn out
to be set in the future, so we're better off masking them out
explicitly, otherwise those bits could cause the compare to fail.

If some future mffsl is changed so that it copies additional nonzero
bits, the test will fail, and then we'll have a chance to adjust it
and the emulation.

for  gcc/ChangeLog

PR target/94812
* gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to
output operand in emulation.  Don't overwrite pseudos.

for  gcc/testsuite/ChangeLog

PR target/94812
* gcc.target/powerpc/test_mffsl.c: Call mffsl only once.
Reinterpret the doubles as long longs for compares.  Mask out
mffs bits that are not expected from mffsl.

libstdc++: Fix subrange::advance and subrange::prev (LWG 3433)

This implements the proposed resolution of LWG 3433, which fixes
subrange::advance when called with a negative argument.

libstdc++-v3/ChangeLog:

LWG 3433 subrange::advance(n) has UB when n < 0
* include/std/ranges (subrange::prev): Fix typo.
(subrange::advance): Handle a negative argument as per the proposed
resolution of LWG 3433.
* testsuite/std/ranges/subrange/lwg3433.cc: New test.

Fix some testsuite failures for H8/SX multilibs where short branches where used when long branches were necessary.

* config/h8300/h8300.md (H8/SX mult patterns): All H8/SX specific
multiply patterns are 4 bytes long.

libphobos: Fix multilib powerpc64 builds

Multilibs should not have been split up as two logically different CPU,
so at configure time, powerpc64 was being detected, but none of the
32-bit support files were being compiled in.

libphobos/ChangeLog:

PR d/94825
* configure: Regenerate.
* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Add both
switchcontext.S and callwithstack.S if DRUNTIME_CPU_POWERPC.
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/powerpc/switchcontext.S: Add !__PPC64__ guards.
* libdruntime/config/powerpc64/callwithstack.S: Add __PPC64__ guards.
* m4/druntime/cpu.m4 (DRUNTIME_CPU_SOURCES): Define DRUNTIME_CPU_POWER
for all powerpc biarchs.  Remove DRUNTIME_CPU_POWER64 conditional.

c++: Redeclaration of implicit operator== [PR94583]

My last patch rejected a namespace-scope declaration of the
implicitly-declared friend operator== before the class, but redeclaring it
after the class should be OK.

gcc/cp/ChangeLog
2020-04-28  Jason Merrill  <jason@redhat.com>

PR c++/94583
* decl.c (use_eh_spec_block): Check nothrow type after
DECL_DEFAULTED_FN.
* pt.c (maybe_instantiate_noexcept): Call synthesize_method for
DECL_MAYBE_DELETED fns here.
* decl2.c (mark_used): Not here.
* method.c (get_defaulted_eh_spec): Reject DECL_MAYBE_DELETED here.

analyzer: fix ICE copying struct [PR 94816]

PR analyzer/94816 reports an ICE when attempting to copy a struct
containing a field for which add_region_for_type for fails (on
an OFFSET_TYPE): the region for the src field comes from
make_region_for_unexpected_tree_code which gives it a NULL type, and
then the copy calls add_region_for_type which unconditionally
dereferences the NULL type.

This patch fixes the ICE by checking for NULL types in
add_region_for_type.

gcc/analyzer/ChangeLog:
PR analyzer/94816
* engine.cc (impl_region_model_context::on_unexpected_tree_code):
Handle NULL tree.
* region-model.cc (region_model::add_region_for_type): Handle
NULL type.
* region-model.h
(test_region_model_context::on_unexpected_tree_code): Handle NULL
tree.

gcc/testsuite/ChangeLog:
PR analyzer/94816
* g++.dg/analyzer/pr94816.C: New test.

[arm] Remove +nofp from -mcpu=cortex-m55 options

Turns out for consistency with LLVM the +nofp option shouldn't remove ALL of FP and MVE, just the FP part of MVE.
This requires more surgery with feature bits so for GCC 10 I'd rather just not support +nofp for -mcpu=cortex-m55
and implement it properly for GCC 11.

2020-04-28  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

* config/arm/arm-cpus.in (cortex-m55): Remove +nofp option.
* doc/invoke.texi (Arm Options): Remove -mcpu=cortex-m55 from +nofp option.

[Arm] Account for C++17 artificial field determining Homogeneous Aggregates

In C++14, an empty class deriving from an empty base is not an
aggregate, while in C++17 it is.  In order to implement this, GCC adds
an artificial field to such classes.

This artificial field has no mapping to Fundamental Data Types in the
Arm PCS ABI and hence should not count towards determining whether an
object can be passed using the vector registers as per section
"7.1.2 Procedure Calling" in the arm PCS
https://developer.arm.com/docs/ihi0042/latest?_ga=2.60211309.1506853196.1533541889-405231439.1528186050

This patch avoids counting this artificial field in
aapcs_vfp_sub_candidate, and hence calculates whether such objects
should be passed in vector registers in the same manner as C++14 (where
the artificial field does not exist).

Before this change, the test below would pass the arguments to `f` in
general registers.  After this change, the test passes the arguments to
`f` using the vector registers.

The new behaviour matches the behaviour of `armclang`, and also matches
the GCC behaviour when run with `-std=gnu++14`.

> gcc -std=gnu++17 -march=armv8-a+simd -mfloat-abi=hard test.cpp

``` test.cpp
struct base {};

struct pair : base
{
  float first;
  float second;
  pair (float f, float s) : first(f), second(s) {}
};

void f (pair);
int main()
{
  f({3.14, 666});
  return 1;
}
```

We add a `-Wpsabi` warning to catch cases where this fix has changed the ABI for
some functions.  Unfortunately this warning is not emitted twice for multiple
calls to the same function, but I feel this is not much of a problem and can be
fixed later if needs be.

(i.e. if `main` called `f` twice in a row we only emit a diagnostic for the
first).

Testing:
    Bootstrapped and regression tested on arm-linux.
    This change fixes the struct-layout-1 tests Jakub added
    https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544204.html
    Regression tested on arm-none-eabi.

gcc/ChangeLog:

2020-04-28  Matthew Malcomson  <matthew.malcomson@arm.com>
    Jakub Jelinek  <jakub@redhat.com>

PR target/94711
* config/arm/arm.c (aapcs_vfp_sub_candidate): Account for C++17 empty
base class artificial fields.
(aapcs_vfp_is_call_or_return_candidate): Warn when PCS ABI
decision is different after this fix.

analyzer: remove -Wanalyzer-use-of-uninitialized-value for GCC 10

From what I can tell -Wanalyzer-use-of-uninitialized-value has not
yet found a true diagnostic in real-world code, and seems to be
particularly susceptible to false positives.  These relate to bugs in
the region_model code.

For GCC 10 it seems best to remove this warning, which this patch does.
Internally it also removes POISON_KIND_UNINIT.

I'm working on a rewrite of the region_model code for GCC 11 that I
hope will fix these issues, and allow this warning to be reintroduced.

gcc/analyzer/ChangeLog:
PR analyzer/94447
PR analyzer/94639
PR analyzer/94732
PR analyzer/94754
* analyzer.opt (Wanalyzer-use-of-uninitialized-value): Delete.
* program-state.cc (selftest::test_program_state_dumping): Update
expected dump result for removal of "uninit".
* region-model.cc (poison_kind_to_str): Delete POISON_KIND_UNINIT
case.
(root_region::ensure_stack_region): Initialize stack with null
svalue_id rather than with a typeless POISON_KIND_UNINIT value.
(root_region::ensure_heap_region): Likewise for the heap.
(region_model::dump_summary_of_rep_path_vars): Remove
summarization of uninit values.
(region_model::validate): Remove check that the stack has a
POISON_KIND_UNINIT value.
(poisoned_value_diagnostic::emit): Remove POISON_KIND_UNINIT
case.
(poisoned_value_diagnostic::describe_final_event): Likewise.
(selftest::test_dump): Update expected dump result for removal of
"uninit".
(selftest::test_svalue_equality): Remove "uninit" and "freed".
* region-model.h (enum poison_kind): Remove POISON_KIND_UNINIT.

gcc/ChangeLog:
PR analyzer/94447
PR analyzer/94639
PR analyzer/94732
PR analyzer/94754
* doc/invoke.texi (Static Analyzer Options): Remove
-Wanalyzer-use-of-uninitialized-value.
(-Wno-analyzer-use-of-uninitialized-value): Remove item.

gcc/testsuite/ChangeLog:
PR analyzer/94447
PR analyzer/94639
PR analyzer/94732
PR analyzer/94754
* gcc.dg/analyzer/data-model-1.c: Mark "use of uninitialized
value" warnings as xfail for now.
* gcc.dg/analyzer/data-model-5b.c: Remove uninitialized warning.
* gcc.dg/analyzer/pr94099.c: Mark "uninitialized" warning as xfail
for now.
* gcc.dg/analyzer/pr94447.c: New test.
* gcc.dg/analyzer/pr94639.c: New test.
* gcc.dg/analyzer/pr94732.c: New test.
* gcc.dg/analyzer/pr94754.c: New test.
* gcc.dg/analyzer/zlib-6.c: Mark "uninitialized" warning as xfail
for now.

Fix missing gcc/ChangeLog entry from fa29cf0c3f19b648e30b16fd2485c3c17a528a6e

Check whether -fcf-protection=none -Wl,-z,ibt,-z,shstk work first

GCC_CET_HOST_FLAGS uses -Wl,-z,ibt,-z,shstk to check if Linux/x86 host
has Intel CET enabled by introducing an Intel CET violation on purpose.
To avoid false positive, check whether -Wl,-z,ibt,-z,shstk works first.
-fcf-protection=none is added to avoid false negative when -fcf-protection
is enabled by default.

config/

PR bootstrap/94739
* cet.m4 (GCC_CET_HOST_FLAGS): Add -fcf-protection=none to
-Wl,-z,ibt,-z,shstk.  Check whether -fcf-protection=none
-Wl,-z,ibt,-z,shstk works first.

libiberty/

PR bootstrap/94739
* configure: Regenerated.

lto-plugin/

PR bootstrap/94739
* configure: Regenerated.

tree: Fix up TREE_SIDE_EFFECTS on internal calls [PR94809]

On the following testcase, match.pd during GENERIC folding
changes the -1U / x < y into __imag__ .MUL_OVERFLOW (x, y),
but unfortunately unlike for normal calls nothing sets TREE_SIDE_EFFECTS on
the call.  There is the process_call_operands function that non-internal
call creation calls and it is usable for internal calls too,
e.g. TREE_SIDE_EFFECTS is derived from checking whether the
call has side-effects (non-ECF_{CONST,PURE}; we have those for internal
calls) and from whether any of the arguments has TREE_SIDE_EFFECTS.

2020-04-28  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/94809
* tree.c (build_call_expr_internal_loc_array): Call
process_call_operands.

* gcc.c-torture/execute/pr94809.c: New test.

aarch64: Add TX3 machine model

Here is the patch introducing thunderx3t110 machine model
for the scheduler. A name for the new chip was added to the
list of the names to be recognized as a valid parameter for
mcpu and mtune flags. Added the TX3 tuning table and cost
model tables.

Added the new chip name to the documentation. Fixed copyright
names and dates.

Lowering the chip capabilities to v8.3 to be on the safe side.

Bootstrapped on AArch64.

2020-04-27 Anton Youdkevitch <anton.youdkevitch@bell-sw.com>

        * config/aarch64/aarch64-cores.def: Add the chip name.
        * config/aarch64/aarch64-tune.md: Regenerated.
        * config/aarch64/aarch64.c: Add tuning table for the chip.
        * gcc/config/aarch64/aarch64-cost-tables.h: Add cost tables.
        * config/aarch64/thunderx3t110.md: New file: add the new
        machine model for the scheduler
        * config/aarch64/aarch64.md: Include the new model.
        * doc/invoke.texi: Add the new name to the list

s390: -Wpsabi diagnostics for C++14 vs. C++17 ABI incompatibility on s390{,x} [PR94704]

> We probably have to look into providing a -Wpsabi warning as well.

So like this?

2020-04-28  Jakub Jelinek  <jakub@redhat.com>

PR target/94704
* config/s390/s390.c (s390_function_arg_vector,
s390_function_arg_float): Emit -Wpsabi diagnostics if the ABI changed.

vect: Fix COND_EXPRs involving variant booleans [PR94727]

The previous patch for this PR handled separate comparisons.
However, as arm targets show, the same fix is needed when
handling comparisons embedded in a VEC_COND_EXPR.

Here too, the problem is that vect_get_constant_vectors will
calculate its own vector type, using truth_type_for on the
STMT_VINFO_VECTYPE, and the vectoriable_* routines need to be
consistent with that.

2020-04-28  Richard Sandiford  <richard.sandiford@arm.com>

gcc/
PR tree-optimization/94727
* tree-vect-stmts.c (vect_is_simple_cond): If both comparison
operands are invariant booleans, use the mask type associated with the
STMT_VINFO_VECTYPE.  Use !slp_node instead of !vectype to exclude SLP.
(vectorizable_condition): Pass vectype unconditionally to
vect_is_simple_cond.

coroutines: Pass class ref to traits lookup and promise allocator [PR94760].

We changed the argument passed to the promise parameter preview
to match a reference to *this.  However to be consistent with the
other ports, we do need to match the reference transformation in
the traits lookup and the promise allocator lookup.

gcc/cp/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

PR c++/94760
* coroutines.cc (instantiate_coro_traits): Pass a reference to
object type rather than a pointer type for 'this', for method
coroutines.
(struct param_info): Add a field to hold that the parm is a lambda
closure pointer.
(morph_fn_to_coro): Check for lambda closure pointers in the
args.  Use a reference to *this when building the args list for the
promise allocator lookup.

gcc/testsuite/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

PR c++/94760
* g++.dg/coroutines/pr94760-mismatched-traits-and-promise-prev.C:
New test.

coroutines: Fix handling of non-class coroutine returns [PR94759]

From the standard:

The header <coroutine> defines the primary template coroutine_traits
such that if ArgTypes is a parameter pack of types and if the
qualified-id R::promise_type is valid and denotes a type, then
coroutine_traits<R,ArgTypes...> has the following publicly accessible
member:
     using promise_type = typename R::promise_type;

this should not prevent more specialised cases and  the following
code should be accepted, but is currently rejected with:

'error: coroutine return type ‘void’ is not a class'

This is because the check for non-class-ness of the return value was
in the wrong place; it needs to be carried out in a SFINAE context.

The following patch removes the restriction in the traits template
instantiation and allows for the case that the ramp function could
return void.

The <coroutine> header is amended to implement the required
functionality.

gcc/cp/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

PR c++/94759
* coroutines.cc (coro_promise_type_found_p): Do not
exclude non-classes here (this needs to be handled in the
coroutine header).
(morph_fn_to_coro):  Allow for the case where the coroutine
returns void.

gcc/testsuite/ChangeLog:

2020-04-28  Iain Sandoe  <iain@sandoe.co.uk>

PR c++/94759
* g++.dg/coroutines/coro-bad-alloc-00-bad-op-new.C: Adjust for
updated error messages.
* g++.dg/coroutines/coro-bad-alloc-01-bad-op-del.C: Likewise.
* g++.dg/coroutines/coro-bad-alloc-02-no-op-new-nt.C: Likewise.
* g++.dg/coroutines/coro-missing-promise.C: Likewise.
* g++.dg/coroutines/pr93458-5-bad-coro-type.C: Liekwise.
* g++.dg/coroutines/torture/co-ret-17-void-ret-coro.C: New test.

libstdc++-v3/ChangeLog:

2020-04-28  Jonathan Wakely  <jwakely@redhat.com>
    Iain Sandoe  <iain@sandoe.co.uk>

PR c++/94759
* include/std/coroutine: Implement handing for non-
class coroutine return types.