Here we crash on this invalid code because we seem to infinitely recurse
and end up with __type_pack_element with index that doesn't tree_fits_shwi_p
which then crashes on tree_to_shwi.

Thanks to Jakub for suggesting a nicer fix than my original one.

	PR c++/113834

gcc/cp/ChangeLog:

	* semantics.cc (finish_type_pack_element): Perform range checking
	before tree_to_shwi.

gcc/testsuite/ChangeLog:

	* g++.dg/ext/type_pack_element4.C: New test.

Here the problem is that we give hard errors while substituting
template parameters during overload resolution of is_throwable
which has an invalid throw in decltype.

The backtrace shows that fn_type_unification -> instantiate_template
-> tsubst* passes complain=0 as expected, but build_throw doesn't
have a complain parameter.  So let's add one.  Also remove a redundant
local variable which I should have removed in my P2266 patch.

There's still one problem for which I opened <https://gcc.gnu.org/PR113853>.
We need to patch up treat_lvalue_as_rvalue_p and remove the dg-bogus.

Thanks to Patrick for notifying me of this PR.  This doesn't fully fix
113789; there I think I'll have to figure our why a candidate wasn't
discarded from the overload set.

	PR c++/98388

gcc/cp/ChangeLog:

	* coroutines.cc (coro_rewrite_function_body): Pass tf_warning_or_error
	to build_throw.
	(morph_fn_to_coro): Likewise.
	* cp-tree.h (build_throw): Adjust.
	* except.cc (expand_end_catch_block): Pass tf_warning_or_error to
	build_throw.
	(build_throw): Add a tsubst_flags_t parameter.  Use it.  Remove
	redundant variable.  Guard an inform call.
	* parser.cc (cp_parser_throw_expression): Pass tf_warning_or_error
	to build_throw.
	* pt.cc (tsubst_expr) <case THROW_EXPR>: Pass complain to build_throw.

libcc1/ChangeLog:

	* libcp1plugin.cc (plugin_build_unary_expr): Pass tf_error to
	build_throw.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/sfinae69.C: New test.

	PR fortran/113799

gcc/fortran/ChangeLog:

	* arith.cc (reduce_unary): Remember any overflow encountered during
	reduction of unary arithmetic operations on array constructors and
	continue, and return error status, but terminate on serious errors.

gcc/testsuite/ChangeLog:

	* gfortran.dg/arithmetic_overflow_2.f90: New test.

Since is_same has a fallback native implementation, and
_GLIBCXX_HAVE_BUILTIN_IS_SAME does not support toggling which
implementation to use, we remove the _GLIBCXX_HAVE_BUILTIN_IS_SAME
definition and use _GLIBCXX_USE_BUILTIN_TRAIT instead.

libstdc++-v3/ChangeLog:

	* include/bits/c++config (_GLIBCXX_HAVE_BUILTIN_IS_SAME):
	Removed.
	* include/std/type_traits (is_same): Use
	_GLIBCXX_USE_BUILTIN_TRAIT instead of
	_GLIBCXX_HAVE_BUILTIN_IS_SAME.
	(is_same_v): Likewise.

Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org>
Reviewed-by: Patrick Palka <ppalka@redhat.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

Here when streaming in the fields of the as-base version of
_Formatting_scanner<int> we end up overwriting ANON_AGGR_TYPE_FIELD
of the anonymous union type, since it turns out this type is shared
between the original FIELD_DECL and the as-base FIELD_DECL copy (copied
during layout_class_type).  ANON_AGGR_TYPE_FIELD first gets properly set
to the original FIELD_DECL when streaming in the canonical definition of
_Formatting_scanner<int>, and then gets overwritten to the as-base
FIELD_DECL when streaming in the the as-base definition.  This leads to
lookup_anon_field later giving the wrong answer when resolving the
_M_values use at instantiation time.

This patch makes us avoid overwriting ANON_AGGR_TYPE_FIELD when streaming
in an as-base class definition; it should already be properly set at that
point.

	PR c++/112580

gcc/cp/ChangeLog:

	* module.cc (trees_in::read_class_def): When streaming in
	an anonymous union field of an as-base class, don't overwrite
	ANON_AGGR_TYPE_FIELD.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/anon-3_a.H: New test.
	* g++.dg/modules/anon-3_b.C: New test.

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

lower-bitint: Fix handling of VIEW_CONVERT_EXPRs to minimally supported huge INTEGER_TYPEs [PR113783]

On the following testcases memcpy lowering folds the calls to
reading and writing of MEM_REFs with huge INTEGER_TYPEs - uint256_t
with OImode or uint512_t with XImode.  Further optimization turn
the load from MEM_REF from the large/huge _BitInt var into VIEW_CONVERT_EXPR
from it to the uint256_t/uint512_t.  The backend doesn't really
support those except for "movoi"/"movxi" insns, so it isn't possible
to handle it like casts to supportable INTEGER_TYPEs where we can
construct those from individual limbs - there are no OImode/XImode shifts
and the like we can use.
So, the following patch makes sure for such VCEs that the SSA_NAME operand
of the VCE lives in memory and then turns it into a VIEW_CONVERT_EXPR so
that we actually load the OImode/XImode integer from memory (i.e. a mov).
We need to make sure those aren't merged with other
operations in the gimple_lower_bitint hunks.
For SSA_NAMEs which have underlying VAR_DECLs that is all we need, those
VAR_DECL have ARRAY_TYPEs.
For SSA_NAMEs which have underlying PARM_DECLs or RESULT_DECLs those have
BITINT_TYPE and I had to tweak expand_expr_real_1 for that so that it
doesn't try convert_modes on those when one of the modes is BLKmode - we
want to fall through into the adjust_address on the MEM.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113783
	* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Look
	through VIEW_CONVERT_EXPR for final cast checks.  Handle
	VIEW_CONVERT_EXPRs from large/huge _BitInt to > MAX_FIXED_MODE_SIZE
	INTEGER_TYPEs.
	(gimple_lower_bitint): Don't merge mergeable operations or other
	casts with VIEW_CONVERT_EXPRs to > MAX_FIXED_MODE_SIZE INTEGER_TYPEs.
	* expr.cc (expand_expr_real_1): Don't use convert_modes if either
	mode is BLKmode.

	* gcc.dg/bitint-88.c: New test.

build_conflict_bit_table uses %ld format string for
(long) some_int_expression * sizeof (something)
argument, that doesn't work on LLP64 hosts because the
expression has then size_t aka unsigned long long type there.
It can be fixed with
(long) (some_int_expression * sizeof (something))
but it means the value is truncated if it doesn't fit into long.
Ideally we'd use %zd or %zu modifiers here, but it is unclear if we
can rely on it on all hosts, it has been introduced in C99 and C++11
includes C99 by reference, but in reality whether this works or not
depends on the host C library and some of them are helplessly obsolete.

This patch instead introduces new macros HOST_SIZE_T_PRINT_* which
one can use in *printf family function format strings and cast to
fmt_size_t type.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	* hwint.h (GCC_PRISZ, fmt_size_t, HOST_SIZE_T_PRINT_DEC,
	HOST_SIZE_T_PRINT_UNSIGNED, HOST_SIZE_T_PRINT_HEX,
	HOST_SIZE_T_PRINT_HEX_PURE): Define.
	* ira-conflicts.cc (build_conflict_bit_table): Use it.  Formatting
	fixes.

Some exports were missed from the GCC-13 cycle, these are added here
along with the bitint-related ones added in GCC-14.

libgcc/ChangeLog:

	* config/i386/libgcc-darwin.ver: Export bf and bitint-related
	synbols.

The asm goto expansion ICEs on the following testcase (which normally
is rejected later), because expand_asm_stmt emits the code to copy
the large var out of the out operand to its memory location into
after_rtl_seq ... after_rtl_end sequence and because it is asm goto,
it duplicates the sequence on each successor edge of the asm goto.
The problem is that with -mstringop-strategy=byte_loop that sequence
contains loops, so CODE_LABELs, JUMP_INSNs, with other strategies
could contain CALL_INSNs etc.
But the copying is done using a loop doing
emit_insn (copy_insn (PATTERN (curr)));
which does the right thing solely for INSNs, it will do the wrong thing
for JUMP_INSNs, CALL_INSNs, CODE_LABELs (with RTL checking even ICE on
them), BARRIERs and the like.

The following patch partially fixes it (with the hope that such stuff only
occurs in asms that really can't be accepted; if one uses say "=rm" or
"=g" constraint then the operand uses the memory directly and nothing is
copied) by using the
duplicate_insn_chain function which is used e.g. in RTL loop unrolling and
which can handle JUMP_INSNs, CALL_INSNs, BARRIERs etc.
As it is meant to operate on sequences inside of basic blocks, it doesn't
handle CODE_LABELs (well, it skips them), so if we need a solution that
will be correct at runtime here for those cases, we'd need to do further
work (e.g. still use duplicate_insn_chain, but if we notice any CODE_LABELs,
walk the sequence again, add copies of the CODE_LABELs and then remap
references to the old CODE_LABELs in the copied sequence to the new ones).
Because as is now, if the code in one of the sequence copies (where the
CODE_LABELs have been left out) decides to jump to such a CODE_LABEL, it
will jump to the CODE_LABEL which has been in the original sequence (which
the code emits on the last edge, after all, duplicating the sequence
EDGE_COUNT times and throwing away the original was wasteful, compared to
doing that just EDGE_COUNT - 1 times and using the original.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/113415
	* cfgexpand.cc (expand_asm_stmt): For asm goto, use
	duplicate_insn_chain to duplicate after_rtl_seq sequence instead
	of hand written loop with emit_insn of copy_insn and emit original
	after_rtl_seq on the last edge.

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

Due to -fnon-call-exceptions the bitint lowering adds new EH edges
in various places, so that the EH edge points from handling (e.g. load or
store) of each of the limbs.  The problem is that the EH edge destination
as shown in the testcase can have some PHIs.  If it is just a virtual
PHI, no big deal, the pass uses TODO_update_ssa_only_virtuals, but if
it has other PHIs, I think we need to copy the values from the preexisting
corresponding EH edge (which is from the original stmt to the EH pad)
to the newly added EH edge, so that the PHI arguments are the same rather
than missing (which ICEs during checking at the end of the pass).

This patch adds a function to do that and uses it whenever adding EH edges.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113818
	* gimple-lower-bitint.cc (add_eh_edge): New function.
	(bitint_large_huge::handle_load,
	bitint_large_huge::lower_mergeable_stmt,
	bitint_large_huge::lower_muldiv_stmt): Use it.

	* gcc.dg/bitint-89.c: New test.

The following patch is the optimization part of PR113774, where in
handle_cast we emit some conditionals which are always true and presumably
VRP would figure that out later and clean it up, except that instead
thread1 is invoked and threads everything through the conditions, so we end
up with really ugly code which is hard to be cleaned up later and then
run into PR113831 VN bug and miscompile stuff.

handle_cast computes low and high as limb indexes, where idx < low
doesn't need any special treatment, just uses the operand's limb,
idx >= high cases all the bits in the limb are an extension (so, for
unsigned widening cast all those bits are 0, for signed widening cast
all those bits are equal to the in earlier code computed sign mask,
narrowing cast don't trigger this code) and then the idx == low && idx <
high case if it exists need special treatment (some bits are copied, others
extended, or all bits are copied but sign mask needs to be computed).

The code already attempted to optimize away some unneeded casts, in the
first hunk below e.g. for the case like 257 -> 321 bit extension, where
low is 4 and high 5 and we use a loop handling the first 4 limbs (2
iterations) with m_upwards_2limb 4 - no special handling is needed in the
loop, and the special handling is done on the first limb after the loop
and then the last limb after the loop gets the extension only, or
in the second hunk where can emit a single comparison instead of
2 e.g. for the low == high case - that must be a zero extension from
multiple of limb bits, say 192 -> 328, or for the case where we know
the idx == low case happens in the other limb processed in the loop, not
the current one.

But the testcase shows further cases where we always know some of the
comparisons can be folded to true/false, in particular there is
255 -> 257 bit zero extension, so low 3, high 4, m_upwards_2limb 4.
The loop handles 2 limbs at the time and for the first limb we were
emitting idx < low ? operand[idx] : 0; but because idx goes from 0
with step 2 2 iterations, idx < 3 is always true, so we can just
emit operand[idx].  This is handled in the first hunk.  In addition
to fixing it (that is the " - m_first" part in there) I've rewritten
it using low to make it more readable.

Similarly, in the other limb we were emitting
idx + 1 <= low ? (idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx]) : 0
but idx + 1 <= 3 is always true in the loop, so all we should emit is
idx + 1 == low ? operand[idx] & 0x7ff....ff : operand[idx],
Unfortunately for the latter, when single_comparison is true, we emit
just one comparison, but the code which fills the branches will fill it
with the operand[idx] and 0 cases (for zero extension, for sign extension
similarly), not the operand[idx] (aka copy) and operand[idx] & 0x7ff....ff
(aka most significant limb of the narrower precision) cases.  Instead
of making the code less readable by using single_comparison for that and
handling it in the code later differently I've chosen to just emit
a condition which will be always true and let cfg cleanup clean it up.

2024-02-09  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113774
	* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't
	emit any comparison if m_first and low + 1 is equal to
	m_upwards_2limb, simplify condition for that.  If not
	single_comparison, not m_first and we can prove that the idx <= low
	comparison will be always true, emit instead of idx <= low
	comparison low <= low such that cfg cleanup will optimize it at
	the end of the pass.

	* gcc.dg/torture/bitint-57.c: New test.

When running the testsuite for newlib nano, the --specs=nano.specs
option is used.  This option prepends cpp_unique_options with
"-isystem =/include/newlib-nano" so that the newlib nano header files
override the newlib standard ones.  As the -isystem option is prepended,
the -quiet option is no longer the first option to cc1.  Adjust the test
accordingly.

Patch has been verified on Windows and Linux.

gcc/testsuite/ChangeLog:

	* gcc.misc-tests/options.exp: Allow other options before the
	-quite option for cc1.

Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

libstdc++-v3/ChangeLog:

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

There's no need to check for self-assignment here, it would just add
extra code for an unlikely case. Add a comment saying so.

libstdc++-v3/ChangeLog:

	PR libstdc++/100147
	* include/bits/gslice.h (operator=): Add comment about lack of
	self-assignment check.

Adding rvv related flags (i.e. --param=riscv-autovec-preference) to
non vector targets bypassed the dejagnu skip test directive. Change the
target selector to skip if rvv is enabled

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/abi-1.c: change selector
	* gcc.target/riscv/rvv/base/pragma-2.c: ditto
	* gcc.target/riscv/rvv/base/pragma-3.c: ditto

Signed-off-by: Edwin Lu <ewlu@rivosinc.com>

These non-standard extensions use GCC-specific built-ins. Use
__has_builtin to avoid errors when Clang compiles this header.

See https://github.com/llvm/llvm-project/issues/24289

libstdc++-v3/ChangeLog:

	* include/tr2/type_traits (bases, direct_bases): Use
	__has_builtin to check if required built-ins are supported.

The v*_fp16_xN_1.c tests on Arm have been unstable since they were
added.  This is not a problem with the tests themselves, or even the
patches that were added, but with the testsuite infrastructure.  It
turned out that another set of dg- tests for fp16 were corrupting the
cached set of options used by the new tests, leading to running the
tests with incorrect flags.

So the primary goal of this patch is to fix the incorrect internal
caching of the options needed to enable fp16 alternative format on
Arm: the code was storing the result in the same variable that was
being used for neon_fp16 and this was leading to testsuite instability
for tests that were checking for neon with fp16.

But in cleaning this up I also noted that we weren't then applying the
flags correctly having detected what they were, so we also address
that.

I suspect there are still some further issues to address here, since
the framework does not correctly test that the multilibs and startup
code enable alternative format; but this is still an improvement over
what we had before.

gcc/testsuite/ChangeLog:

	* lib/target-supports.exp
	(check_effective_target_arm_fp16_alternative_ok_nocache): Use
	et_arm_fp16_alternative_flags to cache the result.  Improve test
	for FP16 availability.
	(add_options_for_arm_fp16_alternative): Use
	et_arm_fp16_alternative_flags.
	* g++.dg/ext/arm-fp16/arm-fp16-ops-3.C: Update dg-* flags.
	* g++.dg/ext/arm-fp16/arm-fp16-ops-4.C: Likewise.
	* gcc.dg/torture/arm-fp16-int-convert-alt.c: Likewise.
	* gcc.dg/torture/arm-fp16-ops-3.c: Likewise.
	* gcc.dg/torture/arm-fp16-ops-4.c: Likewise.
	* gcc.target/arm/fp16-aapcs-3.c: Likewise.
	* gcc.target/arm/fp16-aapcs-4.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-1.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-10.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-11.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-12.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-2.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-3.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-4.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-5.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-6.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-7.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-8.c: Likewise.
	* gcc.target/arm/fp16-compile-alt-9.c: Likewise.
	* gcc.target/arm/fp16-rounding-alt-1.c: Likewise.

Since template argument coercion happens relative to the most general
template (for a class template at least), during NTTP type CTAD we might
need to consider outer arguments particularly if the CTAD template is from
the current instantiation (and so depends on outer template parameters).

This patch makes do_class_deduction substitute as many levels of outer
template arguments into a CTAD template (from the current instantiation)
as it can take.

	PR c++/113649

gcc/cp/ChangeLog:

	* pt.cc (do_class_deduction): Add outer_targs parameter.
	Substitute outer arguments into the CTAD template.
	(do_auto_deduction): Pass outer_targs to do_class_deduction.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/nontype-class65.C: New test.

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

The relation oracle grows the internal vector of SSAs as needed, but
due to an oversight was not growing the basic block vector.  This
fixes the oversight.

	PR tree-optimization/113735

gcc/testsuite/ChangeLog:

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

gcc/ChangeLog:

	* value-relation.cc (equiv_oracle::add_equiv_to_block): Call
	limit_check().

Some information was (re-)computed in different places.
This patch computes them in new struct McuInfo and passes
it around in order to provide the information.

gcc/
	* config/avr/gen-avr-mmcu-specs.cc (struct McuInfo): New.
	(main, print_mcu, diagnose_mrodata_in_ram): Pass it down.

1. The only supported TLS code sequence with ADD is

	addq foo@gottpoff(%rip),%reg

Change je constraint to a memory operand in APX NDD ADD pattern with
register source operand.

2. The instruction length of APX NDD instructions with immediate operand:

op imm, mem, reg

may exceed the size limit of 15 byes when non-default address space,
segment register or address size prefix are used.

Add jM constraint which is a memory operand valid for APX NDD instructions
with immediate operand and add jO constraint which is an offsetable memory
operand valid for APX NDD instructions with immediate operand.  Update
APX NDD patterns with jM and jO constraints.

gcc/

	PR target/113711
	PR target/113733
	* config/i386/constraints.md: List all constraints with j prefix.
	(j>): Change auto-dec to auto-inc in documentation.
	(je): Changed to a memory constraint with APX NDD TLS operand
	check.
	(jM): New memory constraint for APX NDD instructions.
	(jO): Likewise.
	* config/i386/i386-protos.h (x86_poff_operand_p): Removed.
	* config/i386/i386.cc (x86_poff_operand_p): Likewise.
	* config/i386/i386.md (*add<dwi>3_doubleword): Use rjO.
	(*add<mode>_1[SWI48]): Use je and jM.
	(addsi_1_zext): Use jM.
	(*addv<dwi>4_doubleword_1[DWI]): Likewise.
	(*sub<mode>_1[SWI]): Use jM.
	(@add<mode>3_cc_overflow_1[SWI]): Likewise.
	(*add<dwi>3_doubleword_cc_overflow_1): Use rjO.
	(*and<dwi>3_doubleword): Likewise.
	(*anddi_1): Use jM.
	(*andsi_1_zext): Likewise.
	(*and<mode>_1[SWI24]): Likewise.
	(*<code><dwi>3_doubleword[any_or]): Use rjO
	(*code<mode>_1[any_or SWI248]): Use jM.
	(*<code>si_1_zext[zero_extend + any_or]): Likewise.
	* config/i386/predicates.md (apx_ndd_memory_operand): New.
	(apx_ndd_add_memory_operand): Likewise.

gcc/testsuite/

	PR target/113711
	PR target/113733
	* gcc.target/i386/apx-ndd-2.c: New test.
	* gcc.target/i386/apx-ndd-base-index-1.c: Likewise.
	* gcc.target/i386/apx-ndd-no-seg-global-1.c: Likewise.
	* gcc.target/i386/apx-ndd-seg-1.c: Likewise.
	* gcc.target/i386/apx-ndd-seg-2.c: Likewise.
	* gcc.target/i386/apx-ndd-seg-3.c: Likewise.
	* gcc.target/i386/apx-ndd-seg-4.c: Likewise.
	* gcc.target/i386/apx-ndd-seg-5.c: Likewise.
	* gcc.target/i386/apx-ndd-tls-1a.c: Likewise.
	* gcc.target/i386/apx-ndd-tls-2.c: Likewise.
	* gcc.target/i386/apx-ndd-tls-3.c: Likewise.
	* gcc.target/i386/apx-ndd-tls-4.c: Likewise.
	* gcc.target/i386/apx-ndd-x32-1.c: Likewise.

Rename pr to lowercase and drop lastprivate.

gcc/testsuite/ChangeLog:

	PR tree-optimization/113808
	* gfortran.dg/vect/vect-early-break_1-PR113808.f90: Moved to...
	* gfortran.dg/vect/vect-early-break_1-pr113808.f90: ...here.

gcc/
	PR target/113824
	* config/avr/avr-mcus.def (ata5797): Move from avr5 to avr4.
	* doc/avr-mmcu.texi: Rebuild.

There's a bug in vectorizable_live_operation that restart_loop is defined
outside the loop.

This variable is supposed to indicate whether we are doing a first or last
index reduction.  The problem is that by defining it outside the loop it becomes
dependent on the order we visit the USE/DEFs.

In the given example, the loop isn't PEELED, but we visit the early exit uses
first.  This then sets the boolean to true and it can't get to false again.

So when we visit the main exit we still treat it as an early exit for that
SSA name.

This cleans it up and renames the variables to something that's hopefully
clearer to their intention.

gcc/ChangeLog:

	PR tree-optimization/113808
	* tree-vect-loop.cc (vectorizable_live_operation): Don't cache the
	value cross iterations.

gcc/testsuite/ChangeLog:

	PR tree-optimization/113808
	* gfortran.dg/vect/vect-early-break_1-PR113808.f90: New test.

gcc/
	* config/avr/gen-avr-mmcu-specs.cc (print_mcu) <*cpp_mcu>: Spec always
	defines __AVR_PM_BASE_ADDRESS__ if the core has it.

I've reconsidered my last change to dr_may_alias_p and decided
it was correct before.  The following reverts that change.

	* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
	Revert last change to dr_may_alias_p.

I had missed a conversion from unsigned long to uint64_t.
This fixes the failing test on -m32.

gcc/testsuite/ChangeLog:

	* gcc.dg/vect/vect-early-break_110-pr113467.c: Change unsigned long *
	to uint64_t *.

gcc/
	* config/avr/gen-avr-mmcu-specs.cc: Rename spec cc1_misc to
	cc1_rodata_in_ram.  Rename spec link_misc to link_rodata_in_ram.
	Remove spec asm_misc.
	* config/avr/specs.h: Same.

There is another corn case when similar as below example:

void test (void)
{
  __riscv_vaadd ();
}

We report error when overloaded function with empty args.  For example:

test.c: In function 'foo':
test.c:8:3: error: no matching function call to '__riscv_vaadd' with empty args
    8 |   __riscv_vaadd ();
      |   ^~~~~~~~~~~~~~~~~~~~

Unfortunately, it will meet another ICE similar to below after above
message.  The underlying build function checker will have zero args
and break some assumption of the function checker.  For example, the
count of args is not less than 2.

ice.c: In function ‘foo’:
ice.c:8:3: internal compiler error: in require_immediate, at
config/riscv/riscv-vector-builtins.cc:4252
    8 |   __riscv_vaadd ();
      |   ^~~~~~~~~~~~~
0x20b36ac riscv_vector::function_checker::require_immediate(unsigned
int, long, long) const
        .../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4252
0x20b890c riscv_vector::alu_def::check(riscv_vector::function_checker&) const
        .../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins-shapes.cc:387
0x20b38d7 riscv_vector::function_checker::check()
        .../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4315
0x20b4876 riscv_vector::check_builtin_call(unsigned int, vec<unsigned int, va_heap, vl_ptr>,
        .../__RISC-V_BUILD__/../gcc/config/riscv/riscv-vector-builtins.cc:4605
0x2069393 riscv_check_builtin_call
        .../__RISC-V_BUILD__/../gcc/config/riscv/riscv-c.cc:227

Below test are passed for this patch.

* The riscv regression tests.

	PR target/113766

gcc/ChangeLog:

	* config/riscv/riscv-vector-builtins-shapes.cc (struct alu_def): Make
	sure the c.arg_num is >= 2 before checking.
	(struct build_frm_base): Ditto.
	(struct narrow_alu_def): Ditto.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr113766-1.c: Add new cases.

Signed-off-by: Pan Li <pan2.li@intel.com>

My fix for bug 111059 and bug 111911 caused a conversion of a floating
constant to boolean to wrongly no longer be considered an integer
constant expression, because logic to insert a NOP_EXPR in
c_objc_common_truthvalue_conversion for an argument not an integer
constant expression itself now took place after rather than before the
conversion to bool.  In the specific case of casting a floating
constant to bool, the result is an integer constant expression even
though the argument isn't (build_c_cast deals with ensuring that casts
to integer type of anything of floating type more complicated than a
single floating constant don't get wrongly treated as integer constant
expressions even if they fold to constants), so fix the logic in
c_objc_common_truthvalue_conversion to handle that special case.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

	PR c/113776

gcc/c
	* c-typeck.cc (c_objc_common_truthvalue_conversion): Return an
	integer constant expression for boolean conversion of floating
	constant.

gcc/testsuite/
	* gcc.dg/pr113776-1.c, gcc.dg/pr113776-2.c, gcc.dg/pr113776-3.c,
	gcc.dg/pr113776-4.c: New tests.

The new testcase from P2308 crashed trying to expand 'this' without an
object to refer to, because we stripped the TARGET_EXPR in
create_template_parm_object.  So let's leave it on for giving an error.

gcc/cp/ChangeLog:

	* pt.cc (create_template_parm_object): Pass TARGET_EXPR to
	cxx_constant_value.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/nontype-class64.C: New test.

	* zh_CN.po: Update.

The forward declarations of std::get in <bits/stl_pair.h> added in
r14-8710-g65b4cba9d6a9ff are causing an ICE in the test modules/hello-1
due to what seems to be a declaration merging issue in modules.

What's happening is that in hello-1_b.C we first include <string_view>,
which indirectly includes <bits/stl_pair.h> which forms the dependent
specialization tuple_element<__i, tuple<_Elements...>> (appearing in
the signatures of some of the std::get overloads) and adds it to the
specializations table.

We then import hello which indirectly includes <tuple> (in the GMF),
within which we define a partial specialization of tuple_element with
that same template-id.  So importing hello in turn streams in this
partial specialization but we don't merge it with the previously created
dependent specialization, and we end up with two equivalent types for
this template-id with different TYPE_CANONICAL.

This patch works around this issue by adding a forward declaration of
the tuple_element partial specialization from <tuple> to <bits/stl_pair.h>
so that it appears alongside the dependent specialization of the same
template-id.  So when including <bits/stl_pair.h> we immediately register
the template-id as a partial specialization, and if we later stream in the
partial specialization the MK_partial case of trees_in::key_mergeable will
match them up.  (So perhaps a proper modules fix for this might be to make
key_mergeable try to match up a streamed in partial specialization with an
existing specialization from the table via match_mergeable_specialization.)

	PR testsuite/113710
	PR c++/113814

libstdc++-v3/ChangeLog:

	* include/bits/stl_pair.h (tuple_element): Add forward
	declaration of the partial specialization for tuple.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

The following makes sure to wipe range info before folding the
COND_EXPRs we insert as part of replacing PHI nodes when combining
blocks in the if-conversion pass.

	PR tree-optimization/113796
	* tree-if-conv.cc (combine_blocks): Wipe range-info before
	replacing PHIs and inserting predicates.

	* gcc.dg/torture/pr113796.c: New testcase.

This patch fixes PR target/113690, an ICE-on-valid regression on x86_64
that exhibits with a specific combination of command line options.  The
cause is that x86's scalar-to-vector pass converts a chain of instructions
from TImode to V1TImode, but fails to appropriately update or delete the
attached REG_EQUAL note.  This implements Uros' recommendation of removing
these notes.  For convenience, this code (re)factors the logic to convert
a TImode constant into a V1TImode constant vector into a subroutine and
reuses it.

For the record, STV is actually doing something useful in this strange
testcase,  GCC with -O2 -fno-dce -fno-forward-propagate -fno-split-wide-types
-funroll-loops generates:

foo:	movl    $v, %eax
        pxor    %xmm0, %xmm0
        movaps  %xmm0, 48(%rax)
        movaps  %xmm0, (%rax)
        movaps  %xmm0, 16(%rax)
        movaps  %xmm0, 32(%rax)
        ret

With the addition of -mno-stv (to disable the patched code) it gives:

foo:	movl    $v, %eax
        movq    $0, 48(%rax)
        movq    $0, 56(%rax)
        movq    $0, (%rax)
        movq    $0, 8(%rax)
        movq    $0, 16(%rax)
        movq    $0, 24(%rax)
        movq    $0, 32(%rax)
        movq    $0, 40(%rax)
        ret

2024-02-07  Roger Sayle  <roger@nextmovesoftware.com>
	    Uros Bizjak  <ubizjak@gmail.com>

gcc/ChangeLog
	PR target/113690
	* config/i386/i386-features.cc (timode_convert_cst): New helper
	function to convert a TImode CONST_SCALAR_INT_P to a V1TImode
	CONST_VECTOR.
	(timode_scalar_chain::convert_op): Use timode_convert_cst.
	(timode_scalar_chain::convert_insn): Delete REG_EQUAL notes.
	Use timode_convert_cst.

gcc/testsuite/ChangeLog
	PR target/113690
	* gcc.target/i386/pr113690.c: New test case.

With the release of Binutils 2.42, this brings the level of
system-register support in GCC in line with the current
state-of-the-art in Binutils, ensuring everything available in
Binutils is plainly accessible from GCC.

Where Binutils uses a more detailed description of which features are
responsible for enabling a given system register, GCC aliases the
binutils-equivalent feature flag macro constant to that of the base
architecture implementing the feature, resulting in entries such as

  #define AARCH64_FL_S2PIE	   AARCH64_FL_V8_9A

in `aarch64.h', thus ensuring that the Binutils `aarch64-sys-regs.def'
file can be understood by GCC without the need for modification.

To accompany the addition of the new system registers, a new test is
added confirming they were successfully added to the list of
recognized registers.

gcc/ChangeLog:

	* config/aarch64/aarch64-sys-regs.def: Copy from Binutils.
	* config/aarch64/aarch64.h (AARCH64_FL_AIE): New.
	(AARCH64_FL_DEBUGv8p9): Likewise.
	(AARCH64_FL_FGT2): Likewise.Likewise.
	(AARCH64_FL_ITE): Likewise.
	(AARCH64_FL_PFAR): Likewise.
	(AARCH64_FL_PMUv3_ICNTR): Likewise.
	(AARCH64_FL_PMUv3_SS): Likewise.
	(AARCH64_FL_PMUv3p9): Likewise.
	(AARCH64_FL_RASv2): Likewise.
	(AARCH64_FL_S1PIE): Likewise.
	(AARCH64_FL_S1POE): Likewise.
	(AARCH64_FL_S2PIE): Likewise.
	(AARCH64_FL_S2POE): Likewise.
	(AARCH64_FL_SCTLR2): Likewise.
	(AARCH64_FL_SEBEP): Likewise.
	(AARCH64_FL_SPE_FDS): Likewise.
	(AARCH64_FL_TCR2): Likewise.

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/acle/rwsr-armv8p9.c: New.

gcc/rust/ChangeLog:

	* parse/rust-parse-impl.h (Parser::parse_trait_item):
	Handle macros in trait items similar to how its handled for trait
	implementation items.

Signed-off-by: Kushal Pal <kushalpal109@gmail.com>

Trait functions now use AST::Function class, so classes
AST::TraitItemFunc, AST::TraitItemMethod, AST::TraitFunctionDecl,
AST::TraitMethodDecl and their related functions can be removed.

gcc/rust/ChangeLog:

	* ast/rust-ast-collector.cc (TokenCollector::visit):
	Remove obsolete classes and functions.
	* ast/rust-ast-collector.h:
	Likewise.
	* ast/rust-ast-full-decls.h (class TraitFunctionDecl):
	Likewise.
	(class TraitItemFunc):
	Likewise.
	(class TraitMethodDecl):
	Likewise.
	(class TraitItemMethod):
	Likewise.
	* ast/rust-ast-visitor.cc (DefaultASTVisitor::visit):
	Likewise.
	* ast/rust-ast-visitor.h:
	Likewise.
	* ast/rust-ast.cc (TraitItemFunc::TraitItemFunc):
	Likewise.
	(TraitItemFunc::operator=):
	Likewise.
	(TraitItemFunc::as_string):
	Likewise.
	(TraitFunctionDecl::as_string):
	Likewise.
	(TraitItemMethod::TraitItemMethod):
	Likewise.
	(TraitItemMethod::operator=):
	Likewise.
	(TraitItemMethod::as_string):
	Likewise.
	(TraitMethodDecl::as_string):
	Likewise.
	(TraitItemFunc::accept_vis):
	Likewise.
	(TraitItemMethod::accept_vis):
	Likewise.
	* ast/rust-item.h (class TraitFunctionDecl):
	Likewise.
	(class TraitItemFunc):
	Likewise.
	(class TraitMethodDecl):
	Likewise.
	(class TraitItemMethod):
	Likewise.
	* checks/errors/rust-ast-validation.cc (ASTValidation::visit):
	Likewise.
	* checks/errors/rust-ast-validation.h:
	Likewise.
	* checks/errors/rust-feature-gate.h:
	Likewise.
	* expand/rust-cfg-strip.cc (CfgStrip::maybe_strip_trait_function_decl):
	Likewise.
	(CfgStrip::maybe_strip_trait_method_decl):
	Likewise.
	(CfgStrip::visit):
	Likewise.
	* expand/rust-cfg-strip.h:
	Likewise.
	* expand/rust-derive.h:
	Likewise.
	* expand/rust-expand-visitor.cc (ExpandVisitor::expand_trait_function_decl):
	Likewise.
	(ExpandVisitor::expand_trait_method_decl):
	Likewise.
	(ExpandVisitor::visit):
	Likewise.
	* expand/rust-expand-visitor.h:
	Likewise.
	* hir/rust-ast-lower-base.cc (ASTLoweringBase::visit):
	Likewise.
	* hir/rust-ast-lower-base.h:
	Likewise.
	* hir/rust-ast-lower-implitem.cc (ASTLowerTraitItem::visit):
	Likewise.
	* hir/rust-ast-lower-implitem.h:
	Likewise.
	* resolve/rust-ast-resolve-base.cc (ResolverBase::visit):
	Likewise.
	* resolve/rust-ast-resolve-base.h:
	Likewise.
	* resolve/rust-ast-resolve-implitem.h (visit):
	Likewise.
	* resolve/rust-ast-resolve-item.cc (ResolveTraitItems::visit):
	Likewise.
	* resolve/rust-ast-resolve-item.h:
	Likewise.
	* resolve/rust-default-resolver.cc (DefaultResolver::visit):
	Likewise.
	* resolve/rust-default-resolver.h:
	Likewise.
	* resolve/rust-toplevel-name-resolver-2.0.cc (TopLevel::visit):
	Likewise.
	* resolve/rust-toplevel-name-resolver-2.0.h:
	Likewise.
	* util/rust-attributes.cc (AttributeChecker::visit):
	Likewise.
	* util/rust-attributes.h:
	Likewise.

Signed-off-by: Kushal Pal <kushalpal109@gmail.com>