For is_device_ptr, optional checks should only be done before calling
libgomp, afterwards they are NULL either because of absent or, by
chance, because it is unallocated or unassociated (for pointers/allocatables).

Additionally, it fixes an issue with explicit mapping for 'type(c_ptr)'.

	PR middle-end/108546

gcc/fortran/ChangeLog:

	* trans-openmp.cc (gfc_trans_omp_clauses): Fix mapping of
	type(C_ptr) variables.

gcc/ChangeLog:

	* omp-low.cc (lower_omp_target): Remove optional handling
	on the receiver side, i.e. inside target (data), for
	use_device_ptr.

libgomp/ChangeLog:

	* testsuite/libgomp.fortran/is_device_ptr-3.f90: New test.
	* testsuite/libgomp.fortran/use_device_ptr-optional-4.f90: New test.

I think it is useful to cover also this, rather than just arrays at the
flexible array member positions.

2023-03-01  Jakub Jelinek  <jakub@redhat.com>

	PR sanitizer/108894
	* c-c++-common/ubsan/bounds-16.c: New test.

cfgexpand: Handle WIDEN_{PLUS,MINUS}_EXPR and VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR in expand_debug_expr [PR108967]

When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them.  For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily.  In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
tree codes there.

2023-03-01  Jakub Jelinek  <jakub@redhat.com>

	PR debug/108967
	* cfgexpand.cc (expand_debug_expr): Handle WIDEN_{PLUS,MINUS}_EXPR
	and VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR.

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

The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch
from
      return RECUR (tmp, want_rval);
to
      return RECUR (DECL_INITIAL (tmp), want_rval);
This is on DECL_EXPR handling code, where tmp can be lots of different
trees and DECL_INITIAL unfortunately also means different things on
different trees.
It is the initializer on VAR_DECL, DECL_ARG_TYPE on PARM_DECLs (though
those are unlikely to have DECL_EXPRs), for FUNCTION_DECLs the body,
..., USING_DECL_DECLS on USING_DECLs and DECL_FRIENDLIST on TYPE_DECLs.

The testcase below ICEs because we have a DECL_EXPR for TYPE_DECL
which has non-NULL DECL_FRIENDLIST and we certainly can't recurse on
the friend list.

The following patch will RECUR on DECL_INITIAL only for VAR_DECLs and
for anything else just return true.

2023-03-01  Jakub Jelinek  <jakub@redhat.com>

	PR c++/108606
	* constexpr.cc (potential_constant_expression_1) <case DECL_EXPR>:
	Only recurse on DECL_INITIAL (tmp) if tmp is a VAR_DECL, otherwise
	just return true.

	* g++.dg/cpp1y/pr108606.C: New test.

The function slpeel_can_duplicate_loop_p fails to verify we can
copy blocks, instead slpeel_tree_duplicate_loop_to_edge_cfg does
but that's too late.  The following fixes this, also simplifying
error reporting which is somewhat pointless if we ICE immediately.

	PR tree-optimization/108970
	* tree-vect-loop-manip.cc (slpeel_can_duplicate_loop_p):
	Check we can copy the BBs.
	(slpeel_tree_duplicate_loop_to_edge_cfg): Avoid redundant
	check.
	(vect_do_peeling): Streamline error handling.

	* gcc.dg/pr108970.c: New testcase.

Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained
inside of build_{pointer,reference}_type_for_mode and those routines
ensure that the pointer/reference type added to the chain is really
without any user attributes (unless something would modify the types
in place, but that would be wrong).

Now, LTO adds stuff to these chains in lto_fixup_prevailing_type but
doesn't guarantee that.  The testcase in the PR (which I'm not including
for testsuite because when (I hope) the aarch64 backend bug will be fixed,
the testcase would work either way) shows a case where user has
TYPE_USER_ALIGN type with very high alignment, as there aren't enough
pointers to float in the code left that one becomes the prevailing one
(because types with attributes are created with build_distinct_type_copy
and thus their own TYPE_MAIN_VARIANTs), lto_fixup_prevailing_type puts
it into the TYPE_POINTER_TO chain of float and later on during expansion
of __builtin_cexpif expander uses build_pointer_type (float_type_node)
to emit a sincosf call and instead of getting a normal pointer type gets
this non-standard one.

The following patch fixes that by not adding into those chains
types with TYPE_ATTRIBUTES, and for REFERENCE_TYPEs not even with
TYPE_REF_IS_RVALUE - while the C++ FE adds those into those chains,
it always ensures such a type goes immediately after the corresponding
non-TYPE_REF_IS_RVALUE REFERENCE_TYPE with the same
mode/TYPE_REF_CAN_ALIAS_ALL, so LTO would need to ensure that too, but
TYPE_REF_IS_RVALUE types are looked that way only in the C++ FE.

2023-03-01  Jakub Jelinek  <jakub@redhat.com>

	PR target/108910
	* lto-common.cc (lto_fixup_prevailing_type): Don't add t to
	TYPE_POINTER_TO or TYPE_REFERENCE_TO chain if it has
	TYPE_ATTRIBUTES or is TYPE_REF_IS_RVALUE.

When we end up with a widen-sum with an invariant smaller operand
the reduction code uses a wrong vector type for it, causing
IL checking ICEs.  The following fixes that and the inefficiency
of using a widen-sum with a widenend invariant operand as well
by actually performing the check the following comment wants.

	PR tree-optimization/108950
	* tree-vect-patterns.cc (vect_recog_widen_sum_pattern):
	Check oprnd0 is defined in the loop.
	* tree-vect-loop.cc (vectorizable_reduction): Record all
	operands vector types, compute that of invariants and
	properly update their SLP nodes.

	* gcc.dg/vect/pr108950.c: New testcase.

Before r13-4894, if 64 bit is explicitly specified, option
powerpc64 is explicitly enabled too; while if 64 bit is
implicitly enabled and there is no explicit setting for
option powerpc64, option powerpc64 is eventually enabled
or not would rely on the default value of the used cpu.
It's initially set as the setting for 64 bit, but later if
the used cpu doesn't have powerpc64 supported by default,
it gets cleared.

To keep it consistent with before (also the relevant error/
warning messages), this patch is to allow that powerpc64
can be unset if 64 bit is enabled implicitly, and only stop
it from being unset if 64 bit is enabled explicitly.

Note that since the behaviors are different for implicit
and explicit 64 bit, I failed to construct one solid test
case since it becomes fragile once RUNTESTFLAGS specifying
-m64 explicitly.

	PR target/108240

gcc/ChangeLog:

	* config/rs6000/rs6000.cc (rs6000_option_override_internal): Allow
	implicit powerpc64 setting to be unset if 64 bit is enabled implicitly.

Investigating analyzer testsuite errors for cris-elf.  The same are
seen for pru-elf according to posts to gcc-testresults@.

The test fd-access-mode-target-headers.c uses the analyzer
"sm-fd" which for this use requires (e.g.) that constants
O_ACCMODE, O_RDONLY and O_WRONLY are defined as literal
constants.  While for glibc, O_ACCMODE is defined as:
 #define O_ACCMODE 0003
in newlib, it's defined as:
 #define O_ACCMODE (O_RDONLY|O_WRONLY|O_RDWR)
and the analyzer is not able to make use of an expression
like this (even though O_RDONLY, O_WRONLY and O_RDWR are
defined as literal constants and the whole evaluates to 3).
Better do as for AIX and skip this test.

testsuite:
	* gcc.dg/analyzer/fd-access-mode-target-headers.c: Skip for
	newlib targets too.

Here we're treating deeming the non-dependent variable template-id
tag<int> as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR
an empty type, which causes the call to finish_template_variable from
finish_id_expression_1 to be unreachable at template parse time.  Thus
we're led into thinking tag<int>.var<void> refers to a dependent name.

This patch fixes this by making finish_id_expression_1 instantiate a
variable template-id as long as it's not dependent according to the
dependence test in lookup_and_finish_template_variable rather than
according to type_dependent_expression_p.

	PR c++/108848

gcc/cp/ChangeLog:

	* pt.cc (finish_template_variable): Move dependence check
	to here from ...
	(lookup_and_finish_template_variable): ... here.
	* semantics.cc (finish_id_expression_1): Call
	finish_template_variable sooner, before (and regardless of) the
	type_dependent_expression_p test.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/noexcept1.C: Don't expect a bogus "different
	exception specifier" error.  Expect a separate "not usable
	in a constant expression" error.
	* g++.dg/cpp1y/var-templ75.C: New test.
	* g++.dg/cpp1y/var-templ76.C: New test.

This is a bug in tree-ssa-uninit.cc.
When doing the following:

  /* Ignore the call to .DEFERRED_INIT that define the original
     var itself as the following case:
       temp = .DEFERRED_INIT (4, 2, “alt_reloc");
       alt_reloc = temp;
     In order to avoid generating warning for the fake usage
     at alt_reloc = temp.
  */

We need to compare the var name inside the .DEFERRED_INIT call
(the 3rd argument) and the name for the LHS variable. if they are the same,
we will NOT report the warning.

There is one issue when we get the name for the LHS variable. when the
variable doesn't have a DECL_NAME (it's not a user declared variable,
which is the case for this bug):

  _1 = .DEFERRED_INIT (4, 2, &"D.2389"[0]);
  D.2389 = _1;

The current checking just ignores this case, and still report the warning.

The fix is very simple, when getting the name for the LHS variable, we should
consider this case and come up with the name the same way as we construct the
3rd argument for the call to .DEFERRED_INIT (please refer to the routine
"gimple_add_init_for_auto_var")

	PR middle-end/107411

gcc/ChangeLog:

	PR middle-end/107411
	* gimplify.cc (gimple_add_init_for_auto_var): Use sprintf to replace
	xasprintf.
	* tree-ssa-uninit.cc (warn_uninit): Handle the case when the
	LHS varaible of a .DEFERRED_INIT call doesn't have a DECL_NAME.

gcc/testsuite/ChangeLog:

	PR middle-end/107411
	* g++.dg/pr107411.C: New test.

mc needs a fix to optionally suppress the generation of the noreturn
attribute when building M2RTS.  All the hand built C++ modules calling
RegisterModule must supply the library name.  These changes require
the boot strap tools mc and pge to be rebuilt.

gcc/m2/ChangeLog:

	PR modula2/108956
	* Make-lang.in (m2/gm2-libs-boot/M2RTS.o): New specific rule to
	add the --suppress-noreturn option.
	* Make-maintainer.in (m2/gm2-ppg-boot/$(SRC_PREFIX)M2RTS.o): New
	specific rule to add the --suppress-noreturn option.
	(m2/gm2-pg-boot/$(SRC_PREFIX)M2RTS.o): New
	specific rule to add the --suppress-noreturn option.
	(m2/gm2-pg-boot/$(SRC_PREFIX)%.o): Add missing $(srcdir).
	(m2/gm2-pge-boot/$(SRC_PREFIX)M2RTS.o): New
	specific rule to add the --suppress-noreturn option.
	(m2/gm2-pge-boot/$(SRC_PREFIX)%.o): Add missing $(srcdir).
	* gm2-libs-ch/UnixArgs.cc (LIBNAME): New define.
	(_M2_UnixArgs_ctor): Add LIBNAME parameter to RegisterModule.
	* gm2-libs-ch/dtoa.cc (LIBNAME): New define.
	(_M2_dtoa_ctor): Add LIBNAME parameter to RegisterModule.
	* gm2-libs-ch/ldtoa.cc (LIBNAME): New define.
	(_M2_ldtoa_ctor): Add LIBNAME parameter to RegisterModule.
	* pge-boot/m2rts.h (M2RTS_RegisterModule): Add libname
	parameter.
	* gm2-libs-ch/m2rts.h (M2RTS_RegisterModule): Add libname
	parameter.
	* mc-boot-ch/GUnixArgs.cc (_M2_UnixArgs_ctor): Remove.
	* pge-boot/GUnixArgs.cc (LIBNAME): New define.
	(_M2_UnixArgs_ctor): Add LIBNAME parameter to RegisterModule.
	* gm2-libs/RTint.def (AttachVector): Rename parameter.
	* mc-boot/GDynamicStrings.c: Rebuilt.
	* mc-boot/GFIO.c: Rebuilt.
	* mc-boot/GIndexing.c: Rebuilt.
	* mc-boot/GM2EXCEPTION.c: Rebuilt.
	* mc-boot/GPushBackInput.c: Rebuilt.
	* mc-boot/GRTExceptions.c: Rebuilt.
	* mc-boot/GRTint.c: Rebuilt.
	* mc-boot/GRTint.h: Rebuilt.
	* mc-boot/GStdIO.c: Rebuilt.
	* mc-boot/GStringConvert.c: Rebuilt.
	* mc-boot/GSysStorage.c: Rebuilt.
	* mc-boot/Gdecl.c: Rebuilt.
	* mc-boot/Gkeyc.c: Rebuilt.
	* mc-boot/GmcComment.c: Rebuilt.
	* mc-boot/GmcComp.c: Rebuilt.
	* mc-boot/GmcDebug.c: Rebuilt.
	* mc-boot/GmcMetaError.c: Rebuilt.
	* mc-boot/GmcOptions.c: Rebuilt.
	* mc-boot/GmcOptions.h: Rebuilt.
	* mc-boot/GmcStack.c: Rebuilt.
	* mc-boot/GnameKey.c: Rebuilt.
	* mc-boot/GsymbolKey.c: Rebuilt.
	* mc/decl.mod:: Rebuilt.
	* mc/mcOptions.def: Rebuilt.
	* mc/mcOptions.mod:: Rebuilt.
	* pge-boot/GDynamicStrings.c: Rebuilt.
	* pge-boot/GFIO.c: Rebuilt.
	* pge-boot/GIndexing.c: Rebuilt.
	* pge-boot/GM2EXCEPTION.c: Rebuilt.
	* pge-boot/GM2RTS.c: Rebuilt.
	* pge-boot/GNameKey.c: Rebuilt.
	* pge-boot/GPushBackInput.c: Rebuilt.
	* pge-boot/GRTExceptions.c: Rebuilt.
	* pge-boot/GStdIO.c: Rebuilt.
	* pge-boot/GSymbolKey.c: Rebuilt.
	* pge-boot/GSysStorage.c: Rebuilt.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

In this test, we get a bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer<Tp>::value;
to bool.  Then ensure_literal_type_for_constexpr_object thinks the object
isn't literal and an error is reported.

This is another case of the interaction between tf_partial and 'auto',
where the auto was not reduced so the deduction failed.  In more detail:
we have

  Wrap1<int>()

in the code and we need to perform OR -> fn_type_unification.  The targ
list is incomplete, so we do
      tsubst_flags_t ecomplain = complain | tf_partial | tf_fndecl_type;
      fntype = tsubst (TREE_TYPE (fn), explicit_targs, ecomplain, NULL_TREE);
where TREE_TYPE (fn) is struct integral_constant <T402> (void).  Then
we substitute the return type, which results in tsubsting is_pointer_v<int>.
is_pointer_v is a variable template with a placeholder type:

  template <class Tp>
  constexpr auto is_pointer_v = is_pointer<Tp>::value;

so we find ourselves in lookup_and_finish_template_variable.  tf_partial is
still set, so finish_template_variable -> instantiate_template -> tsubst
won't reduce the level of auto.  But then we do mark_used which eventually
calls do_auto_deduction which clears tf_partial, because we want to replace
the auto now.  But we hadn't reduced auto's level so this fails.  And
since we're not in an immediate context, we emit a hard error.

I suppose that when we reach lookup_and_finish_template_variable it's
probably time to clear tf_partial.  (I added an assert and our testsuite
doesn't have a test whereby we get to lookup_and_finish_template_variable
while tf_partial is still active.)

	PR c++/108550

gcc/cp/ChangeLog:

	* pt.cc (lookup_and_finish_template_variable): Clear tf_partial.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/var-templ70.C: New test.
	* g++.dg/cpp1y/var-templ71.C: New test.
	* g++.dg/cpp1y/var-templ72.C: New test.

Since r11-557, cp_finish_decl can call check_initializer even in
a template for a constexpr initializer.  That ultimately leads to
convert_for_assignment and check_address_or_pointer_of_packed_member,
where we crash, because it doesn't expect that the CALL_EXPR is
a function object.  Q has a constexpr operator(), but since we're
in a template, q(0) is a CALL_EXPR whose CALL_EXPR_FN is just
a VAR_DECL; it hasn't been converted to Q::operator<int>(&q, 0) yet.
I propose to robustify check_address_or_pointer_of_packed_member.

var-templ74.C has an XFAIL, subject to 107939.

I noticed that our -Waddress-of-packed-member tests weren't testing
member functions, added thus.  (I was tempted to check
FUNCTION_POINTER_TYPE_P but that doesn't include METHOD_TYPE.)

	PR c++/107938

gcc/c-family/ChangeLog:

	* c-warn.cc (check_address_or_pointer_of_packed_member): Check
	POINTER_TYPE_P.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/var-templ73.C: New test.
	* g++.dg/cpp1y/var-templ74.C: New test.
	* g++.dg/warn/Waddress-of-packed-member3.C: New test.

While this isn't really a regression, the -fstrict-flex-arrays*
option is new in GCC 13 and so I think we should make -fsanitize=bounds
play with it well from the beginning.

The current behavior is that -fsanitize=bounds considers all trailing
arrays as flexible member-like arrays and both -fsanitize=bounds and
-fsanitize=bounds-strict because of a bug don't even instrument
[0] arrays at all, not as trailing nor when followed by other members.

I think -fstrict-flex-arrays* options can be considered as language
mode changing options, by default flexible member-like arrays are
handled like flexible arrays, but that option can change the set of
the arrays which are treated like that.  So, -fsanitize=bounds should
change with that on what is considered acceptable and what isn't.
While -fsanitize=bounds-strict should reject them all always to
continue previous behavior.

The following patch implements that.  To support [0] array instrumentation,
I had to change the meaning of the bounds argument to .UBSAN_BOUNDS,
previously it was the TYPE_MAX_VALUE of the domain unless ignore_off_by_one
(used for taking address of the array element rather than accessing it;
in that case 1 is added to the bound argument) and the later lowered checks
were if (index > bound) report_failure ().
The problem with that is that for [0] arrays where (at least for C++)
the max value is all ones, for accesses that condition will be never true;
for addresses of elements it was working (in C++) correctly before.
This patch changes it to add 1 + ignore_off_by_one, so -1 becomes 0 or
1 for &array_ref and changing the lowering to be if (index >= bound)
report_failure ().  Furthermore, as C represents the [0] arrays with
NULL TYPE_MAX_VALUE, I treated those like the C++ ones.

2023-02-28  Jakub Jelinek  <jakub@redhat.com>

	PR sanitizer/108894
gcc/
	* ubsan.cc (ubsan_expand_bounds_ifn): Emit index >= bound
	comparison rather than index > bound.
	* gimple-fold.cc (gimple_fold_call): Use tree_int_cst_lt
	rather than tree_int_cst_le for IFN_UBSAN_BOUND comparison.
	* doc/invoke.texi (-fsanitize=bounds): Document that whether
	flexible array member-like arrays are instrumented or not depends
	on -fstrict-flex-arrays* options of strict_flex_array attributes.
	(-fsanitize=bounds-strict): Document that flexible array members
	are not instrumented.
gcc/c-family/
	* c-common.h (c_strict_flex_array_level_of): Declare.
	* c-common.cc (c_strict_flex_array_level_of): New function,
	moved and renamed from c-decl.cc's strict_flex_array_level_of.
	* c-ubsan.cc (ubsan_instrument_bounds): Fix comment typo.  For
	C check c_strict_flex_array_level_of whether a trailing array
	should be treated as flexible member like.  Handle C [0] arrays.
	Add 1 + index_off_by_one rather than index_off_by_one to bounds
	and use tree_int_cst_lt rather than tree_int_cst_le for idx vs.
	bounds comparison.
gcc/c/
	* c-decl.cc (strict_flex_array_level_of): Move to c-common.cc
	and rename to c_strict_flex_array_level_of.
	(is_flexible_array_member_p): Adjust caller.
gcc/testsuite/
	* gcc.dg/ubsan/bounds-4.c: New test.
	* gcc.dg/ubsan/bounds-4a.c: New test.
	* gcc.dg/ubsan/bounds-4b.c: New test.
	* gcc.dg/ubsan/bounds-4c.c: New test.
	* gcc.dg/ubsan/bounds-4d.c: New test.
	* g++.dg/ubsan/bounds-1.C: New test.

The following properly uses __SIZETYPE__ for pointer offsets.

	PR testsuite/108942
	* gcc.dg/torture/ssa-fre-7.c: Use __SIZETYPE__.

This implements LWG 3527 which fixes the handling of pair<T&&, U&&> in
std::uses_allocator_construction_args.

libstdc++-v3/ChangeLog:

	PR libstdc++/108952
	* include/bits/uses_allocator_args.h
	(uses_allocator_construction_args): Implement LWG 3527.
	* testsuite/20_util/pair/astuple/get-2.cc: New test.
	* testsuite/20_util/scoped_allocator/108952.cc: New test.
	* testsuite/20_util/uses_allocator/lwg3527.cc: New test.

This avoids overwriting tail padding when algorithms like std::copy are
used to write a single value through a pointer to a base subobject.

The pointer arithmetic on a Base* is valid for N==1, but the copy/move
operation needs to be done using assignment, not a memmove or memcpy of
sizeof(Base) bytes.

Instead of putting a check for N==1 in all of copy, copy_n, move etc.
this adds it to the __copy_move and __copy_move_backward partial
specializations used for trivially copyable types. When N==1 those
partial specializations dispatch to new static member functions of the
partial specializations for non-trivial types, so that a copy/move
assignment is done appropriately for the _IsMove constant.

libstdc++-v3/ChangeLog:

	PR libstdc++/108846
	* include/bits/stl_algobase.h (__copy_move<false, false, RA>)
	Add __assign_one static member function.
	(__copy_move<true, false, RA>): Likewise.
	(__copy_move<IsMove, true, RA>): Do not use memmove for a single
	value.
	(__copy_move_backward<IsMove, true, RA>): Likewise.
	* testsuite/25_algorithms/copy/108846.cc: New test.
	* testsuite/25_algorithms/copy_backward/108846.cc: New test.
	* testsuite/25_algorithms/copy_n/108846.cc: New test.
	* testsuite/25_algorithms/move/108846.cc: New test.
	* testsuite/25_algorithms/move_backward/108846.cc: New test.

For the common case of converting valid text this improves performance
significantly.

libstdc++-v3/ChangeLog:

	* src/c++11/codecvt.cc: Add [[likely]] and [[unlikely]]
	attributes.

Set sstride[0] and mstride[0] to zero, eliminating some warnings.

libgfortran/ChangeLog:

	* generated/pack_c10.c (pack_c10): Regenerated.
	* generated/pack_c16.c (pack_c16): Regenerated.
	* generated/pack_c17.c (pack_c17): Regenerated.
	* generated/pack_c4.c (pack_c4): Regenerated.
	* generated/pack_c8.c (pack_c8): Regenerated.
	* generated/pack_i1.c (pack_i1): Regenerated.
	* generated/pack_i16.c (pack_i16): Regenerated.
	* generated/pack_i2.c (pack_i2): Regenerated.
	* generated/pack_i4.c (pack_i4): Regenerated.
	* generated/pack_i8.c (pack_i8): Regenerated.
	* generated/pack_r10.c (pack_r10): Regenerated.
	* generated/pack_r16.c (pack_r16): Regenerated.
	* generated/pack_r17.c (pack_r17): Regenerated.
	* generated/pack_r4.c (pack_r4): Regenerated.
	* generated/pack_r8.c (pack_r8): Regenerated.
	* generated/spread_c10.c (spread_c10): Regenerated.
	* generated/spread_c16.c (spread_c16): Regenerated.
	* generated/spread_c17.c (spread_c17): Regenerated.
	* generated/spread_c4.c (spread_c4): Regenerated.
	* generated/spread_c8.c (spread_c8): Regenerated.
	* generated/spread_i1.c (spread_i1): Regenerated.
	* generated/spread_i16.c (spread_i16): Regenerated.
	* generated/spread_i2.c (spread_i2): Regenerated.
	* generated/spread_i4.c (spread_i4): Regenerated.
	* generated/spread_i8.c (spread_i8): Regenerated.
	* generated/spread_r10.c (spread_r10): Regenerated.
	* generated/spread_r16.c (spread_r16): Regenerated.
	* generated/spread_r17.c (spread_r17): Regenerated.
	* generated/spread_r4.c (spread_r4): Regenerated.
	* generated/spread_r8.c (spread_r8): Regenerated.
	* intrinsics/execute_command_line.c (execute_command_line_i4),
	(execute_command_line_i8): Set estat_initial to zero.
	* intrinsics/pack_generic.c (pack_internal): Set sstride[0] and
	mstride[0] to zero.
	* intrinsics/spread_generic.c (spread_internal): Set sstride[0].
	* m4/pack.m4: Set sstride[0] and mstride[0].
	* m4/spread.m4: Set sstride[0].

There are no messages about padding for targets that don't
pad, i.e. default_packed.  Noticed for cris-elf, verified
for pru-elf at gcc-testresults@.

testsuite:
	* gcc.dg/plugin/infoleak-vfio_iommu_type1.c: Don't xfail bogus
	message for "default_packed" targets.

As recommended by testsuite maintainer: Regression analysis
works only if the string is the same.

testsuite:
	* lib/multiline.exp (handle-multiline-outputs): Shorten
	message to the same for fail and pass.

Reacting to a long-standing XPASS for CRIS.  This one is
slightly brown paper-bag level; it was never the here-removed
xfailed scan that failed and I didn't notice that XPASS when
reporting success on the commit as a whole.  It's not logical to
re-read what was just-written even with overlap issues, and I'm
sure that edit was originally a copy-pasto.  I checked
historical m68k-linux and pru-elf test-results too, to verify
that I got that part right.

	PR testsuite/91419
	* gcc.dg/tree-ssa/pr91091-2.c:15 Remove xfail for RHS.

	* sr.po, sv.po: Update.

Reacting to a long-standing XPASS for CRIS.  Maybe better do
as https://gcc.gnu.org/PR79356#c11 suggests: xfail it for
x86 only ...except I see m68k also does not xpass.

testsuite:
	PR testsuite/79356
	* gcc.dg/attr-alloc_size-11.c: Add CRIS to the list
	of targets excluding xfail on lines 50 and 51.

For cris-elf before this patch, ever since it was added,
this test gets:

Running /x/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 115)
FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 116)

and comparing tree dumps with a native x86_64-pc-linux-gnu
run shows a suspicious difference in the "180t.ivopts" dump.
Indeed -fno-ivopts makes the warning appear for cris-elf
too.  It was suggested to simply add -fno-ivopts to the
test-flags, like before -fno-tree-loop-distribute-patterns
was added; thus.

	PR tree-optimization/108828
	* gcc.dg/Wuse-after-free-2.c: Add -fno-ivopts.

gcc/fortran/ChangeLog:

	PR fortran/108937
	* trans-intrinsic.cc (gfc_conv_intrinsic_ibits): Handle corner case
	LEN argument of IBITS equal to BITSIZE(I).

gcc/testsuite/ChangeLog:

	PR fortran/108937
	* gfortran.dg/ibits_2.f90: New test.

According to Intel ISA manual, fprem and fprem1 return NaN when invalid
arithmetic exception is generated. This is documented in Table 8-10 of the
ISA manual and makes these two instructions fully IEEE compatible.

The reverted patch was based on the data from table 3-30 and 3-31 of the
Intel ISA manual, where results in case of st(0) being infinity or
st(1) being 0 are not specified.

2023-02-27  Uroš Bizjak  <ubizjak@gmail.com>

gcc/ChangeLog:

	PR target/108922
	Revert:
	* config/i386/i386.md (fmodxf3): Enable for flag_finite_math_only only.
	(fmod<mode>3): Ditto.
	(fpremxf4_i387): Ditto.
	(reminderxf3): Ditto.
	(reminder<mode>3): Ditto.
	(fprem1xf4_i387): Ditto.

In 2011, the rtl.texi documentation was updated to reflect that the
modes of the RTX unary operations FFS, POPCOUNT and PARITY should
match those of their operands.  Unfortunately, some of the transformations
in simplify-rtx.cc predate this tightening of RTL semantics, and have
not (until now) been updated/fixed.  i.e. The POPCOUNT and PARITY
optimizations were "correct" when I added them back in 2007.

2023-02-27  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
	* simplify-rtx.cc (simplify_unary_operation_1) <case FFS>: Avoid
	generating FFS with mismatched operand and result modes, by using
	an explicit SIGN_EXTEND/ZERO_EXTEND.
	<case POPCOUNT>: Likewise, for POPCOUNT of ZERO_EXTEND.
	<case PARITY>: Likewise, for PARITY of {ZERO,SIGN}_EXTEND.

The pattern parameter to memset is second.  Correct an obvious mistake
in libm2pim/sckt.cc.

libgm2/ChangeLog:

	PR modula2/108944
	* libm2pim/sckt.cc (getLocalIP): Correct parameter order.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

This fixes some header-defined functions that are undesirably declared
static and weren't caught by the "^static inline" pattern used for the
main patch r13-6096-gcb3e0eac262e55.

gcc/ChangeLog:

	* hash-table.h (gt_pch_nx(hash_table<D>)): Remove static.
	* lra-int.h (lra_change_class): Likewise.
	* recog.h (which_op_alt): Likewise.
	* sel-sched-ir.h (sel_bb_empty_or_nop_p): Declare inline
	instead of static.

This is a complicated API that should be clearly documented.

Also improve the comment on basic_ios::_M_setstate.

libstdc++-v3/ChangeLog:

	* include/bits/basic_ios.h (basic_ios::_M_setstate): Add
	caveat to comment.
	* include/bits/basic_string.h (resize_and_overwrite): Add
	doxygen comment.

This patch introduces the use of CLAMPS instruction when the instruction
is configured.

    /* example */
    int test(int a) {
      if (a < -512)
        return -512;
      if (a > 511)
        return 511;
      return a;
    }

    ;; prereq: TARGET_CLAMPS
    test:
	clamps	a2, a2, 9
	ret.n

gcc/ChangeLog:

	* config/xtensa/xtensa-protos.h (xtensa_match_CLAMPS_imms_p):
	New prototype.
	* config/xtensa/xtensa.cc (xtensa_match_CLAMPS_imms_p):
	New function.
	* config/xtensa/xtensa.h (TARGET_CLAMPS): New macro definition.
	* config/xtensa/xtensa.md (*xtensa_clamps): New insn pattern.

gcc/
	* config/xtensa/xtensa-dynconfig.cc (xtensa_get_config_v2)
	(xtensa_get_config_v3): New functions.

include/
	* xtensa-dynconfig.h (xtensa_config_v3): New struct.
	(xtensa_get_config_v3): New declaration.
	(XCHAL_HAVE_CLAMPS, XCHAL_HAVE_DEPBITS, XCHAL_HAVE_EXCLUSIVE)
	(XCHAL_HAVE_XEA3, XTENSA_CONFIG_V3_ENTRY_LIST): New definitions.
	(XTENSA_CONFIG_INSTANCE_LIST): Add xtensa_config_v3 instance.
	(XTENSA_CONFIG_ENTRY_LIST): Add XTENSA_CONFIG_V3_ENTRY_LIST.

gcc/ChangeLog:

	* config/aarch64/aarch64-simd.md (aarch64_abs<mode>): Fix typo in comment.

The PCH mechanism first tries to map the .gch file to the virtual memory
space pointed to by TRY_EMPTY_VM_SPACE during the compilation process.

The original value of TRY_EMPTY_VM_SPACE macro is 0x8000000000,
but like la464 only has 40 bits of virtual address space, this value
just exceeds the address range.

If we want to support chips with less than 40 bits virtual addresses,
then the value of this macro needs to be set small. I think setting
this value small will increase the probability of virtual address
mapping failure. And the purpose of pch is to make compilation faster,
but I think we rarely compile on embedded systems. So this situation
may not be within our consideration.

So change the value of this macro to 0x1000000000.

gcc/ChangeLog:

	* config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value of
	the macro to 0x1000000000.

gcc/ada/
	PR ada/108909
	* Make-generated.in: Use GNATMAKE.
	* gcc-interface/Makefile.in: Ditto.