PR fortran/118740

gcc/fortran/ChangeLog:

	* openmp.cc (gfc_match_omp_context_selector, match_omp_metadirective):
	Change sorry to sorry_at and use gfc_current_locus as location.
	* trans-openmp.cc (gfc_trans_omp_clauses): Likewise, but use n->where.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/append_args-2.f90: Update for line change.

Sorry, our CI bot just notified me I broke SPARC build.  There are two
 #ifdef STACK_ADDRESS_OFFSET
guarded snippets and the macro is only defined on SPARC target, so I didn't
notice there was a syntax error.

Fixed thusly.

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

	PR rtl-optimization/117239
	* cselib.cc (cselib_init): Remove spurious closing paren in
	the #ifdef STACK_ADDRESS_OFFSET specific code.

The following testcase is miscompiled on x86_64 during postreload.
After reload (with IPA-RA figuring out the calls don't modify any
registers but %rax for return value) postreload sees
(insn 14 12 15 2 (set (mem:DI (plus:DI (reg/f:DI 7 sp)
                (const_int 16 [0x10])) [0  S8 A64])
        (reg:DI 1 dx [orig:105 q+16 ] [105])) "pr117239.c":18:7 95 {*movdi_internal}
     (nil))
(call_insn/i 15 14 16 2 (set (reg:SI 0 ax)
        (call (mem:QI (symbol_ref:DI ("baz") [flags 0x3]  <function_decl 0x7ffb2e2bdf00 r>) [0 baz S1 A8])
            (const_int 24 [0x18]))) "pr117239.c":18:7 1476 {*call_value}
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("baz") [flags 0x3]  <function_decl 0x7ffb2e2bdf00 baz>)
        (expr_list:REG_EH_REGION (const_int 0 [0])
            (nil)))
    (nil))
(insn 16 15 18 2 (parallel [
            (set (reg/f:DI 7 sp)
                (plus:DI (reg/f:DI 7 sp)
                    (const_int 24 [0x18])))
            (clobber (reg:CC 17 flags))
        ]) "pr117239.c":18:7 285 {*adddi_1}
     (expr_list:REG_ARGS_SIZE (const_int 0 [0])
        (nil)))
...
(call_insn/i 19 18 21 2 (set (reg:SI 0 ax)
        (call (mem:QI (symbol_ref:DI ("foo") [flags 0x3]  <function_decl 0x7ffb2e2bdb00 l>) [0 foo S1 A8])
            (const_int 0 [0]))) "pr117239.c":19:3 1476 {*call_value}
     (expr_list:REG_CALL_DECL (symbol_ref:DI ("foo") [flags 0x3]  <function_decl 0x7ffb2e2bdb00 foo>)
        (expr_list:REG_EH_REGION (const_int 0 [0])
            (nil)))
    (nil))
(insn 21 19 26 2 (parallel [
            (set (reg/f:DI 7 sp)
                (plus:DI (reg/f:DI 7 sp)
                    (const_int -24 [0xffffffffffffffe8])))
            (clobber (reg:CC 17 flags))
        ]) "pr117239.c":19:3 discrim 1 285 {*adddi_1}
     (expr_list:REG_ARGS_SIZE (const_int 24 [0x18])
        (nil)))
(insn 26 21 24 2 (set (mem:DI (plus:DI (reg/f:DI 7 sp)
                (const_int 16 [0x10])) [0  S8 A64])
        (reg:DI 1 dx [orig:105 q+16 ] [105])) "pr117239.c":19:3 discrim 1 95 {*movdi_internal}
     (nil))
i.e.
        movq    %rdx, 16(%rsp)
        call    baz
        addq    $24, %rsp
...
        call    foo
        subq    $24, %rsp
        movq    %rdx, 16(%rsp)
Now, postreload uses cselib and cselib remembered that %rdx value has been
stored into 16(%rsp).  Both baz and foo are pure calls.  If they weren't,
when processing those CALL_INSNs cselib would invalidate all MEMs
      if (RTL_LOOPING_CONST_OR_PURE_CALL_P (insn)
          || !(RTL_CONST_OR_PURE_CALL_P (insn)))
        cselib_invalidate_mem (callmem);
where callmem is (mem:BLK (scratch)).  But they are pure, so instead the
code just invalidates the argument slots from CALL_INSN_FUNCTION_USAGE.
The calls actually clobber more than that, even const/pure calls clobber
all memory below the stack pointer.  And that is something that hasn't been
invalidated.  In this failing testcase, the call to baz is not a big deal,
we don't have anything remembered in memory below %rsp at that call.
But then we increment %rsp by 24, so the %rsp+16 is now 8 bytes below stack
and do the call to foo.  And that call now actually, not just in theory,
clobbers the memory below the stack pointer (in particular overwrites it
with the return value).  But cselib does not invalidate.  Then %rsp
is decremented again (in preparation for another call, to bar) and cselib
is processing store of %rdx (which IPA-RA says has not been modified by
either baz or foo calls) to %rsp + 16, and it sees the memory already has
that value, so the store is useless, let's remove it.
But it is not, the call to foo has changed it, so it needs to be stored
again.

The following patch adds targetted invalidation of memory below stack
pointer (or on SPARC memory below stack pointer + 2047 when stack bias is
used, or on PA memory above stack pointer instead).
It does so only in !ACCUMULATE_OUTGOING_ARGS or cfun->calls_alloca functions,
because in other functions the stack pointer should be constant from
the end of prologue till start of epilogue and so nothing should be stored
within the function below the stack pointer.

Now, memory below stack pointer is special, except for functions using
alloca/VLAs I believe no addressable memory should be there, it should be
purely outgoing function argument area, if we take address of some automatic
variable, it should live all the time above the outgoing function argument
area.  So on top of just trying to flush memory below stack pointer
(represented by %rsp - PTRDIFF_MAX with PTRDIFF_MAX size on most arches),
the patch tries to optimize and only invalidate memory that has address
clearly derived from stack pointer (memory with other bases is not
invalidated) and if we can prove (we see same SP_DERIVED_VALUE_P bases in
both VALUEs) it is above current stack, also don't call
canon_anti_dependence which might just give up in certain cases.

I've gathered statistics from x86_64-linux and i686-linux
bootstraps/regtests.  During -m64 compilations from those, there were
3718396 + 42634 + 27761 cases of processing MEMs in cselib_invalidate_mem
(callmem[1]) calls, the first number is number of MEMs not invalidated
because of the optimization, i.e.
+             if (sp_derived_base == NULL_RTX)
+               {
+                 has_mem = true;
+                 num_mems++;
+                 p = &(*p)->next;
+                 continue;
+               }
in the patch, the second number is number of MEMs not invalidated because
canon_anti_dependence returned false and finally the last number is number
of MEMs actually invalidated (so that is what hasn't been invalidated
before).  During -m32 compilations the numbers were
1422412 + 39354 + 16509 with the same meaning.

Note, when there is no red zone, in theory even the sp = sp + incr
instruction invalidates memory below the new stack pointer, as signal
can come and overwrite the memory.  So maybe we should be invalidating
something at those instructions as well.  But in leaf functions we certainly
can have even addressable automatic vars in the red zone (which would make
it harder to distinguish), on the other side aren't normally storing
anything below the red zone, and in non-leaf it should normally be just the
outgoing arguments area.

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

	PR rtl-optimization/117239
	* cselib.cc: Include predict.h.
	(callmem): Change type from rtx to rtx[2].
	(cselib_preserve_only_values): Use callmem[0] rather than callmem.
	(cselib_invalidate_mem): Optimize and don't try to invalidate
	for the mem_rtx == callmem[1] case MEMs which clearly can't be
	below the stack pointer.
	(cselib_process_insn): Use callmem[0] rather than callmem.
	For const/pure calls also call cselib_invalidate_mem (callmem[1])
	in !ACCUMULATE_OUTGOING_ARGS or cfun->calls_alloca functions.
	(cselib_init): Initialize callmem[0] rather than callmem and also
	initialize callmem[1].

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

When generating thumb2 code,
	LDM SP!, {PC}
is a two-byte instruction, whereas
	LDR PC, [SP], #4
is needs 4 bytes.  When optimizing for size, or when there's no obvious
performance benefit prefer the former.

gcc/ChangeLog:

	PR target/118089
	* config/arm/arm.cc (thumb2_expand_return): Use LDM SP!, {PC}
	when optimizing for size, or when there's no performance benefit over
	LDR PC, [SP], #4.
	(arm_expand_epilogue): Likewise.

This pattern is intended to be used only by the epilogue generation
code and will always use fixed hard registers.  As such, it does not
need any register constraints, which might be misleading if a
post-reload pass wanted to try renumbering various registers.  So
remove the constraints.

Futhermore, to permit this pattern to match when popping just the PC
(which is not a valid register_operand), remove the match on the first
transfer register: pop_multiple_return will validate everything it
needs to.

gcc/ChangeLog:

	* config/arm/arm.md (*pop_multiple_with_writeback_and_return): Remove
	constraints.  Don't validate the first transfer register here.

I needed to make some adjustments to this function to permit a push or
pop of a single register in thumb2 code, since ldm/stm can be a
two-byte instruction instead of 4.  Trying to read the code as it was
made me scratch my head as the logic was not very clear.  So this
patch cleans up the code somewhat, fixes a couple of minor bugs and
removes the limit of having to use multiple registers when using this
form of the instruction (the shape of this pattern is such that I
can't see it being generated automatically by the compiler, so there
should be no adverse affects of this).

Buglets fixed:
  - Validate that the first element contains RETURN if we're matching
    a return instruction.
  - Don't allow the base address register to be stored if saving regs
    and the address is being updated (this is unpredictable in the
    architecture).
  - Verify that the last register loaded in a RETURN insn is the PC.

gcc/
	* config/arm/arm.cc (decompose_addr_for_ldm_stm): New function.
	(ldm_stm_operation_p): Rework to clarify logic.  Allow single
	registers to be pushed or popped using LDM/STM.

With things like

  // signed char a_14, a_16;
  a.0_4 = (unsigned char) a_14;
  _5 = (int) a.0_4;
  b.1_6 = (unsigned char) b_16;
  _7 = (int) b.1_6;
  c_17 = _5 - _7;
  _8 = ABS_EXPR <c_17>;
  r_18 = _8 + r_23;

An ABD pattern will be recognized for _8:

  patt_31 = .ABD (a.0_4, b.1_6);

It's still correct.  But then when the SAD pattern is recognized:

  patt_29 = SAD_EXPR <a_14, b_16, r_23>;

This is not correct.  This only happens for targets with both uabd and
sabd but not vec_widen_{s,u}abd, currently LoongArch is the only target
affected.

The problem is vect_look_through_possible_promotion will throw away a
series of conversions if the effect is equivalent to a sign change and a
promotion, but here the sign change is definitely relevant, and the
promotion is also relevant for "mixed sign" cases like
r += abs((unsigned int)(unsigned char) a - (signed int)(signed char) b
(we need to promote to HImode as the difference can exceed the range of
QImode).

If there were any redundant promotion, it should have been stripped in
vect_recog_abd_pattern (i.e. when patt_31 = .ABD (a.0_4, b.1_6) is
recognized) instead of in vect_recog_sad_pattern, or we'd have a
missed-optimization if the ABD output is not summerized.  So anyway
vect_recog_sad_pattern is just not a proper location to call
vect_look_through_possible_promotion for the ABD inputs, remove the
calls to fix the issue.

gcc/ChangeLog:

	PR tree-optimization/118727
	* tree-vect-patterns.cc (vect_recog_sad_pattern): Don't call
	vect_look_through_possible_promotion on ABD inputs.

gcc/testsuite/ChangeLog:

	PR tree-optimization/118727
	* gcc.dg/pr108692.c: Mention PR 118727 in the comment.
	* gcc.dg/pr118727.c: New test case.

r15-268-g9dbff9c05520 restored the original GCC 11 output for
pr100056.c, so this patch reverts the changes made to the test
in r12-7259-g25332d2325c7.  (The code parts of r12-7259 still
seem useful, as a belt-and-braces thing.)

gcc/testsuite/
	* gcc.target/aarch64/pr100056.c: Restore the original version of
	the scan-assemblers.

This patch

commit c6977f76
Author: Andreas Schwab <schwab@suse.de>
Date:   Tue Jan 21 23:50:15 2025 +0100

    libstdc++: correct symbol version of typeinfo for bfloat16_t on RISC-V

broke the libstdc++-abi/abi_check test on Solaris: the log shows

1 incompatible symbols
0
Argument "{CXXABI_1.3.15}" isn't numeric in numeric eq (==) at /vol/gcc/src/hg/master/local/libstdc++-v3/scripts/extract_symvers.pl line 129.
version status: incompatible
type: uncategorized
status: added

The problem has two parts:

* The patch above introduced a new version in libstdc++.so,
  CXXABI_1.3.16, which everywhere but on RISC-V contains no symbols (a
  weak version).  This is the first time this happened in libstdc++.

* Solaris uses scripts/extract_symvers.pl to determine the version info.
  The script currently chokes on the pvs output for weak versions:

  libstdc++.so.6.0.34 -	CXXABI_1.3.16 [WEAK]: {CXXABI_1.3.15};

  instead of

  libstdc++.so.6.0.34 -	CXXABI_1.3.16: {CXXABI_1.3.15};

While this patch hardens the script to cope with weak versions, there's
no reason to introduce them in the first place.  So the new version is
only created on __riscv.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.

2025-01-29  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
	    Jonathan Wakely  <jwakely@redhat.com>

	libstdc++-v3:
	PR libstdc++/118701
	* config/abi/pre/gnu.ver (CXXABI_1.3.16): Move __riscv guard
	around version.
	* scripts/extract_symvers.pl: Allow for weak versions.
	* testsuite/util/testsuite_abi.cc (check_version): Wrap
	CXXABI_1.3.16 in __riscv.

ChangeLog:

	* MAINTAINERS: Add myself.

gcc/fortran/ChangeLog:

	PR fortran/118745
	* trans-openmp.cc (gfc_trans_omp_declare_variant): Use
	append_args_list in the condition for the append_arg location.

The -MT and -MQ options should replace the default target in the
generated dependency file. deps_add_target needs to be called before
cpp_read_main_file, otherwise the original object name is added.

Contributed by Vincent Vanlaer <vincenttc@volkihar.be>

	PR fortran/47485

gcc/fortran/ChangeLog:

	* cpp.cc: fix -MT/-MQ adding additional target instead of
	replacing the default.

gcc/testsuite/ChangeLog:

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

Signed-off-by: Vincent Vanlaer <vincenttc@volkihar.be>

Enable use of Armv8-M instruction set.

Account for CVE-2021-35465 mitigation [PR102035].
The -mfix-cmse-cve-2021-35465 option is enabled by default,
if -mcpu=cortex-m33 is used.

gcc/

	* config/arm/t-rtems: Add Cortex-M33 multilib.

This patch fixes location bugs in BuildDecProcedure,
BuildIncProcedure, BuildInclProcedure, BuildExclProcedure and
BuildThrow.  All these procedure functions use the token position
passed as a parameter (rather than from the quad stack).  It also
fixes location bugs in CheckRangeIncDec to ensure that the token
position is stored on the quad stack before calling subsidiary
procedure functions.

gcc/m2/ChangeLog:

	PR modula2/115112
	* gm2-compiler/M2Quads.mod (BuildPseudoProcedureCall): Pass
	tokno to each build procedure.
	(BuildThrowProcedure): New parameter functok.
	(BuildIncProcedure): New parameter proctok.
	Pass proctok on the quad stack during every push.
	(BuildDecProcedure): Ditto.
	(BuildInclProcedure): New parameter proctok.
	(BuildExclProcedure): New parameter proctok.

gcc/testsuite/ChangeLog:

	PR modula2/115112
	* gm2/pim/run/pass/dectest.mod: New test.
	* gm2/pim/run/pass/inctest.mod: New test.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

The recent r15-7339-g26d3424ca5d9f4 fixed this test too.

	PR c++/94100

gcc/testsuite/ChangeLog:

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

The following testcases ICE with RAW_DATA_CSTs (so the first one since
introduction of #embed C++ optimizations and the latter since optimization
of large sequences of comma separated literals).
I've missed the fact that implicit_conversion can embed the exact expression
passed to it into stuff pointed out by conversion * (e.g. for user
conversions in sub->cand->args).
So, it isn't enough in convert_like_internal to pass the right INTEGER_CST
for each element of the RAW_DATA_CST because the whole RAW_DATA_CST might be
in sub->cand->args etc.
Either I'd need to chase for wherever the RAW_DATA_CST is found and update
those for each element processed, or, as implemented in the following patch,
build_list_conv detects the easy optimizable case where
convert_like_internal can be kept as the whole RAW_DATA_CST with changed
type and possibly narrowing diagnostics, and otherwise instead of having
a single subconversion it has RAW_DATA_CST separate subconversions.
Instead of trying to reallocate the subconvs array when we detect that case,
the patch instead uses an artificial ck_list inside of the u.list array
to hold the individual subconversions.
Seems the only places where u.list is used are build_list_conv and
convert_like_internal.

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

	PR c++/118671
	* call.cc (build_list_conv): For RAW_DATA_CST, call
	implicit_conversion with INTEGER_CST representing first byte instead
	of the whole RAW_DATA_CST.  If it is an optimizable trivial
	conversion, just save that to subconvs, otherwise allocate an
	artificial ck_list for all the RAW_DATA_CST bytes and create
	subsubconv for each of them.
	(convert_like_internal): For ck_list with RAW_DATA_CST, instead of
	doing all the checks for optimizable conversion just check kind and
	assert everything else, otherwise use subsubconversions instead of
	the subconversion for each element.

	* g++.dg/cpp/embed-25.C: New test.
	* g++.dg/cpp0x/pr118671.C: New test.

It's just a missing test for the presence of a nonempty parameter.

gcc/ada/
	PR ada/118731
	* sem_aggr.adb (Resolve_Iterated_Association): Add missing guard.

The -mcpu=tt-ascalon-d8 option for the test implies D extension, which
is not compatible with the ILP32E and ILP64E ABIs.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/pr118170.c: Ignore for E ABI.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>

Document new params in invoke.texi.

The auto tuning description was on the wrong tunable, move to lines.

Comitted as obvious.

gcc/ChangeLog:

	* doc/invoke.texi: Document file cache tunables.
	* params.opt: Move auto tuning description to lines.

Since commit r15-491-gc290e6a0b7a9de this failure happens on
armv8l-linux-gnueabihf and arm-eabi:

Running gcc:gcc.target/arm/simd/simd.exp ...
gcc.target/arm/simd/mve-vabs.c: memmove found 0 times
FAIL: gcc.target/arm/simd/mve-vabs.c scan-assembler-times memmove 3

In PR PR target/116010, Andrew Pinski noted that
"gcc.target/arm/simd/mve-vabs.c now calls memcpy because of the restrict
instead of memmove. That should be a simple fix there."

Therefore change the test to expect memcpy rather than memmove.

Another change is that memcpy is inlined rather than called, so also change
the test to check the optimized tree dump rather than the generated
assembly.

Tested on armv8l-linux-gnueabihf and arm-eabi.

gcc/testsuite/ChangeLog:
	PR target/116010
	* gcc.target/arm/simd/mve-vabs.c: Test tree dump and adjust to new
	code.

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

This PR describes a few issues, both ICE and rejects-valid, but
ultimately the problem is that we don't properly synthesize the
second auto in:

  int
  g (auto fp() -> auto)
  {
    return fp ();
  }

since r12-5860, which disabled auto_is_implicit_function_template_parm_p
in cp_parser_parameter_declaration after parsing the decl-specifier-seq.

If there is no trailing auto, there is no problem.

So we have to make sure auto_is_implicit_function_template_parm_p is
properly set when parsing the trailing auto.  A complication is that
one can write:

  auto f (auto fp(auto fp2() -> auto) -> auto) -> auto;
                                      ~~~~~~~

where only the underlined auto should be synthesized.  So when we
parse a parameter-declaration-clause inside another
parameter-declaration-clause, we should not enable the flag.  We
have no flags to keep track of such nesting, but I think I can walk
current_binding_level to see if we find ourselves in such an unlikely
scenario.

	PR c++/117778

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_late_return_type_opt): Maybe override
	auto_is_implicit_function_template_parm_p.
	(cp_parser_parameter_declaration): Move a make_temp_override below.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/lambda-generic-117778.C: New test.
	* g++.dg/cpp2a/abbrev-fn2.C: New test.
	* g++.dg/cpp2a/abbrev-fn3.C: New test.

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

This warning should not warn for

  auto f1 () -> auto;

because that cannot be confused with initializing a variable.

	PR c++/118718

gcc/cp/ChangeLog:

	* parser.cc (warn_about_ambiguous_parse): Don't warn when a trailing
	return type is present.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Wvexing-parse10.C: New test.

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

The match.pd canonicalization that this testcase checks for,
is not applied on ilp32 targets.

This XFAILs the test on ilp32 targets.

	PR testsuite/116845

gcc/testsuite/ChangeLog:

	* gcc.dg/pr109393.c: XFAIL on ilp32 targets.

The GIMPLE FE currently invokes parser_build_unary_op to build
unary GENERIC which has the operand subject to C promotion rules
which does not match GIMPLE.  The following adds a wrapper around
the build_unary_op worker which conveniently has an argument to
indicate whether to skip such promotion.

	PR c/118742
gcc/c/
	* gimple-parser.cc (gimple_parser_build_unary_op): New
	wrapper around build_unary_op.
	(c_parser_gimple_unary_expression): Use it.

gcc/testsuite/
	* gcc.dg/gimplefe-56.c: New testcase.

Commit 0990d93d ("IBM Z: Use @PLT symbols for local functions in
64-bit mode") made GCC call both static and non-static functions and
load both static and non-static function addresses with the @PLT
suffix.  This made it difficult for linkers to distinguish calling and
address taking instructions [1].  It is currently assumed that the
R_390_PLT32DBL relocation, corresponding to the @PLT suffix, is used
only for calling, and the R_390_PC32DBL relocation, corresponding to
the empty suffix, is used only for address taking.

Linkers needs to make this distinction in order to decide whether to
ask ld.so to use canonical PLT entries.  Normally GOT entries in shared
objects contain addresses of the respective functions, with one notable
exception: when a no-pie executable calls the respective function and
also takes its address.  Such executables assume that all addresses are
known in advance, so they use addresses of the respective PLT entries.
For consistency reasons, all respective GOT entries in the process must
also use them.

When a linker sees that a no-pie executable both calls a function and
also takes its address, it creates a PLT entry and asks ld.so to
consider it canonical by setting the respective undefined symbol's
address, which is normally 0, to the address of this PLT entry.

Improve the situation by not using @PLT with larl.

Now that @PLT is not used with larl, also drop the 31-bit handling,
which was required because 31-bit PLT entries require %r12 to point to
the respective object's GOT, and this requirement is not satisfied when
calling them by pointer from another object.

Also drop the weak symbol handling, which was required because it is
not possible to load an undefined weak symbol address (0) using larl.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=29655

gcc/ChangeLog:

	* config/s390/s390.cc (print_operand): Remove the no longer
	necessary 31-bit and weak symbol handling.
	* config/s390/s390.md (*movdi_64): Do not use @PLT with larl.
	(*movsi_larl): Likewise.
	(main_base_64): Likewise.
	(reload_base_64): Likewise.

gcc/testsuite/ChangeLog:

	* gcc.target/s390/call-z10-pic-nodatarel.c: Adjust
	expectations.
	* gcc.target/s390/call-z10-pic.c: Likewise.
	* gcc.target/s390/call-z10.c: Likewise.
	* gcc.target/s390/call-z9-pic-nodatarel.c: Likewise.
	* gcc.target/s390/call-z9-pic.c: Likewise.
	* gcc.target/s390/call-z9.c: Likewise.

We currently emit an incorrect -Woverloaded-virtual warning upon the
following test case

=== cut here ===
struct A {
  virtual operator int() { return 42; }
  virtual operator char() = 0;
};
struct B : public A {
  operator char() { return 'A'; }
};
=== cut here ===

The problem is that when iterating over ovl_range (fns), warn_hidden
gets confused by the conversion operator marker, concludes that
seen_non_override is true and therefore emits a warning for all
conversion operators in A that do not convert to char, even if
-Woverloaded-virtual is 1 (e.g. with -Wall, the case reported).

A second set of problems is highlighted when -Woverloaded-virtual is 2.

First, with the same test case, since base_fndecls contains all
conversion operators in A (except the one to char, that's been removed
when iterating over ovl_range (fns)), we emit a spurious warning for
the conversion operator to int, even though it's unrelated.

Second, in case there are several conversion operators with different
cv-qualifiers to the same type in A, we rightfully emit a warning,
however the note uses the location of the conversion operator marker
instead of the right one; location_of should go over conv_op_marker.

This patch fixes all these by explicitly keeping track of (1) base
methods that are overriden, as well as (2) base methods that are hidden
but not overriden (and by what), and warning about methods that are in
(2) but not (1). It also ignores non virtual base methods, per
"definition" of -Woverloaded-virtual.

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

	PR c++/117114
	PR c++/109918

gcc/cp/ChangeLog:

	* class.cc (warn_hidden): Keep track of overloaded and of hidden
	base methods.
	* error.cc (location_of): Skip over conv_op_marker.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Woverloaded-virt1.C: Check that no warning is
	emitted for non virtual base methods.
	* g++.dg/warn/Woverloaded-virt10.C: New test.
	* g++.dg/warn/Woverloaded-virt11.C: New test.
	* g++.dg/warn/Woverloaded-virt12.C: New test.
	* g++.dg/warn/Woverloaded-virt13.C: New test.
	* g++.dg/warn/Woverloaded-virt5.C: New test.
	* g++.dg/warn/Woverloaded-virt6.C: New test.
	* g++.dg/warn/Woverloaded-virt7.C: New test.
	* g++.dg/warn/Woverloaded-virt8.C: New test.
	* g++.dg/warn/Woverloaded-virt9.C: New test.

When there's an inner loop without virtual header PHI but the outer
loop has one the fusion process cannot handle the need to create
an inner loop virtual header PHI.  Punt in this case.

	PR tree-optimization/117113
	* gimple-loop-jam.cc (unroll_jam_possible_p): Detect when
	we cannot handle virtual SSA update.

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

We currently ICE in checking mode with cxx_dialect < 17 on the following
valid code

=== cut here ===
struct X {
  X(const X&) {}
};
extern X x;
void foo () {
  new X[1]{x};
}
=== cut here ===

We trip on a gcc_checking_assert in cp_gimplify_expr due to a
TARGET_EXPR that is not TARGET_EXPR_ELIDING_P. As pointed by Jason, the
problem is that build_vec_init does not recognize that digest_init has
been called, and we end up calling the copy constructor twice.

This happens because the detection in build_vec_init assumes that BASE
is a reference to the array, while it's a pointer to its first element
here. This patch makes sure that the detection works in both cases.

	PR c++/114619

gcc/cp/ChangeLog:

	* init.cc (build_vec_init): Properly determine whether
	digest_init has been called.

gcc/testsuite/ChangeLog:

	* g++.dg/init/no-elide4.C: New test.

As mentioned in the PR, this pedwarni is desirable for the implicit or
explicit capturing of structured bindings in C++17, but in the case of
init-captures the initializer is just some expression and that can include
structured bindings.

So, the following patch limits the warning to non-explicit_init_p.

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

	PR c++/118719
	* lambda.cc (add_capture): Only pedwarn about capturing structured
	binding if !explicit_init_p.

	* g++.dg/cpp1z/decomp63.C: New test.

r15-4317-ga6f4404689f12 tried to add support for widending optabs
for vec-mode -> scalar-mode but it misunderstood how FOR_EACH_MODE worked,
the limit in this case is not inclusive. Which means setting limit to from,
would cause the loop not be executed at all. This fixes by setting the
limit to be the next mode after from mode.

Note the original version that added the widening optabs for vec-mode -> scalar-mode
(https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665021.html) didn't have this
bug, only the second version with suggested change
(https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665068.html

) dud. The suggested
change missed this issue with FOR_EACH_MODE.

Bootstrapped and tested on x86_64-linux-gnu.

	PR middle-end/116926

gcc/ChangeLog:

	* optabs-query.cc (find_widening_optab_handler_and_mode): Fix
	limit for `vec-mode -> scalar-mode` case.

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

gcc/fortran/ChangeLog:

	* arith.cc (arith_power): Handle modular arithmetic for
	BT_UNSIGNED.
	(eval_intrinsic):  Error for unsigned exponentiation with
	-pedantic.
	* expr.cc (gfc_type_convert_binary): Use type of first
	argument for unsigned exponentiation.
	* gfortran.texi: Mention arithmetic exponentiation.
	* resolve.cc (resolve_operator): Allow unsigned exponentiation.
	* trans-decl.cc (gfc_build_intrinsic_function_decls): Build
	declarations for unsigned exponentiation.
	* trans-expr.cc (gfc_conv_cst_uint_power): New function.
	(gfc_conv_power_op): Call it.  Handle unsigned exponentiation.
	* trans.h (gfor_fndecl_unsigned_pow_list):  Add declaration.

libgfortran/ChangeLog:

	* Makefile.am: Add files for unsigned exponentiation.
	* Makefile.in: Regenerate.
	* gfortran.map: Add functions for unsigned exponentiation.
	* generated/pow_m16_m1.c: New file.
	* generated/pow_m16_m16.c: New file.
	* generated/pow_m16_m2.c: New file.
	* generated/pow_m16_m4.c: New file.
	* generated/pow_m16_m8.c: New file.
	* generated/pow_m1_m1.c: New file.
	* generated/pow_m1_m16.c: New file.
	* generated/pow_m1_m2.c: New file.
	* generated/pow_m1_m4.c: New file.
	* generated/pow_m1_m8.c: New file.
	* generated/pow_m2_m1.c: New file.
	* generated/pow_m2_m16.c: New file.
	* generated/pow_m2_m2.c: New file.
	* generated/pow_m2_m4.c: New file.
	* generated/pow_m2_m8.c: New file.
	* generated/pow_m4_m1.c: New file.
	* generated/pow_m4_m16.c: New file.
	* generated/pow_m4_m2.c: New file.
	* generated/pow_m4_m4.c: New file.
	* generated/pow_m4_m8.c: New file.
	* generated/pow_m8_m1.c: New file.
	* generated/pow_m8_m16.c: New file.
	* generated/pow_m8_m2.c: New file.
	* generated/pow_m8_m4.c: New file.
	* generated/pow_m8_m8.c: New file.
	* m4/powu.m4: New file.

gcc/testsuite/ChangeLog:

	* gfortran.dg/unsigned_15.f90: Adjust error messages.
	* gfortran.dg/unsigned_43.f90: New test.
	* gfortran.dg/unsigned_44.f90: New test.

The following checks we have a scalar int shift mode before
enforcing it.  As AVR shows the mode can be a signed _Accum mode
as well.

	PR rtl-optimization/117611
	* combine.cc (simplify_shift_const_1): Bail if not
	scalar int mode.

	* gcc.dg/fixed-point/pr117611.c: New testcase.

When we process function types we strip volatile and const qualifiers
after building a simplified type variant (which preserves those).
The qualified type handling of both isn't really compatible, so avoid
bad interaction by swapping this, first dropping const/volatile
qualifiers and then building the simplified type thereof.

	PR lto/113207
	* ipa-free-lang-data.cc (free_lang_data_in_type): First drop
	const/volatile qualifiers from function argument types,
	then build a simplified type.

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

Modules makes some assumptions about types that currently aren't
fulfilled by the types created in contracts logic.  This patch ensures
that exporting inline functions using contracts works again with
modules.

	PR c++/108205

gcc/cp/ChangeLog:

	* contracts.cc (get_pseudo_contract_violation_type): Give names
	to generated FIELD_DECLs.
	(declare_handle_contract_violation): Mark contract_violation
	type as external linkage.
	(build_contract_handler_call): Ensure any builtin declarations
	created here aren't treated as attached to the current module.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/contracts-5_a.C: New test.
	* g++.dg/modules/contracts-5_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

'start_cleanup_fn' is not currently viable in modules, due to generating
functions relying on the 'start_cleanup_cnt' counter which is reset to 0
with each new TU.  This means that cleanup functions declared in a TU
will conflict with any imported cleanup functions.

This patch mitigates the problem by using the mangled name of the decl
we're destroying as part of the name of the function.  This should avoid
clashes unless the decls would have clashed anyway.

	PR c++/98893

gcc/cp/ChangeLog:

	* decl.cc (start_cleanup_fn): Make name from the mangled name of
	the passed-in decl.
	(register_dtor_fn): Pass decl to start_cleanup_fn.

gcc/testsuite/ChangeLog:

	* g++.dg/modules/pr98893_a.H: New test.
	* g++.dg/modules/pr98893_b.C: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

For non-type parameter packs when unifying the arguments in
unify_pack_expansion it iterates over the associated packs of a param so
that when it recursively unifies the param with the arguments it knows
which targs have been populated with parameter pack arguments that it can
then collect up. This change adds a tree walk so that in the example above
it reaches ...A and adds it to the associated packs for ...B and therefore
knows it will have been set in targs in unify_pack_expansion and processes
it as per other pack arguments.

	PR c++/118265

gcc/cp/ChangeLog:

	* pt.cc (find_parameter_packs_r) <case TEMPLATE_PARM_INDEX>:
	Walk into the type of a parameter pack.

Signed-off-by: Adam J Ryan <gcc.gnu.org@ajryansolutions.co.uk>

Awaiters always need to have a coroutine state frame copy since
they persist across potential supensions.  It simplifies the later
analysis considerably to assign these early which we do when
building co_await expressions.

The cleanups in r15-3146-g47dbd69b1, unfortunately elided some of
processing used to cater for cases where the var created from an
xvalue, or is a pointer/reference type.

Corrected thus.

	PR c++/116506
	PR c++/116880

gcc/cp/ChangeLog:

	* coroutines.cc (build_co_await): Ensure that xvalues are
	materialised.  Handle references/pointer values in awaiter
	access expressions.
	(is_stable_lvalue): New.
	* decl.cc (cxx_maybe_build_cleanup): Handle null arg.

gcc/testsuite/ChangeLog:

	* g++.dg/coroutines/pr116506.C: New test.
	* g++.dg/coroutines/pr116880.C: New test.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
Co-authored-by: Jason Merrill <jason@redhat.com>

The implementation of extended range-for temporaries in r15-3840 confused
coroutines, because await_statement_walker and the like get confused by the
EXPR_STMT into thinking that the whole for-loop is a single expression
statement and try to process it accordingly.  Fixing this seems to be a
simple matter of dropping the EXPR_STMT.

	PR c++/116914
	PR c++/117231
	PR c++/118470
	PR c++/118491

gcc/cp/ChangeLog:

	* semantics.cc (finish_for_stmt): Don't wrap the result of
	pop_stmt_list in EXPR_STMT.

gcc/testsuite/ChangeLog:

	* g++.dg/coroutines/coro-range-for1.C: New test.