gcc/fortran/ChangeLog:

	PR fortran/99884
	* io.cc (check_open_constraints): Remove double spaces.

sbitmap is a simple bitmap and the memory allocated is not cleared
on creation; you have to clear it or set it to all ones before using
it.  This is unlike bitmap which is a sparse bitmap and the entries are
cleared as created.
The code added in r13-4044-gdc95e1e9702f2f missed that.
This patch fixes that mistake.

Committed as obvious after a bootstrap and test on x86_64-linux-gnu.

gcc/ChangeLog:

	PR middle-end/107734
	* match.pd (perm + vector op pattern): Clear the sbitmap before
	use.

The threader is creating a scenario where we are trying to solve:

	[NEGATIVES] = abs(x)

While solving this we have an intermediate value of UNDEFINED because
we have no positive numbers.  But then we try to union the negative
pair to the final result by querying the bounds.  Since neither
UNDEFINED nor NAN have bounds, they need to be specially handled.

	PR tree-optimization/107732

gcc/ChangeLog:

	* range-op-float.cc (foperator_abs::op1_range): Early exit when
	result is undefined.

gcc/testsuite/ChangeLog:

	* gcc.dg/tree-ssa/pr107732.c: New test.

PR analyzer/107711 reports an ICE since r13-4073-gd8aba860b34203 with
the combination of -fanalyzer and -Wunused-macros.

The issue is that in c_translation_unit::consider_macro's call to
cpp_create_reader I was passing "ident_hash" for use by the the new
reader, but that takes ownership of that hash_table, so that ident_hash
erroneously gets freed when c_translation_unit::consider_macro calls
cpp_destroy, leading to a use-after-free in -Wunused-macros, where:

(gdb) p pfile->hash_table->pfile == pfile
$23 = false

and it's instead pointing at the freed reader from consider_macro,
leading to a use-after-free ICE.

Fixed thusly.

gcc/c/ChangeLog:
	PR analyzer/107711
	* c-parser.cc (ana::c_translation_unit::consider_macro): Pass NULL
	to cpp_create_reader, rather than ident_hash, so that the new
	reader gets its own hash table.

gcc/testsuite/ChangeLog:
	PR analyzer/107711
	* gcc.dg/analyzer/named-constants-Wunused-macros.c: New test.

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

Add a split for cases where we can use two bclri (or one bclri and an
andi) to clear two bits.

gcc/ChangeLog:

	* config/riscv/bitmanip.md (*bclri<mode>_nottwobits): New pattern.
	(*bclridisi_nottwobits): New pattern, handling the sign-bit.
	* config/riscv/predicates.md (const_nottwobits_operand):
	New predicate.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/zbs-bclri.c: New test.

Consider creating a polarity-reversed mask from a set-bit (i.e., if
the bit is set, produce all-ones; otherwise: all-zeros).  Using Zbb,
this can be expressed as bexti, followed by an addi of minus-one.  To
enable the combiner to discover this opportunity, we need to split the
canonical expression for "(a & (1 << BIT_NO)) ? 0 : -1" into a form
combinable into bexti.

Consider the function:
    long f(long a)
    {
      return (a & (1 << BIT_NO)) ? 0 : -1;
    }
This produces the following sequence prior to this change:
	andi	a0,a0,16
	seqz	a0,a0
	neg	a0,a0
	ret
Following this change, it results in:
	bexti	a0,a0,4
	addi	a0,a0,-1
	ret

gcc/ChangeLog:

	* config/riscv/bitmanip.md: Add a splitter to generate
	  polarity-reversed masks from a set bit using bexti + addi.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/zbs-bexti.c: New test.

This commit implements the target macros (TARGET_SHRINK_WRAP_*) that
enable separate shrink wrapping for function prologues/epilogues in
RISC-V.

Tested against SPEC CPU 2017, this change always has a net-positive
effect on the dynamic instruction count.  See the following table for
the breakdown on how this reduces the number of dynamic instructions
per workload on a like-for-like (i.e., same config file; suppressing
shrink-wrapping with -fno-shrink-wrap):

                             # dynamic instructions
                w/o shrink-wrap   w/ shrink-wrap      reduction
500.perlbench_r   1265716786593    1262156218578     3560568015   0.28%
500.perlbench_r    779224795689     765337009025    13887786664   1.78%
500.perlbench_r    724087331471     711307152522    12780178949   1.77%
502.gcc_r          204259864844     194517006339     9742858505   4.77%
502.gcc_r          244047794302     231555834722    12491959580   5.12%
502.gcc_r          230896069400     221877703011     9018366389   3.91%
502.gcc_r          192130616624     183856450605     8274166019   4.31%
502.gcc_r          258875074079     247756203226    11118870853   4.30%
505.mcf_r          662653430325     660678680547     1974749778   0.30%
520.omnetpp_r      985114167068     934191310154    50922856914   5.17%
523.xalancbmk_r    927037633578     921688937650     5348695928   0.58%
525.x264_r         490953958454     490565583447      388375007   0.08%
525.x264_r        1994662294421    1993171932425     1490361996   0.07%
525.x264_r        1897617120450    1896062750609     1554369841   0.08%
531.deepsjeng_r   1695189878907    1669304130411    25885748496   1.53%
541.leela_r       1925941222222    1897900861198    28040361024   1.46%
548.exchange2_r   2073816227944    2073816226729           1215   0.00%
557.xz_r           379572090003     379057409041      514680962   0.14%
557.xz_r           953117469352     952680431430      437037922   0.05%
557.xz_r           536859579650     536456690164      402889486   0.08%
                 18421773405376   18223938521833   197834883543   1.07%  totals

Signed-off-by: Manolis Tsamis <manolis.tsamis@vrull.eu>

gcc/ChangeLog:

	* config/riscv/riscv.cc (struct machine_function): Add array to store
	register wrapping information.
	(riscv_for_each_saved_reg): Skip registers that are wrapped separetely.
	(riscv_get_separate_components): New function.
	(riscv_components_for_bb): Likewise.
	(riscv_disqualify_components): Likewise.
	(riscv_process_components): Likewise.
	(riscv_emit_prologue_components): Likewise.
	(riscv_emit_epilogue_components): Likewise.
	(riscv_set_handled_components): Likewise.
	(TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS): Define.
	(TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB): Likewise.
	(TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS): Likewise.
	(TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS): Likewise.
	(TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS): Likewise.
	(TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Likewise.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/shrink-wrap-1.c: New test.

Add an extra safety check as suggested by Richard.
Tested on aarch64-none-linux-gnu.

gcc/ChangeLog:

	* config/aarch64/atomics.md (*aarch64_atomic_load<ALLX:mode>_rcpc_zext):
	Add mode size check to condition.
	(*aarch64_atomic_load<ALLX:mode>_rcpc_sext): Likewise.

It irks me that a PR named "we should track ranges for floating-point
hasn't been closed in this release.  This is an attempt to do just
that.

As mentioned in the PR, even though we track ranges for floats, it has
been suggested that avoiding recursing through SSA defs in
gimple_assign_nonnegative_warnv_p is also a goal.  This patch uses a
global range query (no on-demand lookups, just global ranges and
minimal folding) to determine if the range of a statement is known to
be non-negative.

	PR tree-optimization/68097

gcc/ChangeLog:

	* gimple-fold.cc (gimple_stmt_nonnegative_warnv_p): Call
	range_of_stmt for floats.

gcc/ChangeLog:

	* config/i386/x86-tune.def
	(X86_TUNE_AVX256_MOVE_BY_PIECES): Add alderlake.
	(X86_TUNE_AVX256_STORE_BY_PIECES): Ditto.

gcc/testsuite/ChangeLog:

	* gcc.target/i386/pieces-memset-50.c: New test.

At the moment when the VEC_PERMs generated by this match.pd rule is generated
it creates two different SSA_NAMEs for the folded operand.  Because of this it
the permute switches from a single operand permute to a two operand permute and
the target may no longer support a permute for this.

This fixes it by ensuring we generate the same SSA_NAME for both operands.

gcc/ChangeLog:

	PR tree-optimization/107717
	* match.pd: Ensure same SSA_NAME.

gcc/testsuite/ChangeLog:

	PR tree-optimization/107717
	* gcc.target/aarch64/sve2/pr107717.c: New test.

After the fix to the addsub patch yesterday for bootstrap I had only regtested on x86.
While looking today it seemed the new tests were failing, this was caused
by a change in the behavior of the GET_MODE_WIDER_MODE macro on trunk.

gcc/ChangeLog:

	* match.pd: Replace GET_MODE_WIDER_MODE with
	custom code.

gcc/ChangeLog:

	* range-op-float.cc (range_operator_float::fold_range): Make check
	for maybe_isnan more readable.

As Robin spotted, my recent commit r13-3716 caused an ICE
on s390 if vector access with length is enabled there (his
patch for the enablement hasn't been committed yet).  The
failure is caused by one stupid typo, the bias on s390 is
-1, so the assertion should use tree_fits_shwi_p rather
than tree_fits_uhwi_p.  Thanks for Robin's catching.

I just reproduced the ICE and verified the fix worked fine
with a cross build, the optimized dump against the test case
gcc.target/powerpc/pr107412.c looked expected.

gcc/ChangeLog:

	* gimple-fold.cc (gimple_fold_partial_load_store_mem_ref): Use
	tree_fits_shwi_p rather than tree_fits_uhwi_p as bias is signed.

Sometimes "step1 -= scalable_frame" will cause adjust equal to
zero. And it will generate additional redundant instruction
"addi sp,sp,0". Add checking segement to skip that case.

This testcase mix exist spill-1.c and adding new fun to check if
there have redundant addi intructions. Idea provided by Jeff Law.

gcc/ChangeLog:

	* config/riscv/riscv.cc (riscv_expand_epilogue):
	Do not emit useless add sp, sp, 0 instrutions.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/spill-sp-adjust.c: New test.

So my tester started showing even more regressions on the sh3/sh4 runs
recently (beyond the one recently reported in BZ triggered by some DCE
related changes).  Bisection kept showing inconsistent results.  I was
starting to think memory management error, but valgrind didn't flag anything.

After a bit of head-banging I was able to track it down to predicate
tests called from the SH specific combiner passes.  And once I started
getting inside the actual code for the predicate function it became
pretty obvious.  The predicate routines are supposed to return a bool,
fine and they dutifully set the low bit in %eax properly.

The *caller* was looking at the full register.  Uh-oh.  Naturally we
became dependent on what happened to be in the upper 31 bits of a register.
That's why the bug would come and go so willy-nilly.  This was ultimately
chased down to an incorrect prototype in sh_treg_combine.cc for predicate
functions defined via define_predicate.

Removing the bogus prototypes and instead including the generated
tm-preds.h fixes this problem.  I also checked the other ports for
similar problems (specifically looking for a extern int.*_operand, then
for each of the hits looking to see if the predicate was defined via
define_predicate).  No other ports had similar braindamage.

This fixes the most recent regressions in my tester for sh3/sh3eb
and I strongly suspect sh4.  It does not fix 107704, but I think
Richi and I both agree that's a visitation order issue and we were
just getting lucky before.

gcc/

	* config/sh/sh_treg_combine.cc: Include tm-preds.h.
	(t_reg_operand): Remove bogus prototype.
	(negt_reg_operand): Likewise.

For powerpc64le we need to be able to format both of __ieee128 and
__ibm128, so we need the std::to_chars overloads for both types to be
visible at once. The __ieee128 overloads are always visible in C++23
mode, because they're used to implement the _Float128 overloads. The
__ibm128 overloads are only visible when long double is __ibm128.

libstdc++-v3/ChangeLog:

	PR libstdc++/107720
	* include/std/format [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT]:
	Declare overloads of std::to_chars for the alternative long
	double type.

gcc/testsuite/ChangeLog:
	* gcc.dg/analyzer/named-constants-via-command-line.c: New test.
	* gcc.dg/analyzer/named-constants-via-macros-3.c: New test.
	* gcc.dg/analyzer/named-constants-via-macros-4.c: New test.
	* gcc.dg/analyzer/named-constants-via-macros-empty.c: New test.
	* gcc.dg/analyzer/named-constants-via-macros-gc.c: New test.
	* gcc.dg/analyzer/named-constants-via-macros-traditional.c: New test.
	* gcc.dg/analyzer/named-constants-via-macros-undef.c: New test.

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

PR analyzer/107711 seems to be a bug in how named constants are looked up
by the analyzer in the C frontend.

To help debug this, this patch extends -fdump-analyzer and
-fdump-analyzer-stderr so that they dump this part of the analyzer's
startup.

gcc/analyzer/ChangeLog:
	PR analyzer/107711
	* analyzer-language.cc: Include "diagnostic.h".
	(maybe_stash_named_constant): Add logger param and use it to log
	the name being looked up, and the result.
	(stash_named_constants): New, splitting out from...
	(on_finish_translation_unit): ...this function.  Call
	get_or_create_logfile and use the result to create a logger
	instance, passing it to stash_named_constants.
	* analyzer.h (get_or_create_any_logfile): New decl.
	* engine.cc (dump_fout, owns_dump_fout): New globals, split out
	from run_checkers.
	(get_or_create_any_logfile): New function, split out from...
	(run_checkers): ...here, so that the logfile can be opened by
	on_finish_translation_unit.  Clear the globals when closing the
	dump file.

gcc/testsuite/ChangeLog:
	PR analyzer/107711
	* gcc.dg/analyzer/fdump-analyzer-1.c: New test.

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

gcc/fortran/ChangeLog:

	PR fortran/107707
	* interface.cc (gfc_compare_actual_formal): Check that we actually
	have integer values before asking gmp_* to use them.

gcc/testsuite/ChangeLog:

	PR fortran/107707
	* gfortran.dg/pr107707.f90: New test.

This patch implements C++23 P2448, which lifts more restrictions on the
constexpr keyword.  It's effectively going the way of being just a hint
(hello, inline!).

This gist is relatively simple: in C++23, a constexpr function's return
type/parameter type doesn't have to be a literal type; and you can have
a constexpr function for which no invocation satisfies the requirements
of a core constant expression.  For example,

  void f(int& i); // not constexpr

  constexpr void g(int& i) {
    f(i); // unconditionally calls a non-constexpr function
  }

is now OK, even though there isn't an invocation of 'g' that would be
a constant expression.  Maybe 'f' will be made constexpr soon, or maybe
this depends on the version of C++ used, and similar.  The patch is
unfortunately not that trivial.  The important bit is to use the new
require_potential_rvalue_constant_expression_fncheck in
maybe_save_constexpr_fundef (and where appropriate).  It has a new flag
that says that we're checking the body of a constexpr function, and in
that case it's OK to find constructs that aren't a constant expression.

Since it's useful to be able to check for problematic constructs even
in C++23, this patch implements a new warning, -Winvalid-constexpr,
which is a pedwarn turned on by default in C++20 and earlier, and which
can be turned on in C++23 as well, in which case it's an ordinary warning.
This I implemented by using the new function constexpr_error, used in
p_c_e_1 and friends.  (In some cases I believe fundef_p will be always
false (= hard error), but it made sense to me to be consistent and use
constexpr_error throughout p_c_e_1.)

While working on this I think I found a bug, see constexpr-nonlit15.C
and <https://gcc.gnu.org/PR107598>.  This patch doesn't address that.

This patch includes changes to diagnose the problem if the user doesn't
use -Winvalid-constexpr and calls a constexpr function that in fact isn't
constexpr-ready yet: maybe_save_constexpr_fundef registers the function
if warn_invalid_constexpr is 0 and explain_invalid_constexpr_fn then
gives the diagnostic.

	PR c++/106649

gcc/c-family/ChangeLog:

	* c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_constexpr for
	C++23.
	* c-opts.cc (c_common_post_options): Set warn_invalid_constexpr
	depending on cxx_dialect.
	* c.opt (Winvalid-constexpr): New option.

gcc/cp/ChangeLog:

	* constexpr.cc (constexpr_error): New function.
	(is_valid_constexpr_fn): Use constexpr_error.
	(maybe_save_constexpr_fundef): Call
	require_potential_rvalue_constant_expression_fncheck rather than
	require_potential_rvalue_constant_expression.  Register the
	function if -Wno-invalid-constexpr was specified.
	(explain_invalid_constexpr_fn): Don't return early if a function marked
	'constexpr' that isn't actually a constant expression was called.
	(non_const_var_error): Add a bool parameter.  Use constexpr_error.
	(inline_asm_in_constexpr_error): Likewise.
	(cxx_eval_constant_expression): Adjust calls to non_const_var_error
	and inline_asm_in_constexpr_error.
	(potential_constant_expression_1): Add a bool parameter.  Use
	constexpr_error.
	(require_potential_rvalue_constant_expression_fncheck): New function.
	* cp-tree.h (require_potential_rvalue_constant_expression_fncheck):
	Declare.
	* method.cc (struct comp_info): Call
	require_potential_rvalue_constant_expression_fncheck rather than
	require_potential_rvalue_constant_expression.

gcc/ChangeLog:

	* doc/invoke.texi: Document -Winvalid-constexpr.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/constexpr-ctor2.C: Expect an error in c++20_down only.
	* g++.dg/cpp0x/constexpr-default-ctor.C: Likewise.
	* g++.dg/cpp0x/constexpr-diag3.C: Likewise.
	* g++.dg/cpp0x/constexpr-ex1.C: Likewise.
	* g++.dg/cpp0x/constexpr-friend.C: Likewise.
	* g++.dg/cpp0x/constexpr-generated1.C: Likewise.
	* g++.dg/cpp0x/constexpr-ice5.C: Likewise.
	* g++.dg/cpp0x/constexpr-ice6.C: Likewise.
	* g++.dg/cpp0x/constexpr-memfn1.C: Likewise.
	* g++.dg/cpp0x/constexpr-neg2.C: Likewise.
	* g++.dg/cpp0x/constexpr-non-const-arg.C: Likewise.
	* g++.dg/cpp0x/constexpr-reinterpret1.C: Likewise.
	* g++.dg/cpp0x/pr65327.C: Likewise.
	* g++.dg/cpp1y/constexpr-105050.C: Likewise.
	* g++.dg/cpp1y/constexpr-89285-2.C: Likewise.
	* g++.dg/cpp1y/constexpr-89285.C: Likewise.
	* g++.dg/cpp1y/constexpr-89785-2.C: Likewise.
	* g++.dg/cpp1y/constexpr-neg1.C: Likewise.
	* g++.dg/cpp1y/constexpr-nsdmi7b.C: Likewise.
	* g++.dg/cpp1y/constexpr-throw.C: Likewise.
	* g++.dg/cpp23/constexpr-nonlit3.C: Remove dg-error.
	* g++.dg/cpp23/constexpr-nonlit6.C: Call the test functions.
	* g++.dg/cpp23/feat-cxx2b.C: Adjust the expected value of
	__cpp_constexpr.
	* g++.dg/cpp2a/consteval3.C: Remove dg-error.
	* g++.dg/cpp2a/constexpr-new7.C: Expect an error in c++20_down only.
	* g++.dg/cpp2a/constexpr-try5.C: Remove dg-error.
	* g++.dg/cpp2a/spaceship-constexpr1.C: Expect an error in c++20_down
	only.
	* g++.dg/cpp2a/spaceship-eq3.C: Likewise.
	* g++.dg/diagnostic/constexpr1.C: Remove dg-error.
	* g++.dg/gomp/pr79664.C: Use -Winvalid-constexpr -pedantic-errors.
	* g++.dg/ubsan/vptr-4.C: Likewise.
	* g++.dg/cpp23/constexpr-nonlit10.C: New test.
	* g++.dg/cpp23/constexpr-nonlit11.C: New test.
	* g++.dg/cpp23/constexpr-nonlit12.C: New test.
	* g++.dg/cpp23/constexpr-nonlit13.C: New test.
	* g++.dg/cpp23/constexpr-nonlit14.C: New test.
	* g++.dg/cpp23/constexpr-nonlit15.C: New test.
	* g++.dg/cpp23/constexpr-nonlit16.C: New test.
	* g++.dg/cpp23/constexpr-nonlit8.C: New test.
	* g++.dg/cpp23/constexpr-nonlit9.C: New test.

This is only a partial fix for the PR.

libstdc++-v3/ChangeLog:

	PR libstdc++/107720
	* include/std/format (__format::_Arg_t): Fix typo in enumerator
	name.
	(_Arg_value::_S_get): Fix missing semi-colons.

We can use an array instead of a std::vector, and we can avoid the
binary search for the common case of a time point after the most recent
leap second. On one system where I tested this, utc_clock::now() now
takes about 16ns instead of 31ns.

libstdc++-v3/ChangeLog:

	* include/std/chrono (get_leap_second_info): Optimize.

Clang doesn't define __builtin_toupper, so use std::toupper.

Also add some (not actually required since C++20) typename keywords to
help Clang versions up to and including 15.

libstdc++-v3/ChangeLog:

	PR libstdc++/107712
	* include/std/format (__format::__formatter_int::format): Use
	std::toupper when __builtin_toupper isn't available.
	(basic_format_arg::handle): Add 'typename'.
	* include/std/complex (complex<T>): Add 'typename'.

This restricts std::format support for _Float128 (and __float128) to
targets where glibc provides __strfromf128 and so can give correct
output.

libstdc++-v3/ChangeLog:

	* include/std/format [__FLT128_DIG__] (_GLIBCXX_FORMAT_F128):
	Only support formatting _Float128 when glibc provides the
	functionality needed for accurate std::to_chars.

gcc/fortran/ChangeLog:

	PR fortran/107681
	* resolve.cc (resolve_fl_var_and_proc): Prevent NULL pointer
	dereference with reference to bad CLASS variable.

gcc/testsuite/ChangeLog:

	PR fortran/107681
	* gfortran.dg/pr107681.f90: New test.

gcc/fortran/ChangeLog:

	PR fortran/107680
	* arith.cc (arith_power): Check that operands are properly converted
	before attempting to simplify.

gcc/testsuite/ChangeLog:

	PR fortran/107680
	* gfortran.dg/pr107680.f90: New test.

We avoid reassociating "(~(a >> BIT_NO)) & 1" into "((~a) >> BIT_NO) & 1"
by splitting it into a zero-extraction (bext) and an xori.  This both
avoids burning a register on a temporary and generates a sequence that
clearly captures 'extract bit, then invert bit'.

This change improves the previously generated
    srl   a0,a0,a1
    not	  a0,a0
    andi  a0,a0,1
into
    bext  a0,a0,a1
    xori  a0,a0,1

Signed-off-by: Philipp Tomsich <philipp.tomsich@vrull.eu>

gcc/ChangeLog:

	* config/riscv/bitmanip.md: Add split covering
	"(a & (1 << BIT_NO)) ? 0 : 1".

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/zbs-bext.c: Add testcases.
	* gcc.target/riscv/zbs-bexti.c: Add testcases.

For a straightforward application of bext for the following function
  long bext64(long a, char bitno)
  {
    return (a & (1UL << bitno)) ? 0 : -1;
  }
we generate
	srl	a0,a0,a1	# 7	[c=4 l=4]  lshrdi3
	andi	a0,a0,1	# 8	[c=4 l=4]  anddi3/1
	addi	a0,a0,-1	# 14	[c=4 l=4]  adddi3/1
due to the following failed match at combine time:
  (set (reg:DI 82)
       (zero_extract:DI (reg:DI 83)
            (const_int 1 [0x1])
            (reg:DI 84)))

The existing pattern for bext requires the 3rd argument to
zero_extract to be a QImode register wrapped in a zero_extension.
This adds an additional pattern that allows an Xmode argument.

With this change, the testcase compiles to
	bext	a0,a0,a1	# 8	[c=4 l=4]  *bextdi
	addi	a0,a0,-1	# 14	[c=4 l=4]  adddi3/1

gcc/ChangeLog:

	* config/riscv/bitmanip.md (*bext<mode>): Add an additional
	pattern that allows the 3rd argument to zero_extract to be
	an Xmode register operand.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/zbs-bext.c: Add testcases.
	* gcc.target/riscv/zbs-bexti.c: Add testcases.

In commit r13-2619-g34b9a03353d3fd, [transform] was applied to all
invocations of gcov, for both out-of-tree and in-tree testing.
For in-tree cross builds, this means gcov was called as
"/path/to/gccobj/gcc/target-tuple-gcov" gcov-pr94029.c which is
incorrect, as it's there "/path/to/gccobj/gcc/gcov" until it's
installed.  This caused a testsuite failure, like:

Running /x/gcc/gcc/testsuite/gcc.misc-tests/gcov.exp ...
FAIL: gcc.misc-tests/gcov-pr94029.c gcov failed: spawn failed

To avoid cumbersome conditionals, use a dedicated new helper function.

gcc/testsuite:
	* lib/gcc-dg.exp (gcc-transform-out-of-tree): New proc.
	* g++.dg/gcov/gcov.exp, gcc.misc-tests/gcov.exp: Call
	gcc-transform-out-of-tree instead of transform.

The following propely restricts the bitfield access to integral types
when we look through VEC_UNPACK with the intent to emit a widening
conversion.

	PR tree-optimization/107686
	* tree-ssa-forwprop.cc (optimize_vector_load): Restrict
	VEC_UNPACK support to integral typed bitfield refs.

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

When the frontend clobbers a parameter and that parameter gets
rewritten into SSA then we ICE because we didn't expect this.  Avoid
using the parameter decl to create a SSA default def in this case.

	PR middle-end/107679
	* tree-into-ssa.cc (maybe_register_def): Use new temporary if
	we require an uninitialized value for a parameter decl.

	* gfortran.dg/pr107679.f90: New testcase.

This test of leap second handling is taken from the C++20 standard.

libstdc++-v3/ChangeLog:

	* testsuite/std/time/clock/utc/1.cc: Check handling across leap
	second insertion.

libatomic/ChangeLog:

	* Makefile.in: Re-generate.

When linking with a static library, the linker seems to discard a
constituent .o object (including its global initializers) if nothing
defined in the object is referenced by the program (unless e.g.
--whole-archive is used).  This behavior breaks iostream with static
libstdc++.a (on systems that support init priorities) because we define
the global initializer for the standard stream objects in a separate TU
(ios_init.cc) from the stream object definitions (globals_io.cc).

This patch fixes this by moving the stream initialization object into
the same TU that defines the stream objects, so that any use of the
streams prevents the linker from discarding this global initializer.

	PR libstdc++/107701

libstdc++-v3/ChangeLog:

	* include/std/iostream (__ioinit): Adjust comment.
	* src/c++98/globals_io.cc: Include "io_base_init.h" here
	instead of ...
	* src/c++98/ios_init.cc: ... here.
	* src/c++98/ios_base_init.h (__ioinit): More comments.
	* testsuite/17_intro/static.cc: dg-do run instead of just link.

When trying to figure out what to do about alignment,
layout_compatible_type_p returns false if TYPE_ALIGN on
ENUMERAL_TYPE/CLASS_TYPE_P (but not scalar types?) differ, or if members
don't have the same positions.

What is in DR2583 doesn't say anything like that though, on the other side
it says that if the corresponding entities don't have the same alignment
requirements, they aren't part of the common initial sequence.

So, my understanding of this is we shouldn't check TYPE_ALIGN in
layout_compatible_type_p, but instead DECL_ALIGN in
next_common_initial_seqence.

2022-11-16  Jakub Jelinek  <jakub@redhat.com>

	* typeck.cc (next_common_initial_sequence): Return false members have
	different DECL_ALIGN.
	(layout_compatible_type_p): Don't test TYPE_ALIGN of ENUMERAL_TYPE
	or CLASS_TYPE_P.

	* g++.dg/cpp2a/is-layout-compatible3.C: Expect enums with different
	alignas to be layout compatible, while classes with different
	alignas on members layout incompatible.
	* g++.dg/DRs/dr2583.C: New test.

As filed by Jonathan in the PR, I've screwed up the requires syntax
in the extended floating point specialization:
-    requires(__complex_type<_Tp>::type)
+    requires requires { typename __complex_type<_Tp>::type; }
and doing this change resulted in lots of errors because __complex_whatever
overfloads from extended floating point types were declared after the
templates which used them.

The following patch fixes that.

Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
I've tested that with _GLIBCXX_HAVE_FLOAT128_MATH not being defined
while __STDCPP_FLOAT128_T__ defined one can still use
std::complex<std::float128_t> for basic arithmetic etc., just one can't
expect std::sin etc. to work in that case (because we don't have any
implementation).

2022-11-16  Jakub Jelinek  <jakub@redhat.com>
	    Jonathan Wakely  <jwakely@redhat.com>

	PR libstdc++/107649
	* include/std/complex (__complex_abs, __complex_arg, __complex_cos,
	__complex_cosh, __complex_exp, __complex_log, __complex_sin,
	__complex_sinh, __complex_sqrt, __complex_tan, __complex_tanh,
	__complex_pow): Move __complex__ _Float{16,32,64,128} and
	__complex__ decltype(0.0bf16) overloads earlier in the file.
	(complex): Fix up requires on the partial specialization for extended
	float types.
	(__complex_acos, __complex_asin, __complex_atan, __complex_acosh,
	__complex_asinh, __complex_atanh): Move
	__complex__ _Float{16,32,64,128} and __complex__ decltype(0.0bf16)
	overloads earlier in the file.

One thing that doesn't work properly is the same problem as I've filed
yesterday for static operator() - PR107624 - that side-effects of
the postfix-expression on which the call or subscript operator are
applied are thrown away, I assume we have to add them into COMPOUND_EXPR
somewhere after we find out that the we've chosen a static member function
operator.

On Mon, Nov 14, 2022 at 06:29:44PM -0500, Jason Merrill wrote:
> Indeed.  The code in build_new_method_call for this case has the comment
>
>               /* In an expression of the form `a->f()' where `f' turns
>                  out to be a static member function, `a' is
>                  none-the-less evaluated.  */

Had to tweak 3 spots for this.  Furthermore, found that if in non-pedantic
C++20 compilation static operator[] is accepted, we required that it has 2
arguments, I think it is better to require exactly one because that case
is the only one that will actually work in C++20 and older.

2022-11-16  Jakub Jelinek  <jakub@redhat.com>

	PR c++/107624
	* call.cc (keep_unused_object_arg): New function.
	(build_op_call): Use it.
	(build_op_subscript): Likewise.
	(build_new_op): Similarly for ARRAY_REF.
	(build_new_method_call): Use it.
	* decl.cc (grok_op_properties): For C++20 and earlier, if operator[]
	is static member function, require exactly one parameter rather than
	exactly two parameters.

	* g++.dg/cpp23/static-operator-call4.C: New test.
	* g++.dg/cpp23/subscript10.C: New test.
	* g++.dg/cpp23/subscript11.C: New test.

gcc/ChangeLog:

	PR target/107676
	* doc/invoke.texi (-mrelax-cmpxchg-loop): Reword description.