Because basic_ostream::sentry::~sentry is implicitly noexcept, we can't
let any exceptions escape from it, or the program would terminate. If
the streambuf's sync() function throws, or if it returns an error and
setting badbit in the stream state throws, then the program would
terminate.

LWG 835 intended to prevent exceptions from being thrown by the
std::basic_ostream::sentry destructor, but failed to cover the case
where the streambuf's sync() member throws an exception. LWG 4188 is
needed to fix that part. In any case, LWG 835 was never implemented for
libstdc++ so this does that, as well as my proposed fix for 4188 (that
badbit should be set if pubsync() exits via an exception).

In order to avoid a second try-catch block to handle an exception that
might be thrown by setting badbit, this introduces an RAII helper class
that temporarily clears the stream's exceptions mask, then restores it
afterwards.

The try-catch block doesn't handle the forced_unwind exception
explicitly, because catching and rethrowing that would just terminate
when it reached the sentry's implicit noexcept(true) anyway.

libstdc++-v3/ChangeLog:

	* include/bits/ostream.h (basic_ostream::_Disable_exceptions):
	RAII helper type.
	(basic_ostream::sentry::~sentry): Use _Disable_exceptions. Add
	try-catch block around call to pubsync.
	* testsuite/27_io/basic_ostream/exceptions/char/lwg4188.cc: New
	test.
	* testsuite/27_io/basic_ostream/exceptions/wchar_t/lwg4188.cc:
	New test.

Add a comment referencing PR 111050, to ensure the fix made by
r12-9903-g1be57348229666 doesn't get reverted.

libstdc++-v3/ChangeLog:

	PR libstdc++/111050
	* include/bits/hashtable_policy.h (_Hash_node_value_base): Add
	comment about always_inline attributes.

Inspired by PR118103, the VXRM register should be treated almost the
same as the FRM register, aka cooperatively-managed global register.
Thus, add the VXRM to global_regs to avoid the elimination by the
late-combine pass.

For example as below code:

  21   │
  22   │ void compute ()
  23   │ {
  24   │   size_t vl = __riscv_vsetvl_e16m1 (N);
  25   │   vuint16m1_t va = __riscv_vle16_v_u16m1 (a, vl);
  26   │   vuint16m1_t vb = __riscv_vle16_v_u16m1 (b, vl);
  27   │   vuint16m1_t vc = __riscv_vaaddu_vv_u16m1 (va, vb, __RISCV_VXRM_RDN, vl);
  28   │
  29   │   __riscv_vse16_v_u16m1 (c, vc, vl);
  30   │ }
  31   │
  32   │ int main ()
  33   │ {
  34   │   initialize ();
  35   │   compute();
  36   │
  37   │   return 0;
  38   │ }

After compile with -march=rv64gcv -O3, we will have:

  30   │ compute:
  31   │     csrwi   vxrm,2
  32   │     lui a3,%hi(a)
  33   │     lui a4,%hi(b)
  34   │     addi    a4,a4,%lo(b)
  35   │     vsetivli    zero,4,e16,m1,ta,ma
  36   │     addi    a3,a3,%lo(a)
  37   │     vle16.v v2,0(a4)
  38   │     vle16.v v1,0(a3)
  39   │     lui a4,%hi(c)
  40   │     addi    a4,a4,%lo(c)
  41   │     vaaddu.vv   v1,v1,v2
  42   │     vse16.v v1,0(a4)
  43   │     ret
  44   │     .size   compute, .-compute
  45   │     .section    .text.startup,"ax",@progbits
  46   │     .align  1
  47   │     .globl  main
  48   │     .type   main, @function
  49   │ main:
       |     // csrwi   vxrm,2 deleted after inline
  50   │     addi    sp,sp,-16
  51   │     sd  ra,8(sp)
  52   │     call    initialize
  53   │     lui a3,%hi(a)
  54   │     lui a4,%hi(b)
  55   │     vsetivli    zero,4,e16,m1,ta,ma
  56   │     addi    a4,a4,%lo(b)
  57   │     addi    a3,a3,%lo(a)
  58   │     vle16.v v2,0(a4)
  59   │     vle16.v v1,0(a3)
  60   │     lui a4,%hi(c)
  61   │     addi    a4,a4,%lo(c)
  62   │     li  a0,0
  63   │     vaaddu.vv   v1,v1,v2

The below test suites are passed for this patch.
* The rv64gcv fully regression test.

	PR target/118103

gcc/ChangeLog:

	* config/riscv/riscv.cc (riscv_conditional_register_usage): Add
	the VXRM as the global_regs.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr118103-2.c: New test.
	* gcc.target/riscv/rvv/base/pr118103-run-2.c: New test.

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

On leon3-elf and presumably on other targets, the test fails due to
differences in calling conventions and other reasons, that add extra
gimple stmts that prevent the expected optimization at the expected
point.  The optimization takes place anyway, just a little later, so
tolerate that.


for  gcc/testsuite/ChangeLog

	PR tree-optimization/108357
	* gcc.dg/tree-ssa/pr108357.c: Tolerate later optimization.

With release checking we get an uninitialization warning
inside aarch64_split_move because of jump threading for the case of `npieces==0`
but `npieces` is never 0 (but there is no way the compiler can know that.
So this fixes the issue by adding a `gcc_assert` to the function which asserts
that `npieces > 0` and fixes the uninitialization warning.

Bootstrapped and tested on aarch64-linux-gnu (with and without --enable-checking=release).

The warning:

aarch64.cc: In function 'void aarch64_split_move(rtx, rtx, machine_mode)':
aarch64.cc:3418:31: error: '*(rtx_def**)((char*)&dst_pieces + offsetof(auto_vec<rtx_def*, 4>,auto_vec<rtx_def*, 4>::m_data[0]))' may be used uninitialized [-Werror=maybe-uninitialized]
 3418 |   if (reg_overlap_mentioned_p (dst_pieces[0], src))
      |       ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~
aarch64.cc:3408:20: note: 'dst_pieces' declared here
 3408 |   auto_vec<rtx, 4> dst_pieces, src_pieces;
      |                    ^~~~~~~~~~

	PR target/118771
gcc/ChangeLog:

	* config/aarch64/aarch64.cc (aarch64_split_move): Assert that npieces is
	greater than 0.

Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>

In addition to upcoming use of '-fdump-tree-original-lineno', this patch
actually resolves XFAILs for 'c-c++-common/goacc/pr92793-1.c', which had
gotten added as part of commit fa410314
"[OpenACC] Elaborate testcases that verify column location information [PR92793]".

	gcc/c-family/
	* c-gimplify.cc (c_genericize): Pass 'local_dump_flags' to
	'print_c_tree'.
	* c-pretty-print.cc (c_pretty_printer::statement): Pass
	'dump_flags' to 'dump_generic_node'.
	(c_pretty_printer::c_pretty_printer): Initialize 'dump_flags'.
	(print_c_tree): Add 'dump_flags_t' formal parameter.
	(debug_c_tree): Adjust.
	* c-pretty-print.h (c_pretty_printer): Add 'dump_flags_t
	dump_flags'.
	(c_pretty_printer::c_pretty_printer): Add 'dump_flags_t' formal
	parameter.
	(print_c_tree): Adjust.
	gcc/testsuite/
	* c-c++-common/goacc/pr92793-1.c: Remove
	'-fdump-tree-original-lineno' XFAILs.

In a member-specification of a class, a noexcept-specifier is
a complete-class context.  Thus we delay parsing until the end of
the class via our DEFERRED_PARSE mechanism; see cp_parser_save_noexcept
and cp_parser_late_noexcept_specifier.

We also attempt to defer instantiation of noexcept-specifiers in order
to reduce the number of instantiations; this is done via DEFERRED_NOEXCEPT.

We can even have both, as in noexcept65.C: a DEFERRED_PARSE wrapped in
DEFERRED_NOEXCEPT, which uses the DEFPARSE_INSTANTIATIONS mechanism.
noexcept65.C works, because when we really need the noexcept, which is
when parsing the body of S::A::A(), the noexcept will have been parsed
already; noexcepts are parsed before bodies of member function.

But in this test we have:

  struct A {
      int x;
      template<class>
      void foo() noexcept(noexcept(x)) {}
      auto bar() -> decltype(foo<int>()) {} // #1
  };

and I think the decltype in #1 needs the unparsed noexcept before it
could have been parsed.  clang++ rejects the test and I suppose we
should reject it as well, rather than crashing on a DEFERRED_PARSE
in tsubst_expr.

	PR c++/117106
	PR c++/118190

gcc/cp/ChangeLog:

	* pt.cc (maybe_instantiate_noexcept): Give an error if the noexcept
	hasn't been parsed yet.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/noexcept89.C: New test.
	* g++.dg/cpp0x/noexcept90.C: New test.

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

We've been rejecting the following valid code since GCC 4

=== cut here ===
struct A {
  explicit A (int);
  operator void* () const;
};
void foo (const A& x) {
  auto res = 0 ? x : 0;
}
int main () {
  A a{5};
  foo(a);
}
=== cut here ===

The problem is that for COND_EXPR, add_builtin_candidate has an early
return if the true and false values are not pointers that does not take
null pointer constants into account. This causes to not find any valid
conversion, and fail to compile.

This patch fixes the condition to also pass if the true/false values are
not pointers but null pointer constants, which resolves the PR.

	PR c++/118282

gcc/cp/ChangeLog:

	* call.cc (add_builtin_candidate): Also check for null_ptr_cst_p
	operands.

gcc/testsuite/ChangeLog:

	* g++.dg/conversion/op8.C: New test.

The following testcase is miscompiled since r12-6325 stopped
preevaluating the initializers for new expression.
If evaluating the initializers throws, there is a correct cleanup
for that, but it is marked CLEANUP_EH_ONLY.  While in standard
C++ that is just fine, if it has statement expressions, it can
return or goto out of the expression and we should delete the
pointer in that case too.

There is already a sentry variable initialized to true and
set to false after everything is initialized and used as a guard
for the cleanup, so just removing the CLEANUP_EH_ONLY flag does
everything we need.  And in the normal case of the initializer
not using statement expressions at least with -O2 we get the same code,
while the change changes one
try { sentry = true; ... sentry = false; } catch { if (sentry) delete ...; }
into
try { sentry = true; ... sentry = false; } finally { if (sentry) delete ...; }
optimizations will see that sentry is false when reaching the finally
other than through an exception.

Though, wonder what other CLEANUP_EH_ONLY cleanups might be an issue
with statement expressions.

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

	PR c++/118763
	* init.cc (build_new_1): Don't set CLEANUP_EH_ONLY.

	* g++.dg/asan/pr118763.C: New test.

My r15-3046 change regressed the first half of the following testcase.
When it calls decl_attributes, it doesn't handle attributes with
dependent arguments correctly and so is now rejected that N is not
a constant integer during template parsing.

I've actually followed the pointer/reference case which did that
too and that one has been failing for a couple of years on the
second part of the testcase.

Note, there is also
          if (decl_context != PARM && decl_context != TYPENAME)
            /* Assume that any attributes that get applied late to
               templates will DTRT when applied to the declaration
               as a whole.  */
            late_attrs = splice_template_attributes (&attrs, type);
          returned_attrs = decl_attributes (&type,
                                            attr_chainon (returned_attrs,
                                                          attrs),
                                            attr_flags);
          returned_attrs = attr_chainon (late_attrs, returned_attrs);
call directly to decl_attributes in grokdeclarator, but this one handles
the splicing manually, so maybe it is ok as is (and I don't have a testcase
of anything misbehaving for that).

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

	PR c++/118773
	* decl.cc (grokdeclarator): Use cplus_decl_attributes rather than
	decl_attributes for std_attributes on pointer and array types.

	* g++.dg/cpp0x/gen-attrs-87.C: New test.
	* g++.dg/gomp/attrs-3.C: Adjust expected diagnostics.

As mentioned in the PR, https://eel.is/c++draft/conv.lval#note-1
says that even volatile reads from std::nullptr_t typed objects actually
don't read anything and https://eel.is/c++draft/expr.const#10.9
says that even those are ok in constant expressions.

So, the following patch adjusts the r9-4793 changes to have an exception
for NULLPTR_TYPE.
As [conv.lval]/3 also talks about accessing to inactive member, I've added
testcase to cover that as well.

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

	PR c++/118661
	* constexpr.cc (potential_constant_expression_1): Don't diagnose
	lvalue-to-rvalue conversion of volatile lvalue if it has NULLPTR_TYPE.
	* decl2.cc (decl_maybe_constant_var_p): Return true for constexpr
	decls with NULLPTR_TYPE even if they are volatile.

	* g++.dg/cpp0x/constexpr-volatile4.C: New test.
	* g++.dg/cpp0x/constexpr-union9.C: New test.

2025-02-07  Tomáš Trnka  <trnka@scm.com>

gcc/fortran
	PR fortran/116829
	* trans-decl.cc (init_intent_out_dt): Always call
	gfc_init_default_dt() for BT_DERIVED to apply s->value if the
	symbol isn't allocatable. Also simplify the logic a bit.

gcc/testsuite/
	PR fortran/116829
	* gfortran.dg/derived_init_7.f90: New test.

The following fixes a latent issue where we use ranges to verify
correctness of a vector conversion optimization.  We rely on ranges
from 'op0' which for SLP is extracted from the representative stmt
which does not necessarily correspond to any actual scalar operation.
We also do not verify the range of all scalar lanes in the SLP
operand match.  The following rectifies this, restricting the support
to single-lane SLP nodes at this point - on branches we'd simply
not perform this optimization with SLP.

	PR tree-optimization/115538
	* tree-vectorizer.h (vect_get_slp_scalar_def): Declare.
	* tree-vect-slp.cc (vect_get_slp_scalar_def): New helper.
	* tree-vect-generic.cc (expand_vector_conversion): Adjust.
	* tree-vect-stmts.cc (vectorizable_conversion): For SLP
	correctly look at ranges of the scalar defs of the SLP operand.
	(supportable_indirect_convert_operation): Likewise.

The amdhsa.version depends on the code object version; while V3 had 1.0,
V4 has 1.1 and V5 (and V6) have 1.2. GCC used 1.0 but generated since
a while either V4 or, with -march=gfx...-generic, V6. Now it uses the
proper version again.

gcc/ChangeLog:

	* config/gcn/gcn.cc (gcn_hsa_declare_function_name): Update
	'amdhsa.version' output to match used code version.
	* config/gcn/gen-gcn-device-macros.awk: Add a comment to
	crosslink.

libgomp/ChangeLog:

	* plugin/plugin-gcn.c (ELFABIVERSION_AMDGPU_HSA_V6,
	EF_AMDGPU_GENERIC_VERSION_V, EF_AMDGPU_GENERIC_VERSION_OFFSET,
	GET_GENERIC_VERSION): New #define.
	(elf_gcn_isa_is_generic): New.
	(isa_matches_agent): Accept all generic code objects on the first
	go; extend the diagnostic and handle runtime-failed case.
	(create_and_finalize_hsa_program): Call it also after loading
	the code failed, pass the status.

For mask{eq,ne}z, rk is always compared with 0 in the full width, thus
the mode for rk should be X.

I found the issue reviewing a patch fixing a similar issue for RISC-V
XTheadCondMov [1], but interestingly I cannot find a test case really
blowing up on LoongArch.  But as the issue is obvious enough let's fix
it anyway so it won't blow up in the future.

[1]: https://gcc.gnu.org/pipermail/gcc-patches/2025-January/674004.html

gcc/ChangeLog:

	* config/loongarch/loongarch.md
	(*sel<code><GPR:mode>_using_<GPR2:mode>): Rename to ...
	(*sel<code><GPR:mode>_using_<X:mode>): ... here.
	(GPR2): Remove as nothing uses it now.

If decode_field_reference finds a load that accesses past the inner
object's size, bail out.

Drop the too-strict assert.


for  gcc/ChangeLog

	PR tree-optimization/118514
	PR tree-optimization/118706
	* gimple-fold.cc (decode_field_reference): Refuse to consider
	merging out-of-bounds BIT_FIELD_REFs.
	(make_bit_field_load): Drop too-strict assert.
	* tree-eh.cc (bit_field_ref_in_bounds_p): Rename to...
	(access_in_bounds_of_type_p): ... this.  Change interface,
	export.
	(tree_could_trap_p): Adjust.
	* tree-eh.h (access_in_bounds_of_type_p): Declare.

for  gcc/testsuite/ChangeLog

	PR tree-optimization/118514
	PR tree-optimization/118706
	* gcc.dg/field-merge-25.c: New.

This patch adds gfx9-generic, completing the gfx*-generic support.
It also adds all gfx* devices that are part of any of the gfx*-generic,
i.e. gfx902, gfx904, gfx909, gfx1031, gfx1032, gfx1033, gfx1034,
gfx1035, gfx1101, gfx1102, gfx1150, gfx1151, gfx1152, and gfx1153.

gcc/ChangeLog:

	* config/gcn/gcn-devices.def (GCN_DEVICE): Add gfx9-generic,
	gfx902, gfx904, gfx909, gfx1031, gfx1032, gfx1033, gfx1034,
	gfx1035, gfx1101, gfx1102, gfx1150, gfx1151, gfx1152, and gfx1153.
	Add a currently unused column linking, a specific ISA to a generic
	one (if it exists).
	* config/gcn/gcn-tables.opt: Regenerate
	* doc/invoke.texi (AMD GCN): Add the the new gfc... and the older
	gfx{10-3,11}-generic to -march= as 'experimental'.

When compiling with -g, mkoffload.cc creates a device object file itself;
however, in order that the linker dos not complain, the ELF flags must
match what the compiler / linker does. For gfx906, the assembler defaults
to sramecc = any, but gcn-devices.def contained unsupported, which is not
the same - causing link errors. That's a regression caused by commit
r15-4540-ga6b26e5ea09779 - which can be best seen by looking at the
changes to mkoffload.cc.

Additionally, this commit adds '...' to the GCN_DEVICE #define in gcn.cc
to make it agnostic to the addition of fields.

gcc/ChangeLog:

	* config/gcn/gcn-devices.def (GCN_DEVICE): Change sramecc for
	gfx906 to 'any'.
	* config/gcn/gcn.cc (GCN_DEVICE): Add tailing ... to #define.

vis3move-3.c expects fsmuld, that is not available on all variants of
sparc.  Select a cpu that supports it for the test.

Now, -mfix-ut699 irrevocbly disables fsmuld, so skip the test if the
test configuration uses that option.


for  gcc/testsuite/ChangeLog

	* gcc.target/sparc/vis3move-3.c: Select ultrasparc.  Skip with
	-mfix-ut699.

A number of tls tests expect TLS-specific relocations, that are not
present when tls is emulated, as on e.g. leon3-elf.  Skip the tests
when tls is emulated.


for  gcc/testsuite/ChangeLog

	* gcc.target/sparc/tls-ld-int16.c: Skip when tls is emulated.
	* gcc.target/sparc/tls-ld-int32.c: Likewise.
	* gcc.target/sparc/tls-ld-int8.c: Likewise.
	* gcc.target/sparc/tls-ld-uint16.c: Likewise.
	* gcc.target/sparc/tls-ld-uint32.c: Likewise.
	* gcc.target/sparc/tls-ld-uint8.c: Likewise.

Option -mfix-ut699 changes the set of instructions that can be placed
in the delay slot, preventing the expected insn placement.  Skip the
test if the option is present.


for  gcc/testsuite/ChangeLog

	* gcc.target/sparc/sparc-ret-1.c: Skip on -mfix-ut699.

If -mcpu=leon3 is present in the command line for a test run,
overriding it with -mcpu=niagara7 is not enough to override the tuning
for leon3 selected by the previous -mcpu option.

niagara7-align.c tests for niagara7 alignment tuning, so use -mtune
rather than -mcpu.


for  gcc/testsuite/ChangeLog

	* gcc.target/sparc/niagara7-align.c: Use -mtune.

commit 3b9b8d6c
Author: Surya Kumari Jangala <jskumari@linux.ibm.com>
Date:   Tue Jun 25 08:37:49 2024 -0500

    ira: Scale save/restore costs of callee save registers with block frequency

scales the cost of saving/restoring a callee-save hard register in epilogue
and prologue with the entry block frequency, which, if not optimizing for
size, is 10000, for all targets.  As the result, callee-saved registers
may not be used to preserve local variable values across calls on some
targets, like x86.  Add a target hook for the callee-saved register cost
scale in epilogue and prologue used by IRA.  The default version of this
target hook returns 1 if optimizing for size, otherwise returns the entry
block frequency.  Add an x86 version of this target hook to restore the
old behavior prior to the above commit.

	PR rtl-optimization/111673
	PR rtl-optimization/115932
	PR rtl-optimization/116028
	PR rtl-optimization/117081
	PR rtl-optimization/117082
	PR rtl-optimization/118497
	* ira-color.cc (assign_hard_reg): Call the target hook for the
	callee-saved register cost scale in epilogue and prologue.
	* target.def (ira_callee_saved_register_cost_scale): New target
	hook.
	* targhooks.cc (default_ira_callee_saved_register_cost_scale):
	New.
	* targhooks.h (default_ira_callee_saved_register_cost_scale):
	Likewise.
	* config/i386/i386.cc (ix86_ira_callee_saved_register_cost_scale):
	New.
	(TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE): Likewise.
	* doc/tm.texi: Regenerated.
	* doc/tm.texi.in (TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE):
	New.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

stack_protect_{set,test}_<mode> were showing up in RTL dumps as
UNSPEC_COPYSIGN and UNSPEC_FMV_X_W due to UNSPEC_SSP_SET and
UNSPEC_SSP_TEST being put in the unspecv enum instead of unspec.

gcc/ChangeLog:

	* config/riscv/riscv.md: Move UNSPEC_SSP_SET and UNSPEC_SSP_TEST
	to unspec enum.

Richard S's recent change to iv increment insertion removed a reg->reg move
(which was its intent AFAICT).  This triggered a failure on a riscv test.

That test was meant to verify that we didn't have an extraneous reg->reg move
due to a buglet in the risc-v splitters.  Before the 2023 change we had two
vector reg->reg moves and after the 2023 fix we had just one.  With Richard's
change we have none ;-)  Adjusting test accordingly.

Pushed to the trunk.

gcc/testsuite
	* gcc.target/riscv/rvv/autovec/madd-split2-1.c: Update expected
	output.

gcc/
	* config/avr/avr.opt.urls: Add mcvt.

It seems that after my IVopts patches the function contain_complex_addr_expr
became unused and clang is rightfully complaining about it.

This removes the unused internal function.

gcc/ChangeLog:

	PR tree-optimization/118756
	* tree-ssa-loop-ivopts.cc (contain_complex_addr_expr): Remove.

This patch is a partial fix of handling of X edit descriptors
when combined with certain T edit descriptors.

	PR libfortran/114618

libgfortran/ChangeLog:

	* io/transfer.c (formatted_transfer_scalar_write): Change name
	of vriable 'pos' to 'tab_pos' to improve clarity. Add new
	variable next_pos when calculating the maximum position.
	Update the calculation of pending spaces.

gcc/testsuite/ChangeLog:

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

Another non-problematic attribute.

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

	PR c++/110345
	* g++.dg/cpp0x/attr-no_unique_address1.C: New test.

Another non-problematic attribute.

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

	PR c++/110345
	* g++.dg/cpp0x/attr-noreturn1.C: New test.

Fairly non-problematic attribute.

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

	PR c++/110345
	* g++.dg/cpp0x/attr-nodiscard1.C: New test.

Some AVR devices support a CVT:

-  Devices from the 0-series, 1-series, 2-series.
-  AVR16, AVR32, AVR64, AVR128 devices.

The support is provided by means of a startup code file
crt<mcu>-cvt.o from AVR-LibC v2.3 that can be linked instead
of the traditional crt<mcu>.o.

This patch adds a new command line option -mcvt that links
that CVT startup code (or issues an error when the device
doesn't support a CVT).

	PR target/118764
gcc/
	* config/avr/avr.opt (-mcvt): New target option.
	* config/avr/avr-arch.h (AVR_CVT): New enum value.
	* config/avr/avr-mcus.def: Add AVR_CVT flag for devices that
	support it.
	* config/avr/avr.cc (avr_handle_isr_attribute) [TARGET_CVT]: Issue
	an error when a vector number larger that 3 is used.
	* config/avr/gen-avr-mmcu-specs.cc (McuInfo.have_cvt): New property.
	(print_mcu) <*avrlibc_startfile>: Use crt<mcu>-cvt.o depending
	on -mcvt (or issue an error when the device doesn't support a CVT).
	* doc/invoke.texi (AVR Options): Document -mcvt.

2025-02-06  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
	PR fortran/118750
	* resolve.cc (resolve_assoc_var): If the target expression has
	a rank, do not use gfc_expression_rank, since it will return 0
	if the function is elemental. Resolution will have produced the
	correct rank.

gcc/testsuite/
	PR fortran/118750
	* gfortran.dg/associate_72.f90: New test.

The following test ICEs on RISC-V at least latently since
r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({zero,sign}_extend:DI (plus:SI op0 op1))

The reason for the ICE is that op1 in this case is CONST_POLY_INT
which unlike the really expected VOIDmode CONST_INTs has its own
mode and still satisfies CONSTANT_P.
GET_MODE (rhs) (SImode) is different from outer_mode (DImode), so
the function later does
        *inner_step = simplify_gen_binary (code, outer_mode,
                                           *inner_step, op1);
but that obviously ICEs because while *inner_step is either VOIDmode
or DImode, op1 has SImode.

The following patch fixes it by extending op1 using code so that
simplify_gen_binary can handle it.  Another option would be
to change the !CONSTANT_P (op1) 3 lines above this to
!CONST_INT_P (op1), I think it isn't very likely that we get something
useful from other constants there.

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

	PR rtl-optimization/117506
	* loop-iv.cc (get_biv_step_1): For {ZERO,SIGN}_EXTEND
	of PLUS apply {ZERO,SIGN}_EXTEND to op1.

	* gcc.dg/pr117506.c: New test.
	* gcc.target/riscv/pr117506.c: New test.

gcc/
	PR target/118768
	* config/avr/genmultilib.awk: Parse the AVR_MCU lines in
	a more robust way w.r.t. white spaces.

	PR target/118561

gcc/ChangeLog:

	* config/loongarch/loongarch-builtins.cc
	(loongarch_expand_builtin_lsx_test_branch):
	NULL_RTX will not be returned when an error is detected.
	(loongarch_expand_builtin): Likewise.

gcc/testsuite/ChangeLog:

	* gcc.target/loongarch/pr118561.c: New test.

In this PR, we used to generate:

     .L6:
	  mov     v30.16b, v31.16b
	  fadd    v31.4s, v31.4s, v27.4s
	  fadd    v29.4s, v30.4s, v28.4s
	  stp     q30, q29, [x0]
	  add     x0, x0, 32
	  cmp     x1, x0
	  bne     .L6

for an unrolled induction in:

  for (int i = 0; i < 1024; i++)
    {
      arr[i] = freq;
      freq += step;
    }

with the problem being the unnecessary MOV.

The main induction IV was incremented by VF * step == 2 * nunits * step,
and then nunits * step was added for the second store to arr.

The original patch for the PR (r14-2367-g224fd59b2dc8) avoided the MOV
by incrementing the IV by nunits * step twice.  The problem with that
approach is that it doubles the loop-carried latency.  This change was
deliberately not preserved when moving from loop-vect to SLP and so
the test started failing again after r15-3509-gd34cda720988.

I think the main problem is that we put the IV increment in the wrong
place.  Normal IVs created by create_iv are placed before the exit
condition where possible, but vectorizable_induction instead always
inserted them at the start of the loop body.  The only use of the
incremented IV is by the phi node, so the effect is to make both
the old and new IV values live for the whole loop body, which is
why we need the MOV.

The simplest fix therefore seems to be to reuse the create_iv logic.

gcc/
	PR tree-optimization/110449
	* tree-ssa-loop-manip.h (insert_iv_increment): Declare.
	* tree-ssa-loop-manip.cc (insert_iv_increment): New function,
	split out from...
	(create_iv): ...here and generalized to gimple_seqs.
	* tree-vect-loop.cc (vectorizable_induction): Use
	standard_iv_increment_position and insert_iv_increment
	to insert the IV increment.

gcc/testsuite/
	PR tree-optimization/110449
	* gcc.target/aarch64/pr110449.c: Expect an increment by 8.0,
	but test that there is no MOV.

The PR shows fold-mem-offsets taking ages and a lot of memory computing
DU/UD chains as that requires the RD problem.  The issue is not so much
the memory required for the pruned sets but the high CFG connectivity
(and that the CFG is cyclic) which makes solving the dataflow problem
expensive.

The following adds the same limit as the one imposed by GCSE and CPROP.

	PR rtl-optimization/117922
	* fold-mem-offsets.cc (pass_fold_mem_offsets::execute):
	Do nothing for a highly connected CFG.