This PR reports that ever since the introduction of the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag, we are sometimes failing to resolve
PLACEHOLDER_EXPRs inside array initializers that refer to some inner
constructor.  In the testcase in the PR, we have as the initializer for "S c[];"
the following

  {{.a=(int &) &_ZGR1c_, .b={*(&<PLACEHOLDER_EXPR struct S>)->a}}}

where CONSTRUCTOR_PLACEHOLDER_BOUNDARY is set on the middle constructor.  When
calling replace_placeholders from store_init_value, we pass the entire
initializer to it, and as a result we fail to resolve the PLACEHOLDER_EXPR
within due to the CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag on the middle
constructor blocking replace_placeholders_r from reaching it.

To fix this, we could perhaps either call replace_placeholders in more places,
or we could change where we set CONSTRUCTOR_PLACEHOLDER_BOUNDARY.  This patch
takes this latter approach -- when building up an array initializer, we now
bubble any CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from the element initializers
up to the array initializer so that the boundary doesn't later impede us when we
call replace_placeholders from store_init_value.

Besides fixing the kind of code like in the testcase, this shouldn't cause any
other differences in PLACEHOLDER_EXPR resolution because we don't create or use
PLACEHOLDER_EXPRs of array type in the frontend, as far as I can tell.

gcc/cp/ChangeLog:

	PR c++/90996
	* tree.c (replace_placeholders): Look through all handled components,
	not just COMPONENT_REFs.
	* typeck2.c (process_init_constructor_array): Propagate
	CONSTRUCTOR_PLACEHOLDER_BOUNDARY up from each element initializer to
	the array initializer.

gcc/testsuite/ChangeLog:

	PR c++/90996
	* g++.dg/cpp1y/pr90996.C: New test.

The following testcases are miscompiled, because expand_vec_perm_pshufb
incorrectly thinks it can use vpshufb instruction for the permutations
when it can't.
The
          if (vmode == V32QImode)
            {
              /* vpshufb only works intra lanes, it is not
                 possible to shuffle bytes in between the lanes.  */
              for (i = 0; i < nelt; ++i)
                if ((d->perm[i] ^ i) & (nelt / 2))
                  return false;
            }
intra-lane check which is correct has been copied and adjusted for 64-byte
modes into:
          if (vmode == V64QImode)
            {
              /* vpshufb only works intra lanes, it is not
                 possible to shuffle bytes in between the lanes.  */
              for (i = 0; i < nelt; ++i)
                if ((d->perm[i] ^ i) & (nelt / 4))
                  return false;
            }
which is not correct, because 64-byte modes have 4 lanes rather than just
two and the above is only testing that the permutation grabs even lane elts
from even lanes and odd lane elts from odd lanes, but not that they are
from the same 256-bit half.

The following patch fixes it by using 3 * nelt / 4 instead of nelt / 4,
so we actually check the most significant 2 bits rather than just one.

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

	PR target/94509
	* config/i386/i386-expand.c (expand_vec_perm_pshufb): Fix the check
	for inter-lane permutation for 64-byte modes.

	* gcc.target/i386/avx512bw-pr94509-1.c: New test.
	* gcc.target/i386/avx512bw-pr94509-2.c: New test.

We need to set OMP_PARALLEL_COMBINED only if the parsing of omp_master
succeeded, because otherwise there is no nested master construct in the
parallel.

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

	PR c++/94512
	* c-parser.c (c_parser_omp_parallel): Set OMP_PARALLEL_COMBINED
	if c_parser_omp_master succeeded.

	* parser.c (cp_parser_omp_parallel): Set OMP_PARALLEL_COMBINED
	if cp_parser_omp_master succeeded.

	* g++.dg/gomp/pr94512.C: New test.

The following testcase ICEs on aarch64 apparently since the introduction of
the aarch64 port.  The reason is that the {ashl,ashr,lshr}<mode>3 expanders
completely unnecessarily FAIL; if operands[2] is something other than
a CONST_INT or REG or MEM and the middle-end code can't cope with the
pattern giving up in these cases.  All the expanders use general_operand
predicate for the shift amount operand, but then have just a special case
for CONST_INT (if in-bound, emit an immediate shift, otherwise force into
REG), or MEM (force into REG), or REG (that is the case it handles).
In the testcase, operands[2] is a lowpart SUBREG of a REG, which is valid
general_operand.
I don't see any reason what is magic about MEMs that it should be forced
into REG and others like SUBREGs that it shouldn't, there isn't even a
reason to check for !REG_P because force_reg will do nothing if the operand
is already a REG, and otherwise can handle general_operand just fine.

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

	PR target/94488
	* config/aarch64/aarch64-simd.md (ashl<mode>3, lshr<mode>3,
	ashr<mode>3): Force operands[2] into reg whenever it is not CONST_INT.
	Assume it is a REG after that instead of testing it and doing FAIL
	otherwise.  Formatting fix.

	* gcc.c-torture/compile/pr94488.c: New test.

gcc/d/ChangeLog:

	PR d/94425
	* toir.cc (IRVisitor::visit (GccAsmStatement *)): Set ASM_VOLATILE_P
	on all asm statements.

The support for the 32-bit float GPRs was removed in GCC 8.

gcc/

	* config/rs6000/t-rtems: Delete mcpu=8540 multilib.

The following testcase is miscompiled in 8.x, because emit_reduc_half is
prepared to handle for 512-bit modes only i equal to 512, 256, 128 and 64.
V32HImode also needs i equal to 32 and V64QImode i equal to 32 and 16,
but emit_reduc_half in that case performs a redundant permutation exactly
like i == 32.  In 9+ the testcase works because Richard in r9-3393
changed the reduc_* expanders so that they actually don't call
ix86_expand_reduc on 512-bit modes, but only 128-bit ones.

The patch fixes emit_reduc_half to handle also i of 32 and 16 similarly to
how V32QImode/V16HImode are handled for AVX2.  I think it shouldn't hurt
to fix the function even on the trunk and 9 branch even when nothing uses
it ATM.

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

	PR target/94500
	* config/i386/i386-expand.c (emit_reduc_half): For V{64QI,32HI}mode
	handle i < 64 using avx512bw_lshrv4ti3.  Formatting fixes.

	* gcc.target/i386/avx512bw-pr94500.c: New test.

duplicate_decls assumed that any TREE_ARTIFICIAL function at namespace scope
was a built-in function, but now in C++20 it's possible to have an
implicitly declared hidden friend operator==.  We just need to move the
assert into the if condition.

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

	PR c++/94462
	* decl.c (duplicate_decls): Fix handling of DECL_HIDDEN_FRIEND_P.

Update to edea4a79e8d7dea2456b688f492c8af33d381dc2 which is likely to
be approximately the 1.14.2 release.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/227377

Fix a problem with commit c8e759b4 ("libgomp/test: Fix compilation
for build sysroot") that caused a regression in some standalone test
environments where testsuite/libgomp-test-support.exp is used, but the
compiler is expected to be determined by `[find_gcc]', and set the
GCC_UNDER_TEST TCL variable in testsuite/libgomp-site-extra.exp instead.

	libgomp/
	* configure.ac: Add testsuite/libgomp-site-extra.exp to output
	files.
	* configure: Regenerate.
	* testsuite/libgomp-site-extra.exp.in: New file.
	* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Remove
	variable.
	* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
	variable.
	* testsuite/Makefile.in: Regenerate.

Fix a problem with the libatomic testsuite using a method to determine
the compiler to use resulting in the tool being different from one the
library has been built with, and causing a catastrophic failure from the
lack of a suitable `--sysroot=' option where the `--with-build-sysroot='
configuration option has been used to build the compiler resulting in
the inability to link executables.

Address this problem by providing a DejaGNU configuration file defining
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC
by autoconf, which will have all the required options set for the target
compiler to build executables in the environment configured, removing
failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors)
Excess errors:
.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm

UNRESOLVED: libatomic.c/atomic-compare-exchange-1.c compilation failed to produce executable

and bringing overall test results for the `riscv64-linux-gnu' target
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user
emulation mode as the target board) from:

		=== libatomic Summary ===

# of unexpected failures	27
# of unresolved testcases	27

to:

		=== libatomic Summary ===

# of expected passes		54

	libatomic/
	* configure.ac: Add testsuite/libatomic-site-extra.exp to output
	files.
	* configure: Regenerate.
	* libatomic/testsuite/libatomic-site-extra.exp.in: New file.
	* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
	variable.
	* testsuite/Makefile.in: Regenerate.

getopt.c hangs the compiler on h8300-elf with -O2 -g, because the
IL contains addition of constant 0, the first PLUS operand is determined
to have the SP_DERIVED_VALUE_P and the new code in cselib recurses
indefinitely on seeing SP_DERIVED_VALUE_P with locs of
(plus:P SP_DERIVED_VALUE_P (const_int 0)).

Fixed by making sure cselib_subst_to_values canonicalizes it, hashing
already hashes it the same too.

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

	* cselib.c (cselib_subst_to_values): For SP_DERIVED_VALUE_P
	+ const0_rtx return the SP_DERIVED_VALUE_P.

	* sv.po: Update.

	* eo.po: Update.

gcc/fortran/ChangeLog:

2020-04-06  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/93686
	* decl.c (gfc_match_data): Handle data matching for derived type
	pointers.

gcc/testsuite/ChangeLog:

2020-04-06  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/93686
	* gfortran.dg/pr93686_1.f90: New test.
	* gfortran.dg/pr93686_2.f90: Likewise.
	* gfortran.dg/pr93686_3.f90: Likewise.
	* gfortran.dg/pr93686_4.f90: Likewise.

This test verifies, by using a weak reference to _Unwind_RaiseException,
that performing division by zero does not cause that symbol to get
indirectly pulled into our closure.

The testing methodology unfortunately does not work on VxWorks targets
when building in kernel mode. This is inherent to how kernel mode
on VxWorks works: The link is only partial and the remaining symbols
which have not been resolved already get automatically resolved by
the VxWorks loader at the moment the module is loaded onto the target,
prior to execution. The resolution includes weak symbols too, which
defeats the purpose of this test.

gcc/testsuite/

        * gcc.target/arm/div64-unwinding.c: Skip on vxworks_kernel targets.

lra_assign has an assert to make sure that no pseudo is allocated
to a conflicting hard register.  It used to be restricted to
!flag_ipa_ra, but in g:a1e6ee38 I'd enabled it for
flag_ipa_ra too.  It then tripped a few times while building
libstdc++ for mips-mti-linux.

Previous patches fixed one of the problems: registers clobbered
by the taking of an exception were being treated as live at the
beginning of the EH receiver, and this got propagated to predecessor
blocks.  But it turns out that there was a second problem: eh_return
data registers were also being marked live in the same way.

These registers are defined by the unwinder and so in reality they
are live on entry to the EH receiver.  But definitions can only happen
in blocks, not on edges, so for liveness purposes we use artificial
definitions at the start of the EH receiver.  process_bb_lives should
therefore model the effect of a definition, not a plain use.

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

gcc/
	PR rtl-optimization/92989
	* lra-lives.c (process_bb_lives): Do not treat eh_return data
	registers as being live at the beginning of the EH receiver.

	PR libstdc++/94498
	* include/bits/char_traits.h (__gnu_cxx::char_traits::move): Make it
	usable in constant expressions for C++20.
	(__gnu_cxx::char_traits::copy, __gnu_cxx::char_traits::assign): Add
	_GLIBCXX20_CONSTEXPR.
	(std::char_traits<char>, std::char_traits<wchar_t>)
	(std::char_traits<char8_t>): Make move, copy and assign usable in
	constant expressions for C++20.
	(std::char_traits<char16_t>, std::char_traits<char32_t>): Make move
	and copy usable in constant expressions for C++20.
	* include/std/string_view (basic_string_view::copy): Add
	_GLIBCXX20_CONSTEXPR.
	* testsuite/21_strings/basic_string_view/operations/copy/char/
	constexpr.cc: New test.
	* testsuite/21_strings/basic_string_view/operations/copy/wchar_t/
	constexpr.cc: New test.

Here we crash in the gimplifier because gimplify_init_ctor_eval doesn't
expect null indexes for a constructor:

      /* ??? Here's to hoping the front end fills in all of the indices,
         so we don't have to figure out what's missing ourselves.  */
      gcc_assert (purpose);

The indexes weren't filled because we never called reshape_init: for
a constructor that represents parenthesized initialization of an
aggregate we don't allow brace elision or designated initializers.

	PR c++/94155 - crash in gimplifier with paren init of aggregates.
	* init.c (build_vec_init): Fill in indexes.

	* g++.dg/cpp2a/paren-init22.C: New test.

	* doc/xml/manual/appendix_contributing.xml: Refer to Git
	documentation instead of Subversion.  Switch to https.
	* doc/html/manual/appendix_contributing.html: Regenerate.

Try to keep tests order by distinct number (and with a short
descriptive name appended).

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

	* g++.dg/coroutines/torture/co-await-14-template-traits.C: Rename...
	* g++.dg/coroutines/torture/co-await-16-template-traits.C: to this.
	* g++.dg/coroutines/torture/co-await-15-capture-comp-ref.C: Rename..
	* g++.dg/coroutines/torture/co-await-17-capture-comp-ref.C: to this.

	* extend.texi: Add free to list of ISO C90 functions that
	are recognized by the compiler.

Microblaze: Fixed missing save of r18 in fast_interrupt. Register 18 is used as a clobber register, and must be stored when entering a fast_interrupt. Before this fix, register 18 was only saved if it was used directly in the interrupt function.

    However, if the fast_interrupt function called a function that used
    r18, the register would not be saved, and thus be mangled
    upon returning from the interrupt.

	* config/microblaze/microblaze.c (microblaze_must_save_register): Check
	for fast_interrupt.

Microblaze: Modified trap instruction There is a bug in trap instruction generation. Instead of "bri 0" instruction "brki r0, -1" was used, corrected it now.

        * gcc/config/microblaze/microblaze.md (trap): Update output pattern.

        * gcc.target/microblaze/others/builtin-trap.c: Update expected output.

On the following testcase, in gdb ptype S<long>::m1 prints long as return
type, but all the other methods show void instead.
PR53756 added code to add_type_attribute if the return type is
auto/decltype(auto), but we actually should look through references,
pointers and qualifiers.
Haven't included there DW_TAG_atomic_type, because I think at least ATM
one can't use that in C++.  Not sure about DW_TAG_array_type or what else
could be deduced.

> http://eel.is/c++draft/dcl.spec.auto#3 says it has to appear as a
> decl-specifier.
>
> http://eel.is/c++draft/temp.deduct.type#8 lists the forms where a template
> argument can be deduced.
>
> Looks like you are missing arrays, pointers to members, and function return
> types.

2020-04-04  Hannes Domani  <ssbssa@yahoo.de>
	    Jakub Jelinek  <jakub@redhat.com>

	PR debug/94459
	* dwarf2out.c (gen_subprogram_die): Look through references, pointers,
	arrays, pointer-to-members, function types and qualifiers when
	checking if in-class DIE had an 'auto' or 'decltype(auto)' return type
	to emit type again on definition.

	* g++.dg/debug/pr94459.C: New test.

Co-Authored-By: Hannes Domani <ssbssa@yahoo.de>

	* generic-morestack.c: Only use __mmap on glibc >= 2.26.

We skip over other conversion codes when mangling expressions, we should do
the same with IMPLICIT_CONV_EXPR.

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

	PR c++/91377
	* mangle.c (write_expression): Skip IMPLICIT_CONV_EXPR.

This removes the use of replace_placeholders in cxx_eval_constant_expression
(which is causing the new test lambda-this6.C to ICE due to replace_placeholders
mutating the shared TARGET_EXPR_INITIAL tree which then trips up the
gimplifier).

In its place, this patch adds a 'parent' field to constexpr_ctx which is used to
store a pointer to an outer constexpr_ctx that refers to another object under
construction.  With this new field, we can beef up lookup_placeholder to resolve
PLACEHOLDER_EXPRs which refer to former objects under construction, which fixes
PR94205 without needing to do replace_placeholders.  Also we can now respect the
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag when resolving PLACEHOLDER_EXPRs, and
doing so fixes the constexpr analogue of PR79937.

gcc/cp/ChangeLog:

	PR c++/94205
	PR c++/79937
	* constexpr.c (struct constexpr_ctx): New field 'parent'.
	(cxx_eval_bare_aggregate): Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY
	flag from the original constructor to the reduced constructor.
	(lookup_placeholder): Prefer to return the outermost matching object
	by recursively calling lookup_placeholder on the 'parent' context,
	but don't cross CONSTRUCTOR_PLACEHOLDER_BOUNDARY constructors.
	(cxx_eval_constant_expression): Link the 'ctx' context to the 'new_ctx'
	context via 'new_ctx.parent' when being expanded without an explicit
	target.  Don't call replace_placeholders.
	(cxx_eval_outermost_constant_expr): Initialize 'ctx.parent' to NULL.

gcc/testsuite/ChangeLog:

	PR c++/94205
	PR c++/79937
	* g++.dg/cpp1y/pr79937-5.C: New test.
	* g++.dg/cpp1z/lambda-this6.C: New test.

This PR reveals that cxx_eval_bare_aggregate and cxx_eval_store_expression do
not anticipate that a constructor element's initializer could mutate the
underlying CONSTRUCTOR.  Evaluation of the initializer could add new elements to
the underlying CONSTRUCTOR, thereby potentially invalidating any pointers to
or assumptions about the CONSTRUCTOR's elements, and so these routines should be
prepared for that.

To fix this problem, this patch makes cxx_eval_bare_aggregate and
cxx_eval_store_expression recompute the constructor_elt pointers through which
we're assigning, after it evaluates the initializer.  Care is taken to to not
slow down the common case where the initializer does not modify the underlying
CONSTRUCTOR.

gcc/cp/ChangeLog:

	PR c++/94219
	PR c++/94205
	* constexpr.c (get_or_insert_ctor_field): Split out (while adding
	support for VECTOR_TYPEs, and optimizations for the common case)
	from ...
	(cxx_eval_store_expression): ... here.  Rename local variable
	'changed_active_union_member_p' to 'activated_union_member_p'.  Record
	the sequence of indexes into 'indexes' that yields the subobject we're
	assigning to.  Record the integer offsets of the constructor indexes
	we're assigning through into 'index_pos_hints'.  After evaluating the
	initializer of the store expression, recompute 'valp' using 'indexes'
	and using 'index_pos_hints' as hints.
	(cxx_eval_bare_aggregate): Tweak comments.  Use get_or_insert_ctor_field
	to recompute the constructor_elt pointer we're assigning through after
	evaluating each initializer.

gcc/testsuite/ChangeLog:

	PR c++/94219
	PR c++/94205
	* g++.dg/cpp1y/constexpr-nsdmi3.C: New test.
	* g++.dg/cpp1y/constexpr-nsdmi4.C: New test.
	* g++.dg/cpp1y/constexpr-nsdmi5.C: New test.
	* g++.dg/cpp1z/lambda-this5.C: New test.

gcc/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	PR ipa/93940
	* ipa-fnsummary.c (vrp_will_run_p): New function.
	(fre_will_run_p): New function.
	(evaluate_properties_for_edge): Use it.
	* ipa-inline.c (can_inline_edge_by_limits_p): Do not inline
	!optimize_debug to optimize_debug.

gcc/testsuite/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	* g++.dg/tree-ssa/pr93940.C: New test.

A recent change to cmcstl2 led to two tests failing due to this bug: our
valid expression checking in the context of a requires-expression wasn't
catching that an expression of member function type can only appear as the
function operand of a call expression.  Fixed by using convert_to_void to do
the same checking as a discarded-value expression.

This patch also fixes 67825, which already had a testcase, but the testcase
was testing for the wrong behavior.

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

	PR c++/67825
	* constraint.cc (tsubst_valid_expression_requirement): Call
	convert_to_void.

The testcase hit an ICE trying to expand a TARGET_EXPR temporary cached from
the other lambda-expression.  This patch fixes this in two ways:

1) Avoid reusing a TARGET_EXPR from another function.
2) Avoid ending up with a TARGET_EXPR at all; the use of 'p' had become
<TARGET_EXPR<NON_LVALUE_EXPR<TARGET_EXPR ...>>>, which doesn't make any
sense.

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

	PR c++/94453
	* constexpr.c (maybe_constant_value): Use break_out_target_exprs.
	* expr.c (mark_use) [VIEW_CONVERT_EXPR]: Don't wrap a TARGET_EXPR in
	NON_LVALUE_EXPR.

this patch fixes wrong code on a testcase where inline predicts
builtin_constant_p to be true but we fail to optimize its parameter to constant
becuase FRE is not run and the value is passed by an aggregate.

This patch makes the inline predicates to disable aggregate tracking
when FRE is not going to be run and similarly value range when VRP is not
going to be run.

This is just partial fix.  Even with it we can arrange FRE/VRP to fail and
produce wrong code, unforutnately.

I think for GCC11 I will need to implement transformation in ipa-inline
but this is bit hard to do: predicates only tracks that value will be constant
and do not track what constant to be.

Optimizing builtin_constant_p in a conditional is not going to do good job
when the value is used later in a place that expects it to be constant.
This is pre-existing problem that is not limited to inline tracking. For example,
FRE may do the transofrm at one place but not in another due to alias oracle
walking limits.

So I am not sure what full fix would be :(

gcc/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	PR ipa/93940
	* ipa-fnsummary.c (vrp_will_run_p): New function.
	(fre_will_run_p): New function.
	(evaluate_properties_for_edge): Use it.
	* ipa-inline.c (can_inline_edge_by_limits_p): Do not inline
	!optimize_debug to optimize_debug.

gcc/testsuite/ChangeLog:

2020-04-04  Jan Hubicka  <hubicka@ucw.cz>

	* g++.dg/tree-ssa/pr93940.C: New test.

The following testcase ICEs, because at one point we see the
SP_DERIVED_VALUE_P VALUE as useless (not PRESERVED_VALUE_P and no locs)
and so expect it to be discarded as useless.  But, later on we
are adding some new VALUE that is equivalent to it, and when adding
the equivalency that that new VALUE is equal to this SP_DERIVED_VALUE_P,
new_elt_loc_list has code for VALUE canonicalization and reverses addition
if uid is smaller, and at that point a new loc is added to the
SP_DERIVED_VALUE_P VALUE and it isn't discarded as useless anymore.
Now, I think we don't want to discard the SP_DERIVED_VALUE_P values
even if they have no locs, because they still have the special behaviour
that they then force other new VALUEs to be canonicalized against them,
which is what this patch implements.  I've not set PRESERVED_VALUE_P
on the SP_DERIVED_VALUE_P at the creation time, because whether a VALUE
is preserved or not is something that affects var-tracking decisions quite a
lot and we shouldn't set it blindly on other VALUEs.

Or, to avoid the repetitive code, should I introduce
static bool
cselib_useless_value_p (cselib_val *v)
{
  return (v->locs == 0
	  && !PRESERVED_VALUE_P (v->val_rtx)
	  && !SP_DERIVED_VALUE_P (v->val_rtx)));
}
predicate and use it in those 6 spots?

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

	PR rtl-optimization/94468
	* cselib.c (references_value_p): Formatting fix.
	(cselib_useless_value_p): New function.
	(discard_useless_locs, discard_useless_values,
	cselib_invalidate_regno_val, cselib_invalidate_mem,
	cselib_record_set): Use it instead of
	v->locs == 0 && !PRESERVED_VALUE_P (v->val_rtx).

	* g++.dg/opt/pr94468.C: New test.

My recent protected_set_expr_location changes work well when
that function is called unconditionally, but as the testcase shows, the C++
FE has a few spots that do:
  if (!EXPR_HAS_LOCATION (stmt))
    protected_set_expr_location (stmt, locus);
or similar.  Now, if we have for -g0 stmt of some expression that can
have location and has != UNKNOWN_LOCATION, while -g instead has
a STATEMENT_LIST containing some DEBUG_BEGIN_STMTs + that expression with
that location, we don't call protected_set_expr_location in the -g0 case,
but do call it in the -g case, because on the STATEMENT_LIST
!EXPR_HAS_LOCATION.
The following patch introduces a helper function which digs up the single
expression of a STATEMENT_LIST and uses that expression in the
EXPR_HAS_LOCATION check (plus changes protected_set_expr_location to
also use that helper).

Or do we want a further wrapper, perhaps C++ FE only, that would do this
protected_set_expr_location_if_unset (stmt, locus)?

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

	PR debug/94441
	* tree-iterator.h (expr_single): Declare.
	* tree-iterator.c (expr_single): New function.
	* tree.h (protected_set_expr_location_if_unset): Declare.
	* tree.c (protected_set_expr_location): Use expr_single.
	(protected_set_expr_location_if_unset): New function.

	* parser.c (cp_parser_omp_for_loop): Use
	protected_set_expr_location_if_unset.
	* cp-gimplify.c (genericize_if_stmt, genericize_cp_loop): Likewise.

	* g++.dg/opt/pr94441.C: New test.

	PR rtl-optimization/92264
	* config/stormy16/stormy16.c (xstormy16_preferred_reload_class): Handle
	reloading of auto-increment addressing modes.