Daily bump.

c++: fix ICE with __type_pack_element [PR113834]

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.

c++: make build_throw SFINAE-friendly [PR98388]

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.

Fortran: error recovery on arithmetic overflow on unary operations [PR113799]

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.

libstdc++: Use _GLIBCXX_USE_BUILTIN_TRAIT for is_same

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>

c++/modules: anon union member of as-base class [PR112580]

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.

hwint: Introduce HOST_SIZE_T_PRINT_*

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.

libgcc, Darwin: Update symbol exports to include bitint and bf.

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.

expand: Fix asm goto expansion [PR113415]

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.

lower-bitint: Fix up additions of EH edges [PR113818]

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.

lower-bitint: Attempt not to emit always true conditions in handle_cast [PR113774]

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.

testsuite: Pattern does not match when using --specs=nano.specs

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>

Daily bump.

libstdc++: Fix comment typo in std::atomic<std::shared_ptr<T>>

libstdc++-v3/ChangeLog:

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

libstdc++: Add comment to gslice::operator=(const gslice&) [PR100147]

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.

RISC-V: Fix rvv intrinsic pragma tests dejagnu selector

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>

libstdc++: Guard tr2::bases and tr2::direct_bases with __has_builtin

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.

arm: testsuite: fix issues relating to fp16 alternative testing

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.

c++: NTTP type CTAD w/ tmpl from current inst [PR113649]

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>

ranger: Grow BBs in relation oracle as needed [PR113735]

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().

AVR: Tidy up gen-avr-mmcu-specs.cc

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.

x86: Update constraints for APX NDD instructions

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.

testsuite: address Jakub's comments on vect-early-break_1-PR113808.f90

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.

AVR: target/113824 - Fix multilib set for ATA5795.

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

middle-end: don't cache restart_loop in vectorizable_live_operations [PR113808]

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.

AVR: Always define __AVR_PM_BASE_ADDRESS__ in specs provided the core has it.

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

Revert part of vect_analyze_early_break_dependences changes

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.

testsuite: fix pointer conversion error in testcase vect-early-break_110-pr113467.c

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 *.

AVR: Rename device-specs %_misc to %_rodata_in_ram.

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.

RISC-V: Bugfix for RVV overloaded intrinsic ICE in function checker

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>

c: Fix boolean conversion of floating constant as integer constant expression [PR113776]

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.

c++: class nttp ICE

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.

Daily bump.

Update gcc zh_CN.po

* zh_CN.po: Update.

libstdc++: Work around modules issue causing hello-1 ICE [PR113710]

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>

tree-optimization/113796 - if-conversion and ranges

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.

PR target/113690: Remove TImode REG_EQUAL notes in STV.

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.

AArch64: Update system register database.

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.

gccrs: Fix macro parsing for trait items.

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>

gccrs: Remove obsolete classes and functions.

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>

gccrs: Parse trait functions as `AST::Function`.

To use AST::Function for trait functions, we can parse trait functions
using available parse_function().

gcc/rust/ChangeLog:

* parse/rust-parse-impl.h (Parser::parse_trait_item):
Use parse_function() to parse trait functions.

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

gccrs: Fix inconsistent formatting.

gcc/testsuite/ChangeLog:

* rust/compile/issue-2040.rs:
Enclose 'const' in single quotes.

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

gccrs: Add missing visitors for AST::Function.

To use AST::Function instead of AST::TraitItemFunc and
AST::TraitItemMethod, we need to provide similar visitors during
lowering and resolving phase.

gcc/rust/ChangeLog:

* hir/rust-ast-lower-implitem.cc (ASTLowerTraitItem::visit):
Provide visitor for AST::Function.
* hir/rust-ast-lower-implitem.h:
Likewise.
* resolve/rust-ast-resolve-implitem.h:
Likewise.
* resolve/rust-ast-resolve-item.cc (ResolveTraitItems::visit):
Likewise.
* resolve/rust-ast-resolve-item.h:
Likewise.

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

gccrs: Add checks for Trait functions

Since we want to use AST::Function class for trait functions as well, we
need to check against specific conditions in ASTValidation phase.

gcc/rust/ChangeLog:

* checks/errors/rust-ast-validation.cc (ASTValidation::visit):
Add checks for Trait functions.

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

gccrs: Use AssociatedItem in place of TraitItem

gcc/rust/ChangeLog:

* ast/rust-ast.h: Replace TraitItem with AssociatedItem.
* ast/rust-item.h (class Trait): Likewise.
* expand/rust-expand-visitor.cc (ExpandVisitor::visit):
Likewise.
* parse/rust-parse-impl.h (Parser::parse_trait): Likewise.
* parse/rust-parse.h: Likewise.

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

gccrs: fix bug in pattern check for tuples

We can point to generic parent types which means we need to do the shallow
resolve thing that rustc does. We have destructure which is similar to get
what the parameter type points to.

Fixes #2775

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-pattern.cc (TypeCheckPattern::visit): use destructure

gcc/testsuite/ChangeLog:

* rust/compile/issue-2775.rs: New test.

Signed-off-by: Philip Herron <herron.philip@googlemail.com>

gccrs: Add testcase to show issue is already fixed

Fixes #2782

gcc/testsuite/ChangeLog:

* rust/compile/issue-2782.rs: New test.

Signed-off-by: Philip Herron <herron.philip@googlemail.com>

gccrs: Move the Implementation of implitem lowering into its own file.

This patch moves the implementation of the implitem lowering
from rust-ast-lower-implitem.h into the rust-ast-lower-implitem.cc
file.

gcc/rust/ChangeLog:

* Make-lang.in: Add rust-ast-lower-implitem.cc to list of objects.
* hir/rust-ast-lower-implitem.h (RUST_AST_LOWER_IMPLITEM_H): Remove
implementation.
* hir/rust-ast-lower-implitem.cc: Copy implementation from header.

Signed-off-by: Nobel Singh <Nobel2073@gmail.com>

gccrs: refactor inference variable computation into a seperate method

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check.cc (TypeResolution::Resolve): refactor
* typecheck/rust-hir-type-check.h: new prototype
* typecheck/rust-typecheck-context.cc (TypeCheckContext::compute_inference_variables): x

gccrs: remove similar hack in type paths as we had in path expressions

This keeps the resolution code in line with paths.

Addresses #2723

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-type.cc: remove hack

gccrs: remove old generics hack to reuse generic symbols from previous seg

This patch introduces one regression because generics are getting better
understood over time. The code here used to apply generics with the same
symbol from previous segments which was a bit of a hack with out limited
inference variable support. The regression looks like it will be related
to another issue which needs to default integer inference variables much
more aggresivly to default integer.

Fixes #2723

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::resolve_segments): remove hack

gcc/testsuite/ChangeLog:

* rust/compile/issue-1773.rs: Moved to...
* rust/compile/issue-1773.rs.bak: ...here.
* rust/compile/issue-2723-1.rs: New test.
* rust/compile/issue-2723-2.rs: New test.

gccrs: Fix ICE accessing empty vector without check

Fixes #2747

gcc/rust/ChangeLog:

* typecheck/rust-tyty-subst.cc (SubstitutionRef::get_mappings_from_generic_args): fix

gcc/testsuite/ChangeLog:

* rust/compile/issue-2747.rs: New test.

gccrs: add test cases to prove type inference is working

Fixes #2772

gcc/testsuite/ChangeLog:

* rust/compile/issue-2772-1.rs: New test.
* rust/compile/issue-2772-2.rs: New test.

gccrs: add testcase to prove issue has already been fixed

Fixes #1483

gcc/testsuite/ChangeLog:

* rust/compile/issue-1483.rs: New test.

gccrs: Set the default ABI to C for extern blocks and extern functions

Previously, the default ABI was set to Rust, which is not correct for
extern blocks and extern functions. This patch changes the default
ABI to C for these cases.

gcc/rust/ChangeLog:

* hir/rust-ast-lower-base.cc (ASTLoweringBase::lower_qualifiers):
Change default ABI to C for extern functions
(ASTLoweringBase::lower_extern_block): Likewise

Signed-off-by: Nobel Singh <nobel2073@gmail.com>

gccrs: TyTy: Store reference to type before any substitutions

gcc/rust/ChangeLog:

* typecheck/rust-tyty.cc (BaseType::BaseType): Store orig ref.
(BaseType::get_orig_ref): Add getter.
* typecheck/rust-tyty.h: Store orig ref.

Signed-off-by: Jakub Dupak <dev@jakubdupak.com>

gccrs: TyTy: Store region constraints

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check-implitem.cc (TypeCheckTopLevelExternItem::visit):
Add region constraints.
(TypeCheckImplItem::visit): Add region constraints.
* typecheck/rust-hir-type-check-implitem.h: Add region constraints.
* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::ResolveImplBlockSelf):
Add region constraints.
(TypeCheckItem::visit): Add region constraints.
(TypeCheckItem::resolve_impl_item): Add region constraints.
(TypeCheckItem::resolve_impl_block_substitutions): Add region constraints.
* typecheck/rust-hir-type-check-item.h: Add region constraints.
* typecheck/rust-hir-type-check-type.cc (ResolveWhereClauseItem::Resolve):
Add region constraints.
(ResolveWhereClauseItem::visit): Add region constraints.
* typecheck/rust-hir-type-check-type.h (class ResolveWhereClauseItem):
Add region constraints.
* typecheck/rust-hir-type-check.cc (TraitItemReference::get_type_from_fn):
Add region constraints.
* typecheck/rust-tyty-bounds.cc (TypeBoundPredicate::TypeBoundPredicate):
Add region constraints.
* typecheck/rust-tyty-subst.cc (SubstitutionRef::get_region_constraints):
Add region constraints.
* typecheck/rust-tyty-subst.h (class BaseType): Add region constraints.
(struct RegionConstraints): Add region constraints.
* typecheck/rust-tyty.cc (BaseType::monomorphized_clone): Add region constraints.
(ADTType::clone): Add region constraints.
(FnType::clone): Add region constraints.
(ProjectionType::clone): Add region constraints.
* typecheck/rust-tyty.h: Add region constraints.

Signed-off-by: Jakub Dupak <dev@jakubdupak.com>

gccrs: Typecheck: add regions (lifetimes) to TyTy

gcc/rust/ChangeLog:

* typecheck/rust-hir-trait-resolve.cc: add regions
* typecheck/rust-hir-type-check-base.cc (TypeCheckBase::resolve_literal):
add regions, resolve generic lifetimes
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit): add regions
* typecheck/rust-hir-type-check-implitem.cc (TypeCheckTopLevelExternItem::visit):
add regions, resolve lifetimes
(TypeCheckImplItem::visit): add regions, resove lifetimes
* typecheck/rust-hir-type-check-implitem.h: add default value for result
* typecheck/rust-hir-type-check-item.cc (TypeCheckItem::visit): add regions,
resove lifetimes
(TypeCheckItem::resolve_impl_block_substitutions): add regions, resove lifetimes
* typecheck/rust-hir-type-check-path.cc (TypeCheckExpr::visit): add regions,
resove lifetimes
(TypeCheckExpr::resolve_root_path): add regions, resove lifetimes
(TypeCheckExpr::resolve_segments): add regions, resove lifetimes
* typecheck/rust-hir-type-check-type.cc (TypeCheckType::visit): add regions,
resove lifetimes
(TypeCheckType::resolve_root_path): add regions, resove lifetimes
(ResolveWhereClauseItem::Resolve): add regions, resove lifetimes
(ResolveWhereClauseItem::visit): add regions, resove lifetimes
* typecheck/rust-hir-type-check.cc (TypeCheckContext::LifetimeResolver::resolve):
add regions, resolve lifetimes
(TraitItemReference::get_type_from_fn): add regions, resove lifetimes
* typecheck/rust-hir-type-check.h: add regions, resove lifetimes
* typecheck/rust-substitution-mapper.cc (SubstMapper::SubstMapper): add regions,
resove lifetimes
(SubstMapper::Resolve): add regions, resove lifetimes
(SubstMapper::InferSubst): add regions, resove lifetimes
(SubstMapper::visit): add regions, resove lifetimes
* typecheck/rust-substitution-mapper.h: add regions, resove lifetimes
* typecheck/rust-typecheck-context.cc (TypeCheckContext::TypeCheckContext):
lifetime resolution
(TypeCheckContext::regions_from_generic_args): lifetime resolution helper
* typecheck/rust-tyty-bounds.cc (TypeBoundPredicate::TypeBoundPredicate):
add regions, resove lifetimes
(TypeBoundPredicate::operator=): add regions, resove lifetimes
(TypeBoundPredicate::apply_generic_arguments): add regions, resove lifetimes
(TypeBoundPredicateItem::get_tyty_for_receiver): add regions, resove lifetimes
* typecheck/rust-tyty-subst.cc (SubstitutionArgumentMappings::get_regions):
add regions, resove lifetimes
(SubstitutionArgumentMappings::get_mut_regions): getter
(SubstitutionArgumentMappings::error): split error and empty
(SubstitutionArgumentMappings::empty): split error and empty
(SubstitutionArgumentMappings::find_symbol): helper
(SubstitutionRef::get_num_lifetime_params): getter
(SubstitutionRef::get_num_type_params): getter
(SubstitutionRef::needs_substitution): extend to regions
(SubstitutionRef::get_mappings_from_generic_args): helper
(SubstitutionRef::infer_substitions): add regions
* typecheck/rust-tyty-subst.h (class RegionParamList): region param handler
* typecheck/rust-tyty.cc (BaseType::monomorphized_clone): add regions, resove lifetimes
(InferType::default_type): add regions, resove lifetimes
(FnType::clone): add regions, resove lifetimes
(ReferenceType::ReferenceType): add regions
(ReferenceType::get_region): getter
(ReferenceType::clone): add regions
* typecheck/rust-tyty.h: add regions, resove

Signed-off-by: Jakub Dupak <dev@jakubdupak.com>

gccrs: HIR: Add mising getter

gcc/rust/ChangeLog:

* hir/tree/rust-hir-item.h: Add missing getter

Signed-off-by: Jakub Dupak <dev@jakubdupak.com>

gccrs: TyTy: Region (lifetime) representation

gcc/rust/ChangeLog:

* typecheck/rust-tyty-region.h: New file.

Signed-off-by: Jakub Dupak <dev@jakubdupak.com>

gccrs: Typecheck: lifetime interning and resolution tool

gcc/rust/ChangeLog:

* typecheck/rust-hir-type-check.h (class Lifetime): add interned lifetime class
* typecheck/rust-typecheck-context.cc (TypeCheckContext::TypeCheckContext): add
resolution tool
(TypeCheckContext::intern_lifetime): add method to intern lifetime from tyctx
(TypeCheckContext::lookup_lifetime): add method to lookup lifetime from tyctx
(TypeCheckContext::intern_and_insert_lifetime): add a helper method

Signed-off-by: Jakub Dupak <dev@jakubdupak.com>

gccrs: Implement quick-check for Unicode

gcc/rust/ChangeLog:

* rust-lang.cc (run_rust_tests): Add test.
* rust-system.h: Add <algorithm>.
* util/make-rust-unicode.py: Output NFC_Quick_Check table.
* util/rust-codepoint.h (struct Codepoint): Add is_supplementary
method.
* util/rust-unicode-data.h: Generated.
* util/rust-unicode.cc (binary_search_sorted_array): Removed.
(lookup_cc): Remove namespace.
(is_alphabetic): Use std::binary_search
(nfc_quick_check): New function.
(nfc_normalize): Use nfc_quick_check.
(is_nfc_qc_maybe): New function.
(is_nfc_qc_no): New function.
(rust_nfc_qc_test): New test.
* util/rust-unicode.h (is_nfc_qc_no): New function.
(is_nfc_qc_maybe): New function.
(enum class): New enum class.
(nfc_quick_check): New function.
(rust_nfc_qc_test): New test.

Signed-off-by: Raiki Tamura <tamaron1203@gmail.com>

gccrs: Parse normal functions with `self` parameter correctly

Fixes #2812

gcc/rust/ChangeLog:

* parse/rust-parse-impl.h (Parser::parse_function):
Skip token if its a COMMA.

gcc/testsuite/ChangeLog:

* rust/compile/issue-2812.rs: New test.

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

Apply TLC to vect_analyze_early_break_dependences

There has been some confusion in my understanding of how early breaks
work, the following clarifies some comments and undoes one change that
shouldn't have been necessary.  It also fixes the dependence test
to avoit TBAA (we're moving stores down across loads).

* tree-vect-data-refs.cc (vect_analyze_early_break_dependences):
Only check whether reads are in-bound in places that are not safe.
Fix dependence check.  Add missing newline.  Clarify comments.

middle-end: fix ICE when destination BB for stores starts with a label [PR113750]

The report shows that if the FE leaves a label as the first thing in the dest
BB then we ICE because we move the stores before the label.

This is easy to fix if we know that there's still only one way into the BB.
We would have already rejected the loop if there was multiple paths into the BB
however I added an additional check just for early break in case the other
constraints are relaxed later with an explanation.

After that we fix the issue just by getting the GSI after the labels and I add
a bunch of testcases for different positions the label can be added.  Only the
vect-early-break_112-pr113750.c one results in the label being kept.

gcc/ChangeLog:

PR tree-optimization/113750
* tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Check
for single predecessor when doing early break vect.
* tree-vect-loop.cc (move_early_exit_stmts): Get gsi at the start but
after labels.

gcc/testsuite/ChangeLog:

PR tree-optimization/113750
* gcc.dg/vect/vect-early-break_112-pr113750.c: New test.
* gcc.dg/vect/vect-early-break_113-pr113750.c: New test.
* gcc.dg/vect/vect-early-break_114-pr113750.c: New test.
* gcc.dg/vect/vect-early-break_115-pr113750.c: New test.
* gcc.dg/vect/vect-early-break_116-pr113750.c: New test.

middle-end: fix ICE when moving statements to empty BB [PR113731]

We use gsi_move_before (&stmt_gsi, &dest_gsi); to request that the new statement
be placed before any other statement.  Typically this then moves the current
pointer to be after the statement we just inserted.

However it looks like when the BB is empty, this does not happen and the CUR
pointer stays NULL.   There's a comment in the source of gsi_insert_before that
explains:

/* If CUR is NULL, we link at the end of the sequence (this case happens

This adds a default parameter to gsi_move_before to allow us to control where
the insertion happens.

gcc/ChangeLog:

PR tree-optimization/113731
* gimple-iterator.cc (gsi_move_before): Take new parameter for update
method.
* gimple-iterator.h (gsi_move_before): Default new param to
GSI_SAME_STMT.
* tree-vect-loop.cc (move_early_exit_stmts): Call gsi_move_before with
GSI_NEW_STMT.

gcc/testsuite/ChangeLog:

PR tree-optimization/113731
* gcc.dg/vect/vect-early-break_111-pr113731.c: New test.

middle-end: add additional runtime test for [PR113467]

This just adds an additional runtime testcase for the fixed issue.

gcc/testsuite/ChangeLog:

PR tree-optimization/113467
* gcc.dg/vect/vect-early-break_110-pr113467.c: New test.

range-op: Fix up ABSU_EXPR handling [PR113756]

ABSU_EXPR unary expr is special because it has a signed integer
argument and unsigned integer result (of the same precision).

The following testcase is miscompiled since ABSU_EXPR handling has
been added to range-op because it uses widest_int::from with the
result sign (i.e. UNSIGNED) rather than the operand sign (i.e. SIGNED),
so e.g. for the 32-bit int argument mask ends up 0xffffffc1 or something
similar and even when it has most significant bit in the precision set,
in widest_int (tree-ssa-ccp.cc really should stop using widest_int, but
that is I think stage1 task) it doesn't appear to be negative and so
bit_value_unop ABSU_EXPR doesn't set the resulting mask/value from
oring of the argument and its negation.

Fixed thusly, not doing that for GIMPLE_BINARY_RHS because I don't know
about a binary op that would need something similar.

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

PR tree-optimization/113756
* range-op.cc (update_known_bitmask): For GIMPLE_UNARY_RHS,
use TYPE_SIGN (lh.type ()) instead of sign for widest_int::from
of lh_bits value and mask.

* gcc.dg/pr113756.c: New test.

testsuite: Don't xfail gcc.dg/debug/dwarf2/inline5.c

gcc.dg/debug/dwarf2/inline5.c has been XPASSing on Solaris (both SPARC
and x86, 32 and 64-bit) with the native assembler since 20210429.
According to gcc-testresults postings, the same is true on AIX.

XPASS: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not \\\\(DIE \\\\(0x([0-9a-f]*)\\\\) DW_TAG_lexical_block\\\\)[^#/!@;\\\\|]*[#/!@;\\\\|]+ +DW_AT.*DW_TAG_lexical_block\\\\)[^#/!@;\\\\|x]*x\\\\1[^#/!@;\\\\|]*[#/!@;\\\\|] +DW_AT_abstract_origin

This is obviously due to

commit 16683cefc636636ba6fed23fe0de89ed19bc7876
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Wed Apr 28 14:07:41 2021 -0300

    fix asm-not pattern in dwarf2/inline5.c

This patch thus removes the xfail.

Tested on i386-pc-solaris2.11 (as and gas), sparc-sun-solaris2.11 (as
and gas), and i686-pc-linux-gnu.

2024-02-06  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

gcc/testsuite:
* gcc.dg/debug/dwarf2/inline5.c: Don't xfail scan-assembler-not on
{ aix || solaris2 } && !gas.

wide-int: Fix mul_internal overflow handling [PR113753]

As the following testcases show, the overflow (needs_overflow) and high
handling in wi::mul_internal seem to only work correctly for either
small precisions (less than or equal to 32, that is handled by earlier
simpler code, not the full Knuth's multiplication algorithm) or for
precisions which are multiple of HOST_BITS_PER_WIDE_INT, so it happened
to work fine in most pre-_BitInt era types (and for large bitfields we
probably didn't have good coverage or were lucky and nothing was asking
if there was overflow or not; I think high multiplication is typically
used only when we have optab in corresponding mode).
E.g. on the gcc.dg/bitint-87.c testcase, there were overflow warnings
emitted only the the / 2wb * 3wb _BitInt(128) cases, but not in the
other precisions.

I found 3 issues when prec > HOST_BITS_PER_HALF_WIDE_INT and
(prec % HOST_BITS_PER_WIDE_INT) != 0:
1) the checking for overflow was simply checking the values of the
   r array members from half_blocks_needed to 2 * half_blocks_needed - 1,
   for UNSIGNED overflow checking if any of them is non-zero, for
   SIGNED comparing them if any is different from top where top is computed
   from the sign bit of the result (see below); similarly, the highpart
   multiplication simply picks the half limbs at r + half_blocks_needed
   offset; and furthermore, for SIGNED there is an adjustment if either
   operand was negative which also just walks r half-limbs from
   half_blocks_needed onwards;
   this works great for precisions like 64 or 128, but for precisions like
   129, 159, 160 or 161 doesn't, it would need to walk the bits in the
   half-limbs starting right above the most significant bit of the base
   precision; that can be up to a whole half-limb and all but one bit from
   the one below it earlier
2) as the comment says, the multiplication is originally done as unsigned
   multiplication, with adjustment of the high bits which subtracts the
   other operand once:
      if (wi::neg_p (op1))
        {
          b = 0;
          for (i = 0; i < half_blocks_needed; i++)
            {
              t = (unsigned HOST_WIDE_INT)r[i + half_blocks_needed]
                - (unsigned HOST_WIDE_INT)v[i] - b;
              r[i + half_blocks_needed] = t & HALF_INT_MASK;
              b = t >> (HOST_BITS_PER_WIDE_INT - 1);
            }
        }
   and similarly for the other one.  Now, this also only works nicely if
   a negative operand has just a single sign bit set in the given precision;
   but we were unpacking the operands with wi_unpack (..., SIGNED);, so
   say for the negative operand in 129-bit precision, that means the least
   significant bit of u[half_blocks_needed - 2] (or v instead of u depending
   on which argument it is) is the set sign bit, but then there are 31
   further copies of the sign bit in u[half_blocks_needed - 2] and
   further 32 copies in u[half_blocks_needed - 1]; the above adjustment
   for signed operands doesn't really do the right job in such cases, it
   would need to subtract many more times the other operand
3) the computation of top for SIGNED
          top = r[(half_blocks_needed) - 1];
          top = SIGN_MASK (top << (HOST_BITS_PER_WIDE_INT / 2));
          top &= mask;
   also uses the most significant bit which fits into prec of the result
   only if prec is multiple of HOST_BITS_PER_WIDE_INT, otherwise we need
   to look at a different bit and sometimes it can be also a bit in
   r[half_blocks_needed - 2]

For 1), while for UNSIGNED overflow it could be fairly easy to check
the bits above prec in r half-limbs for being non-zero, doing all the
shifts also in the SIGNED adjustment code in 2 further locations and finally
for the high handling (unless we want to assert one doesn't do the highpart
multiply for such precisions) would be quite ugly and hard to maintain, so
I instead chose (implemented in the second hunk) to shift the
beyond-precision bits up such that the expectations of the rest of the
code are met, that is the LSB of r[half_blocks_needed] after adjustment
is the bit immediately above the precision, etc.  We don't need to care
about the bits it shifts out, because the multiplication will yield at most
2 * prec bits.

For 2), the patch changes the wi_unpack argument from SIGNED to UNSIGNED,
so that we get all zero bits above the precision.

And finally for 3) it does shifts and perhaps picks lower r half-limb so
that it uses the actual MSB of the result within prec.

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

PR tree-optimization/113753
* wide-int.cc (wi::mul_internal): Unpack op1val and op2val with
UNSIGNED rather than SIGNED.  If high or needs_overflow and prec is
not a multiple of HOST_BITS_PER_WIDE_INT, shift left bits above prec
so that they start with r[half_blocks_needed] lowest bit.  Fix up
computation of top mask for SIGNED.

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

RISC-V: Bugfix for RVV overloaded intrinisc ICE when empty args

There is one corn case when similar as below example:

void test (void)
{
  __riscv_vfredosum_tu ();
}

It will meet ICE because of the implement details of overloaded function
in gcc.  According to the rvv intrinisc doc, we have no such overloaded
function with empty args.  Unfortunately, we register the empty args
function as overloaded for avoiding conflict.  Thus, there will be actual
one register function after return NULL_TREE back to the middle-end,
and finally result in ICE when expanding.  For example:

1. First we registered void __riscv_vfredmax () as the overloaded function.
2. Then resolve_overloaded_builtin (this func) return NULL_TREE.
3. The functions register in step 1 bypass the args check as empty args.
4. Finally, fall into expand_builtin with empty args and meet ICE.

Here 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_vfredosum_tu' with empty args
    8 |   __riscv_vfredosum_tu();
      |   ^~~~~~~~~~~~~~~~~~~~

Below test are passed for this patch.

* The riscv regression tests.

PR target/113766

gcc/ChangeLog:

* config/riscv/riscv-protos.h (resolve_overloaded_builtin): Adjust
the signature of func.
* config/riscv/riscv-c.cc (riscv_resolve_overloaded_builtin): Ditto.
* config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin): Make
overloaded func with empty args error.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr113766-1.c: New test.
* gcc.target/riscv/rvv/base/pr113766-2.c: New test.

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

Daily bump.

c++: Disallow this specifier except for parameter declarations [PR113788]

The deducing this patchset added parsing of this specifier to
cp_parser_decl_specifier_seq unconditionally, but in the C++ grammar
this[opt] only appears in the parameter-declaration non-terminal, so
rather than checking in all the callers of cp_parser_decl_specifier_seq
except for cp_parser_parameter_declaration that this specifier didn't
appear I think it is far easier and closer to what the standard says
to only parse this specifier when called from
cp_parser_parameter_declaration.

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

PR c++/113788
* parser.cc (CP_PARSER_FLAGS_PARAMETER): New enumerator.
(cp_parser_decl_specifier_seq): Parse RID_THIS only if
CP_PARSER_FLAGS_PARAMETER is set in flags.
(cp_parser_parameter_declaration): Or in CP_PARSER_FLAGS_PARAMETER
when calling cp_parser_decl_specifier_seq.

* g++.dg/parse/pr113788.C: New test.

x86-64: Return 10_REG if there is no scratch register

If we can't find a scratch register for large model profiling, return
R10_REG.

PR target/113689
* config/i386/i386.cc (x86_64_select_profile_regnum): Return
R10_REG after sorry.

c++: add fixed test [PR94231]

I was suprised to find out that r14-8759 fixed this accepts-invalid.

clang version 17.0.6 rejects the test as well; clang version 19.0.0git
crashes for which I opened
<https://github.com/llvm/llvm-project/issues/80869>.

PR c++/94231

gcc/testsuite/ChangeLog:

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

aarch64: Fix function multiversioning mangling

It would be neater if the middle end for target_clones used a target
hook for version name mangling, so we only do version name mangling
once.  However, that would require more intrusive refactoring that will
have to wait till Stage 1.

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_mangle_decl_assembler_name):
Move before new caller, and add ".default" suffix.
(get_suffixed_assembler_name): New.
(make_resolver_func): Use get_suffixed_assembler_name.
(aarch64_generate_version_dispatcher_body): Redo name mangling.

gcc/testsuite/ChangeLog:

* g++.target/aarch64/mv-symbols1.C: New test.
* g++.target/aarch64/mv-symbols2.C: Ditto.
* g++.target/aarch64/mv-symbols3.C: Ditto.
* g++.target/aarch64/mv-symbols4.C: Ditto.
* g++.target/aarch64/mv-symbols5.C: Ditto.
* g++.target/aarch64/mvc-symbols1.C: Ditto.
* g++.target/aarch64/mvc-symbols2.C: Ditto.
* g++.target/aarch64/mvc-symbols3.C: Ditto.
* g++.target/aarch64/mvc-symbols4.C: Ditto.

aarch64: Fix build against libc++ in c++11 mode [PR113763]

std::pair ctor used in tiles constexpr variable is only constexpr in C++14
and later, it works with libstdc++ because it is marked constexpr there even
in C++11 mode.

The following patch fixes it by using an unnamed local class instead of
std::pair, and additionally changes the first element from unsigned int to
unsigned char because 0xff has to fit into unsigned char on all hosts.

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

PR target/113763
* config/aarch64/aarch64.cc (aarch64_output_sme_zero_za): Change tiles
element from std::pair<unsigned int, char> to an unnamed struct.
Adjust uses of tile range variable.

c++: add auto_diagnostic_group to early_check_defaulted_comparison

gcc/cp/ChangeLog:

* method.cc (early_check_defaulted_comparison): Add
auto_diagnostic_group.

RISC-V: Fix infinite compilation of VSETVL PASS

This patch fixes issue reported by Jeff.

Testing is running. Ok for trunk if I passed the testing with no regression ?

gcc/ChangeLog:

* config/riscv/riscv-vsetvl.cc (pre_vsetvl::emit_vsetvl): Fix inifinite compilation.
(pre_vsetvl::remove_vsetvl_pre_insns): Ditto.

asan: Don't fold some strlens with -fsanitize=address [PR110676]

The UB on the following testcase isn't diagnosed by -fsanitize=address,
because we see that the array has a single element and optimize the
strlen to 0.  I think it is fine to assume e.g. for range purposes the
lower bound for the strlen as long as we don't try to optimize
strlen (str)
where we know that it returns [26, 42] to
26 + strlen (str + 26), but for the upper bound we really want to punt
on optimizing that for -fsanitize=address to read all the bytes of the
string and diagnose if we run to object end etc.

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

PR sanitizer/110676
* gimple-fold.cc (gimple_fold_builtin_strlen): For -fsanitize=address
reset maxlen to sizetype maximum.

* gcc.dg/asan/pr110676.c: New test.

lower-bitint: Encode address space qualifiers in VIEW_CONVERT_EXPRs [PR113736]

As discussed in the PR, e.g. build_fold_addr_expr needs TYPE_ADDR_SPACE
on the outermost reference rather than just on the base, so the
following patch makes sure to propagate the address space from
the accessed var to the MEM_REFs and/or VIEW_CONVERT_EXPRs used to
access those.

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

PR tree-optimization/113736
* gimple-lower-bitint.cc (bitint_large_huge::limb_access): Use
var's address space for MEM_REF or VIEW_CONVERT_EXPRs.

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

tree-ssa-math-opts: Fix up convert_{mult,plusminus}_to_widen [PR113759]

On the following testcase we emit invalid stmt:
error: type mismatch in ‘widen_mult_plus_expr’
    6 | foo (int c, int b)
      | ^~~
unsigned long
int
unsigned int
unsigned long
_31 = WIDEN_MULT_PLUS_EXPR <b_5(D), 2, _30>;

The recent PR113560 r14-8680 changes tweaked convert_mult_to_widen,
but didn't change convert_plusminus_to_widen for the
TREE_TYPE (rhsN) != typeN cases, but looking at this, it was already
before that change quite weird.

Earlier in those functions it determines actual_precision and from_unsignedN
and wants to use that precision and signedness for the operands and
it used build_and_insert_cast for that (which emits a cast stmt, even for
INTEGER_CSTs) and later on for INTEGER_CST arguments fold_converted them
to typeN (which is unclear to me why, because it seems to have assumed
that TREE_TYPE (rhsN) is typeN, for the actual_precision or from_unsignedN
cases it would be wrong except that build_and_insert_cast forced a SSA_NAME
and so it doesn't trigger anymore).
Now, since r14-8680 it is possible that rhsN also has some other type from
typeN and we again want to cast.

The following patch changes this, so that for the differences in
actual_precision and/or from_unsignedN we actually update typeN and then use
it as the type to convert the arguments to if it isn't useless, for
INTEGER_CSTs by just fold_converting, otherwise using build_and_insert_cast.
And uses useless_type_conversion_p test so that we don't convert unless
necessary.  Plus by doing that effectively also doing the important part of
the r14-8680 convert_mult_to_widen changes in convert_plusminus_to_widen.

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

PR tree-optimization/113759
* tree-ssa-math-opts.cc (convert_mult_to_widen): If actual_precision
or from_unsignedN differs from properties of typeN, update typeN
to build_nonstandard_integer_type.  If TREE_TYPE (rhsN) is not
uselessly convertible to typeN, convert it using fold_convert or
build_and_insert_cast depending on if rhsN is INTEGER_CST or not.
(convert_plusminus_to_widen): Likewise.

* gcc.c-torture/compile/pr113759.c: New test.

libssp: Fix gets-chk.c compilation on Solaris

The recent warning patches broke the libssp build on Solaris:

/vol/gcc/src/hg/master/local/libssp/gets-chk.c: In function '__gets_chk':
/vol/gcc/src/hg/master/local/libssp/gets-chk.c:67:12: error: implicit
declaration of function 'gets'; did you mean 'getw'?
[-Wimplicit-function-declaration]
   67 |     return gets (s);
      |            ^~~~
      |            getw
/vol/gcc/src/hg/master/local/libssp/gets-chk.c:67:12: error: returning
'int' from a function with return type 'char *' makes pointer from integer
without a cast [-Wint-conversion]
   67 |     return gets (s);
      |            ^~~~~~~~
/vol/gcc/src/hg/master/local/libssp/gets-chk.c:74:12: error: returning
'int' from a function with return type 'char *' makes pointer from integer
without a cast [-Wint-conversion]
   74 |     return gets (s);
      |            ^~~~~~~~

The guard around the gets declaration in gets-chk.c is

      || (defined __cplusplus && __cplusplus <= 201103L))
extern char *gets (char *);

where __USE_ISOC11 is glibc-only, while Solaris <iso/stdio_iso.h> declares
gets like

extern char     *gets(char *) __ATTR_DEPRECATED;

Instead of using a target-specific macro, this patch just uses the
canonical autoconf test.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
x86_64-pc-linux-gnu, x86_64-apple-darwin23.3.0, and amd64-freebsd14.0.

2023-12-07  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

libssp:
* configure.ac (AC_CHECK_DECLS): Check for gets.
* configure, config.h.in: Regenerate.
* gets-chk.c (gets): Guard declaration with !HAVE_DECL_GETS.

AArch64: aarch64_class_max_nregs mishandles 64-bit structure modes [PR112577]

The target hook aarch64_class_max_nregs returns the incorrect result for 64-bit
structure modes like V31DImode or V41DFmode etc.  The calculation of the nregs
is based on the size of AdvSIMD vector register for 64-bit modes which ought to
be UNITS_PER_VREG / 2.  This patch fixes the register size.

gcc/ChangeLog:

PR target/112577
* config/aarch64/aarch64.cc (aarch64_class_max_nregs): Handle 64-bit
vector structure modes correctly.

libgcc: Export i386 symbols added after GCC_7.0.0 on Solaris [PR113700]

As reported in the PR, all libgcc x86 symbol versions added after
GCC_7.0.0 were only added to i386/libgcc-glibc.ver, missing all of
libgcc-sol2.ver, libgcc-bsd.ver, and libgcc-darwin.ver.

This patch fixes this for Solaris/x86, adding all of them
(GCC_1[234].0.0) as GCC_14.0.0 to not retroactively change history.

Since this isn't the first time this happens, I've added a note to the
end of libgcc-glibc.ver to request notifying other maintainers in case
of additions.

Tested on i386-pc-solaris2.11.

2024-02-01  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

libgcc:
PR target/113700
* config/i386/libgcc-sol2.ver (GCC_14.0.0): Added all symbols from
i386/libgcc-glibc.ver (GCC_12.0.0, GCC_13.0.0, GCC_14.0.0).
* config/i386/libgcc-glibc.ver: Request notifications on updates.

libgcc: fix SEH C++ rethrow semantics [PR113337]

SEH _Unwind_Resume_or_Rethrow invokes abort directly if
_Unwind_RaiseException doesn't manage to find a handler for the rethrown
exception; this is incorrect, as in this case std::terminate should be
invoked, allowing an application-provided terminate handler to handle
the situation instead of straight crashing the application through
abort.

The bug can be demonstrated with this simple test case:
===
static void custom_terminate_handler() {
    fprintf(stderr, "custom_terminate_handler invoked\n");
    std::exit(1);
}

int main(int argc, char *argv[]) {
    std::set_terminate(&custom_terminate_handler);
    if (argc < 2) return 1;
    const char *mode = argv[1];
    fprintf(stderr, "%s\n", mode);
    if (strcmp(mode, "throw") == 0) {
        throw std::exception();
    } else if (strcmp(mode, "rethrow") == 0) {
        try {
            throw std::exception();
        } catch (...) {
            throw;
        }
    } else {
        return 1;
    }
    return 0;
}
===

On all gcc builds with non-SEH exceptions, this will print
"custom_terminate_handler invoked" both if launched as ./a.out throw or
as ./a.out rethrow, on SEH builds instead if will work as expected only
with ./a.exe throw, but will crash with the "built-in" abort message
with ./a.exe rethrow.

This patch fixes the problem, forwarding back the error code to the
caller (__cxa_rethrow), that calls std::terminate if
_Unwind_Resume_or_Rethrow returns.

The change makes the code path coherent with SEH _Unwind_RaiseException,
and with the generic _Unwind_Resume_or_Rethrow from libgcc/unwind.inc
(used for SjLj and Dw2 exception backend).

libgcc/ChangeLog:

PR libgcc/113337

* unwind-seh.c (_Unwind_Resume_or_Rethrow): forward
_Unwind_RaiseException return code back to caller instead of
calling abort, allowing __cxa_rethrow to invoke std::terminate
in case of uncaught rethrown exception

libstdc++: /dev/null is not accessible on Windows

When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".

In 17_intro/tag_type_explicit_ctor.cc, the following statement would
fail to match when the DejaGNU testsuite is running in cygwin with a
native toolchain.
// dg-error 53 "explicit" "" { target hosted }

The "target hosted"-check is using cpp to verify if _GLIBCXX_HOSTED is
defined and discards the output by simply redirecting it to /dev/null.
In v3_target_compile, it's overridden to "nul" for MinGW targets, but
the same rule applies when host is cygwin, so replace the condition
with a check for Windows.

The error in the log would look like this for the "target hosted" check:
cc1plus.exe: fatal error: opening output file /dev/null: No such file or directory

The tag_type_explicit_ctor.cc test fails with this on Windows:
.../tag_type_explicit_ctor.cc:53: error: converting to 'std::defer_lock_t' from initializer list would use explicit constructor 'constexpr std::defer_lock_t::defer_lock_t()'
.../tag_type_explicit_ctor.cc:54: error: converting to 'std::try_to_lock_t' from initializer list would use explicit constructor 'constexpr std::try_to_lock_t::try_to_lock_t()'
.../tag_type_explicit_ctor.cc:55: error: converting to 'std::try_to_lock_t' from initializer list would use explicit constructor 'constexpr std::try_to_lock_t::try_to_lock_t()'
.../tag_type_explicit_ctor.cc:67: error: converting to 'std::defer_lock_t' from initializer list would use explicit constructor 'constexpr std::defer_lock_t::defer_lock_t()'
.../tag_type_explicit_ctor.cc:68: error: converting to 'std::try_to_lock_t' from initializer list would use explicit constructor 'constexpr std::try_to_lock_t::try_to_lock_t()'
.../tag_type_explicit_ctor.cc:69: error: converting to 'std::adopt_lock_t' from initializer list would use explicit constructor 'constexpr std::adopt_lock_t::adopt_lock_t()'

Patch has been verified on Windows and Linux.

libstdc++-v3:

* testsuite/lib/libstdc++.exp: Use "nul" for Windows, "/dev/null"
for other environments.

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

c++: defaulted op== for incomplete class [PR107291]

After complaining about lack of friendship, we should not try to go on and
define the defaulted comparison operator anyway.

PR c++/107291

gcc/cp/ChangeLog:

* method.cc (early_check_defaulted_comparison): Fail if not friend.

gcc/testsuite/ChangeLog:

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

LoongArch: libsanitizer: Enable Lsan and Tsan for loongarch64.

libsanitizer/ChangeLog:

* configure.tgt: Enable tsan and lsan for loongarch64.
* tsan/Makefile.am (EXTRA_libtsan_la_SOURCES): Add
tsan_rtl_loongarch64.S.
* tsan/Makefile.in: Regenerate.

Daily bump.

riscv: Fix compiler warning in thead.cc

A recent commit introduced a compiler warning in thead.cc:
error: invalid suffix on literal; C++11 requires a space between literal and string macro [-Werror=literal-suffix]
 1144 |       fprintf (file, "(%s),"HOST_WIDE_INT_PRINT_DEC",%u", reg_names[REGNO (addr.reg)],
      |                      ^

This commit addresses this issue and breaks the line such that it won't
exceed 80 characters.

gcc/ChangeLog:

* config/riscv/thead.cc (th_print_operand_address): Fix compiler
warning.

Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>

c++: -frounding-math test [PR109359]

This test was fixed by the patch for PR95226, but that patch had no
testcase so let's add this one.

PR c++/109359

gcc/testsuite/ChangeLog:

* g++.dg/ext/frounding-math1.C: New test.

Update gcc zh_CN.po

* zh_CN.po: Update.

c++: prvalue of array type [PR111286]

Here we want to build a prvalue array to bind to the T reference, but we
were wrongly trying to strip cv-quals from the array prvalue, which should
be treated the same as a class prvalue.

PR c++/111286

gcc/cp/ChangeLog:

* tree.cc (rvalue): Don't drop cv-quals from an array.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-array22.C: New test.

libgo: bump libgo version for GCC 14 release

PR go/113668

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

compiler: add Type::message_name

As we move toward generics, the error messages need to be able
to refer to types in a readable manner.  Add that capability,
and use it today in AST dumps.

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

x86-64: Find a scratch register for large model profiling

2 scratch registers, %r10 and %r11, are available at function entry for
large model profiling.  But %r10 may be used by stack realignment and we
can't use %r10 in this case.  Add x86_64_select_profile_regnum to find
a caller-saved register which isn't live or a callee-saved register
which has been saved on stack in the prologue at entry for large model
profiling and sorry if we can't find one.

gcc/

PR target/113689
* config/i386/i386.cc (x86_64_select_profile_regnum): New.
(x86_function_profiler): Call x86_64_select_profile_regnum to
get a scratch register for large model profiling.

gcc/testsuite/

PR target/113689
* gcc.target/i386/pr113689-1.c: New file.
* gcc.target/i386/pr113689-2.c: Likewise.
* gcc.target/i386/pr113689-3.c: Likewise.

contrib: Fill in HOST{CC,CFLAGS,CXX,CXXFLAGS} in test_installed

gcc/Makefile.in since my r0-60234 change fills in HOSTCC and HOSTCFLAGS
in site.exp and since r8-671 also HOSTCXX and HOSTCXXFLAGS.
If those variables aren't set, we get errors like:
/usr/src/gcc/contrib/test_installed --without-g++ --without-gfortran --without-objc struct-layout-1.exp
...
ERROR: tcl error sourcing /usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp.
ERROR: tcl error code TCL LOOKUP VARNAME HOSTCC
ERROR: can't read "HOSTCC": no such variable
    while executing
"remote_exec build "$HOSTCC $HOSTCFLAGS $generator_cmd""
    (file "/usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp" line 96)
    invoked from within
"source /usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 source /usr/src/gcc/gcc/testsuite/gcc.dg/compat/struct-layout-1.exp"
    invoked from within
"catch "uplevel #0 source $test_file_name" msg"

(similarly in g++ or gfortran) struct-layout-1.exp.  One doesn't need to
test specially for just struct-layout-1.exp alone, just not using any arg
will trigger it as well, just later.

The following patch fills it in as cc and c++ with empty flags to compile
those, I believe that is what e.g. make uses by default, so it should be a
reasonable default.  We IMHO shouldn't default to GCC_UNDER_TEST because
that might be a cross-compiler etc.

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

* test_installed: Fill in HOSTCC, HOSTCXX, HOSTCFLAGS and
HOSTCXXFLAGS.

c: Avoid ICE with _BitInt(N) : 0 bitfield [PR113740]

finish_struct already made sure not to call build_bitint_type for
signed _BitInt(2) : 1;
or
signed _BitInt(2) : 0;
bitfields (but instead build a zero precision integral type,
we remove it later), this patch makes sure we do it also for
unsigned _BitInt(1) : 0;
because of the build_bitint_type assertion that precision is
>= (unsigned ? 1 : 2).

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

PR c/113740
* c-decl.cc (finish_struct): Only use build_bitint_type if
bit-field has width larger or equal to minimum _BitInt
precision.

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