Add some missing require-effect-targets directives (alloca, indirect_jumps,
label_values and nonlocal_goto).

Tested on nvptx.

gcc/testsuite/ChangeLog:

	* gcc.dg/Warray-bounds-46.c: Add missing require-effective-target
	directive.
	* gcc.dg/Warray-bounds-48.c: Same.
	* gcc.dg/Warray-bounds-50.c: Same.
	* gcc.dg/Wreturn-local-addr-2.c: Same.
	* gcc.dg/Wreturn-local-addr-3.c: Same.
	* gcc.dg/Wreturn-local-addr-4.c: Same.
	* gcc.dg/Wreturn-local-addr-6.c: Same.
	* gcc.dg/Wstack-usage.c: Same.
	* gcc.dg/Wstringop-overflow-15.c: Same.
	* gcc.dg/Wstringop-overflow-23.c: Same.
	* gcc.dg/Wstringop-overflow-25.c: Same.
	* gcc.dg/Wstringop-overflow-27.c: Same.
	* gcc.dg/Wstringop-overflow-39.c: Same.
	* gcc.dg/analyzer/alloca-leak.c: Same.
	* gcc.dg/analyzer/data-model-1.c: Same.
	* gcc.dg/analyzer/data-model-16.c: Same.
	* gcc.dg/analyzer/malloc-1.c: Same.
	* gcc.dg/analyzer/malloc-paths-8.c: Same.
	* gcc.dg/analyzer/pr93546.c: Same.
	* gcc.dg/analyzer/setjmp-1.c: Same.
	* gcc.dg/analyzer/setjmp-2.c: Same.
	* gcc.dg/analyzer/setjmp-3.c: Same.
	* gcc.dg/analyzer/setjmp-4.c: Same.
	* gcc.dg/analyzer/setjmp-5.c: Same.
	* gcc.dg/analyzer/setjmp-6.c: Same.
	* gcc.dg/analyzer/setjmp-7.c: Same.
	* gcc.dg/analyzer/setjmp-7a.c: Same.
	* gcc.dg/analyzer/setjmp-8.c: Same.
	* gcc.dg/analyzer/setjmp-9.c: Same.
	* gcc.dg/analyzer/setjmp-pr93378.c: Same.
	* gcc.dg/gimplefe-44.c: Same.
	* gcc.dg/pr84131.c: Same.
	* gcc.dg/pr93986.c: Same.
	* gcc.dg/pr95133.c: Same.
	* gcc.dg/pr95857.c: Same.
	* gcc.dg/strlenopt-83.c: Same.
	* gcc.dg/strlenopt-84.c: Same.
	* gcc.dg/strlenopt-91.c: Same.
	* gcc.dg/uninit-32.c: Same.
	* gcc.dg/uninit-36.c: Same.

These two tests fail on AIX because <sys/thread.h> defines struct thread
in the global namespace (despite it not being a reserved name). That
means the using-declaration that adds it to the global namespace causes
a redeclaration error.

libstdc++-v3/ChangeLog:

	* testsuite/30_threads/thread/cons/84535.cc: Use a custom
	namespace.
	* testsuite/30_threads/thread/cons/lwg2097.cc: Likewise.

Make the experimental Networking TS code work without std::mutex and
std::condition_variable.

libstdc++-v3/ChangeLog:

	PR libstdc++/89760
	* include/experimental/executor [!_GLIBCXX_HAS_GTHREADS]:
	(execution_context::mutex_type): Define dummy mutex type.
	(system_context): Use execution_context::mutex_type.
	(system_context) [!_GLIBCXX_HAS_GTHREADS]: Define dummy
	thread and condition variable types.
	[!_GLIBCXX_HAS_GTHREADS] (system_context::_M_run()): Do not
	define.
	(system_context::_M_post) [!_GLIBCXX_HAS_GTHREADS]: Throw
	an exception when threads aren't available.
	(strand::running_in_this_thread()): Defer to _M_state.
	(strand::_State::running_in_this_thread()): New function.
	(use_future_t): Do not depend on _GLIBCXX_USE_C99_STDINT_TR1.
	* include/experimental/io_context (io_context): Use the
	execution_context::mutex_type alias. Replace stack of thread
	IDs with counter.
	* testsuite/experimental/net/execution_context/use_service.cc:
	Enable test for non-pthread targets.

libstdc++-v3/ChangeLog:

	* include/experimental/executor (system_context::a__tag): Make
	default constructor explicit.

libstdc++-v3/ChangeLog:

	* include/experimental/executor (system_context::_M_run()):
	Fix predicate.
	* testsuite/experimental/net/system_context/1.cc: New test.

libstdc++-v3/ChangeLog:

	* include/std/stop_token: Check _GLIBCXX_HAS_GTHREADS using
	#ifdef instead of #if.
	(stop_token::_S_yield()): Check _GLIBCXX_HAS_GTHREADS before
	using __gthread_yield.

The only function in namespace std::this_thread that actually depends on
thread support being present is this_thread::get_id(). The other
functions (yield, sleep_for and sleep_until) can be defined for targets
without gthreads.

A small change is needed in std::this_thread::sleep_for which currently
uses the __gthread_time_t typedef. Since it just calls nanosleep
directly, it should use timespec directly instead of the typedef.

Even std::this_thread::get_id() could be made to work, the only
difficulty is that it returns a value of type std::thread::id and
std::thread is only defined when gthreads support exists.

libstdc++-v3/ChangeLog:

	* include/std/thread [!_GLIBCXX_HAS_GTHREADS] (this_thread::yield)
	(this_thread::sleep_until): Define.
	[!_GLIBCXX_HAS_GTHREADS] (this_thread::sleep_for): Define. Replace
	use of __gthread_time_t typedef with timespec.
	* src/c++11/thread.cc [!_GLIBCXX_HAS_GTHREADS] (__sleep_for):
	Likewise.
	* testsuite/30_threads/this_thread/2.cc: Moved to...
	* testsuite/30_threads/this_thread/yield.cc: ...here.
	* testsuite/30_threads/this_thread/3.cc: Moved to...
	* testsuite/30_threads/this_thread/sleep_for-mt.cc: ...here.
	* testsuite/30_threads/this_thread/4.cc: Moved to...
	* testsuite/30_threads/this_thread/sleep_until-mt.cc: ...here.
	* testsuite/30_threads/this_thread/58038.cc: Add
	dg-require-sleep.
	* testsuite/30_threads/this_thread/60421.cc: Likewise.
	* testsuite/30_threads/this_thread/sleep_for.cc: New test.
	* testsuite/30_threads/this_thread/sleep_until.cc: New test.

As the testcase shows, we would ICE if the type of the first argument of
various atomic builtins was pointer to (non-void) incomplete type, we would
assume that TYPE_SIZE_UNIT must be non-NULL.  This patch diagnoses it
instead.  And also changes the TREE_CODE != INTEGER_CST check to
!tree_fits_uhwi_p, as we use tree_to_uhwi after this and at least in theory
the int could be too large and not fit.

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

	PR c/96545
	* c-common.c (get_atomic_generic_size): Require that first argument's
	type points to a complete type and use tree_fits_uhwi_p instead of
	just INTEGER_CST TREE_CODE check for the TYPE_SIZE_UNIT.

	* c-c++-common/pr96545.c: New test.

At GIMPLE e.g. for __builtin_memmove we optimize away (to just the return
value) noop copies where src == dest, but at the RTL we don't, and as the
testcase shows, in some cases such copies can appear only at the RTL level
e.g. from trying to copy an aggregate by value argument to the same location
as it already has.  If the block move is expanded e.g. piecewise, we
actually manage to optimize it away, as the individual memory copies are
seen as noop moves, but if the target optabs are used, often the sequences
stay until final.

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

	PR rtl-optimization/96539
	* expr.c (emit_block_move_hints): Don't copy anything if x and y
	are the same and neither is MEM_VOLATILE_P.

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

My changes to get_narrower to support COMPOUND_EXPRs apparently
used a wrong type for the COMPOUND_EXPRs, while e.g. the rhs
type was unsigned short, the COMPOUND_EXPR got int type as that was the
original type of op.  The type of COMPOUND_EXPR should be always the type
of the rhs.

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

	PR c/96549
	* tree.c (get_narrower): Use TREE_TYPE (ret) instead of
	TREE_TYPE (win) for COMPOUND_EXPRs.

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

This patch avoids both PRED_LOOP_GUARD and PRED_LOOP_GUARD_WITH_RECURSION to be
attached to one edge.  We have logic that prevents same predictor to apply to
one edge twice, but since we split LOOP_GUARD to two more specialized cases,
this no longer fires.

Double prediction happens in exchange benchmark and leads to unrealistically
low hitrates on some edges which in turn leads to bad IPA profile and misguides
ipa-cp.

Unforutnately it seems that the bad profile also leads to bit better
performance by disabling some of loop stuff, but that really ought to be done
in some meaningful way, not by an accident.

gcc/ChangeLog:

2020-08-11  Jan Hubicka  <hubicka@ucw.cz>

	* predict.c (not_loop_guard_equal_edge_p): New function.
	(maybe_predict_edge): New function.
	(predict_paths_for_bb): Use it.
	(predict_paths_leading_to_edge): Use it.

gcc/testsuite/ChangeLog:

2020-08-11  Jan Hubicka  <hubicka@ucw.cz>

	* gcc.dg/ipa/ipa-clone-2.c: Lower threshold from 500 to 400.

gcc/ChangeLog:

	* dbgcnt.def (DEBUG_COUNTER): Add ipa_cp_bits.
	* ipa-cp.c (ipcp_store_bits_results): Use it when we store known
	bits for parameters.

Now that dg-ice is available, let's try it out.

gcc/testsuite/ChangeLog:

	PR c++/88003
	* g++.dg/cpp1y/auto-fn61.C: New test.

AIX linker is not able to merge identical type descriptors in a single
symbol if there are coming from different object or shared object files.
This results into several pointers referencing the same type
descriptors.
Thus, eqtype is needed to ensure that these different symbols will be
considered as the same type descriptor.

Fixes golang/go#39276

gcc/go/ChangeLog:

	* go-c.h (struct go_create_gogo_args): Add need_eqtype field.
	* go-lang.c (go_langhook_init): Set need_eqtype.

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

This patch adds a new DejaGNU directive, dg-ice, as outlined in the
proposal here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550913.html

It means that it's expected that the compiler crashes with an internal
compiler error when compiling test with such a directive.

A minor optimization could be to use -pass-exit-codes and then check for
ICE_EXIT_CODE return code instead of using string match.

gcc/ChangeLog:

	* doc/sourcebuild.texi: Document dg-ice.

gcc/testsuite/ChangeLog:

	* lib/gcc-dg.exp (gcc-dg-test-1): Handle dg-ice.
	(cleanup-after-saved-dg-test): Reset expect_ice.
	* lib/prune.exp (prune_ices): New.
	* lib/target-supports-dg.exp (dg-ice): New.

To make amends for the recent (temporary) testsuite failure
of my new gcc.target/i386/minmax-9.c when compiled with -m32,
this patch improves the -m32 code we generate for the examples
in that test case.

The trick is to expand smin(x,0) as "x < 0 ? x : 0" instead
of the current "x <= 0 ? x : 0", as the former can take
advantage of sign_bit_mask operations.

2020-08-10  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	* config/i386/i386-expand.c (ix86_expand_int_movcc): Expand
	signed MIN_EXPR against zero as "x < 0 ? x : 0" instead of
	"x <= 0 ? x : 0" to enable sign_bit_compare_p optimizations.

gcc/testsuite/ChangeLog
	* gcc.target/i386/minmax-12.c: New test.

libstdc++-v3/ChangeLog:

	PR libstdc++/94681
	* src/c++17/fs_ops.cc (read_symlink): Use posix::lstat instead
	of calling ::lstat directly.
	* src/filesystem/ops.cc (read_symlink): Likewise.

The support for the old std::unique_ptr implementation was failing,
because it tried to work on a typedef instead of the underlying type.
The test supposed to verify the support worked wasn't using a typedef,
so didn't notice the problem.

libstdc++-v3/ChangeLog:

	* python/libstdcxx/v6/printers.py (UniquePointerPrinter.__init__):
	Use gdb.Type.strip_typedefs().
	* testsuite/libstdc++-prettyprinters/compat.cc: Use a typedef in
	the emulated old type.

gcc/fortran/ChangeLog:

	PR fortran/96556
	* frontend-passes.c (doloop_contained_function_call):
	Do not dereference a NULL pointer for value.function.esym.

gcc/testsuite/ChangeLog:

	PR fortran/96556
	* gfortran.dg/do_check_15.f90: New test.

The following valid testcase is rejected, because cxx_eval_binary_expression
is called on the SPACESHIP_EXPR with lval = true, as the address of the
spaceship needs to be passed to a method call.
After recursing on the operands and calling genericize_spaceship which turns
it into a TARGET_EXPR with initialization, we call cxx_eval_constant_expression
on it which succeeds, but then we fall through into code that will
VERIFY_CONSTANT (r) which FAILs because it is an address of a variable.  Rather
than avoiding that for lval = true and SPACESHIP_EXPR, the patch just tail
calls cxx_eval_constant_expression - I believe that call should perform all
the needed verifications.

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

	PR c++/96497
	* constexpr.c (cxx_eval_binary_expression): For SPACESHIP_EXPR, tail
	call cxx_eval_constant_expression after genericize_spaceship to avoid
	undesirable further VERIFY_CONSTANT.

	* g++.dg/cpp2a/spaceship-constexpr3.C: New test.

When resolving the address of a template-id, we need to drop functions
whose associated constraints are not satisfied, as per [over.over].  We
do so in resolve_address_of_overloaded_function, but not in
resolve_overloaded_unification or resolve_nondeduced_context, which
seems like an oversight.

gcc/cp/ChangeLog:

	* pt.c (resolve_overloaded_unification): Drop functions with
	unsatisfied constraints.
	(resolve_nondeduced_context): Likewise.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/concepts-fn5.C: New test.
	* g++.dg/concepts/fn8.C: Generalize dg-error directive to accept
	"no matching function ..." diagnostic.
	* g++.dg/cpp2a/concepts-fn1.C: Likewise.
	* g++.dg/cpp2a/concepts-ts2.C: Likewise.
	* g++.dg/cpp2a/concepts-ts3.C: Likewise.

The configure switch should only affect the optional Filesystem TS, not
the std::filesystem features of C++17.

libstdc++-v3/ChangeLog:

	PR libstdc++/94681
	* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Do not depend on
	$enable_libstdcxx_filesystem_ts.
	* configure: Regenerate.

libstdc++-v3/ChangeLog:

	* include/bits/stl_iterator.h (inserter): Do not deduce
	iterator type (LWG 561).
	* testsuite/24_iterators/insert_iterator/dr561.cc: New test.

If exceptions are disabled then reallocating could abort, so ignore
shrink-to-fit requests.

libstdc++-v3/ChangeLog:

	* include/bits/basic_string.tcc [_GLIBCXX_USE_CXX11_ABI=0]
	(basic_string::reserve()): Do nothing if exceptions are not
	enabled.

gcc/ChangeLog:

	* value-range.h (gt_ggc_mx): Declare inline.
	(gt_pch_nx): Same.

Odd numbers are invertible in Z / 2^n Z, so X * C1 == C2 can be rewritten
as X == C2 * inv(C1) when overflow wraps.

mod_inv should probably be updated to better match the other wide_int
functions, but that's a separate issue.

2020-08-10  Marc Glisse  <marc.glisse@inria.fr>

	PR tree-optimization/95433
	* match.pd (X * C1 == C2): Handle wrapping overflow.
	* expr.c (maybe_optimize_mod_cmp): Qualify call to mod_inv.
	(mod_inv): Move...
	* wide-int.cc (mod_inv): ... here.
	* wide-int.h (mod_inv): Declare it.

	* gcc.dg/tree-ssa/pr95433-2.c: New file.

In order to handle large files on Windows we need to use stat API with
64-bit st_sioze member.

libstdc++-v3/ChangeLog:

	PR libstdc++/95749
	* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
	(stat_type): Change to __wstat64.
	(stat): Use _wstat64.

remove_predictions_associated_with_edge currently calls filter_predicitons
passing it equal_edge_p. Becase filter_predictions removes all edges where
filter returns false, the function does exact oposite. Fixed thus.

Bootstrapped/regtested x86_64-linux.

gcc/ChangeLog:

2020-08-02  Jan Hubicka  <hubicka@ucw.cz>

	* predict.c (filter_predictions): Document semantics of filter.
	(equal_edge_p): Rename to ...
	(not_equal_edge_p): ... this; reverse semantics.
	(remove_predictions_associated_with_edge): Fix.

2020-08-10  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
	PR fortran/96312
	* trans-expr.c (fcncall_realloc_result): Only compare shapes if
	lhs was allocated..

gcc/testsuite/
	PR fortran/96312
	* gfortran.dg/pr96312.f90: New test.

2020-08-10  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
	PR fortran/96102
	* resolve.c (check_host_association): Replace the gcc_assert
	with an error for internal procedures.

gcc/testsuite/
	PR fortran/96102
	* gfortran.dg/pr96102.f90: New test.

For rtx like (eq:HI (V8SI 90) (V8SI 91)), cse will take it as a
boolean value and try to do some optimization. But it is not true for
vector compare, also other places in rtl passes hold the same
assumption.

2020-07-20  Hongtao Liu  <hongtao.liu@intel.com>

gcc/
	PR target/96243
	* config/i386/i386-expand.c (ix86_expand_sse_cmp): Refine for
	maskcmp.
	(ix86_expand_mask_vec_cmp): Change prototype.
	* config/i386/i386-protos.h (ix86_expand_mask_vec_cmp): Change prototype.
	* config/i386/i386.c (ix86_print_operand): Remove operand
	modifier 'I'.
	* config/i386/sse.md
	(*<avx512>_cmp<mode>3<mask_scalar_merge_name><round_saeonly_name>): Deleted.
	(*<avx512>_cmp<mode>3<mask_scalar_merge_name>): Ditto.
	(*<avx512>_ucmp<mode>3<mask_scalar_merge_name>): Ditto.
	(*<avx512>_ucmp<mode>3<mask_scalar_merge_name>,
	avx512f_maskcmp<mode>3): Ditto.

gcc/testsuite
	* gcc.target/i386/pr92865-1.c: Adjust testcase.

This patch fixes a subtle bug in the depths of GCC's synth_mult,
where the middle-end queries whether (how well) the target supports
widening and highpart multiplications by calling targetm.rtx_costs.
The code in init_expmed and init_expmed_one_mode iterates over various
RTL patterns querying the cost of each.  To avoid generating & garbage
collecting too much junk, it reuses the same RTL over and over, but
adjusting the modes between each call.

Alas this reuse of state is a little fragile, and at some point a
change to init_expmed_one_conv has resulted in the state (mode of
a register) being changed, but not reset before being used again.

Using the old software engineering/defensive programming maxim of
"why fix a bug just once, if it can be fixed in multiple places",
this patch both restores the original value in init_expmed_one_conv,
and also sets it to the expected value in init_expmed_one_mode.
This should hopefully signal the need to be careful of invariants for
anyone modifying this code in future.

2020-08-09  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	* expmed.c (init_expmed_one_conv): Restore all->reg's mode.
	(init_expmed_one_mode): Set all->reg to desired mode.

gcc/testsuite/ChangeLog
	PR target/71321
	* gcc.target/i386/pr71321.c: Check that the code doesn't use
	the 4B zero displacement lea, not that it uses lea.

X86 Darwin fails these at present, because (to work around PR80556)
we insert libSystem ahead of libgcc.  The libSystem implementation
has a similar bug to one that was fixed for GCC.  We need to fix
80556 properly, and then this issue will go away - we will be able
to use the libgcc impl as intended.

XFAIL the run for now, to reduce testsuite noise.

gcc/testsuite/ChangeLog:

	* gcc.dg/torture/fp-int-convert-timode-3.c: XFAIL run.
	* gcc.dg/torture/fp-int-convert-timode-4.c: Likewise.

The test makes sense only for targets that return the
"struct { int a, b, c; }" in registers (not in memory).

Starting a skip-construct is IMHO better than another iteration of
that obscuring "{ ... && { !  mytarget-*-* } }".  New targets can just
append to the list without additional {}:s.  I chose not to "convert"
any of the previous exclusions, as without targets to test, I'd surely
mess up {}-pairs.

A new effective_target would be even better, but such a
check_effective_target_returns_struct_in_memory (or complementary,
_in_registers) would surely have to be parametrized on the size and
type of the returned blob.

Maybe best to restrict to just x86_64, as seems to have been the
original problem target.

gcc/testsuite:
	* gcc.dg/pr44194-1.c: Skip for mmix.

IV (loop2_unroll) doesn't like the mmix port.  The feelings are mutual.

For mmix, gcc.dg/pr30957-1.c fails (runtime and rtl-scan) for these
reasons:

- IV doesn't handle the zero-extension-by-shift sequences generated by
  middle-end (expr.c:convert_mode_scalar) in the absence of
  zero-extend patterns in a port.

- (when adding such patterns)
  IV doesn't understand the subreg constructs generated by middle-end
  in the absence of addsi3 and compare/branch in SImode (int).

- (when hacking pr30957-1.c to iterate using a register-mode type)
  IV doesn't understand the admittedly weird SFmode operations
  (performing in DFmode, then truncating, for lack of SFmode
  operations, but presence of truncdfsf2 and float_extendsfdf2) in
  order to perform the "Expanding Accumulator" optimization.  When
  also editing the type in the test to be double instead of float, the
  test passes.

While at least the last point seems like a valid reason to just skip
the test for mmix, it also seems possible that IV (and maybe
convert_mode_scalar by e.g. adding REG_EQUIV notes) be improved to be
both smarter and dumber to actually make the test pass, so I think
it's better to use xfail.  Smarter: understanding zero-extend-
by-shift and subregged operations better, and "seeing" the
accumulation through the DF/SFmode truncations and expansions.
Dumber: ignoring the cost; unrolling the several operations per SFmode
add anyway.

I'm considering adding a variant of this test with "double" and
"__SIZE_TYPE__" iteration types, as that passes for mmix as-is.
Maybe as a mmix-specific test; the world has suffered enough from the
questionable gcc.dg/pr30957-1.c (see the test and its history).

gcc/testsuite:
	* gcc.dg/pr30957-1.c: xfail for mmix.

We do not allow conversions between the MMA types and other types.
However, we are being too strict in not matching MMA types with
typdefs of those types.  Use TYPE_CANONICAL to see through the
types to their canonical types before comparing them.

2020-08-08  Peter Bergner  <bergner@linux.ibm.com>

gcc/
	PR target/96530
	* config/rs6000/rs6000.c (rs6000_invalid_conversion): Use canonical
	types for type comparisons.  Refactor code to simplify it.

gcc/testsuite/
	PR target/96530
	* gcc.target/powerpc/pr96530.c: New test.