This patch introduces a convenience wrapper tsubst_scope for tsubst'ing
into a type with tf_qualifying_scope set, and makes suitable callers use
it instead of explicitly setting tf_qualifying_scope.  This patch also
makes tsubst_copy immediately delegate to tsubst for all type trees,
which allows tsubst_copy to be oblivious to the tf_qualifying_scope flag.

gcc/cp/ChangeLog:

	* pt.cc (tsubst_scope): Define.
	(tsubst_decl) <case USING_DECL>: Call tsubst_scope instead of
	calling tsubst_scope with tf_qualifying_scope set.
	(tsubst_qualified_id): Call tsubst_scope instead of
	calling tsubst with tf_qualifying_scope set.
	(tsubst_copy): Immediately delegate to tsubst for all TYPE_P
	trees.  Remove tf_qualifying_scope manipulation.
	<case SCOPE_REF>: Call tsubst_scope instead of calling
	tsubst with tf_qualifying_scope set.

Previously, if the analyzer saw a call to a non-pure and non-const
built-in function that it didn't have explicit knowledge of the behavior
of, it would fall back to assuming that the builtin could have arbitrary
behavior, similar to a function defined outside of the current TU.

However, this only worked for BUILTIN_NORMAL functions that matched
gimple_builtin_call_types_compatible_p; for BUILT_IN_FRONTEND and
BUILT_IN_MD, and for mismatched types the analyzer would erroneously
assume that the builtin had no side-effects, leading e.g. to
PR analyzer/107565, where the analyzer falsely reported that x
was still uninitialized after this target-specific builtin:

  _1 = __builtin_ia32_rdrand64_step (&x);

This patch generalizes the handling to cover all classes of builtin,
fixing the above false positive.

Unfortunately this patch regresses gcc.dg/analyzer/pr99716-1.c due to
the:
  fprintf (fp, "hello");
being optimized to:
   __builtin_fwrite ("hello", 1, (ssizetype)5, fp_6);
and the latter has gimple_builtin_call_types_compatible_p return false,
whereas the original call had it return true.  I'm assuming that this is
an optimization bug, and have filed it as PR middle-end/108988.  The
effect on the analyzer is that it fails to recognize the call to
__builtin_fwrite and instead assumes arbitraty side-effects (including
that it could call fclose on fp, hence the report about the leak goes
away).

I tried various more involved fixes with new heuristics for handling
built-ins that aren't explicitly covered by the analyzer, but those
fixes tended to introduce many more regressions, so I'm going with this
simpler fix.

gcc/analyzer/ChangeLog:
	PR analyzer/107565
	* region-model.cc (region_model::on_call_pre): Flatten logic by
	returning early.  Consolidate logic for detecting const and pure
	functions.  When considering whether an unhandled built-in
	function has side-effects, consider all kinds of builtin, rather
	than just BUILT_IN_NORMAL, and don't require
	gimple_builtin_call_types_compatible_p.

gcc/testsuite/ChangeLog:
	PR analyzer/107565
	* gcc.dg/analyzer/builtins-pr107565.c: New test.
	* gcc.dg/analyzer/pr99716-1.c (test_2): Mark the leak as xfailing.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

libstdc++-v3/ChangeLog:

	* include/bits/cow_string.h: Fix typo in comment.

This is consistent with the behaviour of glibc, which assumes UTC when
/etc/localtime and TZ do not identify a valid time zone. The fallback
tzdb used when no valid tzdata exists always contains the UTC zone, so
this change means we have a valid tzdb and valid current zone even in
the degenerate case.

With this default we no longer need the AIX-specific kluge to try and
identify TZ values specifying a 0-offset zone. We can just use the UTC
default for those, as it has the same effect.

It's still possible for chrono::current_zone() to fail, because the user
could have provided a custom tzdata.zi file which doesn't contain the
UTC time zone, so the "UTC" default would fail to find a valid zone, and
throw an exception. That's just user error, they should not provide bad
data and expect reasonable behaviour.

libstdc++-v3/ChangeLog:

	* src/c++20/tzdb.cc (chrono::tzdb::current_zone()) Use "UTC" if
	current time zone cannot be determined.
	* testsuite/std/time/tzdb/1.cc: Remove conditions based on
	HAVE_TZDB macro and test all members unconditionally.

Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts.  This shouldn't make a difference
here since the array sizes are constant literals, except they're expressed
as NON_LVALUE_EXPR location wrappers around INTEGER_CST, wrappers which
used to get stripped as part of constant evaluation and now no longer do.
Moreover it means build_vec_init can't constant fold the MINUS_EXPR
'maxindex' passed from build_new_1 when in an unevaluated context (since
it tries reducing it via maybe_constant_value called with mce_unknown).

This patch fixes these issues by making maybe_constant_value (and
fold_non_dependent_expr) try folding an unevaluated non-manifestly-constant
operand via fold(), as long as it simplifies to a simple constant, rather
than doing no simplification at all.  This covers e.g. simple arithmetic
and casts including stripping of location wrappers around INTEGER_CST.

In passing, this patch also fixes maybe_constant_value to avoid constant
evaluating an unevaluated operand when called with mce_false, by adjusting
the early exit test appropriately.

Co-authored-by: Jason Merrill <jason@redhat.com>

	PR c++/108219
	PR c++/108218

gcc/cp/ChangeLog:

	* constexpr.cc (fold_to_constant): Define.
	(maybe_constant_value): Move up early exit test for unevaluated
	operands.  Try reducing an unevaluated operand to a constant via
	fold_to_constant.
	(fold_non_dependent_expr_template): Add early exit test for
	CONSTANT_CLASS_P nodes.  Try reducing an unevaluated operand
	to a constant via fold_to_constant.
	* cp-tree.h (fold_to_constant): Declare.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/new6.C: New test.
	* g++.dg/cpp2a/concepts-new1.C: New test.

With volatile, two 'x.data' comp refs aren't regarded as identical,
causing that the two items in the first map of
  map(to:x.a, x.a.data) map(pset: x.a.data)
end up in separate 'map(struct:x)', which will cause a later ICE.

Solution: Ignore side effects when checking the operands in the hash
for being equal. (Do so by creating a variant of tree_operand_hash
that calls operand_equal_p with OEP_MATCH_SIDE_EFFECTS.)

gcc/ChangeLog:

	PR middle-end/108545
	* gimplify.cc (struct tree_operand_hash_no_se): New.
	(omp_index_mapping_groups_1, omp_index_mapping_groups,
	omp_reindex_mapping_groups, omp_mapped_by_containing_struct,
	omp_tsort_mapping_groups_1, omp_tsort_mapping_groups,
	oacc_resolve_clause_dependencies, omp_build_struct_sibling_lists,
	gimplify_scan_omp_clauses): Use tree_operand_hash_no_se instead
	of tree_operand_hash.

gcc/testsuite/ChangeLog:

	PR middle-end/108545
	* c-c++-common/gomp/map-8.c: New test.
	* gfortran.dg/gomp/map-9.f90: New test.

gcc/analyzer/ChangeLog:
	PR analyzer/108935
	* infinite-recursion.cc (contains_unknown_p): New.
	(sufficiently_different_region_binding_p): New function, splitting
	out inner loop from...
	(sufficiently_different_p): ...here.  Extend detection of unknown
	svalues to also include svalues that contain unknown.  Treat
	changes in frames below the entry to the recursion as being
	sufficiently different to reject being an infinite recursion.

gcc/testsuite/ChangeLog:
	PR analyzer/108935
	* gcc.dg/analyzer/infinite-recursion-pr108935-1.c: New test.
	* gcc.dg/analyzer/infinite-recursion-pr108935-1a.c: New test.
	* gcc.dg/analyzer/infinite-recursion-pr108935-2.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

PCHs can now be relocated, so the size limit makes no sense any more.

This patch was submited to MSYS2 9 months ago for GCC 12. No issue has been reported so far.

Reference: https://github.com/msys2/MINGW-packages/blob/717d5a5a09e2370e3bd7e12b393a26dbfbe48921/mingw-w64-gcc/0010-Fix-using-large-PCH.patch


Signed-off-by: LIU Hao <lh_mouse@126.com>

gcc/ChangeLog:

	PR pch/14940
	* config/i386/host-mingw32.cc (mingw32_gt_pch_get_address):
	Remove the size limit `pch_VA_max_size`

Signed-off-by: Jonathan Yong <10walls@gmail.com>

gcc/testsuite/ChangeLog:

	* gcc.target/i386/harden-sls-6.c: Fix warning on LLP64
	targets.

Signed-off-by: Jonathan Yong <10walls@gmail.com>

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.