libstdc++-v3/ChangeLog:

	* include/debug/safe_local_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS):
	Add parentheses to avoid -Wparentheses warning.

Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g.  std::copy(first, last, first) which
violates the preconditions for the algorithms.

This fix simply returns early if there's nothing to insert. Most callers
already ensure that we don't even call _M_range_insert_aux with an empty
range, but some callers don't. Rather than checking for n == 0 in each
of the callers, this just does the check once and uses __builtin_expect
to treat empty insertions as unlikely.

libstdc++-v3/ChangeLog:

	PR libstdc++/118035
	* include/bits/deque.tcc (_M_range_insert_aux): Return
	immediately if inserting an empty range.
	* testsuite/23_containers/deque/modifiers/insert/118035.cc: New
	test.

PR c/26154 is one of our oldest documentation issues.  The only
discussion of OpenMP support in the GCC manual is buried in the "C
Dialect Options" section, with nothing at all under "Extensions".  The
Fortran manual does have separate sections for OpenMP and OpenACC
extensions so I have copy-edited/adapted that text for similar sections
in the GCC manual, as well as breaking out the OpenMP and OpenACC options
into their own section (they apply to all of C, C++, and Fortran).

I also updated the information about what versions of OpenMP and
OpenACC are supported and removed some redundant text from the Fortran
manual to prevent it from getting out of sync on future updates, and
inserted some cross-references to the new sections elsewhere.

gcc/c-family/ChangeLog
	PR c/26154
	* c.opt.urls: Regenerated.

gcc/ChangeLog
	PR c/26154
	* common.opt.urls: Regenerated.
	* doc/extend.texi (C Extensions): Adjust menu for new sections.
	(Attribute Syntax): Mention OpenMP directives.
	(Pragmas): Mention OpenMP and OpenACC directives.
	(OpenMP): New section.
	(OpenACC): New section.
	* doc/invoke.texi (Invoking GCC): Adjust menu for new section.
	(Option Summary): Move OpenMP and OpenACC options to their own
	category.
	(C Dialect Options): Move documentation for -foffload, -fopenacc,
	-fopenacc-dim, -fopenmp, -fopenmd-simd, and
	-fopenmp-target-simd-clone to...
	(OpenMP and OpenACC Options): ...this new section.  Light
	copy-editing of the option descriptions.

gcc/fortran/ChangeLog:
	PR c/26154
	* gfortran.texi (Standards): Remove redundant info about
	OpenMP/OpenACC standard support.
	(OpenMP): Copy-editing and update version info.
	(OpenACC): Likewise.
	* lang.opt.urls: Regenerated.

The generic expand_vector_piecewise routine supports lowering of
a vector operation to vector operations of smaller size.  When
computing the extract position from the larger vector it uses the
element size in bits of the original result vector to determine
the number of elements in the smaller vector.  That is wrong when
lowering a compare as the vector element size of a bool vector
does not have to agree with that of the compare operand.  The
following simplifies this, fixing the error.

	PR middle-end/118062
	* tree-vect-generic.cc (expand_vector_piecewise): Properly
	compute delta.

This crash started with my r12-7803 but I believe the problem lies
elsewhere.

build_vec_init has cleanup_flags whose purpose is -- if I grok this
correctly -- to avoid destructing an object multiple times.  Let's
say we are initializing an array of A.  Then we might end up in
a scenario similar to initlist-eh1.C:

  try
    {
      call A::A in a loop
      // #0
      try
        {
	  call a fn using the array
	}
      finally
	{
	  // #1
	  call A::~A in a loop
	}
    }
  catch
    {
      // #2
      call A::~A in a loop
    }

cleanup_flags makes us emit a statement like

  D.3048 = 2;

at #0 to disable performing the cleanup at #2, since #1 will take
care of the destruction of the array.

But if we are not emitting the loop because we can use a constant
initializer (and use a single { a, b, ...}), we shouldn't generate
the statement resetting the iterator to its initial value.  Otherwise
we crash in gimplify_var_or_parm_decl because it gets the stray decl
D.3048.

	PR c++/117985

gcc/cp/ChangeLog:

	* init.cc (build_vec_init): Pop CLEANUP_FLAGS if we're not
	generating the loop.

gcc/testsuite/ChangeLog:

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

The patch optimizes code generation for comparisons of the form
X & C1 == C2 by converting them to (X | ~C1) == (C2 | ~C1).
C1 is a constant that requires li and addi to be loaded,
while ~C1 requires a single lui instruction.
As the values of C1 and C2 are not visible within
the equality expression, a plus pattern is matched instead.

      PR target/114087

gcc/ChangeLog:

	* config/riscv/riscv.md (*lui_constraint<ANYI:mode>_and_to_or): New pattern

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/pr114087-1.c: New test.

There should be no svvptc in the riscv-ext-bitmask.def file since it has
not yet been added to the RISC-V C API Specification or the Linux
hwprobe. And there is no need for userspace software to know that this
extension exists. So remove it from the riscv-ext-bitmask.def file.

Fixes: e4f4b2dc ("RISC-V: Minimal support for svvptc extension.")
Signed-off-by: Yangyu Chen <cyy@cyyself.name>

gcc/ChangeLog:

	* common/config/riscv/riscv-ext-bitmask.def (RISCV_EXT_BITMASK): Remove svvptc.

Test fails for Cortex-M0 with:

.../pr81812.C:6:8: error: generic thunk code fails for method 'virtual void ChildNode::_ZTv0_n12_NK9ChildNode5errorEz(...) const' which uses '...'

According to PR108277, it's expected that thumb1 targets does not
support empty virtual functions with ellipsis.

gcc/testsuite/ChangeLog:

	* g++.dg/torture/pr81812.C: Add xfail for thumb1.

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

This adds the Tenstorrent Ascalon 8 wide architecture (tt-ascalon-d8)
to the list of known cores.

gcc/ChangeLog:

	* config/riscv/riscv-cores.def: Add tt-ascalon-d8.
	* config/riscv/riscv.cc (tt_ascalon_d8_tune_info): New.
	* doc/invoke.texi (RISC-V): Add tt-ascalon-d8 to -mcpu.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/mcpu-tt-ascalon-d8.c: New test.

gcc/ChangeLog
	* doc/invoke.texi (RISC-V): Add thead-c906, xiangshan-nanhu to
	-mcpu, add generic-ooo and remove thead-c906 from -mtune.

Fixes Linaro CI reported regression on r15-6164-gbdf75257aad2 in
https://linaro.atlassian.net/browse/GNU-1463

.

gcc/testsuite/ChangeLog:

	* lib/target-supports.exp: Added corresponding -mtune= option
	for each fo the arm_cpu_* effective targets.

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

Although this constraint is not currently used for any instructions, it is very
useful for custom instructions. Additionally, some new standard extensions
(not yet upstream), such as `Zilsd` and `Zclsd`, are potential users of this
constraint. Therefore, I believe there is sufficient justification to add it
now.

gcc/ChangeLog:

	* config/riscv/constraints.md (R): New constraint.
	* doc/md.texi: Document new constraint `R`.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/constraint-R.c: New.

The modifier `N`, to print the raw encoding of a register. This is used
when using `.insn <length>, <encoding>`, where the user wants to pass
a value to the instruction in a known register, but where the
instruction doesn't follow the existing instruction formats, so the
assembly parser is not expecting a register name, just a raw integer.

gcc/ChangeLog:

	* config/riscv/riscv.cc (riscv_print_operand): Add N.
	* doc/extend.texi: Document for N,

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/modifier-N-fpr.c: New.
	* gcc.target/riscv/modifier-N-vr.c: New.
	* gcc.target/riscv/modifier-N.c: New.

Here is a purposal that using N for printing register encoding number,
so let rename the existing internal operand modifier `N` to `n`.

gcc/ChangeLog:

	* config/riscv/corev.md (*cv_branch<mode>): Update modifier.
	(*branch<mode>): Ditto.
	* config/riscv/riscv.cc (riscv_print_operand): Update modifier.
	* config/riscv/riscv.md (*branch<mode>): Update modifier.

gcc/ChangeLog:

	* config/riscv/constraints.md (cr): New.
	(cf): New.
	* config/riscv/riscv.h (reg_class): Add RVC_GR_REGS and
	RVC_FP_REGS.
	(REG_CLASS_NAMES): Ditto.
	(REG_CLASS_CONTENTS): Ditto.
	* doc/md.texi: Document cr and cf constraint.
	* config/riscv/riscv.cc (riscv_regno_to_class): Update
	FP_REGS to RVC_FP_REGS since it smaller set.
	(riscv_secondary_memory_needed): Handle RVC_FP_REGS.
	(riscv_register_move_cost): Ditto.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/constraint-cf-zfinx.c: New.
	* gcc.target/riscv/constraint-cf.c: New.
	* gcc.target/riscv/constraint-cr.c: New.

Rename those constraint since we want define other constraint start with
`c`, those constraints are internal and undocumented, so it's fine to
rename.

gcc/ChangeLog:

	* config/riscv/constraints.md (c01): Rename to...
	(k01): ...this.
	(c02): Rename to...
	(k02): ...this.
	(c03): Rename to...
	(k03): ...this.
	(c04): Rename to...
	(k04): ...this.
	(c08): Rename to...
	(k08): ...this.
	* config/riscv/corev.md (riscv_cv_simd_add_h_si): Update
	constraints.
	(riscv_cv_simd_sub_h_si): Ditto.
	(riscv_cv_simd_cplxmul_i_si): Ditto.
	(riscv_cv_simd_subrotmj_si): Ditto.
	* config/riscv/riscv-v.cc (splat_to_scalar_move_p): Update
	constraints.
	* config/riscv/vector-iterators.md (stride_load_constraint):
	Update constraints.
	(stride_store_constraint): Ditto.

I believe that the current function ipa_range_set_and_normalize lacks
a check that a base of an ADDR_EXPR lacks a test whether the base
really cannot be NULL, so this patch adds it.  Moreover, I never liked
the name as I do not think it makes the value of ranges any more
normal but rather just special-cases non-zero ip_invariant pointers.
Therefore, I have given it a different name and moved it to a .cc
file, our LTO bootstrap should inline (and/or split) it if necessary
anyway.

Because, as Honza correctly pointed out, deriving non-NULLness from a
pointer depends on flag_delete_null_pointer_checks which is an
optimization flag and thus depends on a given function, in this
version of the patch ipa_get_range_from_ip_invariant gets a
context_node parameter for that purpose.  This then needs to be used
within symtab_node::nonzero_address which gets a special overload in
which the value of the flag can be provided as a parameter.

gcc/ChangeLog:

2024-12-11  Martin Jambor  <mjambor@suse.cz>

	* cgraph.h (symtab_node): Add a new overload of nonzero_address.
	* symtab.cc (symtab_node::nonzero_address): Add a new overload whith a
	parameter for delete_null_pointer_checks.  Make the original overload
	call the new one which has retains the actual implementation.
	* ipa-prop.h (ipa_get_range_from_ip_invariant): Declare.
	(ipa_range_set_and_normalize): Remove.
	* ipa-prop.cc (ipa_get_range_from_ip_invariant): New function.
	(ipa_range_set_and_normalize): Remove.
	* ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Add a new parameter
	context_node. Use ipa_get_range_from_ip_invariant instead of
	ipa_range_set_and_normalize and pass to it the new parameter.
	(ipa_value_range_from_jfunc): Pass cs->caller as the context_node to
	ipa_vr_intersect_with_arith_jfunc.
	(propagate_vr_across_jump_function): Likewise.
	(ipa_get_range_from_ip_invariant): New function.
	* ipa-fnsummary.cc (evaluate_conditions_for_known_args): Use
	ipa_get_range_from_ip_invariant instead of ipa_range_set_and_normalize

When looking into cases where we know an actual argument of a call is
a constant but we don't generate a singleton value-range for the jump
function, I found out that the special handling of pointer constants
does not work well for constant zero pointer values.  In fact the code
only attempts to see if it can figure out that an argument is not zero
and if it can figure out any alignment information.

With this patch, we try to use the value_range that ranger can give us
in the jump function if we can and we query ranger for all kinds of
arguments, not just SSA_NAMES (and so also pointer integer constants).
If we cannot figure out a useful range we fall back again on figuring
out non-NULLness with tree_single_nonzero_warnv_p.

With this patch, we generate

  [prange] struct S * [0, 0] MASK 0x0 VALUE 0x0

instead of for example:

  [prange] struct S * [0, +INF] MASK 0xfffffffffffffff0 VALUE 0x0

for a zero constant passed in a call.

If you are wondering why we check whether the value range obtained
from range_of_expr can be undefined, even when the function returns
true, that is because that can apparently happen fro default-definition
SSA_NAMEs.

gcc/ChangeLog:

2024-11-15  Martin Jambor  <mjambor@suse.cz>

	* ipa-prop.cc (ipa_compute_jump_functions_for_edge): Try harder to
	use the value range obtained from ranger for pointer values.

Originally, we did not stream any formal parameter types into WPA and
were generally very conservative when it came to type mismatches in
IPA-CP.  Over the time, mismatches that happen in code and blew up in
WPA made us to be much more resilient and also to stream the types of
the parameters which we now use commonly.

With that information, we can safely skip conversions when looking at
the IL from which we build jump functions and then simply fold convert
the constants and ranges to the resulting type, as long as we are
careful that performing the corresponding folding of constants gives
the corresponding results.  In order to do that, we must ensure that
the old value can be represented in the new one without any loss.
With this change, we can nicely propagate non-NULLness in IPA-VR as
demonstrated with the new test case.

I have gone through all other uses of (all components of) jump
functions which could be affected by this and verified they do indeed
check types and can handle mismatches.

gcc/ChangeLog:

2024-12-11  Martin Jambor  <mjambor@suse.cz>

	* ipa-prop.cc: Include vr-values.h.
	(skip_a_safe_conversion_op): New function.
	(ipa_compute_jump_functions_for_edge): Use it.

gcc/testsuite/ChangeLog:

2024-11-01  Martin Jambor  <mjambor@suse.cz>

	* gcc.dg/ipa/vrp9.c: New test.

In r10-6457 aka PR92593 fix a check has been added to reject
earlier non-static data members with current_class_type in templates,
as the deduction then can result in endless recursion in reshape_init.
It fixed the
template <class T>
struct S { S s = 1; };
S t{2};
crashes, but as the following testcase shows, didn't catch when there
are cv qualifiers on the non-static data member.

Fixed by using TYPE_MAIN_VARIANT.

2024-12-17  Jakub Jelinek  <jakub@redhat.com>

	PR c++/116108
gcc/cp/
	* decl.cc (grokdeclarator): Pass TYYPE_MAIN_VARIANT (type)
	rather than type to same_type_p when checking if the non-static
	data member doesn't have current class type.
gcc/testsuite/
	* g++.dg/cpp1z/class-deduction117.C: New test.

gcc/fortran/ChangeLog:

	PR fortran/117347

	* primary.cc (gfc_match_varspec): Add array constructors for
	guessing their type like with unresolved function calls.

gcc/testsuite/ChangeLog:

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

	* sr.po: Update.

gcc/ChangeLog:

	* config/i386/mmx.md: Fix tabs vs. spaces.

Move explicit Himode handling for SSE2 XMM regnos from
ix86_hard_regno_mode_ok to VALID_SSE2_REG_MODE.

No functional change.

gcc/ChangeLog:

	* config/i386/i386.cc (ix86_hard_regno_mode_ok):
	Remove explicit HImode handling for SSE2 XMM regnos.
	* config/i386/i386.h (VALID_SSE2_REG_MODE): Add HImode.