* sv.po: Update.

During backporting I've noticed I've missed one return spot for the
restoration of the original flag_trapv flag value.

2024-04-19  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/114753
	* internal-fn.cc (expand_arith_overflow): Add one missing restore
	of flag_trapv before return.

Hi All,

As the reporter in PR114769 points out the control flow for the abd detection
is hard to follow.  This is because vect_recog_absolute_difference has two
different ways it can return true.

1. It can return true when the widening operation is matched, in which case
   unprom is set, half_type is not NULL and diff_stmt is not set.

2. It can return true when the widening operation is not matched, but the stmt
   being checked is a minus.  In this case unprom is not set, half_type is set
   to NULL and diff_stmt is set.  This because to get to diff_stmt you have to
   dig through the abs statement and any possible promotions.

This however leads to complicated uses of the function at the call sites as the
exact semantic needs to be known to use it safely.

vect_recog_absolute_difference has two callers:

1. vect_recog_sad_pattern where if you return true with unprom not set, then
   *half_type will be NULL.  The call to vect_supportable_direct_optab_p will
   always reject it since there's no vector mode for NULL.  Note that if looking
   at the dump files, the convention in the dump files have always been that we
   first indicate that a pattern could possibly be recognize and then check that
   it's supported.

   This change somewhat incorrectly makes the diagnostic message get printed for
   "invalid" patterns.

2. vect_recog_abd_pattern, where if half_type is NULL, it then uses diff_stmt to
   set them.

This refactors the code, it now only has 1 success condition, and diff_stmt is
always set to the minus statement in the abs if there is one.

The function now only returns success if the widening minus is found, in which
case unprom and half_type set.

This then leaves it up to the caller to decide if they want to do anything with
diff_stmt.

Thanks,
Tamar

gcc/ChangeLog:

	PR tree-optimization/114769
	* tree-vect-patterns.cc:
	(vect_recog_absolute_difference): Have only one success condition.
	(vect_recog_abd_pattern): Handle further checks if
	vect_recog_absolute_difference fails.

Follow-up to commit 9f295847
"rtlanal: Fix set_noop_p for volatile loads or stores [PR114768]": nvptx does
behave in the exactly same way as expected; see 'diff' of before vs. after the
'gcc/rtlanal.cc' code changes:

    PASS: gcc.dg/pr114768.c (test for excess errors)
    [-FAIL:-]{+PASS:+} gcc.dg/pr114768.c scan-rtl-dump final "\\(mem/v:"

    --- 0/pr114768.c.347r.final	2024-04-19 11:34:34.577037596 +0200
    +++ ./pr114768.c.347r.final	2024-04-19 12:08:00.118312524 +0200
    @@ -13,15 +13,27 @@
     ;;  entry block defs 	 1 [%stack] 2 [%frame] 3 [%args]
     ;;  exit block uses 	 1 [%stack] 2 [%frame]
     ;;  regs ever live
    -;;  ref usage 	r1={1d,2u} r2={1d,2u} r3={1d,1u}
    -;;    total ref usage 8{3d,5u,0e} in 1{1 regular + 0 call} insns.
    +;;  ref usage 	r1={1d,3u} r2={1d,3u} r3={1d,2u} r22={1d,1u} r23={1d,2u}
    +;;    total ref usage 16{5d,11u,0e} in 4{4 regular + 0 call} insns.
     (note 1 0 4 NOTE_INSN_DELETED)
     (note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
    -(note 2 4 3 2 NOTE_INSN_DELETED)
    +(insn 2 4 3 2 (set (reg/v/f:DI 23 [ p ])
    +        (unspec:DI [
    +                (const_int 0 [0])
    +            ] UNSPEC_ARG_REG)) "source-gcc/gcc/testsuite/gcc.dg/pr114768.c":8:1 14 {load_arg_regdi}
    +     (nil))
     (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
    -(note 6 3 10 2 NOTE_INSN_DELETED)
    -(note 10 6 11 2 NOTE_INSN_EPILOGUE_BEG)
    -(jump_insn 11 10 12 2 (return) "source-gcc/gcc/testsuite/gcc.dg/pr114768.c":10:1 289 {return}
    +(insn 6 3 7 2 (set (reg:SI 22 [ _1 ])
    +        (mem/v:SI (reg/v/f:DI 23 [ p ]) [1 MEM[(volatile int *)p_3(D)]+0 S4 A32])) "source-gcc/gcc/testsuite/gcc.dg/pr114768.c":9:8 6 {*movsi_insn}
    +     (nil))
    +(insn 7 6 10 2 (set (mem:SI (reg/v/f:DI 23 [ p ]) [1 *p_3(D)+0 S4 A32])
    +        (reg:SI 22 [ _1 ])) "source-gcc/gcc/testsuite/gcc.dg/pr114768.c":9:6 6 {*movsi_insn}
    +     (expr_list:REG_DEAD (reg/v/f:DI 23 [ p ])
    +        (expr_list:REG_DEAD (reg:SI 22 [ _1 ])
    +            (nil))))
    +(note 10 7 13 2 NOTE_INSN_EPILOGUE_BEG)
    +(note 13 10 11 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
    +(jump_insn 11 13 12 3 (return) "source-gcc/gcc/testsuite/gcc.dg/pr114768.c":10:1 289 {return}
	  (nil)
      -> return)
     (barrier 12 11 0)

    --- 0/pr114768.s	2024-04-19 11:34:34.577037596 +0200
    +++ ./pr114768.s	2024-04-19 12:08:00.118312524 +0200
    @@ -13,5 +13,10 @@
     {
	.reg.u64 %ar0;
	ld.param.u64 %ar0, [%in_ar0];
    +	.reg.u32 %r22;
    +	.reg.u64 %r23;
    +		mov.u64	%r23, %ar0;
    +		ld.u32	%r22, [%r23];
    +		st.u32	[%r23], %r22;
	ret;
     }

	PR testsuite/114768
	gcc/testsuite/
	* gcc.dg/pr114768.c: Enable for nvptx target.

The BPF backend was allocating an unnecessarily large string when
constructing CO-RE relocations for enum types.
This patch also verifies that those enumerators are valid for CO-RE,
returning an error otherwise.

gcc/ChangeLog:
	* config/bpf/core-builtins.cc (get_index_for_enum_value): Create
	function.
	(pack_enum_value): Check for enumerator and error out.
	(process_enum_value): Correct string allocation.

BPF supports multiple instructions to be CO-RE relocatable regardless of
the position of the immediate field in the encoding.
In particular, not only the MOV instruction allows a CO-RE
relocation of its immediate operand, but the LD and ST instructions can
have a CO-RE relocation happening to their offset immediate operand,
even though those operands are encoded in different encoding bits.
This patch moves matching from a more traditional matching of the
UNSPEC_CORE_RELOC pattern within a define_insn to a match within the
constraints of both immediates and address operands from more generic
mov define_insn rule.

gcc/Changelog:
	* config/bpf/bpf-protos.h (bpf_add_core_reloc): Renamed function
	to bpf_output_move.
	* config/bpf/bpf.cc (bpf_legitimate_address_p): Allow
	UNSPEC_CORE_RELOC to match an address.
	(bpf_insn_cost): Make UNSPEC_CORE_RELOC immediate moves
	expensive to prioritize loads and stores.
	(TARGET_INSN_COST): Add hook.
	(bpf_output_move): Wrapper to call bpf_output_core_reloc.
	(bpf_print_operand): Add support to print immediate operands
	specified with the UNSPEC_CORE_RELOC.
	(bpf_print_operand_address): Likewise, but to support
	UNSPEC_CORE_RELOC in addresses.
	(bpf_init_builtins): Flag BPF_BUILTIN_CORE_RELOC as NOTHROW.
	* config/bpf/bpf.md: Wrap patterns for MOV, LD and ST
	instruction with bpf_output_move call.
	(mov_reloc_core<MM:mode>): Remove now spurious define_insn.
	* config/bpf/constraints.md: Added "c" and "C" constraints to
	match immediates represented with UNSPEC_CORE_RELOC.
	* config/bpf/core-builtins.cc (bpf_add_core_reloc): Remove
	(bpf_output_core_reloc): Add function to create the CO-RE
	relocations based on new matching rules.
	* config/bpf/core-builtins.h (bpf_output_core_reloc): Add
	prototype.
	* config/bpf/predicates.md (core_imm_operand) Add predicate.
	(mov_src_operand): Add match for core_imm_operand.

gcc/testsuite/ChangeLog:
	* gcc.target/bpf/btfext-funcinfo.c: Updated to changes.
	* gcc.target/bpf/core-builtin-fieldinfo-const-elimination.c:
	Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-existence-1.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-be.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-lshift-1-le.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-lshift-2.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-offset-1.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-rshift-1.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-rshift-2.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-sign-1.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-sign-2.c: Likewise.
	* gcc.target/bpf/core-builtin-fieldinfo-size-1.c: Likewise.

	PR d/111650

gcc/d/ChangeLog:

	* decl.cc (get_fndecl_arguments): Move generation of frame type to ...
	(DeclVisitor::visit (FuncDeclaration *)): ... here, after the call to
	build_closure.

gcc/testsuite/ChangeLog:

	* gdc.dg/pr111650.d: New test.

On the following testcase, combine propagates the mem/v load into mem store
with the same address and then removes it, because noop_move_p says it is a
no-op move.  If it was the other way around, i.e. mem/v store and mem load,
or both would be mem/v, it would be kept.
The problem is that rtx_equal_p never checks any kind of flags on the rtxes
(and I think it would be quite dangerous to change it at this point), and
set_noop_p checks side_effects_p on just one of the operands, not both.
In the MEM <- MEM set, it only checks it on the destination, in
store to ZERO_EXTRACT only checks it on the source.

The following patch adds the missing side_effects_p checks.

2024-04-19  Jakub Jelinek  <jakub@redhat.com>

	PR rtl-optimization/114768
	* rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM
	sets if src has side-effects or for stores into ZERO_EXTRACT
	if ZERO_EXTRACT operand has side-effects.

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

The following testcase is miscompiled because the code to decrement
vn on negative value with all ones in most significant limb (even partial)
and 0 in most significant bit of the second most significant limb doesn't
take into account the case where all bits below the most significant limb
are zero.  This has been a problem both in the version before yesterday's
commit where it has been done only if un was one shorter than vn before this
decrement, and is now problem even more often when it is done earlier.
When we decrement vn in such case and negate it, we end up with all 0s in
the v2 value, so have both the problems with UB on __builtin_clz* and the
expectations of the algorithm that the divisor has most significant bit set
after shifting, plus when the decremented vn is 1 it can SIGFPE on division
by zero even when it is not division by zero etc.  Other values shouldn't
get 0 in the new most significant limb after negation, because the
bitint_reduce_prec canonicalization should reduce prec if the second most
significant limb is all ones and if that limb is all zeros, if at least
one limb below it is non-zero, carry in will make it non-zero.

The following patch fixes it by checking if at least one bit below the
most significant limb is non-zero, in that case it decrements, otherwise
it will do nothing (but e.g. for the un < vn case that also means the
divisor is large enough that the result should be q 0 r u).

2024-04-18  Jakub Jelinek  <jakub@redhat.com>

	PR libgcc/114762
	* libgcc2.c (__divmodbitint4): Perform the decrement on negative
	v with most significant limb all ones and the second least
	significant limb with most significant bit clear always, regardless of
	un < vn.

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

The mangling of the macro name that guards limits.h from reinclusion
was mangling a c23-required macro as well.  Make the edit pattern
stricter.


for  gcc/ChangeLog

	* config/t-vxworks (vxw-glimits.h): Don't mangle c23-required
	__STDC_VERSION_LIMITS_H__ define.

This patch marks the nios2*-*-* targets obsolete in GCC 14.  Intel has
EOL'ed this architecture and the maintainers no longer have access to
hardware for testing.  While the port is still in reasonably good
shape at this time, no further testing or updates are planned.

gcc/
	* config.gcc: Add nios2*-*-* to the list of obsoleted targets.

contrib/
	* config-list.mk (LIST): --enable-obsolete for nios2*-*-*.

2024-04-18  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
	PR fortran/114739
	* primary.cc (gfc_match_varspec): Check for default type before
	checking for derived types with the right component name.

gcc/testsuite/
	PR fortran/114739
	* gfortran.dg/pr114739.f90: New test.
	* gfortran.dg/derived_comp_array_ref_8.f90: Add 'implicit none'
	for consistency with expected error message.
	* gfortran.dg/nullify_4.f90: ditto
	* gfortran.dg/pointer_init_6.f90: ditto
	* gfortran.dg/pr107397.f90: ditto
	* gfortran.dg/pr88138.f90: ditto

Without -msse2, an i586-targeting toolchain fails bf16_short_warn.c
because neither type __m128bh nor intrinsic _mm_cvtneps_pbh get
declared.


for  gcc/testsuite/ChangeLog

	* gcc.target/i386/bf16_short_warn.c: Add -msse2.

A few x86 tests get unexpected insn counts if the toolchain is
configured with --enable-frame-pointer.  Add explicit
-fomit-frame-pointer so that the expected insn sequences are output.


for  gcc/testsuite/ChangeLog

	* gcc.target/i386/pr107261.c: Add -fomit-frame-pointer.
	* gcc.target/i386/pr69482-1.c: Likewise.
	* gcc.target/i386/pr69482-2.c: Likewise.

Complete r13-2205, adjusting an arm-specific test that expects a
no-longer-issued error at an empty initializer.


for  gcc/testsuite/ChangeLog

	* gcc.target/arm/bfloat16_scalar_typecheck.c: Accept C23
	empty initializers.

The test expected the address of a literal string, converted to long
long, to yield a positive value.  That expectation doesn't necessarily
hold, and the test fails where it doesn't.

Adjust the test to use a pointer that will compare as expected.

for  gcc/testsuite/ChangeLog

	* g++.dg/contracts/contracts9.C: Don't assume string literals
	have non-negative addresses.

Co-authored-by: Olivier Hainque <hainque@adacore.com>

for  gcc/testsuite/ChangeLog

	* gcc.target/aarch64/pr94201.c: Add missing
	dg-require-effective-target fpic.
	* gcc.target/aarch64/pr103085.c: Likewise.

Fix another test that uses -fPIC without requiring fpic support.


for  gcc/testsuite/ChangeLog

	* g++.target/i386/pr111497.C: Require fpic support.

pr103798-2.c fails in C++ on targets that provide a ISO C++-compliant
declaration of memchr, because it mismatches the C-compatible builtin,
as per PR113706.  Expect the C++ test to fail on vxworks as well.


for  gcc/testsuite/ChangeLog

	PR testsuite/113706
	* c-c++-common/pr103798-2.c: XFAIL in C++ on vxworks too.

Test that calls select fails on vxworks because select is only
declared in sys/select.h.  Include that header if it's present.


for  gcc/testsuite/ChangeLog

	* gcc.dg/analyzer/fd-glibc-byte-stream-connection-server.c:
	Include sys/select.h if present.

Mark tests that fail due to the lack of fork, as in vxworks kernel
mode, as requiring fork.


for  gcc/testsuite/ChangeLog

	* gcc.dg/analyzer/pipe-glibc.c: Require fork.
	* gcc.dg/analyzer/pipe-manpages.c: Likewise.

O_ACCMODE is not defined on vxworks, and the test is meaningless and
failing without it, so skip it.


for  gcc/testsuite/ChangeLog

	* gcc.dg/analyzer/fd-access-mode-target-headers.c: Skip on
	vxworks as well.

Define macro that prevents mode_t from being defined by vxworks'
headers as well.


for  gcc/testsuite/ChangeLog

	* gcc.dg/analyzer/fd-4.c: Define macro to avoid mode_t on
	vxworks.

A number of tests that call strndup fail on vxworks, where there's no
strndup.  Some of them already had workarounds to skip the strndup
parts of the tests on platforms that don't offer it.  I've changed
them to rely on a strndup effective target instead, and extended the
logic to other tests that were otherwise skipped entirely.


for  gcc/ChangeLog

	* doc/sourcebuild.texi (strndup): Add effective target.

for  gcc/testsuite/ChangeLog

	* lib/target-supports.exp (check_effective_target_strndup): New.
	* gcc.dg/builtin-dynamic-object-size-0.c: Skip strndup tests
	when the function is not available.
	* gcc.dg/builtin-dynamic-object-size-1.c: Likewise.
	* gcc.dg/builtin-dynamic-object-size-2.c: Likewise.
	* gcc.dg/builtin-dynamic-object-size-3.c: Likewise.
	* gcc.dg/builtin-dynamic-object-size-4.c: Likewise.
	* gcc.dg/builtin-object-size-1.c: Likewise.
	* gcc.dg/builtin-object-size-2.c: Likewise.
	* gcc.dg/builtin-object-size-3.c: Likewise.
	* gcc.dg/builtin-object-size-4.c: Likewise.

On arm-vx7r2, the uses of as.load() as initializer get SRAed, so the
padding bits in the tests are not what we might expect from full-word
struct copies.

I tried adding a function to perform bitwise copying, but even taking
the as.load() argument by const&, we'd still construct a temporary
with SRAed field-wise copying.  Unable to find another way to ensure
we wouldn't get a temporary, I went for disabling SRA.


for  libstdc++-v3/ChangeLog

	* testsuite/29_atomics/atomic/compare_exchange_padding.cc:
	Disable SRA.

Tests 20_util/from_chars/4.cc and 20_util/to_chars/long_double.cc were
adjusted about a year ago to skip long double on some targets, because
the fastfloat library was limited to 64-bit doubles.

The same problem comes up in similar float128_t tests on
aarch64-vxworks.  This patch adjusts them similarly.

Unlike the earlier tests, that got similar treatment for
x86_64-vxworks, these haven't failed there.


for  libstdc++-v3/ChangeLog

	* testsuite/20_util/from_chars/8.cc: Skip float128_t testing
	on aarch64-vxworks.
	* testsuite/20_util/to_chars/float128_c++23.cc: Xfail run on
	aarch64-vxworks.

VxWorks fails to load kernel-mode modules with weak undefined symbols.
In RTP mode modules, that undergo final linking, weak undefined
symbols are not a problem.

This patch adds kernel-mode VxWorks multilibs to the set of targets
that don't support weak undefined symbols without special flags, in
which tzdb's zoneinfo_dir_override is given a weak definition.


for  libstdc++-v3/ChangeLog

	* src/c++20/tzdb.cc (__gnu_cxx::zoneinfo_dir_override): Define
	on VxWorks non-RTP.

In PR114741 we see that we have a regression in codegen when SVE is enable where
the simple testcase:

void foo(unsigned v, unsigned *p)
{
    *p = v & 1;
}

generates

foo:
        fmov    s31, w0
        and     z31.s, z31.s, #1
        str     s31, [x1]
        ret

instead of:

foo:
        and     w0, w0, 1
        str     w0, [x1]
        ret

This causes an impact it not just codesize but also performance.  This is caused
by the use of the ^ constraint modifier in the pattern <optab><mode>3.

The documentation states that this modifier should only have an effect on the
alternative costing in that a particular alternative is to be preferred unless
a non-psuedo reload is needed.

The pattern was trying to convey that whenever both r and w are required, that
it should prefer r unless a reload is needed.  This is because if a reload is
needed then we can construct the constants more flexibly on the SIMD side.

We were using this so simplify the implementation and to get generic cases such
as:

double negabs (double x)
{
   unsigned long long y;
   memcpy (&y, &x, sizeof(double));
   y = y | (1UL << 63);
   memcpy (&x, &y, sizeof(double));
   return x;
}

which don't go through an expander.
However the implementation of ^ in the register allocator is not according to
the documentation in that it also has an effect during coloring.  During initial
register class selection it applies a penalty to a class, similar to how ? does.

In this example the penalty makes the use of GP regs expensive enough that it no
longer considers them:

    r106: preferred FP_REGS, alternative NO_REGS, allocno FP_REGS
;;        3--> b  0: i   9 r106=r105&0x1
    :cortex_a53_slot_any:GENERAL_REGS+0(-1)FP_REGS+1(1)PR_LO_REGS+0(0)
                         PR_HI_REGS+0(0):model 4

which is not the expected behavior.  For GCC 14 this is a conservative fix.

1. we remove the ^ modifier from the logical optabs.

2. In order not to regress copysign we then move the copysign expansion to
   directly use the SIMD variant.  Since copysign only supports floating point
   modes this is fine and no longer relies on the register allocator to select
   the right alternative.

It once again regresses the general case, but this case wasn't optimized in
earlier GCCs either so it's not a regression in GCC 14.  This change gives
strict better codegen than earlier GCCs and still optimizes the important cases.

gcc/ChangeLog:

	PR target/114741
	* config/aarch64/aarch64.md (<optab><mode>3): Remove ^ from alt 2.
	(copysign<GPF:mode>3): Use SIMD version of IOR directly.

gcc/testsuite/ChangeLog:

	PR target/114741
	* gcc.target/aarch64/fneg-abs_2.c: Update codegen.
	* gcc.target/aarch64/fneg-abs_4.c: xfail for now.
	* gcc.target/aarch64/pr114741.c: New test.

The following testcase aborts on aarch64-linux but does not on x86_64-linux.
In both cases there is UB in the __divmodbitint4 implemenetation.
When the divisor is negative with most significant limb (even when partial)
all ones, has at least 2 limbs and the second most significant limb has the
most significant bit clear, when this number is negated, it will have 0
in the most significant limb.
Already in the PR114397 r14-9592 fix I was dealing with such divisors, but
thought the problem is only if because of that un < vn doesn't imply the
quotient is 0 and remainder u.
But as this testcase shows, the problem is with such divisors always.
What happens is that we use __builtin_clz* on the most significant limb,
and assume it will not be 0 because that is UB for the builtins.
Normally the most significant limb of the divisor shouldn't be 0, as
guaranteed by the bitint_reduce_prec e.g. for the positive numbers, unless
the divisor is just 0 (but for vn == 1 we have special cases).

The following patch moves the handling of this corner case a few lines
earlier before the un < vn check, because adjusting the vn later is harder.

2024-04-18  Jakub Jelinek  <jakub@redhat.com>

	PR libgcc/114755
	* libgcc2.c (__divmodbitint4): Perform the decrement on negative
	v with most significant limb all ones and the second least
	significant limb with most significant bit clear always, regardless of
	un < vn.

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

internal-fn: Temporarily disable flag_trapv during .{ADD,SUB,MUL}_OVERFLOW etc. expansion [PR114753]

__builtin_{add,sub,mul}_overflow{,_p} builtins are well defined
for all inputs even for -ftrapv, and the -fsanitize=signed-integer-overflow
ifns shouldn't abort in libgcc but emit the desired ubsan diagnostics
or abort depending on -fsanitize* setting regardless of -ftrapv.
The expansion of these internal functions uses expand_expr* in various
places (e.g. MULT_EXPR at least in 2 spots), so temporarily disabling
flag_trapv in all those spots would be hard.
The following patch disables it around the bodies of 3 functions
which can do the expand_expr calls.
If it was in the C++ FE, I'd use some RAII sentinel, but I don't think
we have one in the middle-end.

2024-04-18  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/114753
	* internal-fn.cc (expand_mul_overflow): Save flag_trapv and
	temporarily clear it for the duration of the function, then
	restore previous value.
	(expand_vector_ubsan_overflow): Likewise.
	(expand_arith_overflow): Likewise.

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

Test case builtins-6-p9-runnable.c doesn't work well on BE
due to two problems:
  - When applying vec_xl_len onto data_128 and data_u128
    with length 8, it expects to load 1280000[01] from
    the memory, but unfortunately assigning 1280000[01] to
    a {vector} {u,}int128 type variable, the value isn't
    guaranteed to be at the beginning of storage (in the
    low part of memory), which means the loaded value can
    be unexpected (as shown on BE).  So this patch is to
    introduce getU128 which can ensure the given value
    shows up as expected and also update some dumping code
    for debugging.
  - When applying vec_xl_len_r with length 16, on BE it's
    just like the normal vector load, so the expected data
    should not be reversed from the original.

	PR testsuite/114744

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/builtins-6-p9-runnable.c: Adjust for BE by fixing
	data_{u,}128, their uses and vec_uc_expected1, also adjust some formats.

gcc/testsuite/
	* gcc.target/powerpc/bcd-4.c: Enable the case to be tested on P9.
	Enable the case to be run on big endian.  Fix function maxbcd and
	other misc. problems.

This was recently approved for C++26 at the Tokyo meeting. As suggested
by Stephan T. Lavavej, I'm defining it as an extension for C++23 mode
(when std::print and std::prinln were first added) rather than as a new
C++26 feature. Both MSVC and libc++ have agreed to do this too.

libstdc++-v3/ChangeLog:

	* include/std/ostream (println(ostream&)): Define new overload.
	* include/std/print (println(FILE*), println()): Likewise.
	* testsuite/27_io/basic_ostream/print/2.cc: New test.
	* testsuite/27_io/print/1.cc: Remove unused header.
	* testsuite/27_io/print/3.cc: New test.

Starting with GCC 14 we have the nice URLification of the options printed
in diagnostics, say for in
test.c:4:23: warning: format ‘%d’ expects argument of type ‘int’, but argument 2 has type ‘long int’ [-Wformat=]
the -Wformat= is underlined in some terminals and hovering on it shows
https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wformat
link.

This works nicely on the GCC trunk, where the online documentation is
regenerated every day from a cron job and more importantly, people rarely
use the trunk snapshots for too long, so it is unlikely that further changes
in the documentation will make too many links stale, because users will
simply regularly update to newer snapshots.

I think it doesn't work properly on release branches though.
Some users only use the relased versions (i.e. MAJOR.MINOR.0) from tarballs
but can use them for a couple of years, others use snapshots from the
release branches, but again they could be in use for months or years and
the above mentioned online docs which represent just the GCC trunk might
diverge significantly.

Now, for the relases we always publish also online docs for the release,
which unlike the trunk online docs will not change further, under
e.g.
https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wformat
or
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Warning-Options.html#index-Wformat
etc.

So, I think at least for the MAJOR.MINOR.0 releases we want to use
URLs like above rather than the trunk ones and we can use the same process
of updating *.opt.urls as well for that.

For the snapshots from release branches, we don't have such docs.
One option (implemented in the patch below for the URL printing side) is
point to the MAJOR.MINOR.0 docs even for MAJOR.MINOR.1 snapshots.
Most of the links will work fine, for options newly added on the release
branches (rare thing but still happens) can have until the next release
no URLs for them and get them with the next point release.
The question is what to do about make regenerate-opt-urls for the release
branch snapshots.  Either just document that users shouldn't
make regenerate-opt-urls on release branches (and filter out *.opt.urls
changes from their commits), add make regenerate-opt-urls task be RM
responsibility before making first release candidate from a branch and
adjust the autoregen CI to know about that.  Or add a separate goal
which instead of relying on make html created files would download
copy of the html files from the last release from web (kind of web
mirroring the https://gcc.gnu.org/onlinedocs/gcc-14.1.0/ subtree locally)
and doing regenerate-opt-urls on top of that?  But how to catch the
point when first release candidate is made and we want to update to
what will be the URLs once the release is made (but will be stale URLs
for a week or so)?

Another option would be to add to cron daily regeneration of the online
docs for the release branches.  I don't think that is a good idea though,
because as I wrote earlier, not all users update to the latest snapshot
frequently, so there can be users that use gcc 13.1.1 20230525 for months
or years, and other users which use gcc 13.1.1 20230615 for years etc.

Another question is what is most sensible for users who want to override
the default root and use the --with-documentation-root-url= configure
option.  Do we expect them to grab the whole onlinedocs tree or for release
branches at least include gcc-14.1.0/ subdirectory under the root?
If so, the patch below deals with that.  Or should we just change the
default documentation root url, so if user doesn't specify
--with-documentation-root-url= and we are on a release branch, default that
to https://gcc.gnu.org/onlinedocs/gcc-14.1.0/ or
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/ etc. and don't add any infix in
get_option_url/make_doc_url, but when people supply their own, let them
point to the root of the tree which contains the right docs?
Then such changes would go into gcc/configure.ac, some case based on
"$gcc_version", from that decide if it is a release branch or trunk.

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

	PR other/114738
	* opts.cc (get_option_url): On release branches append
	gcc-MAJOR.MINOR.0/ after DOCUMENTATION_ROOT_URL.
	* gcc-urlifier.cc (gcc_urlifier::make_doc_url): Likewise.

As discussed in the PR, aclocal.m4 and configure were incorrectly
regenerated at some point.

2024-04-17  Christophe Lyon  <christophe.lyon@linaro.org>

	PR preprocessor/114748
	libcpp/
	* aclocal.m4: Regenerate.
	* configure: Regenerate.

The following makes sure to reset LOOP_VINFO_USING_PARTIAL_VECTORS_P
to its default of false when re-trying without SLP as otherwise
analysis may run into bogus asserts.

	PR tree-optimization/114749
	* tree-vect-loop.cc (vect_analyze_loop_2): Reset
	LOOP_VINFO_USING_PARTIAL_VECTORS_P when re-trying without SLP.

... as made apparent by a number of unexpectedly UNSUPPORTED test cases, which
now all turn into PASS, with just one exception:

    PASS: gcc.dg/vect/vect-early-break_124-pr114403.c (test for excess errors)
    PASS: gcc.dg/vect/vect-early-break_124-pr114403.c execution test
    FAIL: gcc.dg/vect/vect-early-break_124-pr114403.c scan-tree-dump vect "LOOP VECTORIZED"

..., which needs to be looked into, separately.

	gcc/testsuite/
	* lib/target-supports.exp (check_effective_target_vect_long_long):
	Enable for GCN.

gcc/
	PR target/114752
	* config/avr/avr.cc (avr_print_operand) [CONST_DOUBLE_P]: Handle DFmode.