The issue is that tree_is_indexable doesn't return the same result for
a FIELD_DECL with QUAL_UNION_TYPE and the QUAL_UNION_TYPE, resulting
in two instances of the QUAL_UNION_TYPE in the bytecode.  The result
for the type is the correct one (false, since it is variably modified)
while the result for the field is falsely true because:

  else if (TREE_CODE (t) == FIELD_DECL
           && lto_variably_modified_type_p (DECL_CONTEXT (t)))
    return false;

is not satisfied.  The reason for this is that the DECL_QUALIFIER of
fields of a QUAL_UNION_TYPE depends on a discriminant in Ada, which
means that the size of the type does too (CONTAINS_PLACEHOLDER_P),
which in turn means that it is reset to a mere PLACEHOLDER_EXPR by
free_lang_data, which finally means that the size of DECL_CONTEXT is
too, so RETURN_TRUE_IF_VAR is false.

In other words, the CONTAINS_PLACEHOLDER_P property of the DECL_QUALIFIER
of fields of a QUAL_UNION_TYPE hides the variably_modified_type_p property
of  these fields, if you look from the outside.

	PR middle-end/93961
	* tree.c (variably_modified_type_p) <RECORD_TYPE>: Recurse into
	fields whose type is a qualified union.

If the type is derived in the current compilation unit, and Allocate
is not overridden on derivation (as is typically the case with
Root_Storage_Pool_With_Subpools), the entity for Allocate of the
derived type is an alias for System.Storage_Pools.Subpools.Allocate.

The main assertion in gnat_to_gnu_entity fails in this case, since
this is not a definition and Is_Public is false (since the entity
is nested in the same compilation unit).

2020-03-11  Richard Wai  <richard@annexi-strayline.com>

	* gcc-interface/decl.c (gnat_to_gnu_entity): Also test Is_Public on
	the Alias of the entitiy, if is present, in the main assertion.

abs_hwi asserts that the argument is not HOST_WIDE_INT_MIN and as the
(invalid) testcase shows, the function can be called with such an offset.
The following patch is IMHO minimal fix, absu_hwi unlike abs_hwi allows even
that value and will return (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN
in that case.  The function then uses moffset in two spots which wouldn't
care if the value is (unsigned HOST_WIDE_INT) HOST_WIDE_INT_MIN or
HOST_WIDE_INT_MIN and wouldn't accept it (!moffset and
aarch64_uimm12_shift (moffset)), then in one spot where the signedness of
moffset does matter and using unsigned is the right thing -
moffset < 0x1000000 - and finally has code which will handle even this
value right; the assembler doesn't really care for DImode immediates if
        mov     x1, -9223372036854775808
or
        mov     x1, 9223372036854775808
is used and similarly it doesn't matter if we add or sub it in DImode.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR target/94121
	* config/aarch64/aarch64.c (aarch64_add_offset_1): Use absu_hwi
	instead of abs_hwi, change moffset type to unsigned HOST_WIDE_INT.

	* gcc.dg/pr94121.c: New test.

Jeff has recently fixed dump_histogram_value to use std::abs instead of abs,
because on FreeBSD apparently the ::abs isn't overloaded and only has
int abs (int);
Seems on Solaris /usr/include/iso/stdlib_iso.h abs has:
int abs (int);
long abs (long);
overloads but already not
long long abs (long long);
and there is another abs use in get_nth_most_common_value, also on int64_t.
The long long std::abs (long long); overload is there only in C++11 and we
in GCC10 still support C++98.

Martin has said that a counter should never be INT64_MIN, so IMHO it is
better to use abs_hwi which will assert that.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR bootstrap/93962
	* value-prof.c (dump_histogram_value): Use abs_hwi instead of
	std::abs.
	(get_nth_most_common_value): Use abs_hwi instead of abs.

As e.g. decimal_from_decnumber shows, the REAL_VALUE_TYPE representation
contains a decimal128 embedded in ->sig only if it is rvc_normal, for
other kinds like rvc_inf or rvc_nan, ->sig is ignored and everything is
contained in the REAL_VALUE_TYPE flags (cl, sign, signalling and decimal).
decimal_to_binary which is used when folding a decimal{32,64,128} constant
to a binary floating point type ignores this and thus folds infinities and
NaNs into +0.0.
The following patch fixes that by only doing that for rvc_normal.
Similarly to the binary to decimal folding, it goes through a string, in
order to e.g. deal with canonical NaN mantissas, or binary float formats
that don't support infinities and/or NaNs.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/94111
	* dfp.c (decimal_to_binary): Only use decimal128ToString if from->cl
	is rvc_normal, otherwise use real_to_decimal to print the number to
	string.

	* gcc.dg/dfp/pr94111.c: New test.

As the testcase shows, arithmetics that for -ftrapv would need multiple
basic blocks can show up not just in nb_bytes expressions where we
are calling rewrite_to_non_trapping_overflow for a while already,
but also in the pointer expression to the start of the region.
While the testcase covers just the first hunk and I've failed to create
a testcase for the latter, it is at least in theory possible too, so I've
adjusted that hunk too.

2020-03-11  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/94114
	* tree-loop-distribution.c (generate_memset_builtin): Call
	rewrite_to_non_trapping_overflow even on mem.
	(generate_memcpy_builtin): Call rewrite_to_non_trapping_overflow even
	on dest and src.

	* gcc.dg/pr94114.c: New test.

... a call to ranges::begin on an input range.

This implements LWG 3286.  The new wording for the single-argument constructor
for subrange is implemented by splitting the constructor into two delegating
constructors, one constrained by _S_store_size and the other by !_S_store_size.

Tested on x86_64-pc-linux-gnu, both added tests fail before the patch and pass
with the patch.

libstdc++-v3/ChangeLog:

	LWG 3286 ranges::size is not required to be valid after a call to
	ranges::begin on an input range
	* include/std/ranges (subrange::subrange): Split single-argument
	constructor into two, one constrained by _S_store_size and another by
	!_S_store_size.
	(take_view::begin): Call size() before calling ranges::begin(_M_base).
	* testsuite/std/ranges/adaptors/lwg3286.cc: New test.
	* testsuite/std/ranges/subrange/lwg3286.cc: New test.

Fix length computation for movsi_insv which resulted in regressions due to out of range branches on the bfin port.

	* config/bfin/bfin.md (movsi_insv): Add length attribute.

This is a bad interaction between sharing a constructor for an array
and stripping its trailing zero-initializers.  Here we reuse a ctor
and then strip its 0s.  This breaks overload resolution in this test:
D can be initialized from {} but not from {0}, so if we truncate the
constructor not to include the zero, the F(D) overload becomes valid
and then we get the ambiguous conversion error.

	PR c++/94124 - wrong conversion error with non-viable overload.
	* decl.c (reshape_init_array_1): Unshare a constructor if we
	stripped trailing zero-initializers.

	* g++.dg/cpp0x/initlist-overload1.C: New test.

My change in r10-4394 to only update clones when we actually instantiate a
deferred noexcept-spec broke this because deferred parsing updates the
primary function but not the clones.  For GCC 10, let's just revert it.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  <jason@redhat.com>

	PR c++/93901
	* pt.c (maybe_instantiate_noexcept): Always update clones.

reshape_init only wants to work on BRACE_ENCLOSED_INITIALIZER_P, i.e. raw
initializer lists, and here was getting a CONSTRUCTOR that had already been
processed for type A<int>.  maybe_aggr_guide should also use that test.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  <jason@redhat.com>

	PR c++/93956
	* pt.c (maybe_aggr_guide): Check BRACE_ENCLOSED_INITIALIZER_P.

PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
relates to max of '-inf' and 'nan'. This regression occur on P9 because
P9 new instruction 'xsmaxcdp' is generated. 
And for C code `a < b ? b : a` is also generated as `xsmaxcdp` under -O2
for P9. While this instruction behavior more like C/C++ semantic (a>b?a:b).

This generates prevents 'xsmaxcdp' to be generated for those cases.
'xsmincdp' also is handled in patch.

gcc/
2020-03-10  Jiufu Guo  <guojiufu@linux.ibm.com>

	PR target/93709
	* gcc/config/rs6000/rs6000.c (rs6000_emit_p9_fp_minmax): Check
	NAN and SIGNED_ZEROR for smax/smin.

gcc/testsuite
2020-03-10  Jiufu Guo  <guojiufu@linux.ibm.com>

	PR target/93709
	* gcc.target/powerpc/p9-minmax-3.c: New test.

These direct uses of _M_current should all be __current() so they are
valid when the base type doesn't satisfy the forward_range concept.

	* include/std/ranges (split_view::_OuterIter::__at_end): Use __current
	instead of _M_current.
	(split_view::_OuterIter::operator++): Likewise.

The patch for 66139 exposed a long-standing bug with
split_nonconstant_init (since 4.7, apparently): initializion of individual
elements of an aggregate are not a full-expressions, but
split_nonconstant_init was making full-expressions out of them.  My fix for
66139 extended the use of split_nonconstant_init, and thus the bug, to
aggregate initialization of temporaries within an expression, in which
context (PR94041) the bug is more noticeable.  PR93922 is a problem with my
implementation strategy of splitting out at gimplification time, introducing
function calls that weren't in the GENERIC.  So I'm going to revert the
patch now and try again for GCC 11.

gcc/cp/ChangeLog
2020-03-10  Jason Merrill  <jason@redhat.com>

	PR c++/93922
	PR c++/94041
	PR c++/52320
	PR c++/66139
	* cp-gimplify.c (cp_gimplify_init_expr): Partially revert patch for
	66139: Don't split_nonconstant_init.  Remove pre_p parameter.

PR target/90763
	* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
	clause to handle P9V_BUILTIN_VEC_LXVL with const arguments.

	* gcc.target/powerpc/pr90763.c: New.

Also introduce the _M_i_current() accessors to solve the problem of
access to the private member of _OuterIter from the iter_move and
iter_swap overloads (which are only friends of _InnerIter not
_OuterIter).

	* include/std/ranges (transform_view::_Iterator::__iter_move): Remove.
	(transform_view::_Iterator::operator*): Add noexcept-specifier.
	(transform_view::_Iterator::iter_move): Inline __iter_move body here.
	(split_view::_OuterIter::__current): Add noexcept.
	(split_view::_InnerIter::__iter_swap): Remove.
	(split_view::_InnerIter::__iter_move): Remove.
	(split_view::_InnerIter::_M_i_current): New accessors.
	(split_view::_InnerIter::__at_end): Use _M_i_current().
	(split_view::_InnerIter::operator*): Likewise.
	(split_view::_InnerIter::operator++): Likewise.
	(iter_move(const _InnerIter&)): Likewise.
	(iter_swap(const _InnerIter&, const _InnerIter&)): Likewise.
	* testsuite/std/ranges/adaptors/split.cc: Check noexcept-specifier
	for iter_move and iter_swap on split_view's inner iterator.

Function 'find_simple_exit' is used only from loop-iv.c
In 2004-2006 it was also used in predict.c, but since r118694
(992c31e6) it does not.

gcc/ChangeLog:
	* loop-iv.c (find_simple_exit): Make it static.
	* cfgloop.h: Remove the corresponding prototype.

gcc/ChangeLog:
	* ddg.c (create_ddg): Fix intendation.
	(set_recurrence_length): Likewise.
	(create_ddg_all_sccs): Likewise.

The function needs more than 8 SSE registers, avoid
false positives triggered by SSE spills for 32bit targets.

	* g++.dg/pr80481.C (dg-final): Scan for SSE reg-reg moves only.

This reverts commit d48e1175.

2020-03-10  Jeff Law  <law@redhat.com>

	Revert:
	2020-02-29  Jeff Law  <law@redhat.com>

	* gcc.target/xstormy16/sfr/06_sfrw_to_var.c: Update expected output.

G++ fails to diagnose this non-dependent expression, but Clang doesn't
like it.

	PR c++/94117
	* include/std/ranges (ranges::transform_view::_Iterator::iter_move):
	Change expression in noexcept-specifier to match function body.

The 24_iterators/ostream_iterator/1.cc test uses VERIFY and so is
obviously meant to have been run, not just compiled.

	* testsuite/23_containers/unordered_set/allocator/ext_ptr.cc: Add
	comment explaining multiple dg-do directives.
	* testsuite/24_iterators/ostream_iterator/1.cc: Fix do-do directive
	so test is run as well as compiled.

In r10-1938-g460bf043 *testdi_1 has been
changed, so that if the mask has upper 32-bits 0 and then at least one bit
set, it requires CCZmode rather than CCNOmode, because in that case it uses
testl instruction rather than testq and so the SF flag wouldn't respect the
state of the 64-bit result.
The *testqi_ext_3 define_insn_and_split needs to match that though,
otherwise it can create an RTL pattern that used to match *testdi_1 but
doesn't anymore and we'd ICE due to an unrecognizable insn.

2020-03-10  Jakub Jelinek  <jakub@redhat.com>

	PR target/94088
	* config/i386/i386.md (*testqi_ext_3): Call ix86_match_ccmode with
	CCZmode instead of CCNOmode if operands[2] has DImode and pos + len
	is 32.

	* gcc.target/i386/pr94088.c: New test.

	* sv.po: Update.

gcc/ChangeLog
2020-03-09  Jason Merrill  <jason@redhat.com>

	* gdbinit.in (pgs): Fix typo in documentation.

	* da.po: Update.

The point of this patch is to fix the recurring problem of trees
generated by convert_like while processing a template that break when
substituting.  For instance, when convert_like creates a CALL_EXPR
while in a template, substituting such a call breaks in finish_call_expr
because we have two 'this' arguments.  Another problem is that we
can create &TARGET_EXPR<> and then fail when substituting because we're
taking the address of an rvalue.  I've analyzed some of the already fixed
PRs and also some of the currently open ones:

In c++/93870 we create EnumWrapper<E>::operator E(&operator~(E)).
In c++/87145 we create S::operator int (&{N}).
In c++/92031 we create &TARGET_EXPR <0>.

The gist of the problem is when convert_like_real creates a call for
a ck_user or wraps a TARGET_EXPR in & in a template.  So in these cases
use IMPLICIT_CONV_EXPR.  In a template we shouldn't need to perform the
actual conversion, we only need it's result type.
perform_direct_initialization_if_possible and
perform_implicit_conversion_flags can also create an IMPLICIT_CONV_EXPR.

Given the change above, build_converted_constant_expr can return an
IMPLICIT_CONV_EXPR so call fold_non_dependent_expr rather than
maybe_constant_value to deal with that.

To avoid the problem of instantiating something twice in a row I'm
removing a call to instantiate_non_dependent_expr_sfinae in
compute_array_index_type_loc.  And the build_converted_constant_expr
pattern can now be simplified.

2020-03-09  Marek Polacek  <polacek@redhat.com>

	PR c++/92031 - bogus taking address of rvalue error.
	PR c++/91465 - ICE with template codes in check_narrowing.
	PR c++/93870 - wrong error when converting template non-type arg.
	PR c++/94068 - ICE with template codes in check_narrowing.
	* call.c (convert_like_real): Return IMPLICIT_CONV_EXPR
	in a template when not ck_identity and we're dealing with a class.
	(convert_like_real) <case ck_ref_bind>: Return IMPLICIT_CONV_EXPR
	in a template if we need a temporary.
	* decl.c (compute_array_index_type_loc): Remove
	instantiate_non_dependent_expr_sfinae call.  Call
	fold_non_dependent_expr instead of maybe_constant_value.
	(build_explicit_specifier): Don't instantiate or create a sentinel
	before converting the expression.
	* except.c (build_noexcept_spec): Likewise.
	* pt.c (convert_nontype_argument): Don't build IMPLICIT_CONV_EXPR.
	Set IMPLICIT_CONV_EXPR_NONTYPE_ARG if that's what
	build_converted_constant_expr returned.
	* typeck2.c (check_narrowing): Call fold_non_dependent_expr instead
	of maybe_constant_value.

	* g++.dg/cpp0x/conv-tmpl2.C: New test.
	* g++.dg/cpp0x/conv-tmpl3.C: New test.
	* g++.dg/cpp0x/conv-tmpl4.C: New test.
	* g++.dg/cpp0x/conv-tmpl5.C: New test.
	* g++.dg/cpp0x/conv-tmpl6.C: New test.
	* g++.dg/cpp1z/conv-tmpl1.C: New test.

The filesystem::path::operator+= and filesystem::path::concat functions
operate directly on the native format of the path and so can cause a
path to mutate to a completely different type.

For Windows combining a filename "x" with a filename ":" produces a
root-name "x:". Similarly, a Cygwin root-directory "/" combined with a
root-directory and filename "/x" produces a root-name "//x".

Before this patch the implemenation didn't support those kind of
mutations, assuming that concatenating two filenames would always
produce a filename and concatenating with a root-dir would still have a
root-dir.

This patch fixes it simply by checking for the problem cases and
creating a new path by re-parsing the result of the string
concatenation. This is slightly suboptimal because the argument has
already been parsed if it's a path, but more importantly it doesn't
reuse any excess capacity that the path object being modified might
already have allocated. That can be fixed later though.

	PR libstdc++/94063
	* src/c++17/fs_path.cc (path::operator+=(const path&)): Add kluge to
	handle concatenations that change the type of the first component.
	(path::operator+=(basic_string_view<value_type>)): Likewise.
	* testsuite/27_io/filesystem/path/concat/94063.cc: New test.

Since r10-6527-gaaa26bf4 fold_for_warn
will perform maybe_constant_value even on some cp_fold produced trees and
so can include rotate exprs which were removed last fall from constexpr.c

2020-03-09  Jakub Jelinek  <jakub@redhat.com>

	PR c++/94067
	Revert
	2019-10-11  Paolo Carlini  <paolo.carlini@oracle.com>

	* constexpr.c (cxx_eval_constant_expression): Do not handle
	RROTATE_EXPR and LROTATE_EXPR.

	* g++.dg/warn/Wconversion-pr94067.C: New test.

2020-03-09  Vladimir Makarov  <vmakarov@redhat.com>

	Revert:

	2020-02-28  Vladimir Makarov  <vmakarov@redhat.com>

	PR rtl-optimization/93564
	* ira-color.c (assign_hard_reg): Prefer smaller hard regno when we
	do not honor reg alloc order.

The problem here is there was a typo in the documentation
for the 'A' modifier in the table, it was recorded as 'a'
in the table on the modifier column.

Committed as obvious.

2020-03-09  Andrew Pinski  <apinski@marvell.com>

	PR inline-asm/94095
	* doc/extend.texi (x86 Operand Modifiers): Fix column
	for 'A' modifier.

gcc/ChangeLog

2020-03-09  Carl Love  <cel@us.ibm.com>

	* config/rs6000/rs6000.opt: Update the description of the
	command line option.

        * configure.ac: Build libgomp by default for amdgcn.
        * configure: Regenerate.

The static_assert in the following test was failing on armv7hl because
we were disregarding the alignas specifier on Cell.  BaseShape's data
takes up 20B on 32-bit architectures, but we failed to round up its
TYPE_SIZE.  This happens since the
<https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01189.html>
patch: here, in layout_class_type for TenuredCell, we see that the size
of TenuredCell and its CLASSTYPE_AS_BASE match, so we set

  CLASSTYPE_AS_BASE (t) = t;

While TYPE_USER_ALIGN of TenuredCell was 0, because finalize_type_size
called from finish_record_layout reset it, TYPE_USER_ALIGN of its
CLASSTYPE_AS_BASE still remained 1.  After we replace it, it's no longer
1.  Then we perform layout_empty_base_or_field for TenuredCell and since
TYPE_USER_ALIGN of its CLASSTYPE_AS_BASE is now 0, we don't do this
adjustment:

  if (CLASSTYPE_USER_ALIGN (type))
    {
      rli->record_align = MAX (rli->record_align, CLASSTYPE_ALIGN (type));
      if (warn_packed)
        rli->unpacked_align = MAX (rli->unpacked_align, CLASSTYPE_ALIGN (type));
      TYPE_USER_ALIGN (rli->t) = 1;
    }

where rli->t is BaseShape.  Then finalize_record_size won't use the
correct rli->record_align and therefore
  /* Round the size up to be a multiple of the required alignment.  */
  TYPE_SIZE (rli->t) = round_up (unpadded_size, TYPE_ALIGN (rli->t));
after this we end up with the wrong size.

Since the original fix was to avoid creating extra copies for LTO
purposes, I think the following fix should be acceptable.

	PR c++/94050 - ABI issue with alignas on armv7hl.
	* class.c (layout_class_type): Don't replace a class's
	CLASSTYPE_AS_BASE if their TYPE_USER_ALIGN don't match.

	* g++.dg/abi/align3.C: New test.

2020-03-09  Christophe Lyon  <christophe.lyon@linaro.org>

	* gcc.target/arm/fuse-caller-save.c: Fix DejaGnu typo.

	PR target/93800
	* config/rs6000/rs6000.c (rs6000_option_override_internal):
	Remove set of str_align_loops and str_align_jumps as these
	should be set in previous 2 conditions in the function.
	PR target/93800
	* gcc.target/powerpc/pr93800.c: New test.

As mentioned in the PR, on a largish C++ testcase the compile time
on i686-linux is about 16 minutes on a fast box, mostly spent in
find_base_term recursive calls dealing with very deep chains of preserved
VALUEs during var-tracking.

The following patch punts after we process many VALUEs (we already have code
to punt if we run into a VALUE cycle).

I've gathered statistics on when we punt this way (with BITS_PER_WORD, TU,
function columns piped through sort | uniq -c | sort -n):
     36 32 ../../gcc/asan.c _Z29initialize_sanitizer_builtinsv.part.0
    108 32 _first_test.go reflect_test.reflect_test..import
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr85180.c foo
   1005 64 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr87985.c foo
   2534 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/stack-check-9.c f3
   6346 32 ../../gcc/brig/brig-lang.c brig_define_builtins
   6398 32 ../../gcc/d/d-builtins.cc d_define_builtins
   8816 32 ../../gcc/c-family/c-common.c c_common_nodes_and_builtins
   8824 32 ../../gcc/lto/lto-lang.c lto_define_builtins
  41413 32 /home/jakub/src/gcc/gcc/testsuite/gcc.dg/pr43058.c test
Additionally, for most of these (for the builtins definitions tested just
one) I've verified with a different alias.c change which didn't punt but
in the toplevel find_base_term recorded if visited_vals reached the limit
whether the return value was NULL_RTX or something different, and in all
these cases the end result was NULL_RTX, so at least in these cases it
should just shorten the time until it returns NULL.

2020-03-09  Jakub Jelinek  <jakub@redhat.com>

	PR rtl-optimization/94045
	* params.opt (-param=max-find-base-term-values=): New option.
	* alias.c (find_base_term): Add cut-off for number of visited VALUEs
	in a single toplevel find_base_term call.