Merge remote-tracking branch 'mainline/master' into ibuclaw/merge_mainline

Fixes: #1544

libstdc++: Adjust deduction guides for static operator() [PR106651]

Adjust the deduction guides for std::function and std::packaged_task to
work with static call operators. This finishes the implementation of
P1169R4 for C++23.

libstdc++-v3/ChangeLog:

PR c++/106651
* include/bits/std_function.h (__function_guide_t): New alias
template.
[__cpp_static_call_operator] (__function_guide_static_helper):
New class template.
(function): Use __function_guide_t in deduction guide.
* include/std/future (packaged_task): Use __function_guide_t in
deduction guide.
* testsuite/20_util/function/cons/deduction_c++23.cc: New test.
* testsuite/30_threads/packaged_task/cons/deduction_c++23.cc:
New test.

fixincludes: FIx up for Debian/Ubuntu includes

As reported by Tobias, my C++ _Float{16,32,64,128,32x,64x,128x} support
patch broke Debian/Ubuntu bootstraps.  The problem is that there
glibc bits/floatn.h and bits/floatn-common.h isn't in /usr/include/
directly, but in a subdirectory like /usr/include/x86_64-linux-gnu/
Seems other fixinclude rules for bits/* headers use
files = bits/whatever.h, "*/bits/whatever.h";
so this patch just follows the suit.

2022-06-27  Jakub Jelinek  <jakub@redhat.com>

* inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2,
glibc_cxx_floatn_3): Add to files also "*/bits/floatn.h"
and "*/bits/floatn-common.h".
* fixincl.x: Regenerated.

d: Merge upstream dmd d579c467c1, phobos 88aa69b14.

D front-end changes:

    - Throwing from contracts of `nothrow' functions has been
      deprecated, as this breaks the guarantees of `nothrow'.
    - Added language support for initializing the interior pointer of
      associative arrays using `new' keyword.

Phobos changes:

    - The std.digest.digest module has been removed.
    - The std.xml module has been removed.

gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd d579c467c1.
* decl.cc (layout_struct_initializer): Update for new front-end
interface.
* expr.cc (ExprVisitor::visit (AssignExp *)): Remove lowering of array
assignments.
(ExprVisitor::visit (NewExp *)): Add new lowering of new'ing
associative arrays to an _aaNew() library call.
* runtime.def (ARRAYSETASSIGN): Remove.
(AANEW): Define.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime d579c467c1.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES): Remove
rt/arrayassign.d.
* libdruntime/Makefile.in: Regenerate.
* src/MERGE: Merge upstream phobos 88aa69b14.
* src/Makefile.am (PHOBOS_DSOURCES): Remove std/digest/digest.d,
std/xml.d.
* src/Makefile.in: Regenerate.

irange: keep better track of powers of 2.

When setting the nonzero bits to a mask containing only one bit, set
the range immediately, as it can be devined from the mask.  This helps
us keep better track of powers of two.

For example, with this patch a nonzero mask of 0x8000 is set to a
range of [0,0][0x8000,0x8000] with a nonzero mask of 0x8000.

gcc/ChangeLog:

* value-range.cc (irange::set_nonzero_bits): Set range when known.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/popcount6.c: New test.

Add an irange setter for wide_ints.

Just the same way as we have real_value setters for franges, we should
have a wide_int version for irange.  This matches the irange
constructor for wide_ints, and paves the way for the eventual
conversion of irange to wide ints.

gcc/ChangeLog:

* value-range.h (irange::set): New version taking wide_int_ref.

c++: Implement C++23 P1169R4 - static operator() [PR106651]

The following patch attempts to implement C++23 P1169R4 - static operator()
paper's compiler side (there is some small library side too not implemented
yet).  This allows static members as user operator() declarations and
static specifier on lambdas without lambda capture.
The synthetized conversion operator changes for static lambdas as it can just
return the operator() static method address, doesn't need to create a thunk
for it.
The change in call.cc (joust) is to avoid ICEs because we assumed that len
could be different only if both candidates are direct calls but it can be
one direct and one indirect call, and to implement the
[over.match.best.general]/1 and [over.best.ics.general] changes from
the paper (implemented always as Jason is sure it doesn't make a difference
in C++20 and earlier unless static member function operator() or
static lambda which we accept with pedwarn in earlier standards too appears
and my testing confirmed that).

2022-09-27  Jakub Jelinek  <jakub@redhat.com>

PR c++/106651
gcc/c-family/
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__cpp_static_call_operator=202207L for C++23.
gcc/cp/
* cp-tree.h (LAMBDA_EXPR_STATIC_P): Implement C++23
P1169R4 - static operator().  Define.
* parser.cc (CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): Document
that it also allows static.
(cp_parser_lambda_declarator_opt): Handle static lambda specifier.
(cp_parser_decl_specifier_seq): Allow RID_STATIC for
CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR.
* decl.cc (grok_op_properties): If operator() isn't a method,
use a different error wording, if it is static member function,
allow it (for C++20 and older with a pedwarn unless it is
a lambda function or template instantiation).
* call.cc (joust): Don't ICE if one candidate is static member
function and the other is an indirect call.  If the parameter
conversion on the other candidate is user defined conversion,
ellipsis or bad conversion, make static member function candidate
a winner for that parameter.
* lambda.cc (maybe_add_lambda_conv_op): Handle static lambdas.
* error.cc (dump_lambda_function): Print static for static lambdas.
gcc/testsuite/
* g++.dg/template/error30.C: Adjust expected diagnostics.
* g++.dg/cpp1z/constexpr-lambda13.C: Likewise.
* g++.dg/cpp23/feat-cxx2b.C: Test __cpp_static_call_operator.
* g++.dg/cpp23/static-operator-call1.C: New test.
* g++.dg/cpp23/static-operator-call2.C: New test.
* g++.old-deja/g++.jason/operator.C: Adjust expected diagnostics.

reassoc: Handle OFFSET_TYPE like POINTER_TYPE in optimize_range_tests_cmp_bitwise [PR107029[

As the testcase shows, OFFSET_TYPE needs the same treatment as
POINTER_TYPE/REFERENCE_TYPE, otherwise we fail the same during the
newly added verification.  OFFSET_TYPE is signed though, so unlike
POINTER_TYPE/REFERENCE_TYPE it can also trigger with the
x < 0 && y < 0 && z < 0 to (x | y | z) < 0
optimization.

2022-09-27  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/107029
* tree-ssa-reassoc.cc (optimize_range_tests_cmp_bitwise): Treat
OFFSET_TYPE like POINTER_TYPE, except that OFFSET_TYPE may be
signed and so can trigger even the (b % 4) == 3 case.

* g++.dg/torture/pr107029.C: New test.

openmp: Add OpenMP assume, assumes and begin/end assumes support

The following patch implements OpenMP 5.1
 #pragma omp assume
 #pragma omp assumes
and
 #pragma omp begin assumes
 #pragma omp end assumes
directive support for C and C++.  Currently it doesn't remember
anything from the assumption clauses for later, so is mainly
to support the directives and diagnose errors in their use.
If the recently posted C++23 [[assume (cond)]]; support makes it
in, the intent is that this can be easily adjusted at least for
the #pragma omp assume directive with holds clause(s) to use
the same infrastructure.  Now, C++23 portable assumptions are slightly
different from OpenMP 5.1 assumptions' holds clause in that C++23
assumption holds just where it appears, while OpenMP 5.1 assumptions
hold everywhere in the scope of the directive.  For assumes
directive which can appear at file or namespace scope it is the whole
TU and everything that functions from there call at runtime, for
begin assumes/end assumes pair all the functions in between those
directives and everything they call and for assume directive the
associated (currently structured) block.  I have no idea how to
represents such holds to be usable for optimizers, except to
make
 #pragma omp assume holds (cond)
block;
expand essentially to
[[assume (cond)]];
block;
or
[[assume (cond)]];
block;
[[assume (cond)]];
for now.  Except for holds clause, the other assumptions are
OpenMP related, I'd say we should brainstorm where it would be
useful to optimize based on such information (I guess e.g. in target
regions it easily could) and only when we come up with something
like that think about how to propagate the assumptions to the optimizers.

2022-09-27  Jakub Jelinek  <jakub@redhat.com>

gcc/c-family/
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_ASSUME,
PRAGMA_OMP_ASSUMES and PRAGMA_OMP_BEGIN.  Rename
PRAGMA_OMP_END_DECLARE_TARGET to PRAGMA_OMP_END.
* c-pragma.cc (omp_pragmas): Add assumes and begin.
For end rename PRAGMA_OMP_END_DECLARE_TARGET to PRAGMA_OMP_END.
(omp_pragmas_simd): Add assume.
* c-common.h (c_omp_directives): Declare.
* c-omp.cc (omp_directives): Rename to ...
(c_omp_directives): ... this.  No longer static.  Uncomment
assume, assumes, begin assumes and end assumes entries.
In end declare target entry rename PRAGMA_OMP_END_DECLARE_TARGET
to PRAGMA_OMP_END.
(c_omp_categorize_directive): Adjust for omp_directives to
c_omp_directives renaming.
gcc/c/
* c-lang.h (current_omp_begin_assumes): Declare.
* c-parser.cc: Include bitmap.h.
(c_parser_omp_end_declare_target): Rename to ...
(c_parser_omp_end): ... this.  Handle also end assumes.
(c_parser_omp_begin, c_parser_omp_assumption_clauses,
c_parser_omp_assumes, c_parser_omp_assume): New functions.
(c_parser_translation_unit): Also diagnose #pragma omp begin assumes
without corresponding #pragma omp end assumes.
(c_parser_pragma): Use %s in may only be used at file scope
diagnostics to decrease number of translatable messages.  Handle
PRAGMA_OMP_BEGIN and PRAGMA_OMP_ASSUMES.  Handle PRAGMA_OMP_END
rather than PRAGMA_OMP_END_DECLARE_TARGET and call c_parser_omp_end
for it rather than c_parser_omp_end_declare_target.
(c_parser_omp_construct): Handle PRAGMA_OMP_ASSUME.
* c-decl.cc (current_omp_begin_assumes): Define.
gcc/cp/
* cp-tree.h (struct omp_begin_assumes_data): New type.
(struct saved_scope): Add omp_begin_assumes member.
* parser.cc: Include bitmap.h.
(cp_parser_omp_assumption_clauses, cp_parser_omp_assume,
cp_parser_omp_assumes, cp_parser_omp_begin): New functions.
(cp_parser_omp_end_declare_target): Rename to ...
(cp_parser_omp_end): ... this.  Handle also end assumes.
(cp_parser_omp_construct): Handle PRAGMA_OMP_ASSUME.
(cp_parser_pragma): Handle PRAGMA_OMP_ASSUME, PRAGMA_OMP_ASSUMES
and PRAGMA_OMP_BEGIN.  Handle PRAGMA_OMP_END rather than
PRAGMA_OMP_END_DECLARE_TARGET and call cp_parser_omp_end
for it rather than cp_parser_omp_end_declare_target.
* pt.cc (apply_late_template_attributes): Also temporarily clear
omp_begin_assumes.
* semantics.cc (finish_translation_unit): Also diagnose
#pragma omp begin assumes without corresponding
#pragma omp end assumes.
gcc/testsuite/
* c-c++-common/gomp/assume-1.c: New test.
* c-c++-common/gomp/assume-2.c: New test.
* c-c++-common/gomp/assume-3.c: New test.
* c-c++-common/gomp/assumes-1.c: New test.
* c-c++-common/gomp/assumes-2.c: New test.
* c-c++-common/gomp/assumes-3.c: New test.
* c-c++-common/gomp/assumes-4.c: New test.
* c-c++-common/gomp/begin-assumes-1.c: New test.
* c-c++-common/gomp/begin-assumes-2.c: New test.
* c-c++-common/gomp/begin-assumes-3.c: New test.
* c-c++-common/gomp/begin-assumes-4.c: New test.
* c-c++-common/gomp/declare-target-6.c: New test.
* g++.dg/gomp/attrs-1.C (bar): Add n1 and n2 arguments, add
tests for assume directive.
* g++.dg/gomp/attrs-2.C (bar): Likewise.
* g++.dg/gomp/attrs-9.C: Add n1 and n2 variables, add tests for
begin assumes directive.
* g++.dg/gomp/attrs-15.C: New test.
* g++.dg/gomp/attrs-16.C: New test.
* g++.dg/gomp/attrs-17.C: New test.

c++: Improve diagnostics about conflicting specifiers

On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote:
> I wonder why we don't give an error when setting the
> conflicting_specifiers_p flag in cp_parser_set_storage_class?  We should be
> able to give a better diagnostic at that point.

I didn't have time to update the whole patch last night, but this part
seems to be independent and I've managed to test it.

The diagnostics then looks like:
a.C:1:9: error: ‘static’ specifier conflicts with ‘typedef’
    1 | typedef static int a;
      | ~~~~~~~ ^~~~~~
a.C:2:8: error: ‘typedef’ specifier conflicts with ‘static’
    2 | static typedef int b;
      | ~~~~~~ ^~~~~~~
a.C:3:8: error: duplicate ‘static’ specifier
    3 | static static int c;
      | ~~~~~~ ^~~~~~
a.C:4:8: error: ‘extern’ specifier conflicts with ‘static’
    4 | static extern int d;
      | ~~~~~~ ^~~~~~

2022-09-27  Jakub Jelinek  <jakub@redhat.com>

gcc/cp/
* parser.cc (cp_parser_lambda_declarator_opt): Don't diagnose
conflicting specifiers here.
(cp_storage_class_name): New variable.
(cp_parser_decl_specifier_seq): When setting conflicting_specifiers_p
for the first time, diagnose which exact specifiers conflict.
(cp_parser_set_storage_class): Likewise.  Move storage_class
computation earlier.
* decl.cc (grokdeclarator): Don't diagnose conflicting specifiers
here, just return error_mark_node.
gcc/testsuite/
* g++.dg/diagnostic/conflicting-specifiers-1.C: Adjust expected
diagnostics.
* g++.dg/parse/typedef8.C: Likewise.
* g++.dg/parse/crash39.C: Likewise.
* g++.dg/other/mult-stor1.C: Likewise.
* g++.dg/cpp2a/constinit3.C: Likewise.

Fix ICEs due to recent jump-to-return optimization

gcc/
* cfgrtl.cc (fixup_reorder_chain): Verify that simple_return
and return are available before trying to use them.

c++: Implement P1467R9 - Extended floating-point types and standard names compiler part except for bfloat16 [PR106652]

The following patch implements the compiler part of C++23
P1467R9 - Extended floating-point types and standard names compiler part
by introducing _Float{16,32,64,128} as keywords and builtin types
like they are implemented for C already since GCC 7, with DF{16,32,64,128}_
mangling.
It also introduces _Float{32,64,128}x for C++ with the
https://github.com/itanium-cxx-abi/cxx-abi/pull/147
proposed mangling of DF{32,64,128}x.
The patch doesn't add anything for bfloat16_t support, as right now
__bf16 type refuses all conversions and arithmetic operations.
The patch wants to keep backwards compatibility with how __float128 has
been handled in C++ before, both for mangling and behavior in binary
operations, overload resolution etc.  So, there are some backend changes
where for C __float128 and _Float128 are the same type (float128_type_node
and float128t_type_node are the same pointer), but for C++ they are distinct
types which mangle differently and _Float128 is treated as extended
floating-point type while __float128 is treated as non-standard floating
point type.  The various C++23 changes about how floating-point types
are changed are actually implemented as written in the spec only if at least
one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx are
also treated as extended floating-point types) and kept previous behavior
otherwise.  For float/double/long double the rules are actually written that
they behave the same as before.
There is some backwards incompatibility at least on x86 regarding _Float16,
because that type was already used by that name and with the DF16_ mangling
(but only since GCC 12 and I think it isn't that widely used in the wild
yet).  E.g. config/i386/avx512fp16intrin.h shows the issues, where
in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
argument, but with the changes that is not possible anymore, one needs
to either use 0.0f16 or (_Float16) 0.0f.
We have also a problem with glibc headers, where since glibc 2.27
math.h and complex.h aren't compilable with these changes.  One gets
errors like:
In file included from /usr/include/math.h:43,
                 from abc.c:1:
/usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
   86 | typedef __float128 _Float128;
      |         ^~~~~~~~~~
/usr/include/bits/floatn.h:86:20: error: declaration does not declare anything [-fpermissive]
   86 | typedef __float128 _Float128;
      |                    ^~~~~~~~~
In file included from /usr/include/bits/floatn.h:119:
/usr/include/bits/floatn-common.h:214:9: error: multiple types in one declaration
  214 | typedef float _Float32;
      |         ^~~~~
/usr/include/bits/floatn-common.h:214:15: error: declaration does not declare anything [-fpermissive]
  214 | typedef float _Float32;
      |               ^~~~~~~~
/usr/include/bits/floatn-common.h:251:9: error: multiple types in one declaration
  251 | typedef double _Float64;
      |         ^~~~~~
/usr/include/bits/floatn-common.h:251:16: error: declaration does not declare anything [-fpermissive]
  251 | typedef double _Float64;
      |                ^~~~~~~~
This is from snippets like:
 /* The remaining of this file provides support for older compilers.  */
 # if __HAVE_FLOAT128

 /* The type _Float128 exists only since GCC 7.0.  */
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
 typedef __float128 _Float128;
 #  endif
where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x} support nor
{f,F}{16,32,64,128}{,x} literal suffixes nor _Complex _Float{16,32,64,128,32x,64x,128x}.
The patch fixincludes this for now and hopefully if this is committed, then
glibc can change those.  The patch changes those
 #  if !__GNUC_PREREQ (7, 0) || defined __cplusplus
conditions to
 #  if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
Another thing is mangling, as said above, Itanium C++ ABI specifies
DF <number> _ as _Float{16,32,64,128} mangling, but GCC was implementing
a mangling incompatible with that starting with DF for fixed point types.
Fixed point was never supported in C++ though, I believe the reason why
the mangling has been added was that due to a bug it would leak into the
C++ FE through decltype (0.0r) etc.  But that has been shortly after the
mangling was added fixed (I think in the same GCC release cycle), so we
now reject 0.0r etc. in C++.  If we ever need the fixed point mangling,
I think it can be readded but better with a different prefix so that it
doesn't conflict with the published standard manglings.  So, this patch
also kills the fixed point mangling and implements the DF <number> _
demangling.
The patch predefines __STDCPP_FLOAT{16,32,64,128}_T__ macros when
those types are available, but only for C++23, while the underlying types
are available in C++98 and later including the {f,F}{16,32,64,128} literal
suffixes (but those with a pedwarn for C++20 and earlier).  My understanding
is that it needs to be predefined by the compiler, on the other side
predefining even for older modes when <stdfloat> is a new C++23 header
would be weird.  One can find out if _Float{16,32,64,128,32x,64x,128x} is
supported in C++ by
__GNUC__ >= 13 && defined(__FLT{16,32,64,128,32X,64X,128X}_MANT_DIG__)
(but that doesn't work well with older G++ 13 snapshots).

As for std::bfloat16_t, three targets (aarch64, arm and x86) apparently
"support" __bf16 type which has the bfloat16 format, but isn't really
usable, e.g. {aarch64,arm,ix86}_invalid_conversion disallow any conversions
from or to type with BFmode, {aarch64,arm,ix86}_invalid_unary_op disallows
any unary operations on those except for ADDR_EXPR and
{aarch64,arm,ix86}_invalid_binary_op disallows any binary operation on
those.  So, I think we satisfy:
"If the implementation supports an extended floating-point type with the
properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2, storage
width in bits (k) of 16, precision in bits (p) of 8, maximum exponent (emax)
of 127, and exponent field width in bits (w) of 8, then the typedef-name
std::bfloat16_t is defined in the header <stdfloat> and names such a type,
the macro __STDCPP_BFLOAT16_T__ is defined, and the floating-point literal
suffixes bf16 and BF16 are supported."
because we don't really support those right now.

2022-09-27  Jakub Jelinek  <jakub@redhat.com>

PR c++/106652
PR c++/85518
gcc/
* tree-core.h (enum tree_index): Add TI_FLOAT128T_TYPE
enumerator.
* tree.h (float128t_type_node): Define.
* tree.cc (build_common_tree_nodes): Initialize float128t_type_node.
* builtins.def (DEF_FLOATN_BUILTIN): Adjust comment now that
_Float<N> is supported in C++ too.
* config/i386/i386.cc (ix86_mangle_type): Only mangle as "g"
float128t_type_node.
* config/i386/i386-builtins.cc (ix86_init_builtin_types): Use
float128t_type_node for __float128 instead of float128_type_node
and create it if NULL.
* config/i386/avx512fp16intrin.h (_mm_setzero_ph, _mm256_setzero_ph,
_mm512_setzero_ph, _mm_set_sh, _mm_load_sh): Use 0.0f16 instead of
0.0f.
* config/ia64/ia64.cc (ia64_init_builtins): Use
float128t_type_node for __float128 instead of float128_type_node
and create it if NULL.
* config/rs6000/rs6000-c.cc (is_float128_p): Also return true
for float128t_type_node if non-NULL.
* config/rs6000/rs6000.cc (rs6000_mangle_type): Don't mangle
float128_type_node as "u9__ieee128".
* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Use
float128t_type_node for __float128 instead of float128_type_node
and create it if NULL.
gcc/c-family/
* c-common.cc (c_common_reswords): Change _Float{16,32,64,128} and
_Float{32,64,128}x flags from D_CONLY to 0.
(shorten_binary_op): Punt if common_type returns error_mark_node.
(shorten_compare): Likewise.
(c_common_nodes_and_builtins): For C++ record _Float{16,32,64,128}
and _Float{32,64,128}x builtin types if available.  For C++
clear float128t_type_node.
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__STDCPP_FLOAT{16,32,64,128}_T__ for C++23 if supported.
* c-lex.cc (interpret_float): For q/Q suffixes prefer
float128t_type_node over float128_type_node.  Allow
{f,F}{16,32,64,128} suffixes for C++ if supported with pedwarn
for C++20 and older.  Allow {f,F}{32,64,128}x suffixes for C++
with pedwarn.  Don't call excess_precision_type for C++.
gcc/cp/
* cp-tree.h (cp_compare_floating_point_conversion_ranks): Implement
P1467R9 - Extended floating-point types and standard names except
for std::bfloat16_t for now.  Declare.
(extended_float_type_p): New inline function.
* mangle.cc (write_builtin_type): Mangle float{16,32,64,128}_type_node
as DF{16,32,64,128}_.  Mangle float{32,64,128}x_type_node as
DF{32,64,128}x.  Remove FIXED_POINT_TYPE mangling that conflicts
with that.
* typeck2.cc (check_narrowing): If one of ftype or type is extended
floating-point type, compare floating-point conversion ranks.
* parser.cc (cp_keyword_starts_decl_specifier_p): Handle
CASE_RID_FLOATN_NX.
(cp_parser_simple_type_specifier): Likewise and diagnose missing
_Float<N> or _Float<N>x support if not supported by target.
* typeck.cc (cp_compare_floating_point_conversion_ranks): New function.
(cp_common_type): If both types are REAL_TYPE and one or both are
extended floating-point types, select common type based on comparison
of floating-point conversion ranks and subranks.
(cp_build_binary_op): Diagnose operation with floating point arguments
with unordered conversion ranks.
* call.cc (standard_conversion): For floating-point conversion, if
either from or to are extended floating-point types, set conv->bad_p
for implicit conversion from larger to smaller conversion rank or
with unordered conversion ranks.
(convert_like_internal): Emit a pedwarn on such conversions.
(build_conditional_expr): Diagnose operation with floating point
arguments with unordered conversion ranks.
(convert_arg_to_ellipsis): Don't promote extended floating-point types
narrower than double to double.
(compare_ics): Implement P1467R9 [over.ics.rank]/4 changes.
gcc/testsuite/
* g++.dg/cpp23/ext-floating1.C: New test.
* g++.dg/cpp23/ext-floating2.C: New test.
* g++.dg/cpp23/ext-floating3.C: New test.
* g++.dg/cpp23/ext-floating4.C: New test.
* g++.dg/cpp23/ext-floating5.C: New test.
* g++.dg/cpp23/ext-floating6.C: New test.
* g++.dg/cpp23/ext-floating7.C: New test.
* g++.dg/cpp23/ext-floating8.C: New test.
* g++.dg/cpp23/ext-floating9.C: New test.
* g++.dg/cpp23/ext-floating10.C: New test.
* g++.dg/cpp23/ext-floating.h: New file.
* g++.target/i386/float16-1.C: Adjust expected diagnostics.
libcpp/
* expr.cc (interpret_float_suffix): Allow {f,F}{16,32,64,128} and
{f,F}{32,64,128}x suffixes for C++.
include/
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
(struct demangle_component): Add u.s_extended_builtin member.
libiberty/
* cp-demangle.c (d_dump): Handle
DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Don't handle
DEMANGLE_COMPONENT_FIXED_TYPE.
(d_make_extended_builtin_type): New function.
(cplus_demangle_builtin_types): Add _Float entry.
(cplus_demangle_type): For DF demangle it as _Float<N> or
_Float<N>x rather than fixed point which conflicts with it.
(d_count_templates_scopes): Handle
DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.  Just break; for
DEMANGLE_COMPONENT_FIXED_TYPE.
(d_find_pack): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
Don't handle DEMANGLE_COMPONENT_FIXED_TYPE.
(d_print_comp_inner): Likewise.
* cp-demangle.h (D_BUILTIN_TYPE_COUNT): Bump.
* testsuite/demangle-expected: Replace _Z3xxxDFyuVb test
with _Z3xxxDF16_DF32_DF64_DF128_CDF16_Vb.  Add
_Z3xxxDF32xDF64xDF128xCDF32xVb test.
fixincludes/
* inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2,
glibc_cxx_floatn_3): New fixes.
* tests/base/bits/floatn.h: New file.
* fixincl.x: Regenerated.

Merge #1521

1521: expand: eager evaluate macros inside builtin macros r=CohenArthur a=liushuyu

- expand: eagerly evaluate the macros inside some of the builtin macros

Co-authored-by: liushuyu <liushuyu011@gmail.com>

testsuite/rust: add a testcase for testing ...

... builtin macro and decl macro mixed expansion

testsuite: adapt existing testcases

expand: eager evaluate macros inside builtin macros

Updated constants from <https://dwarfstd.org/Languages.php>

include
* dwarf2.h: Update with additional languages from dwarf
standard.

Daily bump.

libstdc++: Update std::pointer_traits to match new LWG 3545 wording

It was pointed out in recent LWG 3545 discussion that having a
constrained partial specialization of std::pointer_traits can cause
ambiguities with program-defined specializations. For example, the
addition to the testcase has:

template<typename P> requires std::derived_from<P, base_type
struct std::pointer_traits<P>;

This would be ambiguous with the library's own constrained partial
specialization:

template<typename Ptr> requires requires { typename Ptr::element_type; }
struct std::pointer_traits<Ptr>;

Neither specialization is more specialized than the other for a type
that is derived from base_type and also has an element_type member.

The solution is to remove the library's partial specialization, and do
the check for Ptr::element_type in the __ptr_traits_elem helper (which
is what we already do for !__cpp_concepts anyway).

libstdc++-v3/ChangeLog:

* include/bits/ptr_traits.h (__ptr_traits_elem) [__cpp_concepts]:
Also define the __ptr_traits_elem class template for the
concepts case.
(pointer_traits<Ptr>): Remove constrained partial
specialization.
* testsuite/20_util/pointer_traits/lwg3545.cc: Check for
ambiguitiy with program-defined partial specialization.

libstdc++: Use new built-ins for std::is_convertible traits

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_convertible, is_convertible_v):
Define using new built-in.
(is_nothrow_convertible is_nothrow_convertible_v): Likewise.

docs: add missing dash in option name

gcc/ChangeLog:

* doc/invoke.texi: Add missing dash for
  Wanalyzer-exposure-through-uninit-copy.

c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656]

P0482R6, which added char8_t, didn't allow

  const char arr[] = u8"howdy";

because it said "Declarations of arrays of char may currently be initialized
with UTF-8 string literals. Under this proposal, such initializations would
become ill-formed."  This caused too many issues, so P2513R4 alleviates some
of those compatibility problems.  In particular, "Arrays of char or unsigned
char may now be initialized with a UTF-8 string literal."  This restriction
has been lifted for initialization only, not implicit conversions.  Also,
my reading is that 'signed char' was excluded from the allowable conversions.

This is supposed to be treated as a DR in C++20.

PR c++/106656

gcc/c-family/ChangeLog:

* c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_char8_t
for C++20.

gcc/cp/ChangeLog:

* typeck2.cc (array_string_literal_compatible_p): Allow
initializing arrays of char or unsigned char by a UTF-8 string literal.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/feat-cxx2b.C: Adjust.
* g++.dg/cpp2a/feat-cxx2a.C: Likewise.
* g++.dg/ext/char8_t-feature-test-macro-2.C: Likewise.
* g++.dg/ext/char8_t-init-2.C: Likewise.
* g++.dg/cpp2a/char8_t3.C: New test.
* g++.dg/cpp2a/char8_t4.C: New test.

Optimize [0 = x & MASK] in range-ops.

For [0 = x & MASK], we can determine that x is ~MASK.  This is
something we're picking up in DOM thanks to maybe_set_nonzero_bits,
but is something we should handle natively.

This is a good example of how much easier to maintain the range-ops
entries are versus the ad-hoc pattern matching stuff we had to do
before.  For the curious, compare the changes to range-op here,
versus maybe_set_nonzero_bits.

I'm leaving the call to maybe_set_nonzero_bits until I can properly
audit it to make sure we're catching it all in range-ops.  It won't
hurt, since both set_range_info() and set_nonzero_bits() are
intersect operations, so we'll never lose information if we do both.

PR tree-optimization/107009

gcc/ChangeLog:

* range-op.cc (operator_bitwise_and::op1_range): Optimize 0 = x & MASK.
(range_op_bitwise_and_tests): New test.

c++: Instantiate less when evaluating __is_convertible

Jon reported that evaluating __is_convertible in a test led to
instantiating something ill-formed and so we failed to compile the test.
__is_convertible doesn't and shouldn't need to instantiate so much, so
let's limit it with a cp_unevaluated guard.  Use a helper function to
implement both built-ins.

PR c++/106784

gcc/cp/ChangeLog:

* method.cc (is_convertible_helper): New.
(is_convertible): Use it.
(is_nothrow_convertible): Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_convertible3.C: New test.
* g++.dg/ext/is_nothrow_convertible3.C: New test.

c++ modules: variable template partial spec fixes [PR107033]

In r13-2775-g32d8123cd6ce87 I missed that we need to adjust the call to
add_mergeable_specialization in the MK_partial case to correctly handle
variable template partial specializations (it currently assumes we're
always dealing with one for a class template).  This fixes an ICE when
converting the testcase from that commit to use an importable header
instead of a named module.

PR c++/107033

gcc/cp/ChangeLog:

* module.cc (trees_in::decl_value): In the MK_partial case for
a variable template partial specialization, pass decl_p=true to
add_mergeable_specialization, and set spec to the VAR_DECL not
the TEMPLATE_DECL.
* pt.cc (add_mergeable_specialization): For a variable template
partial specialization, set the TREE_TYPE of the new
DECL_TEMPLATE_SPECIALIZATIONS node to the TREE_TYPE of the
VAR_DECL not the VAR_DECL itself.

gcc/testsuite/ChangeLog:

* g++.dg/modules/partial-2.cc, g++.dg/modules/partial-2.h: New
files, factored out from ...
* g++.dg/modules/partial-2_a.C, g++.dg/modules/partial-2_b.C: ...
these.
* g++.dg/modules/partial-2_c.H: New test.
* g++.dg/modules/partial-2_d.C: New test.

Update my address and DCO entry in MAINTAINERS file

/
* MAINTAINERS: Update my email address and DCO entry.

Set ranges from unreachable edges for all known ranges.

In the conversion of DOM+evrp to DOM+ranger, we missed that evrp was
exporting ranges for unreachable edges for all SSA names for which we
have ranges for.  Instead we have only been exporting ranges for the
SSA name in the final conditional to the BB involving the unreachable
edge.

This patch adjusts adjusts DOM to iterate over the exports, similarly
to what evrp was doing.

Note that I also noticed that we don't calculate the nonzero bit mask
for op1, when 0 = op1 & MASK.  This isn't needed for this PR,
since maybe_set_nonzero_bits() is chasing the definition and
parsing the bitwise and on its own.  However, I'll be adding the
functionality for completeness sake, plus we could probably drop the
maybe_set_nonzero_bits legacy call entirely.

PR tree-optimization/107009

gcc/ChangeLog:

* tree-ssa-dom.cc
(dom_opt_dom_walker::set_global_ranges_from_unreachable_edges):
Iterate over exports.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/pr107009.c: New test.

nvptx: Allow '--with-arch' to override the default '-misa'

gcc/
* config.gcc (with_arch) [nvptx]: Allow '--with-arch' to override
the default.
* config/nvptx/gen-multilib-matches.sh: New.
* config/nvptx/t-nvptx (MULTILIB_OPTIONS, MULTILIB_MATCHES)
(MULTILIB_EXCEPTIONS): Handle this.
* doc/install.texi (Specific) <nvptx-*-none>: Document this.
* doc/invoke.texi (Nvidia PTX Options): Likewise.

nvptx: Introduce dummy multilib option for default '-misa=sm_30'

... primarily in preparation for later changes.

gcc/
* config.gcc (TM_MULTILIB_CONFIG) [nvptx]: Set to '$with_arch'.
* config/nvptx/t-nvptx (MULTILIB_OPTIONS, MULTILIB_MATCHES)
(MULTILIB_EXCEPTIONS): Handle it.

nvptx: Make default '-misa=sm_30' explicit

... primarily in preparation for later changes.

gcc/
* config.gcc (with_arch) [nvptx]: Set to 'sm_30'.
* config/nvptx/nvptx.cc (nvptx_option_override): Assert that
'-misa' appeared.
* config/nvptx/nvptx.h (OPTION_DEFAULT_SPECS): Define.
* config/nvptx/nvptx.opt (misa=): Remove 'Init'.

nvptx: forward '-v' command-line option to assembler

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

    [...]
     [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
    {+Verifying sm_30 code with sm_35 code generation.+}
    {+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
    [...]

(This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/37>
"Put '-v' verbose output onto stderr instead of stdout".)

gcc/
* config/nvptx/nvptx.h (ASM_SPEC): Define.

[RFA] Minor improvement to coremark, avoid unconditional jump to return

gcc/
* cfgcleanup.cc (bb_is_just_return): No longer static.
* cfgcleanup.h (bb_is_just_return): Add prototype.
* cfgrtl.cc (fixup_reorder_chain): Do not create an
unconditional jump to a return block.  Conditionally
remove unreachable blocks.

gcc/testsuite/

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

fix assert in __deregister_frame_info_bases

When using the atomic fast path deregistering can fail during
program shutdown if the lookup structures are already destroyed.
The assert in __deregister_frame_info_bases takes that into
account. In the non-fast-path case however is not aware of
program shutdown, which caused a compiler error on such platforms.
We fix that by introducing a constant for in_shutdown in
non-fast-path builds.
We also drop the destructor priority, as it is not supported on
all platforms and we no longer rely upon the priority anyway.

libgcc/ChangeLog:
* unwind-dw2-fde.c: Introduce a constant for in_shutdown
for the non-fast-path case. Drop destructor priority.

libstdc++: Add #if around non-C++03 code in std::bitset [PR107037]

libstdc++-v3/ChangeLog:

PR libstdc++/107037
* include/std/bitset (_Base_bitset::_M_do_reset): Use
preprocessor conditional around non-C++03 code.
* testsuite/20_util/bitset/107037.cc: New test.

OpenACC: Fix reduction tree-sharing issue [PR106982]

The tree for var == incoming == outgound was
'MEM <double[5]> [(double *)&reduced]' which caused the ICE
"incorrect sharing of tree nodes".

PR middle-end/106982

gcc/ChangeLog:

* omp-low.cc (lower_oacc_reductions): Add some unshare_expr.

gcc/testsuite/ChangeLog:

* c-c++-common/goacc/reduction-7.c: New test.
* c-c++-common/goacc/reduction-8.c: New test.

s390: fix wrong refactoring

Since r13-2251-g1930c5d05ceff2, the refactoring is not 1:1 and we end
up with a wrong rtx type.

gcc/ChangeLog:

* config/s390/s390.cc (s390_rtx_costs): Remove dest variable
and use only dst.

Merge #1542

1542: Merge GCC mainline/master into gccrs/master r=philberty a=ibuclaw

As per title, pull in the latest and greatest from gcc development.

Co-authored-by: Tim Lange <mail@tim-lange.me>
Co-authored-by: GCC Administrator <gccadmin@gcc.gnu.org>
Co-authored-by: Martin Liska <mliska@suse.cz>
Co-authored-by: Javier Miranda <miranda@adacore.com>
Co-authored-by: Bob Duff <duff@adacore.com>
Co-authored-by: Patrick Bernardi <bernardi@adacore.com>
Co-authored-by: Steve Baird <baird@adacore.com>
Co-authored-by: Gary Dismukes <dismukes@adacore.com>
Co-authored-by: Eric Botcazou <ebotcazou@adacore.com>
Co-authored-by: Justin Squirek <squirek@adacore.com>
Co-authored-by: Piotr Trojanek <trojanek@adacore.com>
Co-authored-by: Joffrey Huguet <huguet@adacore.com>
Co-authored-by: Yannick Moy <moy@adacore.com>

aarch64: Add -march support for Armv9.1-A, Armv9.2-A, Armv9.3-A

This is a straightforward patch that allows targeting the architecture revisions mentioned in the subject
through -march. These are already supported in binutils.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/ChangeLog:

* config/aarch64/aarch64-arches.def (armv9.1-a): Define.
(armv9.2-a): Likewise.
(armv9.3-a): Likewise.
* config/aarch64/aarch64.h (AARCH64_FL_V9_1): Likewise.
(AARCH64_FL_V9_2): Likewise.
(AARCH64_FL_V9_3): Likewise.
(AARCH64_FL_FOR_ARCH9_1): Likewise.
(AARCH64_FL_FOR_ARCH9_2): Likewise.
(AARCH64_FL_FOR_ARCH9_3): Likewise.
(AARCH64_ISA_V9_1): Likewise.
(AARCH64_ISA_V9_2): Likewise.
(AARCH64_ISA_V9_3): Likewise.
* doc/invoke.texi (AArch64 Options): Document armv9.1-a, armv9.2-a,
armv9.3-a values to -march.

ada: Doc: rename Valid_Image to Valid_Value

This renaming happened some time ago in the code, but the documentation
was not updated.

gcc/ada/

* doc/gnat_rm/implementation_defined_attributes.rst: Rename Valid_Image.
* gnat_rm.texi: Regenerate.
* gnat_ugn.texi: Regenerate.

ada: Fix location of pragmas coming from aspects in top-level instances

This patch fixes an AST anomaly where pragmas that correspond to aspects
of a generic package declaration appeared as the auxiliary declarations
of the compilation unit for the instantiated package body.

In particular, this anomaly happened for aspect Annotate and affected
GNATprove, which didn't pick pragma corresponding to this aspect.

gcc/ada/

* sem_ch12.adb (Build_Instance_Compilation_Unit_Nodes): Relocate
auxiliary declarations from the original compilation unit to the
newly created compilation unit for the spec.

ada: Remove unreferenced Rtsfind entries

Remove unreferenced entries for finding runtime units and runtime
entities by the compiler. Code cleanup using basic grep scripting.

gcc/ada/

* rtsfind.ads
(RTU_Id): Remove unreferenced packages; fix whitespace.
(RE_Id): Remove unreferenced entities; add comment about entity
that is only used by GNATprove and not by GNAT.

ada: Remove unreferenced C macro from OS constants template

The STR/STR1 macros in OS constants template has been unreferenced since
2005, so we can safely remove them.

gcc/ada/

* s-oscons-tmplt.c (STR, STR1): Remove.

ada: Document Long_Long_Long_Size parameter for -gnateT

This was overlooked when the new parameter was created.

gcc/ada/

* doc/gnat_ugn/building_executable_programs_with_gnat.rst
(-gnateT): Document new parameter Long_Long_Long_Size.
* gnat_ugn.texi: Regenerate.

ada: Improve CUDA host-side and device-side binder support

Binder-generated code is not allowed to use Ada2012 syntax. In order to
specify an aspect, a pragma must be used.

gcc/ada/

* bindgen.adb: When the binder is invoked for the device, specify
the CUDA_Global aspect for the adainit and adafinal procedures via
a pragma instead of via an aspect_specification.

ada: Document support for the mold linker

gcc/ada/

* doc/gnat_ugn/building_executable_programs_with_gnat.rst
(Linker Switches): Document support for mold along with gold; add some
advice regarding OpenSSL in the Pro version.
* gnat_ugn.texi: Regenerate.

ada: Make Original_Aspect_Pragma_Name more precise

This commit makes Original_Aspect_Pragma_Name more precise in cases
where there is a second level of indirection caused by pragmas being
turned into Check pragmas.

gcc/ada/

* sem_util.adb (Original_Aspect_Pragma_Name): Check for Check
pragmas.

ada: Delay expansion of iterator specification in preanalysis

When preanalysing spec expression (e.g. expression of an expression
function), the name of iterator specification should not be expanded.

This patch simplifies a complicated condition for delaying expansion
within quantified expressions and iterated component associations.

gcc/ada/

* sem_ch5.adb (Analyze_Iterator_Specification): Delay expansion
based on Full_Analysis flag.

ada: Delay expansion of iterated component association

When preanalysing spec expression (e.g. expression of an expression
function), the name of iterator specification within an iterated
component association should not be expanded, especially in GNATprove
mode.

gcc/ada/

* sem_ch5.adb (Analyze_Iterator_Specification): Delay expansion of
for iterated component association just like it is done within
quantified expression.

ada: Only reject volatile ghost objects when SPARK_Mode is On

SPARK rule that forbids ghost volatile objects is only affecting proof
and not generation of object code. It is now only applied where SPARK_Mode
is On. This flexibility is needed to compile code automatically instrumented
by GNATcoverage.

gcc/ada/

* contracts.adb (Analyze_Object_Contract): Check SPARK_Mode before
applying SPARK rule.

ada: Improve accessibility check generation

Improve accessibility check generation by more precisely identifying cases in
which an Original_Node call is needed.

Instead of grabbing the Original_Node of a prefix in all cases (since this
can cause issues where unanalyzed instance names get referenced) we only
obtain the original node when said prefix comes as a result of expanding
function calls.

gcc/ada/

* sem_util.adb
(Accessibility_Level): Modify indexed and selected components case
by reducing the scope where Original_Node gets used.

ada: Remove GNATmetric's documentation from GNAT's documentation

gcc/ada/

* doc/gnat_ugn/gnat_utility_programs.rst: Remove documentation for
gnatmetric.

ada: Remove socket definitions for ancient MinGW

Modern MinGW defines _WIN32_WINNT as 0xa00, so there is no need go guard
against it being lower than 0x0600 or setting it to 0x0501.

gcc/ada/

* gsocket.h: Remove redefinition of _WIN32_WINNT.
* mingw32.h: Remove conditional definition of _WIN32_WINNT.

ada: Remove definition of MAXPATHLEN for ancient MinGW

Modern MinGW defines MAXPATHLEN in sys/param.h, so better to use it
directly.

gcc/ada/

* mingw32.h: Remove condition definition of MAXPATHLEN; the include
directive for stdlib.h was most likely intended to provide the
MAX_PATH.

ada: Deconstruct build support for ancient MinGW

Remove conditional C code for building GNAT with MinGW earlier than 2.0,
which was released in 2007.

gcc/ada/

* adaint.c: Remove conditional #include directives for old MinGW.
* cal.c: Always include winsock.h, since it is part of modern
MinGW.
* cstreams.c: Remove workaround for old MinGW.
* expect.c: Remove conditional #include directive for old MinGW.
* mingw32.h: Remove STD_MINGW and OLD_MINGW declarations.
* sysdep.c: Remove conditional #include directive for old MinGW.

ada: Tune comment of routine for detecting junk names

Reword comment to avoid repetition between spec and body.

gcc/ada/

* sem_warn.ads (Has_Junk_Name): Reword comment.

Small tweaks.

Merge #1527 #1529 #1530 #1534

1527: rust: Add -frust-compile-until option r=CohenArthur a=CohenArthur

This option helps ensure that we do not introduce regressions on various
parts of the compilation pipeline. For example, a testcase (or testsuite
from the `testing` project) might pass attribute checking, expansion and
lowering, but fail during typechecking. Should a change suddenly make
that testcase fail expansion, we would not be able to notice it. By
generating tests that run up until expansion, typechecking, compilation
and so forth we ensure that no regressions are added accidentally to
already failing tests/testsuites.

1529: const generics: Make sure const generic types are visited properly in all contexts r=CohenArthur a=CohenArthur

Closes #1360

1530: const generics: Forbid default values in Functions, Traits and Impls r=CohenArthur a=CohenArthur

Fixes #1310

1534: module lowering: Do not append null pointers as items r=CohenArthur a=CohenArthur

Some module items do not need to get lowered to HIR such as `macro_rules!` definitions. Hence, module lowering should act the same as crate lowering: Only emplace back the lowered item if it is a valid pointer

Fixes #1533

Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>

rust: Add -frust-compile-until option

This option helps ensure that we do not introduce regressions on various
parts of the compilation pipeline. For example, a testcase (or testsuite
from the `testing` project) might pass attribute checking, expansion and
lowering, but fail during typechecking. Should a change suddenly make
that testcase fail expansion, we would not be able to notice it. By
generating tests that run up until expansion, typechecking, compilation
and so forth we ensure that no regressions are added accidentally to
already failing tests/testsuites.

ranger: remove unused function

gcc/ChangeLog:

* value-range.cc (tree_compare): Remove unused function.

Merge #1532

1532: attributes: Add #[macro_use] as builtin r=CohenArthur a=CohenArthur

Fixes #1531

I think the checking for builtin attributes should definitely be moved to the `AttributeChecker` visitor. It's also a bit messy at the moment considering it isn't in effect on *everything*, simply some nodes such as `Module`s. Thoughts?

Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>

rs6000: Fix the condition with frame_pointer_needed_indeed [PR96072]

As PR96072 shows, the code adding REG_CFA_DEF_CFA reg note
makes one assumption that we have emitted one insn which
restores the frame pointer previously.  That part of code
was guarded with flag frame_pointer_needed before, it was
consistent, but it was replaced with flag
frame_pointer_needed_indeed since commit r10-7981.  It
caused ICE due to unexpected NULL insn.

PR target/96072

gcc/ChangeLog:

* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): Update the
condition for adding REG_CFA_DEF_CFA reg note with
frame_pointer_needed_indeed.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr96072.c: New test.

testsuite: Fix up avx256-unaligned-store-3.c test.

gcc/testsuite/ChangeLog:

PR target/94962
* gcc.target/i386/avx256-unaligned-store-3.c: Add -mno-avx512f

rs6000: Fix condition of define_expand vec_shr_<mode> [PR100645]

PR100645 exposes one latent bug in define_expand vec_shr_<mode>
that the current condition TARGET_ALTIVEC is too loose.  The
mode iterator VEC_L contains a few modes, they are not always
supported as vector mode, VECTOR_UNIT_ALTIVEC_OR_VSX_P should
be used like some other VEC_L usages.

PR target/100645

gcc/ChangeLog:

* config/rs6000/vector.md (vec_shr_<mode>): Replace condition
TARGET_ALTIVEC with VECTOR_UNIT_ALTIVEC_OR_VSX_P.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr100645.c: New test.

Support 2-instruction vector shuffle for V4SI/V4SF in ix86_expand_vec_perm_const_1.

2022-09-23  Hongtao Liu  <hongtao.liu@intel.com>
    Liwei Xu  <liwei.xu@intel.com>

gcc/ChangeLog:

PR target/53346
* config/i386/i386-expand.cc (expand_vec_perm_shufps_shufps):
New function.
(ix86_expand_vec_perm_const_1): Insert
expand_vec_perm_shufps_shufps at the end of 2-instruction
expand sequence.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr53346-1.c: New test.
* gcc.target/i386/pr53346-2.c: New test.
* gcc.target/i386/pr53346-3.c: New test.
* gcc.target/i386/pr53346-4.c: New test.

Daily bump.

fortran: Support clobbering of derived types [PR41453]

This adds support for clobbering of non-polymorphic derived type
variables, when they are passed as actual argument whose associated
dummy has the INTENT(OUT) attribute.

We avoid to play with non-constant type sizes or class descriptors by
requiring that the types are derived (not class) and strictly matching,
and by excluding parameterized derived types.

Types that are used in the callee are also excluded: they are types with
allocatable components (the components will be deallocated), and
finalizable types or types with finalizable components (they will be
passed to finalization routines).

PR fortran/41453

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Allow strictly
matching derived types.

gcc/testsuite/ChangeLog:

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

fortran: Support clobbering of allocatables and pointers [PR41453]

This adds support for clobbering of allocatable and pointer scalar
variables passed as actual argument to a subroutine when the associated
dummy has the INTENT(OUT) attribute.
Support was explicitly disabled (since the beginning for pointers, since
r11-7315-g2df374b337a5f6cf5528e91718e4e12e4006b7ae for allocatables),
but the clobber generation code seems to support it well, as
demonstrated by the newly added testcase.

PR fortran/41453
PR fortran/99169

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove conditions
on ALLOCATABLE and POINTER attributes guarding clobber
generation.

gcc/testsuite/ChangeLog:

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

fortran: Support clobbering of ASSOCIATE variables [PR41453]

This is in spirit a revert of:
r9-3051-gc109362313623d83fe0a5194bceaf994cf0c6ce0

That commit added a condition to avoid generating ICE with clobbers
of ASSOCIATE variables.
The test added at that point continues to pass if we remove that
condition now.

PR fortran/41453
PR fortran/87401

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
disabling clobber generation for ASSOCIATE variables.

gcc/testsuite/ChangeLog:

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

fortran: Support clobbering of SAVE variables [PR41453]

This removes a condition added in:
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2.

That commit added a condition to avoid generating ICE with clobbers
of variables with the SAVE attribute.
The test added at that point continues to pass if we remove that
condition now.

PR fortran/41453
PR fortran/87395

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
on SAVE attribute guarding clobber generation.

gcc/testsuite/ChangeLog:

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

fortran: Support clobbering of reference variables [PR41453]

This adds support for clobbering of variables passed by reference,
when the reference is forwarded to a subroutine as actual argument
whose associated dummy has the INTENT(OUT) attribute.
This was explicitly disabled by a condition added with
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2 and removing that
condition seems to work, as demonstrated by the new testcase.

PR fortran/41453
PR fortran/87395

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
disabling clobber generation for dummy variables.  Remove
obsolete comment.

gcc/testsuite/ChangeLog:

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

fortran: Support clobbering with implicit interfaces [PR105012]

Before procedure calls, we clobber actual arguments whose associated
dummy is INTENT(OUT).  This only applies to procedures with explicit
interfaces, as the knowledge of the interface is necessary to know
whether an argument has the INTENT(OUT) attribute.

This change also enables clobber generation for procedure calls without
explicit interface, when the procedure has been defined in the same
file because we can use the dummy arguments' characteristics from the
procedure definition in that case.

The knowledge of the dummy characteristics is directly available through
gfc_actual_arglist’s associated_dummy pointers which have been populated
as a side effect of calling gfc_check_externals.

PR fortran/105012

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Use dummy
information from associated_dummy if there is no information
from the procedure interface.

gcc/testsuite/ChangeLog:

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

Co-Authored-By: Mikael Morin <mikael@gcc.gnu.org>

fortran: Move clobbers after evaluation of all arguments [PR106817]

For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call.  This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we passed an undefined value in that case.

With this change, clobbers are collected separatedly and appended
to the procedure call preliminary code after all the arguments have been
evaluated.

PR fortran/106817

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Collect all clobbers
to their own separate block.  Append the block of clobbers to
the procedure preliminary block after the argument evaluation
codes for all the arguments.

gcc/testsuite/ChangeLog:

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

fortran: Fix invalid function decl clobber ICE [PR105012]

The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself.  This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable.  This change fixes the problem by getting the decl from the
just-retrieved variable reference after the call to
gfc_conv_expr_reference, instead of copying it from the frontend symbol.

PR fortran/105012

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Retrieve variable
from the just calculated variable reference.

gcc/testsuite/ChangeLog:

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

fortran: Move the clobber generation code

This change inlines the clobber generation code from
gfc_conv_expr_reference to the single caller from where the add_clobber
flag can be true, and removes the add_clobber argument.

What motivates this is the standard making the procedure call a cause
for a variable to become undefined, which translates to a clobber
generation, so clobber generation should be closely related to procedure
call generation, whereas it is rather orthogonal to variable reference
generation.  Thus the generation of the clobber feels more appropriate
in gfc_conv_procedure_call than in gfc_conv_expr_reference.

Behaviour remains unchanged.

gcc/fortran/ChangeLog:

* trans.h (gfc_conv_expr_reference): Remove add_clobber
argument.
* trans-expr.cc (gfc_conv_expr_reference): Ditto. Inline code
depending on add_clobber and conditions controlling it ...
(gfc_conv_procedure_call): ... to here.

Fix typo in chapter level for RISC-V attributes

The "RISC-V specific attributes" section should be at the same level
as "PowerPC-specific attributes".

gcc/ChangeLog:

* doc/sourcebuild.texi: Fix chapter level.

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

Daily bump.

Update expected warnings post merge

Merge remote-tracking branch 'mainline/master' into ibuclaw/targetrustm

libstdc++: Simplify detection idiom using concepts

Add a simpler definition of std::__detected_or using concepts.  This
also replaces the __detector::value_t member which should have been using
a reserved name.

Use __detected_or in pointer_traits.

libstdc++-v3/ChangeLog:

* include/bits/alloc_traits.h (allocator_traits::is_always_equal):
Only instantiate is_empty if needed.
* include/bits/ptr_traits.h (__ptr_traits_impl::difference_type)
(__ptr_traits_impl::rebind): Use __detected_or.
* include/experimental/type_traits (is_same_v): Add a partial
specialization instead of instantiating the std::is_same class
template.
(detected_t): Redefine in terms of detected_or_t.
(is_detected, is_detected_v): Redefine in terms of detected_t.
* include/std/type_traits [__cpp_concepts] (__detected_or): Add
new definition using concepts.
(__detector::value_t): Rename to __is_detected.
* testsuite/17_intro/names.cc: Check value_t isn't used.

openmp: Fix ICE with taskgroup at -O0 -fexceptions [PR107001]

The following testcase ICEs because with -O0 -fexceptions GOMP_taskgroup_end
call isn't directly followed by GOMP_RETURN statement, but there are some
conditionals to handle exceptions and we fail to find the correct GOMP_RETURN.

The fix is to treat taskgroup similarly to target data, both of these constructs
emit a try { body } finally { end_call } around the construct's body during
gimplification and we need to see proper construct nesting during gimplification
and omp lowering (including nesting of regions checks), but during omp expansion
we don't really need their nesting anymore, all we need is emit something at
the start of the region and the end of the region is the end API call we've
already emitted during gimplification.  For target data, we weren't adding
GOMP_RETURN statement during omp lowering, so after that pass it is treated
merely like stand-alone omp directives.  This patch does the same for
taskgroup too.

2022-09-24  Jakub Jelinek  <jakub@redhat.com>

PR c/107001
* omp-low.cc (lower_omp_taskgroup): Don't add GOMP_RETURN statement
at the end.
* omp-expand.cc (build_omp_regions_1): Clarify GF_OMP_TARGET_KIND_DATA
is not stand-alone directive.  For GIMPLE_OMP_TASKGROUP, also don't
update parent.
(omp_make_gimple_edges) <case GIMPLE_OMP_TASKGROUP>: Reset
cur_region back after new_omp_region.

* c-c++-common/gomp/pr107001.c: New test.

openmp, c: Tighten up c_tree_equal [PR106981]

This patch changes c_tree_equal to work more like cp_tree_equal, be
more strict in what it accepts.  The ICE on the first testcase was
due to INTEGER_CST wi::wide (t1) == wi::wide (t2) comparison which
ICEs if the two constants have different precision, but as the second
testcase shows, being too lenient in it can also lead to miscompilation
of valid OpenMP programs where we think certain expression is the same
even when it isn't and can be guaranteed at runtime to represent different
memory location.  So, the patch looks through only NON_LVALUE_EXPRs
and for constants as well as casts requires that the types match before
actually comparing the constant values or recursing on the cast operands.

2022-09-24  Jakub Jelinek  <jakub@redhat.com>

PR c/106981
gcc/c/
* c-typeck.cc (c_tree_equal): Only strip NON_LVALUE_EXPRs at the
start.  For CONSTANT_CLASS_P or CASE_CONVERT: return false if t1 and
t2 have different types.
gcc/testsuite/
* c-c++-common/gomp/pr106981.c: New test.
libgomp/
* testsuite/libgomp.c-c++-common/pr106981.c: New test.

Daily bump.

libstdc++: Add test for type traits not having friend access

This ensures that the std::is_assignable and std::is_assignable_v
traits are evaluated "in a context unrelated" to the argument types.

libstdc++-v3/ChangeLog:

* testsuite/20_util/is_assignable/requirements/access.cc:
New test.

libstdc++: Fix std::is_nothrow_invocable_r for uncopyable prvalues [PR91456]

This is the last missing piece of PR 91456.

This also removes the only use of the C++11 version of
std::is_nothrow_invocable, which was just renamed to
__is_nothrow_invocable_lib. We can remove that now.

libstdc++-v3/ChangeLog:

PR libstdc++/91456
* include/std/type_traits (__is_nothrow_invocable_lib): Remove.
(__is_invocable_impl::__nothrow_type): New member type which
checks if the conversion can throw.
(__is_nt_invocable_impl): Replace class template with alias
template to __is_nt_invocable_impl::__nothrow_type.
* testsuite/20_util/is_nothrow_invocable/91456.cc: New test.
* testsuite/20_util/is_nothrow_convertible/value.cc: Remove
macro used by value_ext.cc test.
* testsuite/20_util/is_nothrow_convertible/value_ext.cc: Remove
test for non-standard __is_nothrow_invocable_lib trait.

testsuite: Add more C2x tests

There are some new requirements in C2x where GCC already behaves as
required (for all standard versions), where previous standard versions
either had weaker requirements permitting the GCC behavior, or were
arguably defective in what they said in that area.  Add tests that
specifically verify GCC behaves as expected for C2x.  (There may be
further such tests to be added in future for already-supported C2x
features.)

* Compound literals in function parameter lists have automatic storage
  duration.  (This is a case where strictly this wasn't specified by
  previous standard versions, but it seems to make more sense to treat
  this as a defect in those versions than to implement something
  different conditionally for those versions.)

* Concatenation of string literals with different prefixes is a
  constraint violation (previously it was implementation-defined
  whether it was permitted, and GCC did not permit it).

* UCNs above 0x10ffff are a constraint violation; previously they were
  implicitly undefined behavior by virtue of wording about "designates
  the character" referring to code points outside the ISO/IEC 10646
  range; GCC diagnosed such UCNs since commit
  0900e29cdbc533fecf2a311447bbde17f101bbd6 (Sep 2019).  The test I
  added also has more detailed coverage of what lower-valued UCNs are
  accepted.

Tested for x86_64-pc-linux-gnu.

* gcc.dg/c2x-complit-1.c, gcc.dg/c2x-concat-1.c,
gcc.dg/cpp/c2x-ucn-1.c: New tests.

testsuite: Skip intrinsics test if arm

In the test cases, it's clearly written that intrinsics is not
implemented on arm*. A simple xfail does not help since there are
link error and that would cause an UNRESOLVED testcase rather than
XFAIL.
By changing to dg-skip-if, the entire test case is omitted.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/advsimd-intrinsics/vld1x2.c: Replace
dg-xfail-if with dg-skip-if.
* gcc.target/aarch64/advsimd-intrinsics/vld1x3.c: Likewise.
* gcc.target/aarch64/advsimd-intrinsics/vld1x4.c: Likewise.

Co-Authored-By: Yvan ROUX <yvan.roux@foss.st.com>
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>

c++: Implement __is_{nothrow_,}convertible [PR106784]

To improve compile times, the C++ library could use compiler built-ins
rather than implementing std::is_convertible (and _nothrow) as class
templates.  This patch adds the built-ins.  We already have
__is_constructible and __is_assignable, and the nothrow forms of those.

Microsoft (and clang, for compatibility) also provide an alias called
__is_convertible_to.  I did not add it, but it would be trivial to do
so.

I noticed that our __is_assignable doesn't implement the "Access checks
are performed as if from a context unrelated to either type" requirement,
therefore std::is_assignable / __is_assignable give two different results
here:

  class S {
    operator int();
    friend void g(); // #1
  };

  void
  g ()
  {
    // #1 doesn't matter
    static_assert(std::is_assignable<int&, S>::value, "");
    static_assert(__is_assignable(int&, S), "");
  }

This is not a problem if __is_assignable is not meant to be used by
the users.

This patch doesn't make libstdc++ use the new built-ins, but I had to
rename a class otherwise its name would clash with the new built-in.

PR c++/106784

gcc/c-family/ChangeLog:

* c-common.cc (c_common_reswords): Add __is_convertible and
__is_nothrow_convertible.
* c-common.h (enum rid): Add RID_IS_CONVERTIBLE and
RID_IS_NOTHROW_CONVERTIBLE.

gcc/cp/ChangeLog:

* constraint.cc (diagnose_trait_expr): Handle CPTK_IS_CONVERTIBLE
and CPTK_IS_NOTHROW_CONVERTIBLE.
* cp-objcp-common.cc (names_builtin_p): Handle RID_IS_CONVERTIBLE
RID_IS_NOTHROW_CONVERTIBLE.
* cp-tree.h (enum cp_trait_kind): Add CPTK_IS_CONVERTIBLE and
CPTK_IS_NOTHROW_CONVERTIBLE.
(is_convertible): Declare.
(is_nothrow_convertible): Likewise.
* cxx-pretty-print.cc (pp_cxx_trait_expression): Handle
CPTK_IS_CONVERTIBLE and CPTK_IS_NOTHROW_CONVERTIBLE.
* method.cc (is_convertible): New.
(is_nothrow_convertible): Likewise.
* parser.cc (cp_parser_primary_expression): Handle RID_IS_CONVERTIBLE
and RID_IS_NOTHROW_CONVERTIBLE.
(cp_parser_trait_expr): Likewise.
* semantics.cc (trait_expr_value): Handle CPTK_IS_CONVERTIBLE and
CPTK_IS_NOTHROW_CONVERTIBLE.
(finish_trait_expr): Likewise.

libstdc++-v3/ChangeLog:

* include/std/type_traits: Rename __is_nothrow_convertible to
__is_nothrow_convertible_lib.
* testsuite/20_util/is_nothrow_convertible/value_ext.cc: Likewise.

gcc/testsuite/ChangeLog:

* g++.dg/ext/has-builtin-1.C: Enhance to test __is_convertible and
__is_nothrow_convertible.
* g++.dg/ext/is_convertible1.C: New test.
* g++.dg/ext/is_convertible2.C: New test.
* g++.dg/ext/is_nothrow_convertible1.C: New test.
* g++.dg/ext/is_nothrow_convertible2.C: New test.

RISC-V: make USE_LOAD_ADDRESS_MACRO easier to understand

The current macro has several && and || making it really hard to understand
the first time.

Signed-off-by: Vineet Gupta <vineetg@rivosinc.com>
gcc/ChangeLog:

* config/riscv/riscv.h (LOCAL_SYM_P): New.
(USE_LOAD_ADDRESS_MACRO): Simplify by calling LOCAL_SYM_P.

RISC-V: Add RVV machine modes.

gcc/ChangeLog:

* config/riscv/riscv-modes.def (VECTOR_BOOL_MODE): Add RVV mask modes.
(ADJUST_NUNITS): Adjust nunits using riscv_vector_chunks.
(ADJUST_ALIGNMENT): Adjust alignment.
(ADJUST_BYTESIZE): Adjust bytesize using riscv_vector_chunks.
(RVV_MODES): New macro.
(VECTOR_MODE_WITH_PREFIX): Add RVV vector modes.
(VECTOR_MODES_WITH_PREFIX): Add RVV vector modes.

RISC-V: Support poly move manipulation and selftests.

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc: Change "static void" to "void".
* config.gcc: Add riscv-selftests.o
* config/riscv/predicates.md: Allow const_poly_int.
* config/riscv/riscv-protos.h (riscv_reinit): New function.
(riscv_parse_arch_string): change as exten function.
(riscv_run_selftests): New function.
* config/riscv/riscv.cc (riscv_cannot_force_const_mem): Don't allow poly
into const pool.
(riscv_report_v_required): New function.
(riscv_expand_op): New function.
(riscv_expand_mult_with_const_int): New function.
(riscv_legitimize_poly_move): Ditto.
(riscv_legitimize_move): New function.
(riscv_hard_regno_mode_ok): Add VL/VTYPE register allocation and fix
vector RA.
(riscv_convert_vector_bits): Fix riscv_vector_chunks configuration for
-marh no 'v'.
(riscv_reinit): New function.
(TARGET_RUN_TARGET_SELFTESTS): New target hook support.
* config/riscv/t-riscv: Add riscv-selftests.o.
* config/riscv/riscv-selftests.cc: New file.

gcc/testsuite/ChangeLog:

* selftests/riscv/empty-func.rtl: New test.

libstdc++: Micro-optimizaion for std::bitset stream extraction

Don't bother trying to copy any characters for bitset<0>.

libstdc++-v3/ChangeLog:

* include/std/bitset (operator>>): Do not copy for N==0.
* testsuite/20_util/bitset/io/input.cc: Add comment.

tree-optimization/106922 - extend same-val clobber FRE

The following extends the skipping of same valued stores to
handle an arbitrary number of them as long as they are from the
same value (which we now record).  That's an obvious extension
which allows to optimize the m_engaged member of std::optional
more reliably.

PR tree-optimization/106922
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Allow
an arbitrary number of same valued skipped stores.

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

frange: Make the setter taking trees a wrapper.

The frange setter does all its work in trees.  This incurs a penalty
for the real_value variants because they must wrap their arguments
into a tree and pass it to the tree setter, which will then do the
opposite.  This is leftovers from the irange setter.

Even though the we still need constructors taking trees so we can
interact with the tree world, there's no sense penalizing the rest of
the implementation.

Tested on x86-64 Linux.

gcc/ChangeLog:

* value-range.cc (frange::set): Swap setters such that the one
accepting REAL_VALUE_TYPE does all the work.

libstdc++: Enable constexpr std::bitset for debug mode

We already disable all debug mode checks for C++11 and later, so we can
easily make everything constexpr. This fixes the FAIL results for the
new tests when using -D_GLIBCXX_DEBUG.

Also fix some other tests failing with non-default test flags.

libstdc++-v3/ChangeLog:

* include/debug/bitset (__debug::bitset): Add constexpr to all
member functions.
(operator&, operator|, operator^): Add inline and constexpr.
(operator>>, operator<<): Add inline.
* testsuite/20_util/bitset/access/constexpr.cc: Only check using
constexpr std::string for the cxx11 ABI.
* testsuite/20_util/bitset/cons/constexpr_c++23.cc: Likewise.
* testsuite/20_util/headers/bitset/synopsis.cc: Check constexpr
for C++23.

libstdc++: Optimize std::bitset<N>::to_string

This makes to_string approximately twice as fast at any optimization
level. Instead of iterating through every bit, jump straight to the next
bit that is set, by using _Find_first and _Find_next.

libstdc++-v3/ChangeLog:

* include/std/bitset (bitset::_M_copy_to_string): Find set bits
instead of iterating over individual bits.

aarch64: Add Arm Neoverse V2 support

This patch adds -mcpu/-mtune support for the Arm Neoverse V2 core.
This updates the internal references to "demeter", but leaves "demeter" as an
accepted value to -mcpu/-mtune as it appears in the released GCC 12 series.

Bootstrapped and tested on aarch64-none-linux-gnu.

gcc/ChangeLog:

* config/aarch64/aarch64-cores.def (neoverse-v2): New entry.
(demeter): Update tunings to neoversev2.
* config/aarch64/aarch64-tune.md: Regenerate.
* config/aarch64/aarch64.cc (demeter_addrcost_table): Rename to
neoversev2_addrcost_table.
(demeter_regmove_cost): Rename to neoversev2_addrcost_table.
(demeter_advsimd_vector_cost): Rename to neoversev2_advsimd_vector_cost.
(demeter_sve_vector_cost): Rename to neoversev2_sve_vector_cost.
(demeter_scalar_issue_info): Rename to neoversev2_scalar_issue_info.
(demeter_advsimd_issue_info): Rename to neoversev2_advsimd_issue_info.
(demeter_sve_issue_info): Rename to neoversev2_sve_issue_info.
(demeter_vec_issue_info): Rename to neoversev2_vec_issue_info.
Update references to above.
(demeter_vector_cost): Rename to neoversev2_vector_cost.
(demeter_tunings): Rename to neoversev2_tunings.
(aarch64_vec_op_count::rename_cycles_per_iter): Use
neoversev2_sve_issue_info instead of demeter_sve_issue_info.
* doc/invoke.texi (AArch64 Options): Document neoverse-v2.

MAINTAINERS: Add myself to Write After Approval

ChangeLog:

* MAINTAINERS (Write After Approval): Add myself.

testsuite: make check-functions-body dump expected and seen cases on failure.

Often times when a check_function_body check fails it can be quite hard to
figure out why as no additional information is provided.

This changes it so that on failures it prints out the regex expression it's
using and the text it's comparing against to the verbose log.

This makes it much easier to figure out why a test has failed.

gcc/testsuite/ChangeLog:

* lib/scanasm.exp (check_function_body): Add debug output to verbose log
on failure.

frange: drop endpoints to min/max representable numbers for -ffinite-math-only.

Similarly to how we drop NANs to UNDEFINED when -ffinite-math-only, I
think we can drop the numbers outside of the min/max representable
numbers to the representable number.

This means the endpoings to VR_VARYING for -ffinite-math-only can now
be the min/max representable, instead of -INF and +INF.

Saturating in the setter means that the upcoming implementation for
binary operators no longer have to worry about doing the right
thing for -ffinite-math-only.  If the range goes outside the limits,
it'll get chopped down.

Tested on x86-64 Linux.

gcc/ChangeLog:

* range-op-float.cc (build_le): Use vrp_val_*.
(build_lt): Same.
(build_ge): Same.
(build_gt): Same.
* value-range.cc (frange::set): Chop ranges outside of the
representable numbers for -ffinite-math-only.
(frange::normalize_kind): Use vrp_val*.
(frange::verify_range): Same.
(frange::set_nonnegative): Same.
(range_tests_floats): Remove tests that depend on -INF and +INF.
* value-range.h (real_max_representable): Add prototype.
(real_min_representable): Same.
(vrp_val_max): Set max representable number for
-ffinite-math-only.
(vrp_val_min): Same but for min.
(frange::set_varying): Use vrp_val*.

Add debug functions for REAL_VALUE_TYPE.

We currently have no way of dumping REAL_VALUE_TYPEs when debugging.

Tested on a gdb session examining the real value 10.0:

(gdb) p min
$9 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 4, sig = {0, 0, 11529215046068469760}}
(gdb) p debug (min)
0x0.ap+4

gcc/ChangeLog:

* real.cc (debug): New.