When a generic lambda calls an overload set containing an iobj member
function we speculatively capture 'this'.  We need to do the same
for an xobj member function.

	PR c++/119038

gcc/cp/ChangeLog:

	* lambda.cc (maybe_generic_this_capture): Consider xobj
	member functions as well, not just iobj.  Update function
	comment.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/explicit-obj-lambda15.C: New test.

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

It turns out the reason the behavior of this testcase changed after CWG
2369 is because validity of the substituted return type is now checked
later, after constraints.  So a more reliable workaround for this issue
is to add a constraint to check the validity of the return type earlier,
matching the pre-CWG 2369 semantics.

	PR libstdc++/104606

libstdc++-v3/ChangeLog:

	* include/std/optional (operator<=>): Revert r14-9771 change.
	Add constraint checking the validity of the return type
	compare_three_way_result_t before the three_way_comparable_with
	constraint.

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

Here for

  using RCI = reverse_iterator<basic_const_iterator<vector<int>::iterator>>
  static_assert(std::totally_ordered<RCI>);

we effectively need to check the requirement

  requires (RCI x) { x RELOP x; }  for each RELOP in {<, >, <=, >=}

which we expect to be straightforwardly satisfied by reverse_iterator's
namespace-scope relops.  But due to ADL we find ourselves also
considering the basic_const_iterator relop friends, which before CWG
2369 would be quickly discarded since RCI clearly isn't convertible to
basic_const_iterator.  After CWG 2369 though we must first check these
relops' constraints (with _It = vector<int>::iterator and _It2 = RCI),
which entails checking totally_ordered<RCI> recursively.

This patch fixes this by turning the problematic non-dependent function
parameters of type basic_const_iterator<_It> into dependent ones of
type basic_const_iterator<_It3> where _It3 is constrained to match _It.
Thus the basic_const_iterator relop friends now get quickly discarded
during deduction and before the constraint check if the second operand
isn't a specialization of basic_const_iterator (or derived from one)
like before CWG 2369.

	PR libstdc++/112490

libstdc++-v3/ChangeLog:

	* include/bits/stl_iterator.h (basic_const_iterator::operator<):
	Replace non-dependent basic_const_iterator function parameter with
	a dependent one of type basic_const_iterator<_It3> where _It3
	matches _It.
	(basic_const_iterator::operator>): Likewise.
	(basic_const_iterator::operator<=): Likewise.
	(basic_const_iterator::operator>=): Likewise.
	* testsuite/24_iterators/const_iterator/112490.cc: New test.

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

I've added the asserts that probe == target because {REAL,IMAG}PART_EXPR
always implies a scalar type and so applying ARRAY_REF/COMPONENT_REF
etc. on it further doesn't make sense and the later code relies on it
to be the last one in refs array.  But as the following testcase shows,
we can fail those assertions in case there is a reference or pointer
to the __real__ or __imag__ part, in that case we just evaluate the
constant expression and so probe won't be the same as target.
That case doesn't push anything into the refs array though.

The following patch changes those asserts to verify that refs is still
empty, which fixes it.

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

	PR c++/119045
	* constexpr.cc (cxx_eval_store_expression) <case REALPART_EXPR>:
	Assert that refs->is_empty () rather than probe == target.
	(cxx_eval_store_expression) <case IMAGPART_EXPR>: Likewise.

	* g++.dg/cpp1y/constexpr-complex2.C: New test.

Now that the #embed paper has been voted in, the following patch
removes the pedwarn for C++26 on it (and adjusts pedwarn warning for
older C++ versions) and predefines __cpp_pp_embed FTM.

Also, the patch changes cpp_error to cpp_pedwarning with for C++
-Wc++26-extensions guarding, and for C add -Wc11-c23-compat warning
about #embed.

I believe we otherwise implement everything in the paper already,
except I'm really confused by the
 [Example:

 #embed <data.dat> limit(__has_include("a.h"))

 #if __has_embed(<data.dat> limit(__has_include("a.h")))
 // ill-formed: __has_include [cpp.cond] cannot appear here
 #endif

 — end example]
part.  My reading of both C23 and C++ with the P1967R14 paper in
is that the first case (#embed with __has_include or __has_embed in its
clauses) is what is clearly invalid and so the ill-formed note should be
for #embed.  And the __has_include/__has_embed in __has_embed is actually
questionable.
Both C and C++ have something like
"The identifiers __has_include, __has_embed, and __has_c_attribute
shall not appear in any context not mentioned in this subclause."
or
"The identifiers __has_include and __has_cpp_attribute shall not appear
in any context not mentioned in this subclause."
(into which P1967R14 adds __has_embed) in the conditional inclusion
subclause.  #embed is defined in a different one, so using those in there
is invalid (unless "using the rules specified for conditional inclusion"
wording e.g. in limit clause overrides that).
The reason why I think it is fuzzy for __has_embed is that __has_embed
is actually defined in the Conditional inclusion subclause (so that
would mean one can use __has_include, __has_embed and __has_*attribute
in there) but its clauses are described in a different one.

GCC currently accepts
 #embed __FILE__ limit (__has_include (<stdarg.h>))
 #if __has_embed (__FILE__ limit (__has_include (<stdarg.h>)))
 #endif
 #embed __FILE__ limit (__has_embed (__FILE__))
 #if __has_embed (__FILE__ limit (__has_embed (__FILE__)))
 #endif
Note, it isn't just about limit clause, but also about
prefix/suffix/if_empty, except that in those cases the "using the rules
specified for conditional inclusion" doesn't apply.

In any case, I'd hope that can be dealt with incrementally (and should
be handled the same for both C and C++).

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

libcpp/
	* include/cpplib.h (enum cpp_warning_reason): Add
	CPP_W_CXX26_EXTENSIONS enumerator.
	* init.cc (lang_defaults): Set embed for GNUCXX26 and CXX26.
	* directives.cc (do_embed): Adjust pedwarn wording for embed in C++,
	use cpp_pedwarning instead of cpp_error and add CPP_W_C11_C23_COMPAT
	warning of cpp_pedwarning hasn't diagnosed anything.
gcc/c-family/
	* c.opt (Wc++26-extensions): Add CppReason(CPP_W_CXX26_EXTENSIONS).
	* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_pp_embed=202502
	for C++26.
gcc/testsuite/
	* g++.dg/cpp/embed-1.C: Adjust for pedwarn wording change and don't
	expect any error for C++26.
	* g++.dg/cpp/embed-2.C: Adjust for pedwarn wording change and don't
	expect any warning for C++26.
	* g++.dg/cpp26/feat-cxx26.C: Test __cpp_pp_embed value.
	* gcc.dg/cpp/embed-17.c: New test.

The following fixes a thinko in the handling of interposed weak
definitions which confused the interposition check in
get_availability by setting DECL_EXTERNAL too early.

	PR lto/91299
gcc/lto/
	* lto-symtab.cc (lto_symtab_merge_symbols): Set DECL_EXTERNAL
	only after calling get_availability.

gcc/testsuite/
	* gcc.dg/lto/pr91299_0.c: New testcase.
	* gcc.dg/lto/pr91299_1.c: Likewise.

We currently record a kill for

  *x_4(D) = always_throws ();

because we consider the store always executing since the appropriate
check for whether the stmt could throw is guarded by
!cfun->can_throw_non_call_exceptions.

	PR ipa/111245
	* ipa-modref.cc (modref_access_analysis::analyze_store): Do
	not guard the check of whether the stmt could throw by
	cfun->can_throw_non_call_exceptions.

	* g++.dg/torture/pr111245.C: New testcase.

As documented in the manual, FIX/UNSIGNED_FIX from floating point
mode to integral mode has unspecified rounding and FIX from floating point
mode to the same floating point mode is expressing rounding toward zero.
So, some targets (arc, arm, csky, m68k, mmix, nds32, pdp11, sparc and
visium) use
(fix:SI (fix:SF (match_operand:SF 1 "..._operand")))
etc. to express the rounding toward zero during conversion to integer.
For some reason other targets don't use that.

Anyway, the 2 FIXes (or inner FIX with outer UNSIGNED_FIX) cause problems
since the r15-2890 which removed some strict checks in ifcvt.cc on what
SET_SRC can be actually conditionalized (I must say I'm still worried
about the change, don't know why one can't get e.g. inline asm or
something with UNSPEC or some complex backend specific RTLs that
force_operand can't handle), force_operand just ICEs on it, it can only
handle (through expand_fix) conversions from floating point to integral.

The following patch fixes this by detecting this case and just pretend
the inner FIX isn't there, i.e. call expand_fix with the inner FIX's
operand instead, which works and on targets like arm it will just
create the nested FIXes again.

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

	PR rtl-optimization/117712
	* expr.cc (force_operand): Handle {,UNSIGNED_}FIX with
	FIX operand using expand_fix on the inner FIX operand.

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

The following disables redundant store elimination to hard register
variables which isn't valid.

	PR tree-optimization/87984
	* tree-ssa-dom.cc (dom_opt_dom_walker::optimize_stmt): Do
	not perform redundant store elimination to hard register
	variables.
	* tree-ssa-sccvn.cc (eliminate_dom_walker::eliminate_stmt):
	Likewise.

	* gcc.target/i386/pr87984.c: New testcase.

When the C++ frontend clones a CTOR we do not copy ASM_EXPR constraints
fully as walk_tree does not recurse to TREE_PURPOSE of TREE_LIST nodes.
At this point doing that seems too dangerous so the following instead
avoids gimplification of ASM_EXPRs to clobber the shared constraints
and unshares it there, like it also unshares TREE_VALUE when it
re-writes a "+" output constraint to separate "=" output and matching
input constraint.

	PR middle-end/66279
	* gimplify.cc (gimplify_asm_expr): Copy TREE_PURPOSE before
	rewriting it for "+" processing.

	* g++.dg/pr66279.C: New testcase.

I found another test which uses -m32 in gcc.target/i386/ .  Similarly
to the previously posted test, the test ought to be tested during i686-linux
testing or x86_64-linux test with --target_board=unix\{-m32,-m64\}
There is nothing ia32 specific on the test, so I've just dropped the -m32.

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

	* gcc.target/i386/strub-pr118006.c: Remove -m32 from dg-options.

The testcase uses -m32 in dg-options, something we try hard not to do,
if something should be tested only for -m32, it is { target ia32 } test,
if it can be tested for -m64/-mx32 too, just some extra options are
needed for ia32, it should have dg-additional-options with ia32 target.

Also, the test wasn't reduced, so I've reduced it using cvise and manual
tweaks and verified the test still FAILs before r15-7700 and succeeds
with current trunk.

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

	PR target/118940
	* gcc.target/i386/pr118940.c: Drop -w, -g and -m32 from dg-options, move
	-march=i386 -mregparm=3 to dg-additional-options for ia32 and -fno-pie
	to dg-additional-options for pie.  Reduce the test.

	PR fortran/118730

gcc/fortran/ChangeLog:

	* resolve.cc: Mark unused derived type variable with finalizers
	referenced to execute finalizer when leaving scope.

gcc/testsuite/ChangeLog:

	* gfortran.dg/class_array_15.f03: Remove unused variable.
	* gfortran.dg/coarray_poly_7.f90: Adapt scan-tree-dump expr.
	* gfortran.dg/coarray_poly_8.f90: Same.
	* gfortran.dg/finalize_60.f90: New test.

ChangeLog:

	* MAINTAINERS: Added myself as write after approval and DCO.

Move the TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P target hook from
i386.h to i386.cc.

	* config/i386/i386.h (TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P):
	Moved to ...
	* config/i386/i386.cc (TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P):
	Here.

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

This patch would like to fix one bug when expanding const vector for the
interleave case.  For example, we have:

base1 = 151
step = 121

For vec_series, we will generate vector in format of v[i] = base + i * step.
Then the vec_series will have below result for HImode, and we can find
that the result overflow to the highest 8 bits of HImode.

v1.b = {151, 255, 7,  0, 119,  0, 231,  0, 87,  1, 199,  1, 55,   2, 167,   2}

Aka we expect v1.b should be:

v1.b = {151, 0, 7,  0, 119,  0, 231,  0, 87,  0, 199,  0, 55,   0, 167,   0}

After that it will perform the IOR with v2 for the base2(aka another series).

v2.b =  {0,  17, 0, 33,   0, 49,   0, 65,  0, 81,   0, 97,  0, 113,   0, 129}

Unfortunately, the base1 + i * step1 in HImode may overflow to the high
8 bits, and the high 8 bits will pollute the v2 and result in incorrect
value in const_vector.

This patch would like to perform the overflow to smode check before the
optimized interleave code generation.  If overflow or VLA, it will fall
back to the default merge approach.

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

	PR target/118931

gcc/ChangeLog:

	* config/riscv/riscv-v.cc (expand_const_vector): Add overflow to
	smode check and clean up highest bits if overflow.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/pr118931-run-1.c: New test.

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

Use `dg-runtest' test driver rather than `dg-test' to run the libphobos
unittest testsuite, same as all other libphobos tests.  This prevents
the tests from being ran multiple times when parallelized.

Set `libphobos_test_name' as well so that all tests get a unique name.

libphobos/ChangeLog:

	* testsuite/libphobos.unittest/unittest.exp: Use `dg-runtest' rather
	than `dg-test'.  Set `libphobos_test_name'.

My r15-998-g2a83084ce55363 change replaced the use of nothrow
operator new with a call to __get_temporary_buffer, so update the
comment to match.

libstdc++-v3/ChangeLog:

	* include/std/stacktrace (_Impl::_M_allocate): Fix outdated
	comment.

The following testcase is miscompiled since r15-7597.
The left comparison is unsigned (x & 0x8000U) != 0) while the
right one is signed (x >> 16) >= 0 and is actually a signbit test,
so rsignbit is 64.
After debugging this and reading the r15-7597 change, I believe there
is just a pasto, the if (lsignbit) and if (rsignbit) blocks are pretty
much identical with just the first l on all variables starting with l
replaced with r (the only difference is that if (lsignbit) has a comment
explaining the sign <<= 1; stuff, while it isn't repeated in the second one.
Except the second one was using ll_unsignedp instead of rl_unsignedp
in one spot.  I think it should use the latter, the signedness of the left
comparison doesn't affect the other one, they are basically independent
with the exception that we check that after transformations they are both
EQ or both NE and later on we try to merge them together.

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

	PR tree-optimization/119030
	* gimple-fold.cc (fold_truth_andor_for_ifcombine): Fix a pasto,
	ll_unsignedp -> rl_unsignedp.

	* gcc.c-torture/execute/pr119030.c: New test.

The following testcase ICEs, because we first construct file_cache object
inside of *global_dc, then process options and then call file_cache::tune.
The earlier construction allocates the m_file_slots array (using new)
based on the static data member file_cache::num_file_slots, but then tune
changes it, without actually reallocating all m_file_slots arrays in already
constructed file_cache objects.

I think it is just weird to have the count be a static data member and
the pointer be non-static data member, that is just asking for issues like
this.

So, this patch changes num_file_slots into m_num_file_slots and turns tune
into a non-static member function and changes toplev.cc to call it on the
global_gc->get_file_cache () object.  And let's the tune just delete the
array and allocate it freshly if there is a change in the number of slots
or lines.

Note, file_cache_slot has similar problem, but because there are many, I
haven't moved the count into those objects; I just hope that when tune
is called there is exactly one file_cache constructed and all the
file_cache_slot objects constructed are pointed by its m_file_slots member,
so also on lines change it just deletes it and allocates again.  I think
it should be unlikely that the cache actually has any used slots by the time
it is called.

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

	PR middle-end/118860
	* input.h (file_cache::tune): No longer static.  Rename argument
	from num_file_slots_ to num_file_slots.  Formatting fix.
	(file_cache::num_file_slots): Renamed to ...
	(file_cache::m_num_file_slots): ... this.  No longer static.
	* input.cc (file_cache_slot::tune): Change return type from void to
	size_t, return previous file_cache_slot::line_record_size value.
	Formatting fixes.
	(file_cache::tune): Rename argument from num_file_slots_ to
	num_file_slots.  Set m_num_file_slots rather than num_file_slots.
	If m_num_file_slots or file_cache_slot::line_record_size changes,
	delete[] m_file_slots and new it again.
	(file_cache::num_file_slots): Remove definition.
	(file_cache::lookup_file): Use m_num_file_slots rather than
	num_file_slots.
	(file_cache::evicted_cache_tab_entry): Likewise.
	(file_cache::file_cache): Likewise.  Initialize m_num_file_slots
	to 16.
	(file_cache::dump): Use m_num_file_slots rather than num_file_slots.
	(file_cache_slot::get_next_line): Formatting fixes.
	(file_cache_slot::read_line_num): Likewise.
	(get_source_text_between): Likewise.
	* toplev.cc (toplev::main): Call global_dc->get_file_cache ().tune
	rather than file_cache::tune.

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

... instead of 64 via 'gcc/defaults.h':

    MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (DImode)

This fixes ICEs:

    [-FAIL: c-c++-common/pr111309-1.c  -Wc++-compat  (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -Wc++-compat  (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -Wc++-compat  [-compilation failed to produce executable-]{+execution test+}

    [-FAIL: c-c++-common/pr111309-1.c  -std=gnu++17 (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++17 (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++17 [-compilation failed to produce executable-]{+execution test+}
    [-FAIL: c-c++-common/pr111309-1.c  -std=gnu++26 (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++26 (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++26 [-compilation failed to produce executable-]{+execution test+}
    [-FAIL: c-c++-common/pr111309-1.c  -std=gnu++98 (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++98 (test for excess errors)
    [-UNRESOLVED:-]{+PASS:+} c-c++-common/pr111309-1.c  -std=gnu++98 [-compilation failed to produce executable-]{+execution test+}

    [-FAIL: gcc.dg/torture/pr116480-1.c   -O0  (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} gcc.dg/torture/pr116480-1.c   -O0  (test for excess errors)
    [-FAIL: gcc.dg/torture/pr116480-1.c   -O1  (internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268)-]
    [-FAIL:-]{+PASS:+} gcc.dg/torture/pr116480-1.c   -O1  (test for excess errors)
    PASS: gcc.dg/torture/pr116480-1.c   -O2  (test for excess errors)
    PASS: gcc.dg/torture/pr116480-1.c   -O3 -g  (test for excess errors)
    PASS: gcc.dg/torture/pr116480-1.c   -Os  (test for excess errors)

..., where we ran into 'gcc_assert (icode != CODE_FOR_nothing);' in
'gcc/internal-fn.cc:expand_fn_using_insn' for '__int128' '__builtin_clzg' etc.:

    during RTL pass: expand
    [...]/c-c++-common/pr111309-1.c: In function 'clzI':
    [...]/c-c++-common/pr111309-1.c:69:10: internal compiler error: in expand_fn_using_insn, at internal-fn.cc:268
    0x120ec2cf internal_error(char const*, ...)
            [...]/gcc/diagnostic-global-context.cc:517
    0x102c7c5b fancy_abort(char const*, int, char const*)
            [...]/gcc/diagnostic.cc:1722
    0x109708eb expand_fn_using_insn
            [...]/gcc/internal-fn.cc:268
    0x1098114f expand_internal_call(internal_fn, gcall*)
            [...]/gcc/internal-fn.cc:5273
    0x1098114f expand_internal_call(gcall*)
            [...]/gcc/internal-fn.cc:5281
    0x10594fc7 expand_call_stmt
            [...]/gcc/cfgexpand.cc:3049
    [...]

Likewise, as of commit e8ad697a
"libstdc++: Use new type-generic built-ins in <bit> [PR118855]",
the libstdc++ target library build ICEd in the same way.

Additionally, this change fixes:

    [-FAIL:-]{+PASS:+} gcc.dg/pr105094.c (test for excess errors)

..., which was:

    [...]/gcc.dg/pr105094.c: In function 'foo':
    [...]/gcc.dg/pr105094.c:11:12: error: size of variable 's' is too large

And, finally, regarding 'gcc.target/nvptx/stack_frame-1.c'.  Before, in
'gcc/cfgexpand.cc': 'expand_used_vars' -> 'expand_used_vars_for_block' ->
'expand_one_var' for 'ww' -> 'gcc/function.cc:use_register_for_decl' due to
'DECL_MODE (decl) == BLKmode' did 'return false;', thus -> 'add_stack_var'
(even if 'ww' wasn't then actually living on the stack).  Now, 'ww' has
'TImode' and 'use_register_for_decl' does 'return true;', thus ->
'expand_one_register_var', and therefore no unused stack frame emitted.

	gcc/
	* config/nvptx/nvptx.h (MAX_FIXED_MODE_SIZE): '#define'.
	gcc/testsuite/
	* gcc.target/nvptx/stack_frame-1.c: Adjust.

	gcc/testsuite/
	* gcc.target/nvptx/stack_frame-1.c: New.

As of recent commit 8bf0ee8d
"Fortran: Add transfer_between_remotes [PR107635]", we've got 'alloca' usage
in 'libgfortran/caf/single.c:_gfortran_caf_transfer_between_remotes', and
the libgfortran target library fails to build for legacy configurations where
PTX 'alloca' is not available:

    ../../../../source-gcc/libgfortran/caf/single.c: In function ‘_gfortran_caf_transfer_between_remotes’:
    ../../../../source-gcc/libgfortran/caf/single.c:675:23: sorry, unimplemented: dynamic stack allocation not supported
      675 |       transfer_desc = __builtin_alloca (desc_size);
          |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    ../../../../source-gcc/libgfortran/caf/single.c:680:20: sorry, unimplemented: dynamic stack allocation not supported
      680 |     transfer_ptr = __builtin_alloca (*opt_dst_charlen * src_size);
          |                    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    make[6]: *** [Makefile:4675: caf/single.lo] Error 1

With '-mfake-ptx-alloca', libgfortran again succeeds to build, and compared
to before, we've got only a small number of regressions due to nvptx 'ld'
complaining about 'unresolved symbol __GCC_nvptx__PTX_alloca_not_supported':

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/codimension_2.f90 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/event_4.f08 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)
    [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/event_4.f08 -fcoarray=lib  -O2  -lcaf_single [-execution test-]{+compilation failed to produce executable+}

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)
    [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/fail_image_2.f08 -fcoarray=lib  -O2  -lcaf_single [-execution test-]{+compilation failed to produce executable+}

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 -fcoarray=lib  -O2  -lcaf_single (test for excess errors)
    [-PASS:-]{+UNRESOLVED:+} gfortran.dg/coarray/proc_pointer_assign_1.f90 -fcoarray=lib  -O2  -lcaf_single [-execution test-]{+compilation failed to produce executable+}

    [-PASS:-]{+FAIL:+} gfortran.dg/coarray_43.f90   -O  (test for excess errors)

That's acceptable for such legacy PTX configurations.

	PR target/107635
	libgfortran/
	* config/t-nvptx: New.
	* configure.host [nvptx] (tmake_file): Add it.

With '-mfake-ptx-alloca' enabled, the user-visible behavior changes only
for configurations where PTX 'alloca' is not available.  Rather than a
compile-time 'sorry, unimplemented: dynamic stack allocation not supported'
in presence of dynamic stack allocation, compilation and assembly then
succeeds.  However, attempting to link in such '*.o' files then fails due
to unresolved symbol '__GCC_nvptx__PTX_alloca_not_supported'.

This is meant to be used in scenarios where large volumes of code are
compiled, a small fraction of which runs into dynamic stack allocation, but
these parts are not important for specific use cases, and we'd thus like the
build to succeed, and error out just upon actual, very rare use of the
offending '*.o' files.

	gcc/
	* config/nvptx/nvptx.opt (-mfake-ptx-alloca): New.
	* config/nvptx/nvptx-protos.h (nvptx_output_fake_ptx_alloca):
	Declare.
	* config/nvptx/nvptx.cc (nvptx_output_fake_ptx_alloca): New.
	* config/nvptx/nvptx.md (define_insn "@nvptx_alloca_<mode>")
	[!(TARGET_PTX_7_3 && TARGET_SM52)]: Use it for
	'-mfake-ptx-alloca'.
	gcc/testsuite/
	* gcc.target/nvptx/alloca-1-O0_-mfake-ptx-alloca.c: New.
	* gcc.target/nvptx/alloca-2-O0_-mfake-ptx-alloca.c: Likewise.
	* gcc.target/nvptx/alloca-4-O3_-mfake-ptx-alloca.c: Likewise.
	* gcc.target/nvptx/vla-1-O0_-mfake-ptx-alloca.c: Likewise.
	* gcc.target/nvptx/alloca-4-O3.c:
	'dg-additional-options -mfake-ptx-alloca'.

nvptx: Delay 'sorry, unimplemented: dynamic stack allocation not supported' from expansion time to code generation

This gives the back end a chance to clean out a few more unnecessary instances
of dynamic stack allocation.  This progresses:

    PASS: gcc.dg/pr78902.c  (test for warnings, line 7)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 8)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 9)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 10)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 11)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 12)
    PASS: gcc.dg/pr78902.c  (test for warnings, line 13)
    PASS: gcc.dg/pr78902.c strndup excessive bound at line 14 (test for warnings, line 13)
    [-UNSUPPORTED: gcc.dg/pr78902.c: dynamic stack allocation not supported-]
    {+PASS: gcc.dg/pr78902.c (test for excess errors)+}

    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O0 : dynamic stack allocation not supported
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr71901.c   -O1  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O2 : dynamic stack allocation not supported
    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions : dynamic stack allocation not supported
    UNSUPPORTED: gcc.dg/torture/pr71901.c   -O3 -g : dynamic stack allocation not supported
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr71901.c   -Os  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}

    UNSUPPORTED: gcc.dg/torture/pr78742.c   -O0 : dynamic stack allocation not supported
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O1  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O2  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    [-UNSUPPORTED:-]{+PASS:+} gcc.dg/torture/pr78742.c   -O3 -g  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}
    UNSUPPORTED: gcc.dg/torture/pr78742.c   -Os : dynamic stack allocation not supported

    [-UNSUPPORTED:-]{+PASS:+} gfortran.dg/pr101267.f90   -O  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}

    [-UNSUPPORTED:-]{+PASS:+} gfortran.dg/pr112404.f90   -O  [-: dynamic stack allocation not supported-]{+(test for excess errors)+}

	gcc/
	* config/nvptx/nvptx.md (define_expand "allocate_stack")
	[!TARGET_SOFT_STACK]: Move
	'sorry ("dynamic stack allocation not supported");'...
	(define_insn "@nvptx_alloca_<mode>"): ... here.
	gcc/testsuite/
	* gcc.target/nvptx/alloca-1-unused-O0-sm_30.c: Adjust.

	gcc/testsuite/
	* gcc.target/nvptx/alloca-1-dead-O0-sm_30.c: New.
	* gcc.target/nvptx/alloca-1-dead-O0.c: Likewise.
	* gcc.target/nvptx/alloca-1-dead-O1-sm_30.c: Likewise.
	* gcc.target/nvptx/alloca-1-dead-O1.c: Likewise.
	* gcc.target/nvptx/alloca-1-unused-O0-sm_30.c: Likewise.
	* gcc.target/nvptx/alloca-1-unused-O0.c: Likewise.
	* gcc.target/nvptx/alloca-1-unused-O1-sm_30.c: Likewise.
	* gcc.target/nvptx/alloca-1-unused-O1.c: Likewise.
	* gcc.target/nvptx/vla-1-dead-O0-sm_30.c: Likewise.
	* gcc.target/nvptx/vla-1-dead-O0.c: Likewise.
	* gcc.target/nvptx/vla-1-dead-O1-sm_30.c: Likewise.
	* gcc.target/nvptx/vla-1-dead-O1.c: Likewise.
	* gcc.target/nvptx/vla-1-unused-O0-sm_30.c: Likewise.
	* gcc.target/nvptx/vla-1-unused-O0.c: Likewise.
	* gcc.target/nvptx/vla-1-unused-O1-sm_30.c: Likewise.
	* gcc.target/nvptx/vla-1-unused-O1.c: Likewise.

This change updates information about the -x option to clarify
that it does not ensure standards compliance. Sparked by
discussions in the following PR.

	PR fortran/108369

gcc/ChangeLog:

	* doc/invoke.texi: Add a note to clarify. Adjust some wording.

In this PR we crash in cxx_eval_constant_expression/GOTO_EXPR on:

  gcc_assert (cxx_dialect >= cxx23);

The code obviously doesn't expect to see a goto pre-C++23.  But we can
get here with the new prvalue optimization.  In this test we found
ourselves in synthesize_method for X::X().  This function calls:

 a) finish_function, which does cp_genericize -> ... -> genericize_c_loops,
    which creates the GOTO_EXPR;
 b) expand_or_defer_fn -> maybe_clone_body -> ... -> cp_fold_function
    where we reach the new maybe_constant_init call and crash on the
    goto.

Since we can validly get to that assert, I think we should just remove
it.  I don't see other similar asserts like this one.

	PR c++/118928

gcc/cp/ChangeLog:

	* constexpr.cc (cxx_eval_constant_expression) <case GOTO_EXPR>: Remove
	an assert.

gcc/testsuite/ChangeLog:

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

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

PR115458 also solves given PR.  So the patch adds only a
test case which can be used for testing LRA work aspects different from
PR115458 test case.

gcc/testsuite/ChangeLog:

	PR target/118940
	* gcc.target/i386/pr118940.c: New test.

  Patch for PR116234 solves given PR116366.  So the patch adds only the test
case which is very different from PR116234 one.

gcc/testsuite/ChangeLog:

	PR rtl-optimization/116336
	* gcc.dg/pr116336.c: New test.

Since C++20 P0846, a name followed by a < can be treated as a template-name
even though name lookup did not find a template-name.  That happens
in this test with "i < foo ()":

  for (int id = 0; i < foo(); ++id);

and results in a raft of errors about non-constant foo().  The problem
is that the require_potential_constant_expression call in
cp_parser_template_argument emits errors even when we're parsing
tentatively.  So we repeat the error when we're trying to parse
as a nested-name-specifier, type-name, etc.

Guarding the call with !cp_parser_uncommitted_to_tentative_parse_p would
mean that require_potential_constant_expression never gets called.  But
we don't need the call at all as far as I can tell.  Stuff like

  template<int N> struct S { };
  int foo () { return 4; }
  void
  g ()
  {
    S<foo()> s;
  }

gets diagnosed in convert_nontype_argument.  In fact, with this patch,
we only emit "call to non-constexpr function" once.  (That is, in C++17
only; C++14 uses a different path.)

	PR c++/118516

gcc/cp/ChangeLog:

	* parser.cc (cp_parser_template_argument): Don't call
	require_potential_constant_expression.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/fn-template11.C:
	* g++.dg/template/fn-template1.C: New test.
	* g++.dg/template/fn-template2.C: New test.

This test uses incremental linking, but that can generate warnings if
the LTO step contains a mix of LTO and non-LTO object files (this can
happen when there's a testglue file that is normally included during
linking).

We don't care about the testglue, though, so just tell the LTO
optimizer to generate nolto-rel output, which is what it is falling
back to anyway.

gcc/testsuite:
	* gcc.target/arm/lto/pr61123-enum-size_0.c: (dg-lto-options) Move
	linker related options to ...
	(dg-extra-ld-options): ... here.  Add -flinker-output=nolto-rel.

Fix ICE when associating a pointer to void (c_ptr) by looking at the
compatibility of the type hierarchy.

	PR fortran/118789

gcc/fortran/ChangeLog:

	* trans-stmt.cc (trans_associate_var): Compare pointed to types when
	expr to associate is already a pointer.

gcc/testsuite/ChangeLog:

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

i386: Treat Granite Rapids/Granite Rapids-D/Diamond Rapids similar as Sapphire Rapids in x86-tune.def

Since GNR, GNR-D, DMR are both P-core based, we should treat them
just like SPR for now.

gcc/ChangeLog:

	* config/i386/x86-tune.def
	(X86_TUNE_DEST_FALSE_DEP_FOR_GLC): Add GNR, GNR-D, DMR.
	(X86_TUNE_AVOID_256FMA_CHAINS): Ditto.
	(X86_TUNE_AVX512_MOVE_BY_PIECES): Ditto.
	(X86_TUNE_AVX512_STORE_BY_PIECES): Ditto.

During reading of this file I've noticed a typo in the comment, which
this patch fixes.

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

	* gimple-range-phi.cc (phi_analyzer::process_phi): Fix comment typo,
	dpoesn;t -> doesn't.

Some of the plugin.exp tests FAIL in --enable-checking=release builds while
they succeed in --enable-checking=yes builds.
Initially I've changed some small simple out of line methods into inline ones
in the header, but the tests kept failing, just with different symbols.

The _ZN22simple_diagnostic_path9add_eventEmP9tree_nodeiPKcz symbol (and the
others too) are normally emitted in simple-diagnostic-path.o, it isn't some
fancy C++ optimization of classes with final method or LTO optimization.

The problem is that simple-diagnostic-path.o is like most objects added into
libbackend.a and we then link libbackend.a without -Wl,--whole-archive ...
-Wl,--no-whole-archive around it (and can't easily, not all system compilers
and linkers will support that).
With --enable-checking=yes simple-diagnostic-path.o is pulled in, because
selftest-run-tests.o calls simple_diagnostic_path_cc_tests and so
simple-diagnostic-path.o is linked in.
With --enable-checking=release self-tests aren't done and nothing links in
simple-diagnostic-path.o, because nothing in the compiler proper needs
anything from it, only the plugin tests.

Using -Wl,-M on cc1 linking, I see that in --enable-checking=release
build
analyzer/analyzer-selftests.o
digraph.o
dwarf2codeview.o
fibonacci_heap.o
function-tests.o
hash-map-tests.o
hash-set-tests.o
hw-doloop.o
insn-peep.o
lazy-diagnostic-path.o
options-urls.o
ordered-hash-map-tests.o
pair-fusion.o
print-rtl-function.o
resource.o
rtl-tests.o
selftest-rtl.o
selftest-run-tests.o
simple-diagnostic-path.o
splay-tree-utils.o
typed-splay-tree.o
vmsdbgout.o
aren't linked into cc1 (the *test* for obvious reasons of not doing
selftests, pair-fusion.o because it is aarch64 specific, hw-doloop.o because
x86 doesn't have doloop opts, vmsdbgout.o because not on VMS).

So, the question is if and what from digraph.o, fibinacci_heap.o,
hw-doloop.o, insn-peep.o, lazy-diagnostic-path.o, options-urls.o,
pair-fusion.o, print-rtl-function.o, resource.o, simple-diagnostic-path.o,
splay-tree-utils.o, typed-splay-tree.o are supposed to be part of the
plugin API if anything and how we arrange for those to be linked in when
plugins are enabled.

The following patch just adds unconditionally the
{simple,lazy}-diagnostic-path.o objects to the link lines before libbackend.a
so that their content is available to plugin users.

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

	PR testsuite/116143
	* Makefile.in (EXTRA_BACKEND_OBJS): New variable.
	(BACKEND): Use it before libbackend.a.

This PR is about ubsan error on the c - cx1 + cy1 evaluation in the first
hunk.

The following patch hopefully fixes that by doing the additions/subtractions
in poly_offset_int rather than poly_int64 and then converting back to poly_int64.
If it doesn't fit, -1 is returned (which means it is unknown if there is a conflict
or not).

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

	PR middle-end/118819
	* alias.cc (memrefs_conflict_p): Perform arithmetics on c, xsize and
	ysize in poly_offset_int and return -1 if it is not representable in
	poly_int64.

	PR libstdc++/118083

libstdc++-v3/ChangeLog:

	* include/bits/ranges_base.h
	(ranges::__access::__possibly_const_range): Mention LWG 4027.