The new __is_convertible built-in should only be used after checking
that it's supported.

libstdc++-v3/ChangeLog:

	PR libstdc++/113241
	* include/std/type_traits (is_convertible_v): Guard use of
	built-in with preprocessor check.

(cherry picked from commit 57fa5b60)

The current constexpr implementation of std::char_traits<C>::move relies
on being able to compare the pointer parameters, which is not allowed
for unrelated pointers. We can use __builtin_constant_p to determine
whether it's safe to compare the pointers directly. If not, then we know
the ranges must be disjoint and so we can use char_traits<C>::copy to
copy forwards from the first character to the last. If the pointers can
be compared directly, then we can simplify the condition for copying
backwards to just two pointer comparisons.

libstdc++-v3/ChangeLog:

	PR libstdc++/113200
	* include/bits/char_traits.h (__gnu_cxx::char_traits::move): Use
	__builtin_constant_p to check for unrelated pointers that cannot
	be compared during constant evaluation.
	* testsuite/21_strings/char_traits/requirements/113200.cc: New
	test.

(cherry picked from commit 15cc2918)

The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2
inadvertently increased the execution time of this test by over 5x due
to making the two main loops actually run in the signed_p case instead
of being dead code.

To compensate, this patch cuts the relevant loops' range [-1000,1000] by
10x as proposed in the PR.  This shouldn't significantly weaken the test
since the same important edge cases are still checked in the smaller range
and/or elsewhere.  On my machine this reduces the test's execution time by
roughly 10x (and 1.6x relative to before r14-205).

	PR testsuite/113175

libstdc++-v3/ChangeLog:

	* testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce
	'limit' to 100 from 1000 and adjust 'log2_limit' accordingly.
	(test03): Likewise.

(cherry picked from commit a138b996)

gcc/fortran/ChangeLog:

	PR fortran/97592
	* trans-expr.cc (gfc_conv_procedure_call): For a contiguous dummy
	with the TARGET attribute, the effective argument may still be
	contiguous even if the actual argument is not simply-contiguous.
	Allow packing to be decided at runtime by _gfortran_internal_pack.

gcc/testsuite/ChangeLog:

	PR fortran/97592
	* gfortran.dg/contiguous_15.f90: New test.

(cherry picked from commit 5060825a)

Users may wish just use -mtune=native for performance tuning only.
Let's don't make trouble for its case.

gcc/

	* config/mips/driver-native.cc (host_detect_local_cpu):
	don't add nan2008 option for -mtune=native.

The function `reconcat` cannot append string(s) to NULL,
as the concat process will stop at the first NULL.

Let's always put the `ret` to the end, as it may be NULL.
We keep use reconcat here, due to that reconcat can make it
easier if we add more hardware features detecting, for example
by hwcap.

gcc/

	PR target/112759
	* config/mips/driver-native.cc (host_detect_local_cpu):
	Put the ret to the end of args of reconcat.

The problem is that the predicated subtype does not inherit all the required
attributes of a string subtype with a static predicate.

gcc/ada/
	* sem_ch3.adb (Analyze_Subtype_Declaration): Remove a short-circuit
	for subtypes without aspects when it comes to predicates.
	* sem_util.adb (Inherit_Predicate_Flags): Deal with private subtypes
	whose full view is an Itype.

We are still ICEing on the generic lambda version of the testcase from
this PR, even after r13-6743-g6f90de97634d6f, due to the by-ref capture
of the constant local variable 'dim' being considered value-dependent
when regenerating the lambda (at which point processing_template_decl is
set since the lambda is generic), which prevents us from constant folding
its uses.  Later during prune_lambda_captures we end up not thoroughly
walking the body of the lambda and overlook the (non-folded) uses of
'dim' within the array bound and using-decls.

We could fix this by making prune_lambda_captures walk the body of the
lambda more thoroughly so that it finds these uses of 'dim', but ideally
we should be able to constant fold all uses of 'dim' ahead of time and
prune the implicit capture after all.

To that end this patch makes value_dependent_expression_p return false
for such by-ref captures of constant local variables, allowing their
uses to get constant folded ahead of time.  It seems we just need to
disable the predicate's conservative early exit for reference variables
(added by r5-5022-g51d72abe5ea04e) when DECL_HAS_VALUE_EXPR_P.  This
effectively makes us treat by-value and by-ref captures more consistently
when it comes to value dependence.

	PR c++/108975

gcc/cp/ChangeLog:

	* pt.cc (value_dependent_expression_p) <case VAR_DECL>:
	Suppress conservative early exit for reference variables
	when DECL_HAS_VALUE_EXPR_P.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/lambda/lambda-const11a.C: New test.

(cherry picked from commit 3d674e29)

	PR sanitizer/111736
	* asan.cc (asan_protect_global): Do not protect globals
	in non-generic address-space.

(cherry picked from commit 7e404978)

Apparently when looking for "signbit<mode>2" vector expanders, I've only
looked at sse.md and forgot mmx.md, which has another one and the
following patch still ICEd.

2023-12-19  Jakub Jelinek  <jakub@redhat.com>

	PR target/112816
	* config/i386/mmx.md (signbitv2sf2): Force operands[1] into a REG.

	* gcc.target/i386/sse2-pr112816-2.c: New test.

(cherry picked from commit 80e1375e)

The following testcase ICEs because we aren't careful enough with
alloc_size attribute.  We do check that such an argument exists
(although wouldn't handle correctly functions with more than INT_MAX
arguments), but didn't check that it is scalar integer, the ICE is
trying to fold_convert a structure to sizetype.

Given that the attribute can also appear on non-prototyped functions
where the arguments aren't known, I don't see how the FE could diagnose
that and because we already handle the case where argument doesn't exist,
I think we should also verify the argument is scalar integer convertible
to sizetype.  Furthermore, given this is not just in diagnostics but
used for code generation, I think it is better to punt on arguments with
larger precision then sizetype, the upper bits are then truncated.

The patch also fixes some formatting issues and avoids duplication of the
fold_convert, plus removes unnecessary check for if (arg1 >= 0), that is
always the case after if (arg1 < 0) return ...;

2023-12-18  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/113013
	* tree-object-size.cc (alloc_object_size): Return size_unknown if
	corresponding argument(s) don't have integral type or have integral
	type with higher precision than sizetype.  Don't check arg1 >= 0
	uselessly.  Compare argument indexes against gimple_call_num_args
	in unsigned type rather than int.  Formatting fixes.

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

(cherry picked from commit 5347263b)

In many cases we just specify types for the builtin arguments, in other cases
types and names with @var{name} syntax, and in other case with just name.

Shall we tweak that somehow?  If the argument names are unimportant, perhaps
it is fine to leave that out, but shouldn't we always use @var{...} around
the parameter names when specified?

On Fri, Dec 01, 2023 at 10:43:57AM -0700, Sandra Loosemore wrote:
> Yup.  The Texinfo manual says:  "When using @deftypefn command and
> variations, you should mark parameter names with @var to distinguish these
> from data type names, keywords, and other parts of the literal syntax of the
> programming language."

Here is a patch which does that (but not adding types to where they were
missing, that will be harder to search for).

2023-12-11  Jakub Jelinek  <jakub@redhat.com>

	* doc/extend.texi (__sync_fetch_and_add, __sync_fetch_and_sub,
	__sync_fetch_and_or, __sync_fetch_and_and, __sync_fetch_and_xor,
	__sync_fetch_and_nand, __sync_add_and_fetch, __sync_sub_and_fetch,
	__sync_or_and_fetch, __sync_and_and_fetch, __sync_xor_and_fetch,
	__sync_nand_and_fetch, __sync_bool_compare_and_swap,
	__sync_val_compare_and_swap, __sync_lock_test_and_set,
	__sync_lock_release, __atomic_load_n, __atomic_load, __atomic_store_n,
	__atomic_store, __atomic_exchange_n, __atomic_exchange,
	__atomic_compare_exchange_n, __atomic_compare_exchange,
	__atomic_add_fetch, __atomic_sub_fetch, __atomic_and_fetch,
	__atomic_xor_fetch, __atomic_or_fetch, __atomic_nand_fetch,
	__atomic_fetch_add, __atomic_fetch_sub, __atomic_fetch_and,
	__atomic_fetch_xor, __atomic_fetch_or, __atomic_fetch_nand,
	__atomic_test_and_set, __atomic_clear, __atomic_thread_fence,
	__atomic_signal_fence, __atomic_always_lock_free,
	__atomic_is_lock_free, __builtin_add_overflow,
	__builtin_sadd_overflow, __builtin_saddl_overflow,
	__builtin_saddll_overflow, __builtin_uadd_overflow,
	__builtin_uaddl_overflow, __builtin_uaddll_overflow,
	__builtin_sub_overflow, __builtin_ssub_overflow,
	__builtin_ssubl_overflow, __builtin_ssubll_overflow,
	__builtin_usub_overflow, __builtin_usubl_overflow,
	__builtin_usubll_overflow, __builtin_mul_overflow,
	__builtin_smul_overflow, __builtin_smull_overflow,
	__builtin_smulll_overflow, __builtin_umul_overflow,
	__builtin_umull_overflow, __builtin_umulll_overflow,
	__builtin_add_overflow_p, __builtin_sub_overflow_p,
	__builtin_mul_overflow_p, __builtin_alloca,
	__builtin_alloca_with_align, __builtin_alloca_with_align_and_max,
	__builtin_speculation_safe_value, __builtin_nan, __builtin_nand32,
	__builtin_nand64, __builtin_nand128, __builtin_nanf, __builtin_nanl,
	__builtin_nanf@var{n}, __builtin_nanf@var{n}x, __builtin_nans,
	__builtin_nansd32, __builtin_nansd64, __builtin_nansd128,
	__builtin_nansf, __builtin_nansl, __builtin_nansf@var{n},
	__builtin_nansf@var{n}x, __builtin_ffs, __builtin_clz, __builtin_ctz,
	__builtin_clrsb, __builtin_popcount, __builtin_parity,
	__builtin_bswap16, __builtin_bswap32, __builtin_bswap64,
	__builtin_bswap128, __builtin_extend_pointer,
	__builtin_goacc_parlevel_id, __builtin_goacc_parlevel_size, vec_clrl,
	vec_clrr, vec_mulh, vec_mul, vec_div, vec_dive, vec_mod,
	__builtin_rx_mvtc): Use @var{...} around parameter names.
	(vec_rl, vec_sl, vec_sr, vec_sra): Likewise.  Use @var{...} also
	around A, B and R in description.

(cherry picked from commit 23795106)

The following testcase is miscompiled because two ubsan instrumentations
run into each other.
The first one is the shift instrumentation.  Before the C++ FE calls
it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects
in them aren't evaluated multiple times.  And, ubsan_instrument_shift
itself uses unshare_expr on any uses of the operands to make sure further
modifications in them don't affect other copies of them (the only not
unshared ones are the one the caller then uses for the actual operation
after the instrumentation, which means there is no tree sharing).

Now, if there are side-effects in the first operand like say function
call, cp_save_expr wraps it into a SAVE_EXPR, and ubsan_instrument_shift
in this mode emits something like
if (..., SAVE_EXPR <foo ()>, SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR <foo ()>, ...);
and caller adds
SAVE_EXPR <foo ()> << SAVE_EXPR <op1>
after it in a COMPOUND_EXPR.  So far so good.

If there are no side-effects and cp_save_expr doesn't create SAVE_EXPR,
everything is ok as well because of the unshare_expr.
We have
if (..., SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., ptr->something[i], ...);
and
ptr->something[i] << SAVE_EXPR <op1>
where ptr->something[i] is unshared.

In the testcase below, the !x->s[j] ? 1 : 0 expression is wrapped initially
into a SAVE_EXPR though, and unshare_expr doesn't unshare SAVE_EXPRs nor
anything used in them for obvious reasons, so we end up with:
if (..., SAVE_EXPR <!(bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 1 : 0>, SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR <!(bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 1 : 0>, ...);
and
SAVE_EXPR <!(bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 1 : 0> << SAVE_EXPR <op1>
So far good as well.  But later during cp_fold of the SAVE_EXPR we find
out that VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 0 : 1 is actually
invariant (has TREE_READONLY set) and so cp_fold simplifies the above to
if (..., SAVE_EXPR <op1> > const)
 __ubsan_handle_shift_out_of_bounds (..., (bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 0 : 1, ...);
and
((bool) VIEW_CONVERT_EXPR<const struct S *>(x)->s[j] ? 0 : 1) << SAVE_EXPR <op1>
with the s[j] ARRAY_REFs and other expressions shared in between the two
uses (and obviously the expression optimized away from the COMPOUND_EXPR in
the if condition.

Then comes another ubsan instrumentation at genericization time,
this time to instrument the ARRAY_REFs with strict bounds checking,
and replaces the s[j] in there with s[.UBSAN_BOUNDS (0B, SAVE_EXPR<j>, 8), SAVE_EXPR<j>]
As the trees are shared, it does that just once though.
And as the if body is gimplified first, the SAVE_EXPR<j> is evaluated inside
of the if body and when it is used again after the if, it uses a potentially
uninitialized value of j.1 (always uninitialized if the shift count isn't
out of bounds).

The following patch fixes that by unshare_expr unsharing the folded argument
of a SAVE_EXPR if we've folded the SAVE_EXPR into an invariant and it is
used more than once.

2023-12-08  Jakub Jelinek  <jakub@redhat.com>

	PR sanitizer/112727
	* cp-gimplify.cc (cp_fold): If SAVE_EXPR has been previously
	folded, unshare_expr what is returned.

	* c-c++-common/ubsan/pr112727.c: New test.

(cherry picked from commit 6ddaf06e)

We ICE on the following testcase when wi::multiple_of_p is called on
widest_int 1 and -128 with UNSIGNED.  I still need to work on the
actual wide-int.cc issue, the latest patch attached to the PR regressed
bitint-{38,39}.c, so will need to debug that, but there is a clear bug
on the fold-const.cc side as well - widest_int is a signed representation
by definition, using UNSIGNED with it certainly doesn't match what was
intended, because -128 as the second operand effectively means unsigned
131072 bit 0xfffff............ffff80 integer, not the signed char -128
that appeared in the source.

In the INTEGER_CST case a few lines above this we already use
    case INTEGER_CST:
      if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
        return false;
      return wi::multiple_of_p (wi::to_widest (top), wi::to_widest (bottom),
                                SIGNED);
so I think using SIGNED with widest_int is best there (compared to the
other choices in the PR).

2023-11-29  Jakub Jelinek  <jakub@redhat.com>

	PR middle-end/112733
	* fold-const.cc (multiple_of_p): Pass SIGNED rather than
	UNSIGNED for wi::multiple_of_p on widest_int arguments.

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

(cherry picked from commit 5c95bf94)

These tests are expected to run interactively, with the output checked
by eye. Nobody ever does that, but we can at least use dg-output to
check that the output is as expected.

libstdc++-v3/ChangeLog:

	* testsuite/27_io/objects/char/2.cc: Use dg-output.
	* testsuite/27_io/objects/wchar_t/2.cc: Use dg-output.

(cherry picked from commit 0c773209)

I got the order of arguments to std::format_to wrong. It was in a
discarded statement, for a case which wasn't being tested.

libstdc++-v3/ChangeLog:

	* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix order
	of arguments to std::format_to.
	* testsuite/20_util/duration/io.cc: Test subsecond duration with
	floating-point rep.

(cherry picked from commit 2ef5200a)

gcc/ChangeLog:

	* config/i386/driver-i386.cc (host_detect_local_cpu): Do not
	set Grand Ridge depending on RAO-INT.
	* config/i386/i386.h: Remove PTA_RAOINT from PTA_GRANDRIDGE.
	* doc/invoke.texi: Adjust documentation.