RA: Implement reuse of equivalent memory for caller saves optimization (2nd version)

The test pr103541.c shows opportunity to reuse memory with constant address for
caller saves optimization for constant or pure function call.  The patch
implements the memory reuse.

        PR rtl-optimization/103541
        PR rtl-optimization/108711

gcc/ChangeLog:

* ira.h (struct ira_reg_equiv_s): Add new field caller_save_p.
* ira.cc (validate_equiv_mem): Check memref address variance.
(no_equiv): Clear caller_save_p flag.
(update_equiv_regs): Define caller save equivalence for
valid_combine.
(setup_reg_equiv): Clear defined_p flag for caller save equivalence.
* lra-constraints.cc (lra_copy_reg_equiv): Add new arg
call_save_p.  Use caller save equivalence depending on the arg.
(split_reg): Adjust the call.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr103541.c: New.
* g++.target/i386/pr108711.C: New.

Fortran: catch invalid kind in character conversion [PR69636,PR103779]

gcc/fortran/ChangeLog:

PR fortran/69636
PR fortran/103779
* intrinsic.cc (gfc_convert_chartype): Recover on invalid character
kind in conversion instead of generating an internal error.

gcc/testsuite/ChangeLog:

PR fortran/69636
PR fortran/103779
* gfortran.dg/pr103779.f90: New test.

Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>

i386: Call get_available_features for all CPUs with max_level >= 1 [PR100758]

get_available_features doesn't depend on cpu_model2->__cpu_{family,model}
and just sets stuff up based on CPUID leaf 1, or some extended ones,
so I wonder why are we calling it separately for Intel, AMD and Zhaoxin
and not for all other CPUs too?  I think various programs in the wild
which aren't using __builtin_cpu_{is,supports} just check the various CPUID
leafs and query bits in there, without blacklisting unknown CPU vendors,
so I think even __builtin_cpu_supports ("sse2") etc. should be reliable
if those VENDOR_{CENTAUR,CYRIX,NSC,OTHER} CPUs set those bits in CPUID leaf
1 or some extended ones.  Calling it for all CPUs also means it can be
inlined because there will be just a single caller.

I have tested it on Intel and Martin tested it on AMD, but can't test it
on non-Intel/AMD; for Intel/AMD/Zhaoxin it should be really no change in
behavior.

2023-02-09  Jakub Jelinek  <jakub@redhat.com>

PR target/100758
* common/config/i386/cpuinfo.h (get_zhaoxin_cpu): Formatting fixes.
(cpu_indicator_init): Call get_available_features for all CPUs with
max_level >= 1, rather than just Intel, AMD or Zhaoxin.  Formatting
fixes.

match.pd: Simplify BFR of insert when extracting exactly all inserted bits [PR108688]

On Thu, Feb 09, 2023 at 09:16:17AM +0100, Richard Biener via Gcc-patches wrote:
> Hmm.  Can we handle the case of the extraction exactly covering the
> insertion separately then and simplify to plain @1?

I was suggesting that in the PR.  Here it is as an incremental patch
on top of Andrew's patch.

On the newly added testcase the ifcvt-folding difference without/with the
incremental patch is:
--- pr108688.c.171t.ifcvt_      2023-02-09 10:47:30.169916845 +0100
+++ pr108688.c.171t.ifcvt       2023-02-09 10:48:44.942793453 +0100
@@ -25,6 +25,8 @@ Number of blocks in CFG: 11
 Number of blocks to update: 5 ( 45%)

+Applying pattern match.pd:7487, gimple-match.cc:243200
+Applying pattern match.pd:3987, gimple-match.cc:75423
 Matching expression match.pd:1677, gimple-match.cc:209
 Applying pattern match.pd:1733, gimple-match.cc:109481
 Matching expression match.pd:2393, gimple-match.cc:852
@@ -70,7 +72,6 @@ void foo ()
   signed char _29;
   <unnamed-signed:7> _30;
   unsigned int ivtmp_33;
-  <unnamed-signed:7> _ifc__35;
   unsigned char _ifc__37;
   unsigned char _ifc__38;
   unsigned char _ifc__39;
@@ -91,8 +92,7 @@ void foo ()
   _2 = (<unnamed-signed:7>) a.0_1;
   _ifc__38 = u.D.2741;
   _ifc__39 = BIT_INSERT_EXPR <_ifc__38, _2, 0 (7 bits)>;
-  _ifc__35 = BIT_FIELD_REF <_ifc__39, 7, 0>;
-  _4 = (signed char) _ifc__35;
+  _4 = (signed char) _2;
   b.1_5 = b;
   _6 = (signed char) b.1_5;
   _7 = _4 ^ _6;

2023-02-09  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/108688
* match.pd (bit_field_ref [bit_insert]): Simplify BIT_FIELD_REF
of BIT_INSERT_EXPR extracting exactly all inserted bits even
when without mode precision.  Formatting fixes.

* gcc.c-torture/compile/pr108688-1.c: Add PR number as comment.
* gcc.dg/pr108688.c: New test.

match.pd: When simplifying BFR of an insert, require a mode precision integral type [PR108688]

The same problem as PR 88739 has crept in but
this time in match.pd when simplifying bit_field_ref of
an bit_insert. That is we are generating a BIT_FIELD_REF
of a non-mode-precision integral type.

PR tree-optimization/108688
* match.pd (bit_field_ref [bit_insert]): Avoid generating
BIT_FIELD_REFs of non-mode-precision integral operands.

* gcc.c-torture/compile/pr108688-1.c: New test.

OpenMP/Fortran: Partially fix non-rect loop nests [PR107424]

This patch ensures that loop bounds depending on outer loop vars use the
proper TREE_VEC format. It additionally gives a sorry if such an outer
var has a non-one/non-minus-one increment as currently a count variable
is used in this case (see PR).

Finally, it avoids 'count' and just uses a local loop variable if the
step increment is +/-1.

PR fortran/107424

gcc/fortran/ChangeLog:

* trans-openmp.cc (struct dovar_init_d): Add 'sym' and
'non_unit_incr' members.
(gfc_nonrect_loop_expr): New.
(gfc_trans_omp_do): Call it; use normal loop bounds
for unit stride - and only create local loop var.

libgomp/ChangeLog:

* testsuite/libgomp.fortran/non-rectangular-loop-1.f90: New test.
* testsuite/libgomp.fortran/non-rectangular-loop-1a.f90: New test.
* testsuite/libgomp.fortran/non-rectangular-loop-2.f90: New test.
* testsuite/libgomp.fortran/non-rectangular-loop-3.f90: New test.
* testsuite/libgomp.fortran/non-rectangular-loop-4.f90: New test.
* testsuite/libgomp.fortran/non-rectangular-loop-5.f90: New test.

gcc/testsuite/ChangeLog:

* gfortran.dg/goacc/privatization-1-compute-loop.f90: Update dg-note.
* gfortran.dg/goacc/privatization-1-routine_gang-loop.f90: Likewise.

docs: add caveat for __builtin_cpu_supports

Document that the function does not work correctly for old
VIA processors.

PR target/100758

gcc/ChangeLog:

* doc/extend.texi: Document that the function
does not work correctly for old VIA processors.

OpenMP: Parse align clause in allocate directive in C/C++

gcc/c/ChangeLog:

* c-parser.cc (c_parser_omp_allocate): Parse align
clause and check for restrictions.

gcc/cp/ChangeLog:

* parser.cc (cp_parser_omp_allocate): Parse align
clause and check for restrictions.

gcc/testsuite/ChangeLog:

* c-c++-common/gomp/allocate-5.c: Extend for align clause.

Fortran/OpenMP: Fix -fopenmp-simd for 'omp assume(s)'

While 'omp assume' is enabled by -fopenmp-simd, 'omp assumes' is not;
however, due to the way parsing works in Fortran (esp. for fixed-form
source code), 'assumes' was parsed by 'assume' which then stumbled over
the tailing 's'.

gcc/fortran/

* parse.cc (decode_omp_directive): Really ignore 'assumes' with
-fopenmp-simd.

gcc/testsuite/

* gfortran.dg/gomp/openmp-simd-8.f90: New test.

lto-wrapper: Pass through -funwind-tables and -fasynchronous-unwind-tables

The -funwind-tables and -fasynchronous-unwind-tables options are relevant
for the output pass, so they need to be passed through by the LTO wrapper.
Otherwise, dwarf2out_assembly_start may output a ".cfi_sections
.debug_frame" directive when debug info is enabled even if every
translation unit was compiled with -funwind-tables.

gcc/
* lto-wrapper.cc (merge_and_complain): Handle
-funwind-tables and -fasynchronous-unwind-tables.
(append_compiler_options): Likewise.

c++: Mangle EXCESS_PRECISION_EXPR <REAL_CST> as fold_convert REAL_CST [PR108698]

For standard excess precision, like the C FE we parse floating
point constants as EXCESS_PRECISION_EXPR of promoted REAL_CST
rather than the nominal REAL_CST, and as the following testcase
shows the constants might need mangling.

The following patch mangles those as fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type, i.e. how they were mangled before.

I'm not really sure EXCESS_PRECISION_EXPR can appear elsewhere
in expressions that would need mangling, tried various testcases
but haven't managed to come up with one.  If that is possible,
we'd keep ICEing on it without/with this patch, and the big question
is how to mangle those; they could be mangled as casts from the
promoted type back to nominal, but then in the mangled expressions
one could see the effects of excess precision.  Until we have
a reproducer, that is just theoretical though.

2023-02-09  Jakub Jelinek  <jakub@redhat.com>

PR c++/108698
* mangle.cc (write_expression, write_template_arg): Handle
EXCESS_PRECISION_EXPR with REAL_CST operand as
write_template_arg_literal on fold_convert of the REAL_CST
to EXCESS_PRECISION_EXPR type.

* g++.dg/cpp0x/pr108698.C: New test.

tree-optimization/26854 - slow bitmap operations

With the compiler.i testcase from the PR one can see bitmap_set_bit
very high in the profile, originating from SSA update and alias
stmt walking.  For SSA update mark_block_for_update essentially
performs redundant bitmap_set_bits and is called via
insert_updated_phi_nodes_for as

      EXECUTE_IF_SET_IN_BITMAP (pruned_idf, 0, i, bi)
...
          mark_block_for_update (bb);
          FOR_EACH_EDGE (e, ei, bb->preds)
            if (e->src->index >= 0)
              mark_block_for_update (e->src);

which is quite random in the access pattern and runs into the
O(n) case of the linked list bitmap representation.  Switching
blocks_to_update to tree view around insert_updated_phi_nodes_for
improves SSA update time from

 tree SSA incremental               :   4.26 (  3%)

to

 tree SSA incremental               :   2.98 (  2%)

Likewise the visited bitmap allocated by the alias walker benefits
from using the tree view in case of large CFGs and we see an
improvement from

 alias stmt walking                 :  10.53 (  9%)

to

 alias stmt walking                 :   4.05 (  4%)

PR tree-optimization/26854
* tree-into-ssa.cc (update_ssa): Turn blocks_to_update to tree
view around insert_updated_phi_nodes_for.
* tree-ssa-alias.cc (maybe_skip_until): Allocate visited bitmap
in tree view.
(walk_aliased_vdefs_1): Likewise.

Daily bump.

c: Update checks on constexpr pointer initializers

WG14 has agreed a change of the rules on constexpr pointer
initializers, so that a (constant) null value that is not a null
pointer constant is accepted in that context, rather than only
accepting null pointer constants.  (In particular, this means that a
constexpr variable of pointer type can be used to initializer another
such variable.)  Remove the null pointer constant restriction in GCC,
instead checking just whether the value is null.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/c/
* c-typeck.cc (check_constexpr_init): Remove argument
null_pointer_constant.  Only check pointer initializers for being
null.
(digest_init): Update calls to check_constexpr_init.

gcc/testsuite/
* gcc.dg/c2x-constexpr-1.c: Test initialization of constexpr
pointers with null values that are not null pointer constants.
* gcc.dg/c2x-constexpr-3.c: Test initialization of constexpr
pointers with non-null values, not with null values that are not
null pointer constants.

doc: Change fsf.org to www.fsf.org

fsf.org has been serving a 301 (permanent redirect) http response for
a long while.

gcc/ChangeLog:

* doc/include/gpl_v3.texi: Change fsf.org to www.fsf.org.

testsuite: Fix asm-goto-with-outputs tests; limit to lra targets

These tests spuriously lacked a "lra" limiter.  Code using
"asm goto" with outputs gets a:
 error: the target does not support 'asm goto' with outputs in 'asm'
compilation error when compiled for a non-LRA target.  Limit
to LRA targets as other asm-goto-with-outputs tests.

* gcc.dg/torture/pr100398.c: Limit to lra targets.
* gcc.dg/pr100590.c: Ditto.

analyzer: fix overzealous state purging with on-stack structs [PR108704]

PR analyzer/108704 reports many false positives seen from
-Wanalyzer-use-of-uninitialized-value on qemu's softfloat.c on code like
the following:

   struct st s;
   s = foo ();
   s = bar (s); // bogusly reports that s is uninitialized here

where e.g. "struct st" is "floatx80" in the qemu examples.

The root cause is overzealous purging of on-stack structs in the code I
added in r12-7718-gfaacafd2306ad7, where at:

s = bar (s);

state_purge_per_decl::process_point_backwards "sees" the assignment to 's'
and stops processing, effectively treating 's' as unneeded before this
stmt, not noticing the use of 's' in the argument.

Fixed thusly.

The patch greatly reduces the number of
-Wanalyzer-use-of-uninitialized-value warnings from my integration tests:
  ImageMagick-7.1.0-57:  10 ->  6   (-4)
              qemu-7.2: 858 -> 87 (-771)
         haproxy-2.7.1:   1 ->  0   (-1)
All of the above that I've examined appear to be false positives.

gcc/analyzer/ChangeLog:
PR analyzer/108704
* state-purge.cc (state_purge_per_decl::process_point_backwards):
Don't stop processing the decl if it's fully overwritten by
this stmt if it's also used by this stmt.

gcc/testsuite/ChangeLog:
PR analyzer/108704
* gcc.dg/analyzer/uninit-7.c: New test.
* gcc.dg/analyzer/uninit-pr108704.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

arm: Optimize arm-mlib.h header inclusion [pr108505].

I have committed a fix [1] into gcc trunk for a build
issue mentioned in pr108505 and latter received few upstream
comments proposing more robust fix for this issue.

In this patch I'm addressing those comments and sending this
as a followup patch.

gcc/ChangeLog:

2023-01-27  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

PR target/108505
* config.gcc (tm_mlib_file): Define new variable.

Fortran: error handling of global entity appearing in COMMON block [PR103259]

gcc/fortran/ChangeLog:

PR fortran/103259
* resolve.cc (resolve_common_vars): Avoid NULL pointer dereference
when a symbol's location is not set.

gcc/testsuite/ChangeLog:

PR fortran/103259
* gfortran.dg/pr103259.f90: New test.

vect-patterns: Fix up vect_widened_op_tree [PR108692]

The following testcase is miscompiled on aarch64-linux since r11-5160.
Given
  <bb 3> [local count: 955630225]:
  # i_22 = PHI <i_20(6), 0(5)>
  # r_23 = PHI <r_19(6), 0(5)>
...
  a.0_5 = (unsigned char) a_15;
  _6 = (int) a.0_5;
  b.1_7 = (unsigned char) b_17;
  _8 = (int) b.1_7;
  c_18 = _6 - _8;
  _9 = ABS_EXPR <c_18>;
  r_19 = _9 + r_23;
...
where SSA_NAMEs 15/17 have signed char, 5/7 unsigned char and rest is int
we first pattern recognize c_18 as
patt_34 = (a.0_5) w- (b.1_7);
which is still correct, 5/7 are unsigned char subtracted in wider type,
but then vect_recog_sad_pattern turns it into
SAD_EXPR <a_15, b_17, r_23>
which is incorrect, because 15/17 are signed char and so it is
sum of absolute signed differences rather than unsigned sum of
absolute unsigned differences.
The reason why this happens is that vect_recog_sad_pattern calls
vect_widened_op_tree with MINUS_EXPR, WIDEN_MINUS_EXPR on the
patt_34 = (a.0_5) w- (b.1_7); statement's vinfo and vect_widened_op_tree
calls vect_look_through_possible_promotion on the operands of the
WIDEN_MINUS_EXPR, which looks through the further casts.
vect_look_through_possible_promotion has careful code to stop when there
would be nested casts that need to be preserved, but the problem here
is that the WIDEN_*_EXPR operation itself has an implicit cast on the
operands already - in this case of WIDEN_MINUS_EXPR the unsigned char
5/7 SSA_NAMEs are widened to unsigned short before the subtraction,
and vect_look_through_possible_promotion obviously isn't told about that.

Now, I think when we see those WIDEN_{MULT,MINUS,PLUS}_EXPR codes, we had
to look through possible promotions already when creating those and so
vect_look_through_possible_promotion again isn't really needed, all we need
to do is arrange what that function will do if the operand isn't result
of any cast.  Other option would be let vect_look_through_possible_promotion
know about the implicit promotion from the WIDEN_*_EXPR, but I'm afraid
that would be much harder.

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

PR tree-optimization/108692
* tree-vect-patterns.cc (vect_widened_op_tree): If rhs_code is
widened_code which is different from code, don't call
vect_look_through_possible_promotion but instead just check op is
SSA_NAME with integral type for which vect_is_simple_use is true
and call set_op on this_unprom.

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

aarch64: Fix return_address_sign_ab_exception.C regression

Hi all,

this is to fix the regression of
g++.target/aarch64/return_address_sign_ab_exception.C that I
introduced with d8dadbc9a5199bf7bac1ab7376b0f84f45e94350.

'aarch_ra_sign_key' for aarch64 ended up being non defined in the opt
file and the function attribute "branch-protection=pac-ret+leaf+b-key"
stopped working as expected.

This patch moves the definition of 'aarch_ra_sign_key' to the opt
files for both Arm back-ends.

Regards

  Andera Corallo

gcc/ChangeLog:

* config/aarch64/aarch64-protos.h (aarch_ra_sign_key): Remove
declaration.
* config/aarch64/aarch64.cc (aarch_ra_sign_key): Remove
definition.
* config/aarch64/aarch64.opt (aarch64_ra_sign_key): Rename
to 'aarch_ra_sign_key'.
* config/arm/aarch-common.cc (aarch_ra_sign_key): Remove
declaration.
* config/arm/arm-protos.h (aarch_ra_sign_key): Likewise.
* config/arm/arm.cc (enum aarch_key_type): Remove definition.
* config/arm/arm.opt: Define.

testsuite: Import objc-dg-prune in execute.exp

The GCC-local definition of gcc-dg-prune removes extra error messages,
such as one from the linker warning about executable stacks.  This is
then used by tool-specific pruners like objc-dg-prune, defined in
objc-dg.exp.  However, objc/execute/execute.exp didn't include
objc-dg.exp, meaning that the linker warning could trigger a
failure in objc/execute/nested-func-1.m.

gcc/testsuite/
* objc/execute/execute.exp: Load objc-dg.exp.

vect: Check gather/scatter offset types [PR108316]

The gather/scatter support can over-widen an offset if the target
requires it, but this relies on using a pattern sequence to add
the widening conversion.  That failed in the testcase because an
earlier pattern (bool) took priority.

I think we should allow patterns to be applied to other patterns,
but that's quite an invasive change and isn't suitable for stage 4.
This patch instead punts if the offset type doesn't match the
expected one.

If we switched to using the SLP representation for everything,
we would probably handle both patterns by rewriting the graph,
which should be much easier.

gcc/
PR tree-optimization/108316
* tree-vect-stmts.cc (get_load_store_type): When using
internal functions for gather/scatter, make sure that the type
of the offset argument is consistent with the offset vector type.

gcc/testsuite/
PR tree-optimization/108316
* gcc.dg/vect/pr108316.c: New test.

Revert "RA: Implement reuse of equivalent memory for caller saves optimization"

This reverts commit f661c0bb6371f355966a67b5ce71398e80792948.

testsuite: Fix up PR108525 test [PR108525]

Seems when committing the PR108525 fix I've missed that a test with
the same name had been added a few hours before for PR108526.

This patch separates the PR108525 test into a new file.

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

PR c++/108525
* g++.dg/cpp23/static-operator-call5.C: Move PR108525 testcase
incorrectly applied into PR108526 testcase ...
* g++.dg/cpp23/static-operator-call6.C: ... here.  New test.

tree.def: Remove outdated comment on SAD_EXPR

While looking at PR108692, I've noticed SAD_EXPR comment mentions that
WIDEN_MINUS_EXPR is missing, which is not true anymore since r11-5160.

The following patch just removes that part of the comment.

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

* tree.def (SAD_EXPR): Remove outdated comment about missing
WIDEN_MINUS_EXPR.

Daily bump.

Fix 'libgomp.fortran/reverse-offload-6.f90' nvptx offloading compilation

Fix-up for recent commit 0b1ce70a813b98ef2893779d14ad6c90c5d06a71
"libgomp: Fix reverse offload issues".

libgomp/
* testsuite/libgomp.fortran/reverse-offload-6.f90: Fix nvptx
offloading compilation.

analyzer: fix -Wanalyzer-use-of-uninitialized-value false +ve on "read" [PR108661]

My integration testing shows many false positives from
-Wanalyzer-use-of-uninitialized-value.

One cause turns out to be that as of r13-1404-g97baacba963c06
fd_state_machine::on_stmt recognizes calls to "read", and returns true,
so that region_model::on_call_post doesn't call handle_unrecognized_call
on them, and so the analyzer erroneously "thinks" that the buffer
pointed to by "read" is never touched by the "read" call.

This works for "fread" because sm-file.cc implements kf_fread, which
handles calls to "fread" by clobbering the buffer pointed to.  In the
long term we should probably be smarter about this and bifurcate the
analysis to consider e.g. errors vs full reads vs partial reads, etc
(which I'm tracking in PR analyzer/108689).

In the meantime, this patch adds a kf_read for "read" analogous to the
one for "fread", fixing 6 false positives seen in git-2.39.0 and
2 in haproxy-2.7.1.

gcc/analyzer/ChangeLog:
PR analyzer/108661
* sm-fd.cc (class kf_read): New.
(register_known_fd_functions): Register "read".
* sm-file.cc (class kf_fread): Update comment.

gcc/testsuite/ChangeLog:
PR analyzer/108661
* gcc.dg/analyzer/fread-pr108661.c: New test.
* gcc.dg/analyzer/read-pr108661.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

Fortran: ASSOCIATE variables should not be TREE_STATIC [PR95107]

gcc/fortran/ChangeLog:

PR fortran/95107
* trans-decl.cc (gfc_finish_var_decl): With -fno-automatic, do not
make ASSOCIATE variables TREE_STATIC.

gcc/testsuite/ChangeLog:

PR fortran/95107
* gfortran.dg/save_7.f90: New test.

doc: Update -fchar8_t documentation

Since C++20 P2513R4, char8_t Compatibility and Portability Fix it is
no longer true that

  char ca[] = u8"xx";

causes an error so adjust the example for -fchar8_t.

gcc/ChangeLog:

* doc/invoke.texi: Update -fchar8_t documentation.

RA: Implement reuse of equivalent memory for caller saves optimization

The test case shows opportunity to reuse memory with constant address for
caller saves optimization for constant or pure function call.  The patch
implements the memory reuse.

        PR rtl-optimization/103541

gcc/ChangeLog:

* ira.h (struct ira_reg_equiv_s): Add new field caller_save_p.
* ira.cc (validate_equiv_mem): Check memref address variance.
(update_equiv_regs): Define caller save equivalence for
valid_combine.
(setup_reg_equiv): Clear defined_p flag for caller save equivalence.
* lra-constraints.cc (lra_copy_reg_equiv): Add new arg
call_save_p.  Use caller save equivalence depending on the arg.
(split_reg): Adjust the call.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr103541.c: New.

tree-optimization/26854 - compile-time hog in SSA forwprop

The following addresses

 tree forward propagate             :  12.41 (  9%)

seen with the compile.i testcase of this PR which points at
the has_use_on_stmt function which, for SSA names with many
uses is slow.  The solution is to instead of immediate uses,
look at stmt operands to identify whether a name has a use
on a stmt.  That improves SSA forwprop to

 tree forward propagate             :   1.30 (  0%)

for this testcase.

PR tree-optimization/26854
* gimple-fold.cc (has_use_on_stmt): Look at stmt operands
instead of immediate uses.

ipa-split: Don't split returns_twice functions [PR106923]

As discussed in the PR, returns_twice functions are rare/special beasts
that need special treatment in the cfg, and inside of their bodies
we don't know which part actually works the weird returns twice way
(either in the fork/vfork sense, or in the setjmp) and aren't updating
ab edges to reflect that.

I think easiest is just to never split these, like we already never
split noreturn or malloc functions.

2023-02-07  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/106923
* ipa-split.cc (execute_split_functions): Don't split returns_twice
functions.

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

cgraph: Handle simd clones in cgraph_node::set_{const,pure}_flag [PR106433]

The following testcase ICEs, because we determine only in late pure const
pass that bar is const (the content of the function loses a store to a
global var during dse3 and read from it during cddce2) and local-pure-const2
makes it const.  The cgraph ordering is that post IPA (in late IPA simd
clones are created) bar is processed first, then foo as its caller, then
foo.simdclone* and finally bar.simdclone*.  Conceptually I think that is the
right ordering which allows for static simd clones to be removed.

The reason for the ICE is that because bar was marked const, the call to
it lost vops before vectorization, and when we in foo.simdclone* try to
vectorize the call to bar, we replace it with bar.simdclone* which hasn't
been marked const and so needs vops, which we don't add.

Now, because the simd clones are created from the same IL, just in a loop
with different argument/return value passing, I think generally if the base
function is determined to be const or pure, the simd clones should be too,
unless e.g. the vectorization causes different optimization decisions, but
then still the global memory reads if any shouldn't affect what the function
does and global memory stores shouldn't be reachable at runtime.

So, the following patch changes set_{const,pure}_flag to mark also simd
clones.

2023-02-07  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/106433
* cgraph.cc (set_const_flag_1): Recurse on simd clones too.
(cgraph_node::set_pure_flag): Call set_pure_flag_1 on simd clones too.

* gcc.c-torture/compile/pr106433.c: New test.

testsuite: Expect -Wdeprecated warning in warn/Wstrict-aliasing-bogus-union-2.C for C++23

On Mon, Feb 06, 2023 at 02:26:01PM +0000, Jonathan Wakely via Gcc-patches wrote:
> With the recent change to deprecate std::aligned_storage and
> std::aligned_union we need to adjust some tests that now fail with
> -std=c++23.

The g++.dg/warn/Wstrict-aliasing-bogus-union-2.C test is also affected:
PASS: g++.dg/warn/Wstrict-aliasing-bogus-union-2.C  -std=gnu++2b  (test for bogus messages, line 12)
FAIL: g++.dg/warn/Wstrict-aliasing-bogus-union-2.C  -std=gnu++2b (test for excess errors)
Excess errors:
.../gcc/testsuite/g++.dg/warn/Wstrict-aliasing-bogus-union-2.C:8:8: warning: 'template<long unsigned int _Len, long unsigned int _Align> struct std::aligned_storage' is deprecated [-

The following patch adds dg-warning for it.

2023-02-07  Jakub Jelinek  <jakub@redhat.com>

* g++.dg/warn/Wstrict-aliasing-bogus-union-2.C: Expect
-Wdeprecated warning for C++23.

Enable 512 bit vector for zen4

While internally 512 registers are splits into two 256 halves, 512 bit vectors
reduces number of instructions to retire and has chance to improve paralelism.
There are few tsvc benchmarks that improves significantly:

           runtime
benchmark  256bit  512bit
s2275      48.57   20.67    -58%
s311       32.29   16.06    -50%
s312       32.30   16.07    -50%
vsumr      32.30   16.07    -50%
s314       10.77   5.42     -50%
s313       21.52   10.85    -50%
vdotr      43.05   21.69    -50%
s316       10.80   5.64     -48%
s235       61.72   33.91    -45%
s161       15.91   9.95     -38%
s3251      32.13   20.31    -36%

And there are no benchmarks with off-noise regression.  The basic matrix
multiplication loop improves by 32%.  It is also expected that 512 bit
vectors are more power effecient (I can't masure that).

The down side is that loops with low trip counts may get slower when the
unvectorized prologue and epilogue is hit more often.  With SPECfp this
problem happens with x264 (12% regression) and bwaves (6% regression)
and this is tracked in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108410
and will need more work on vectorizer to support masked epilogues.

After some additional testing it seems that using 512 bit vectors by
default is now overall better choice.

Bootstrapped/regtested x86_64-linux. Plan to commit it tomorrow.

* config/i386/x86-tune.def (X86_TUNE_AVX256_OPTIMAL): Turn off
for znver4.

Daily bump.

Modula2 meets clang [PR108135]

Remove unused function (and build warnings).

gcc/m2/ChangeLog:

* gm2-compiler/M2Search.mod (DSdbEnter): Comment out.
(DSdbExit): Comment out.

PR modula2/108135

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

libstdc++: Document P1642 and extensions

libstdc++-v3/ChangeLog:

* doc/xml/manual/using.xml: Document newly-freestanding
headers and the effect of the -ffreestanding flag.
* doc/xml/manual/status_cxx2023.xml: Document P1642R11 as
completed.
* doc/xml/manual/configure.xml: Document that hosted installs
respect __STDC_HOSTED__.
* doc/xml/manual/test.xml: Document how to run tests in
freestanding mode.
* doc/html/*: Regenerate.

Format error in m2pp.cc (m2pp_integer_cst) [PR107234]

Use HOST_WIDE_INT_PRINT_UNSIGNED instead of hardcoding a
specific format.

gcc/m2/ChangeLog:

* m2pp.cc (m2pp_integer_cst): Use
HOST_WIDE_INT_PRINT_UNSIGNED as the format specifier.

PR modula2/107234
    Co-Authored by: Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

amdgcn: Pass -mstack-size through to runtime

But only for the offload case.

gcc/ChangeLog:

* config/gcn/mkoffload.cc (gcn_stack_size): New global variable.
(process_asm): Create a constructor for GCN_STACK_SIZE.
(main): Parse the -mstack-size option.

Remove unused variables and procedures.

Remove unused variables and procedures (and remove build
warning clutter).

gcc/m2/ChangeLog:

* gm2-compiler/M2Preprocess.mod (BaseName): Comment out.
* gm2-lang.cc (opt): Remove.
* gm2spec.cc (add_include): Remove.
(full_libraries): Remove.
(concat_option): Remove.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

aarch64: Fix up bfmlal lane pattern [PR104921]

As the testcase shows, this pattern had an incorrect constraint leading
to GCC's output getting rejected by the assembler.

This patch fixes the constraint accordingly.

The test is split into two: one that can run without bf16 support from
the assembler and another that checks that the output actually assembles
when such support is available.

Bootstrapped/regtested on aarch64-linux-gnu.

OK for GCC 13? Or better to wait for next stage 1? What about backports?

Thanks,
Alex

gcc/ChangeLog:

PR target/104921
* config/aarch64/aarch64-simd.md (aarch64_bfmlal<bt>_lane<q>v4sf):
Use correct constraint for operand 3.

gcc/testsuite/ChangeLog:

PR target/104921
* gcc.target/aarch64/pr104921-1.c: New test.
* gcc.target/aarch64/pr104921-2.c: New test.
* gcc.target/aarch64/pr104921.x: Include file for new tests.

libstdc++: Fix non-reserved name for template parameter

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__find_last_fn): Rename T to _Tp.
(__find_last_if_fn): Likewise.

libstdc++: Fix testsuite warnings about new C++23 deprecations

With the recent change to deprecate std::aligned_storage and
std::aligned_union we need to adjust some tests that now fail with
-std=c++23.

libstdc++-v3/ChangeLog:

* include/std/type_traits: Add diagnostic pragmas around
references to deprecated std::aligned_storage and
std::aligned_union traits.
* testsuite/20_util/aligned_storage/requirements/alias_decl.cc:
Add dg-warning for et c++23.
* testsuite/20_util/aligned_storage/requirements/explicit_instantiation.cc:
Likewise.
* testsuite/20_util/aligned_storage/value.cc: Likewise.
* testsuite/20_util/aligned_union/1.cc: Likewise.
* testsuite/20_util/aligned_union/requirements/alias_decl.cc:
Likewise.

libstdc++: Implement P1413R3 'deprecate aligned_storage and aligned_union'

Adds deprecated attributes for C++23, and makes use of it for
std::aligned_storage, std::aligned_storage_t, std::aligned_union, and
std::aligned_union_t.

libstdc++-v3/ChangeLog:

* doc/doxygen/user.cfg.in (PREDEFINED): Add new macros.
* include/bits/c++config (_GLIBCXX23_DEPRECATED)
(_GLIBCXX23_DEPRECATED_SUGGEST): New macros.
* include/std/type_traits (aligned_storage, aligned_union)
(aligned_storage_t, aligned_union_t): Deprecate for C++23.
* testsuite/20_util/aligned_storage/deprecated-2b.cc: New test.
* testsuite/20_util/aligned_union/deprecated-2b.cc: New test.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

libstdc++: Normalise _GLIBCXX20_DEPRECATED macro

Updates _GLIBCXX20_DEPRECATED to be defined and behave the same as the
versions for other standards (e.g. _GLIBCXX17_DEPRECATED).

libstdc++-v3/ChangeLog:

* doc/doxygen/user.cfg.in (PREDEFINED): Update macros.
* include/bits/c++config (_GLIBCXX20_DEPRECATED): Make
consistent with other 'deprecated' macros.
* include/std/type_traits (is_pod, is_pod_v): Use
_GLIBCXX20_DEPRECATED_SUGGEST instead.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

libstdc++: Enable building libstdc++.{a,so} when !HOSTED

This enables us to provide symbols for placeholders and numeric limits,
and allows users to mess about with linker flags less.

libstdc++-v3/ChangeLog:

* Makefile.am [!_GLIBCXX_HOSTED]: Enable src/ subdirectory.
* Makefile.in: Regenerate.
* src/Makefile.am [!_GLIBCXX_HOSTED]: Omit compatibility files.
There's no history to be compatible with.
* src/c++11/Makefile.am [!_GLIBCXX_HOSTED]: Omit hosted-only
source files from the build.
* src/c++17/Makefile.am [!_GLIBCXX_HOSTED]: Likewise.
* src/c++20/Makefile.am [!_GLIBCXX_HOSTED]: Likewise.
* src/c++98/Makefile.am [!_GLIBCXX_HOSTED]: Likewise.
* src/Makefile.in: Regenerate.
* src/c++11/Makefile.in: Regenerate.
* src/c++17/Makefile.in: Regenerate.
* src/c++20/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.

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

libstdc++: Disable building additional archives for freestanding

This doesn't have any effect yet as we never build anything under
libstdc++-v3/src for freestanding, but that will change in the next
commit.

libstdc++-v3/ChangeLog:

* src/Makefile.am [GLIBCXX_HOSTED] (SUBDIRS): Do not add
filesystem, libbacktrace and experimental.
* src/Makefile.in: Regenerate.

ipa-sra: Fix a typo in a dump string.

A fix to a typo spotted by Bernhard Reutner-Fischer.  Tested by
building the compiler with the fix.

gcc/ChangeLog:

2023-02-06  Martin Jambor  <mjambor@suse.cz>

* ipa-sra.cc (adjust_parameter_descriptions): Fix a typo in a dump.

LoongArch: Generate bytepick.[wd] for suitable bit operation pattern

We can use bytepick.[wd] for

    a << (8 * x) | b >> (8 * (sizeof(a) - x))

while a and b are uint32_t or uint64_t.  This is useful for some cases,
for example:
https://sourceware.org/pipermail/libc-alpha/2023-February/145203.html

gcc/ChangeLog:

* config/loongarch/loongarch.md (bytepick_w_ashift_amount):
New define_int_iterator.
(bytepick_d_ashift_amount): Likewise.
(bytepick_imm): New define_int_attr.
(bytepick_w_lshiftrt_amount): Likewise.
(bytepick_d_lshiftrt_amount): Likewise.
(bytepick_w_<bytepick_imm>): New define_insn template.
(bytepick_w_<bytepick_imm>_extend): Likewise.
(bytepick_d_<bytepick_imm>): Likewise.
(bytepick_w): Remove unused define_insn.
(bytepick_d): Likewise.
(UNSPEC_BYTEPICK_W): Remove unused unspec.
(UNSPEC_BYTEPICK_D): Likewise.
* config/loongarch/predicates.md (const_0_to_3_operand):
Remove unused define_predicate.
(const_0_to_7_operand): Likewise.

gcc/testsuite/ChangeLog:

* g++.target/loongarch/bytepick.C: New test.

testsuite: remove broken AArch64 test

This test is somewhat broken, on systems with the profiling extension it fails
because the +profile is required.

The functionality tested here is already tested in nativecpu tests, so deleting
this test.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/options_set_10.c: Removed.

ubsan: Fix up another spot that should have been BUILT_IN_UNREACHABLE_TRAPS [PR108655]

We ICE on the following testcase, because ivcanon calls
gimple_build_builtin_unreachable but doesn't expect it would need vops.
BUILT_IN_UNREACHABLE_TRAP I've introduced yesterday doesn't need
vops and should be used in that case instead of BUILT_IN_TRAP which
needs them.

2023-02-06  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/108655
* ubsan.cc (sanitize_unreachable_fn): For -funreachable-traps
or -fsanitize=unreachable -fsanitize-trap=unreachable return
BUILT_IN_UNREACHABLE_TRAP decl rather than BUILT_IN_TRAP.

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

c++: equivalence of non-dependent calls [PR107461]

After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependence of a CALL_EXPR before treating a FUNCTION_DECL callee as a
dependent name, which leads to us incorrectly accepting the first two
testcases below and rejecting the third:

 * In the first testcase, cp_tree_equal incorrectly returns true for
   the two non-dependent CALL_EXPRs f(0) and f(0) (whose CALL_EXPR_FN
   are different FUNCTION_DECLs) which causes us to treat #2 as a
   redeclaration of #1.

 * Same issue in the second testcase, for f<int*>() and f<char>().

 * In the third testcase, cp_tree_equal incorrectly returns true for
   f<int>() and f<void(*)(int)>() which causes us to conflate the two
   dependent specializations A<decltype(f<int>()(U()))> and
   A<decltype(f<void(*)(int)>()(U()))>.

This patch fixes this by making called_fns_equal treat two callees as
dependent names only if the overall CALL_EXPRs are dependent, via a new
convenience function call_expr_dependent_name that is like dependent_name
but also checks dependence of the overall CALL_EXPR.

PR c++/107461

gcc/cp/ChangeLog:

* cp-tree.h (call_expr_dependent_name): Declare.
* pt.cc (iterative_hash_template_arg) <case CALL_EXPR>: Use
call_expr_dependent_name instead of dependent_name.
* tree.cc (call_expr_dependent_name): Define.
(called_fns_equal): Adjust to take two CALL_EXPRs instead of
CALL_EXPR_FNs thereof.  Use call_expr_dependent_name instead
of dependent_name.
(cp_tree_equal) <case CALL_EXPR>: Adjust call to called_fns_equal.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/overload5.C: New test.
* g++.dg/cpp0x/overload5a.C: New test.
* g++.dg/cpp0x/overload6.C: New test.

Daily bump.

Fortran: prevent redundant integer division truncation warnings [PR108592]

gcc/fortran/ChangeLog:

PR fortran/108592
* arith.cc (gfc_arith_divide): Emit integer division truncation
warnings using gfc_warning instead of gfc_warning_now to prevent
redundant messages.

gcc/testsuite/ChangeLog:

PR fortran/108592
* gfortran.dg/pr108592.f90: New test.

doc: Remove note on PW32

gcc/ChangeLog:

* doc/install.texi (Specific): Remove PW32.

Daily bump.

libstdc++: Avoid use of naked int32_t in unseq_backend_simd.h, PR108672

The use of a "naked" int32_t (i.e. without a fitting #include:
stdint.h or cstdint or inttypes.h or an equivalent internal header),
in libstdc++-v3/include/pstl/unseq_backend_simd.h, caused an error for
cris-elf and apparently pru-elf and I guess all "newlib targets".
(Unfortunately, there's a lack of other *-elf targets in recent months
of gcc-testresults archives.)

This does not manifest on e.g. native x86_64-pc-linux-gnu, because
there, a definition is included as an effect of including stdlib.h in
cstdlib (following the trace in native xtreme-header-2_a.ii with
glibc-2.31-13+deb11u5).  Maybe better than chasing the right #includes
is to directly use the built-in type, like so:

libstdc++-v3:

PR libstdc++/108672
* include/pstl/unseq_backend_simd.h (__simd_or): Use __INT32_TYPE__
instead of int32_t.

libstdc++: Adjust link to pdftex

libstdc++-v3/ChangeLog:

* doc/xml/manual/documentation_hacking.xml: Adjust link to pdftex.
* doc/html/manual/documentation_hacking.html: Regenerate.

libstdc++: Optimize basic_string move assignment

Since resolution of Issue 2593 [1] we can consider that equal allocators
before the propagate-on-move-assignment operations will still be equal
afterward.

So we can extend the optimization of transfering the storage of the move-to
instance to the move-from one that is currently limited to always equal
allocators.

[1] https://cplusplus.github.io/LWG/issue2593

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h (operator=(basic_string&&)): Transfer move-to
storage to the move-from instance when allocators are equal.
* testsuite/21_strings/basic_string/allocator/char/move_assign.cc (test04):
New test case.

Daily bump.

range-op: Handle op?.undefined_p () in op[12]_range of comparisons [PR108647]

As mentioned in the PR, we ICE because lhs is singleton [0, 0]
or [1, 1] but op2 (or in other cases op1) is undefined and op?.*_bound ()
ICEs on those because there are no pairs for UNDEFINED.

The following patch makes us set r to varying or return false in those
cases.

2023-02-03  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/108647
* range-op.cc (operator_equal::op1_range,
operator_not_equal::op1_range): Don't test op2 bound
equality if op2.undefined_p (), instead set_varying.
(operator_lt::op1_range, operator_le::op1_range,
operator_gt::op1_range, operator_ge::op1_range): Return false if
op2.undefined_p ().
(operator_lt::op2_range, operator_le::op2_range,
operator_gt::op2_range, operator_ge::op2_range): Return false if
op1.undefined_p ().

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

fortran: Fix up hash table usage in gfc_trans_use_stmts [PR108451]

The first testcase in the PR (which I haven't included in the patch because
it is unclear to me if it is supposed to be valid or not) ICEs since extra
hash table checking has been added recently.  The problem is that
gfc_trans_use_stmts does
          tree *slot = entry->decls->find_slot_with_hash (rent->use_name, hash,
                                                          INSERT);
          if (*slot == NULL)
and later on doesn't store anything into *slot and continues.  Another spot
a few lines later correctly clears the slot if it decides not to use the
slot, so the following patch does the same.

2023-02-03  Jakub Jelinek  <jakub@redhat.com>

PR fortran/108451
* trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before
doing continue.

irange: Compare nonzero bits in irange with widest_int [PR108639]

The problem here is we are trying to compare two ranges with different
precisions and the == operator in wide_int is complaining.

Interestingly, the problem is not the nonzero bits, but the fact that
the entire ranges have different precisions.  The reason we don't ICE
when comparing the sub-ranges, is because the code in
irange::operator== works on trees, and tree_int_cst_equal is
promoting the comparison to a widest int:

  if (TREE_CODE (t1) == INTEGER_CST
      && TREE_CODE (t2) == INTEGER_CST
      && wi::to_widest (t1) == wi::to_widest (t2))
    return 1;

This is why we don't see the ICE until the nonzero bits comparison is
done on wide ints.  I think we should maintain the current equality
behavior, and follow suit in the nonzero bit comparison.

I have also fixed the legacy equality code, even though technically
nonzero bits shouldn't appear in legacy.  But better safe than sorry.

PR tree-optimization/108639

gcc/ChangeLog:

* value-range.cc (irange::legacy_equal_p): Compare nonzero bits as
widest_int.
(irange::operator==): Same.

range-ops: Handle undefined ranges in frange op[12]_range [PR108647]

This patch gracefully handles undefined operand ranges for the floating
point op[12]_range operators.  This is very low risk, as we would have
ICEd otherwise.

We don't have a testcase that ICEs for floating point ranges, but it's
only a matter of time.  Besides, this dovetails nicely with the integer
versions Jakub is testing.

gcc/ChangeLog:

PR tree-optimization/108647
* range-op-float.cc (foperator_lt::op1_range): Handle undefined ranges.
(foperator_lt::op2_range): Same.
(foperator_le::op1_range): Same.
(foperator_le::op2_range): Same.
(foperator_gt::op1_range): Same.
(foperator_gt::op2_range): Same.
(foperator_ge::op1_range): Same.
(foperator_ge::op2_range): Same.
(foperator_unordered_lt::op1_range): Same.
(foperator_unordered_lt::op2_range): Same.
(foperator_unordered_le::op1_range): Same.
(foperator_unordered_le::op2_range): Same.
(foperator_unordered_gt::op1_range): Same.
(foperator_unordered_gt::op2_range): Same.
(foperator_unordered_ge::op1_range): Same.
(foperator_unordered_ge::op2_range): Same.

Reset SCEV before removing unreachable globals.

SCEV should be reset in VRP before trying to remove unreachable globals
to avoid triggering issues with it's cache.

PR tree-optimization/107570
gcc/
* tree-vrp.cc (remove_and_update_globals): Reset SCEV.

gcc/testsuite/
* gcc.dg/pr107570.c: New.

c++: wrong error with constexpr array and value-init [PR108158]

In this test case, we find ourselves evaluating 't' which is
((const struct carray *) this)->data_[VIEW_CONVERT_EXPR<long int>(index)]
in cxx_eval_array_reference.  ctx->object is non-null, a RESULT_DECL, so
we replace it with 't':

  new_ctx.object = t; // result_decl replaced

and then we go to cxx_eval_constant_expression to evaluate an
AGGR_INIT_EXPR, where we end up evaluating an INIT_EXPR (which is in the
body of the constructor for seed_or_index):

  ((struct seed_or_index *) this)->value_ = NON_LVALUE_EXPR <0>

whereupon in cxx_eval_store_expression we go to the probe loop
where the 'this' is evaluated to

  ze_set.tables_.first_table_.data_[0]

so the 'object' is ze_set, but that isn't in ctx->global->get_value_ptr
so we fail with a bogus error.  ze_set is not there because it comes
from a different constexpr context (it's not in cv_cache either).

The problem started with r12-2304 where I added the new_ctx.object
replacement.  That was to prevent a type mismatch: the type of 't'
and ctx.object were different.

It seems clear that we shouldn't have replaced ctx.object here.
The cxx_eval_array_reference I mentioned earlier is called from
cxx_eval_store_expression:
 6257       init = cxx_eval_constant_expression (&new_ctx, init, vc_prvalue,
 6258                                            non_constant_p, overflow_p);
which already created a new context, whose .object we should be
using unless, for instance, INIT contained a.b and we're evaluating
the 'a' part, which I think was the case for r12-2304; in that case
ctx.object has to be something different.

It no longer seems necessary to replace new_ctx.object (likely due to
changes in empty class handling).

PR c++/108158

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_array_reference): Don't replace
new_ctx.object.

gcc/testsuite/ChangeLog:

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

c++: Add fixed test [PR101071]

As a happy accident, this was fixed by the recent r13-2978.

PR c++/101071

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic-alias8.C: New test.

libstdc++: Mark pieces of gnu-linux/os_support.h linux-specific

This is notably needed because in glibc 2.34, the move of pthread functions
into libc.so happened for Linux only, not GNU/Hurd.

The pthread_self() function can also always be used fine as it is on
GNU/Hurd.

libstdc++-v3/ChangeLog:

* config/os/gnu-linux/os_defines.h [!__linux__]
(_GLIBCXX_NATIVE_THREAD_ID, _GLIBCXX_GTHREAD_USE_WEAK): Do not define.

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

[modula-2] Bugfix to allow html doc build and simplify target dir creation

This patch allows the m2 html documentation to be built.
It also simplifies all calls to $(mkinstalldirs) using $(@D) in
gcc/m2/Make-lang.in.

gcc/ChangeLog:

* doc/gm2.texi (Internals): Remove from menu.
(Using): Comment out ifnohtml conditional.
(Documentation): Use gcc url.
(License): Node simplified.
(Copying): New node.  Include gpl_v3_without_node.
(Contributing): Node simplified.
(Internals): Commented out.
(Libraries): Node simplified.
(Indices): Ditto.
(Contents): Ditto.
(Functions): Ditto.

gcc/m2/ChangeLog:

* Make-lang.in (TEXISRC): Remove m2/images/gnu.eps.
(RSTSRC): Remove m2/images/gnu.eps.
(doc/m2.dvi): Add $(objdir)/m2/images/gnu.eps.
(doc/m2.pdf): Add $(objdir)/m2/images/gnu.eps.
(M2_PDFFILES): New definition.
(m2.install-pdf): New rule.
(m2.pod): Add $(objdir)/m2/images/gnu.eps.
(m2.info): Add $(objdir)/m2/images/gnu.eps.
(m2.html): New rule.
(m2/gpl_v3_without_node.texi): New rule.
(plugin/m2rte$(soext)): Simplify mkinstalldirs.
(cc1gm2$(exeext)): Ditto.
(m2/stage1/cc1gm2$(exeext)): Ditto.
(m2/gm2-gcc/%.o): Ditto.
(m2/gm2-gcc/rtegraph.o): Ditto.
(m2/gm2-gcc/$(SRC_PREFIX)%.h): Ditto.
(m2/mc-boot/$(SRC_PREFIX)%.o):Ditto.
(m2/mc-boot-ch/$(SRC_PREFIX)%.o): Ditto.
(m2/mc-boot/main.o): Ditto.
(m2/gm2-libs-boot/%.o): Ditto.
(m2/gm2-libs-boot/$(SRC_PREFIX)%.h): Ditto.
(m2/gm2-libs-boot/RTcodummy.o): Ditto.
(m2/gm2-libs-boot/wrapc.o): Ditto.
(m2/gm2-libs-boot/M2LINK.o): Ditto.
(m2/gm2-libs-boot/UnixArgs.o): Ditto.
(m2/gm2-libs-boot/choosetemp.o): Ditto.
(m2/gm2-libs-boot/errno.o): Ditto.
(m2/gm2-libs-boot/dtoa.o): Ditto.
(m2/gm2-libs-boot/ldtoa.o): Ditto.
(m2/gm2-libs-boot/termios.o): Ditto.
(m2/gm2-libs-boot/SysExceptions.o): Ditto.
(m2/gm2-libs-boot/SysStorage.o): Ditto.
(m2/gm2-compiler-boot/M2GCCDeclare.o): Ditto.
(m2/gm2-compiler-boot/M2Error.o): Ditto.
(m2/gm2-compiler-boot/%.o): Ditto.
(m2/gm2-compiler-boot/$(SRC_PREFIX)%.h): Ditto.
(m2/gm2-compiler-boot/m2flex.o): Ditto.
(m2/gm2-compiler/m2flex.c): Ditto.
(m2/gm2-libiberty/$(SRC_PREFIX)%.h): Ditto.
(m2/gm2-compiler/%.o): Ditto.
(m2/gm2-compiler/m2flex.o): Ditto.
(m2/gm2-compiler/%.o): Ditto.
(m2/gm2-libs-iso/%.o): Ditto.
(m2/gm2-libs/gm2-libs-host.h): Ditto.
($(objdir)/m2/gm2-libs-min/SYSTEM.def): Ditto.
($(objdir)/m2/gm2-libs/SYSTEM.def): Ditto.
($(objdir)/m2/gm2-libs-iso/SYSTEM.def): Ditto.
($(objdir)/m2/gm2-libs-coroutines/SYSTEM.def): Ditto.
(m2/gm2-compiler/gm2.a): Ditto.
(m2/gm2-libs-boot/libgm2.a): Ditto.
(m2/gm2-compiler-boot/gm2.a): Ditto.
(m2/boot-bin/mklink$(exeext)): Ditto.
(m2/gm2-compiler-boot/$(SRC_PREFIX)%.h): Ditto.
(m2/gm2-compiler/%.mod): Ditto.
(m2/gm2-compiler-boot/%.mod): Ditto.
(m2/pge-boot/%.o): Ditto.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

libstdc++: Implement ranges::find_last{,_if,_if_not} from P1223R5

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__find_last_fn, find_last):
Define.
(__find_last_if_fn, find_last_if): Define.
(__find_last_if_not_fn, find_last_if_not): Define.
* testsuite/25_algorithms/find_last/1.cc: New test.
* testsuite/25_algorithms/find_last_if/1.cc: New test.
* testsuite/25_algorithms/find_last_if_not/1.cc: New test.

libstdc++: Implement ranges::iota from P2440R1

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (out_value_result): Define.
(iota_result): Define.
(__iota_fn, iota): Define.
* testsuite/25_algorithms/iota/1.cc: New test.

libstdc++: Implement ranges::contains/contains_subrange from P2302R4

libstdc++-v3/ChangeLog:

* include/bits/ranges_algo.h (__contains_fn, contains): Define.
(__contains_subrange_fn, contains_subrange): Define.
* testsuite/25_algorithms/contains/1.cc: New test.
* testsuite/25_algorithms/contains_subrange/1.cc: New test.

arm: [MVE] Add missing length=8 attribute

I have noticed that the "length" "8" attribute is missing in a few
patterns in mve.md.

gcc/
* config/arm/mve.md (mve_vabavq_p_<supf><mode>): Add length
attribute.
(mve_vqshluq_m_n_s<mode>): Likewise.
(mve_vshlq_m_<supf><mode>): Likewise.
(mve_vsriq_m_n_<supf><mode>): Likewise.
(mve_vsubq_m_<supf><mode>): Likewise.

arm: Fix warning in libgcc/config/arm/pr-support.c

I have noticed some warnings when building GCC for arm-eabi:
pr-support.c:110:7: warning: variable ‘set_pac_sp’ set but not used [-Wunused-but-set-variable]
pr-support.c:109:7: warning: variable ‘set_pac’ set but not used [-Wunused-but-set-variable]

This small patch avoids them by defining these two variables undef
TARGET_HAVE_PACBTI, like the code which actually uses them.

libgcc/
* config/arm/pr-support.c (__gnu_unwind_execute): Use
TARGET_HAVE_PACBTI to define set_pac and set_pac_sp.

c++: unexpected ADDR_EXPR after overload set pruning [PR107461]

Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped
in an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR.  This ends up causing a bogus declaration mismatch error in
the below testcase because the call to min in #1 gets expressed as a
CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call
to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL.

This patch fixes this by stripping the spurious ADDR_EXPR appropriately.
Thus the first call to min now also gets expressed as a CALL_EXPR of
FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f.

PR c++/107461

gcc/cp/ChangeLog:

* semantics.cc (finish_call_expr): Strip ADDR_EXPR from
the selected callee during overload set pruning.

gcc/testsuite/ChangeLog:

* g++.dg/template/call9.C: New test.

c++: ICE on unviable/ambiguous constrained dtors [PR96745]

Here we're crashing from check_bases_and_members due to
CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning
performed by add_method, should only happen if there is no viable
destructor or the destructor is ambiguous because of unsatisfied
or ambiguous constraints.

This patch fixes this by making check_bases_and_members naturally handle
CLASSTYPE_DESTRUCTOR being an OVERLOAD.  It's then convenient to prune
the OVERLOAD after effectively diagnosing the overload resolution
failure in check_methods.

PR c++/96745

gcc/cp/ChangeLog:

* class.cc (check_methods): Diagnose an unviable OVERLOAD
set for CLASSTYPE_DESTRUCTOR differently from an ambiguous one.
Then prune the OVERLOAD to a single function.
(check_bases_and_members): Handle CLASSTYPE_DESTRUCTOR being
an OVERLOAD when calling deduce_noexcept_on_destructor.
Document why it has to be called before check_methods.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-dtor1.C: New test.

c++: excessive satisfaction in check_methods [PR108579]

In check_methods we're unnecessarily checking satisfaction for all
constructors and assignment operators, even those that don't look like
copy/move special members.  In the testcase below this manifests as an
unstable satisfaction error because the satisfaction result is first
determined to be false during check_methods (since A<int> is incomplete
at this point) and later true after completion of A<int>.

This patch fixes this simply by swapping the order of the
constraint_satisfied_p and copy/move_fn_p tests.

PR c++/108579

gcc/cp/ChangeLog:

* class.cc (check_methods): Swap order of constraints_satisfied_p
and copy/move_fn_p tests.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-pr108579.C: New test.

ipa: Avoid invalid gimple when IPA-CP and IPA-SRA disagree on types (108384)

When the compiled program contains type mismatches between callers and
callees when it comes to a parameter, IPA-CP can try to propagate one
constant from callers while IPA-SRA may try to split a parameter
expecting a value of a different size on the same offset.  This then
currently leads to creation of a VIEW_CONVERT_EXPR with mismatching
type sizes of LHS and RHS which is correctly flagged by the GIMPLE
verifier as invalid.

It seems that the best course of action is to try and avoid the
situation altogether and so this patch adds a check to IPA-SRA that
peeks into the result of IPA-CP and when it sees a value on the same
offset but with a mismatching size, it just decides to leave that
particular parameter be.

gcc/ChangeLog:

2023-02-02  Martin Jambor  <mjambor@suse.cz>

PR ipa/108384
* ipa-sra.cc (push_param_adjustments_for_index): Remove a size check
when comparing to an IPA-CP value.
(dump_list_of_param_indices): New function.
(adjust_parameter_descriptions): Check for mismatching IPA-CP values.
Dump removed candidates using dump_list_of_param_indices.
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::modify_expression): Add assert checking
sizes of a VIEW_CONVERT_EXPR will match.
(ipa_param_body_adjustments::modify_assignment): Likewise.

gcc/testsuite/ChangeLog:

2023-02-02  Martin Jambor  <mjambor@suse.cz>

PR ipa/108384
* gcc.dg/ipa/pr108384.c: New test.

libgomp: Fix reverse offload issues

If there is nothing to map, skip the mapping and avoid attempting to
copy 0 bytes from addrs, sizes and kinds.

Additionally, it could happen that a non-allocated address was deallocated,
such as a pointer set, leading to a free for the actual data.

libgomp/
* target.c (gomp_target_rev): Handle mapnum == 0 and avoid
freeing not allocated memory.
* testsuite/libgomp.fortran/reverse-offload-6.f90: New test.

libgomp: enable reverse offload for AMDGCN

libgomp/ChangeLog:

* libgomp.texi (5.0 Impl. Status, gcn specifics): Update for
reverse offload.
* plugin/plugin-gcn.c (GOMP_OFFLOAD_get_num_devices): Accept
reverse-offload requirement.

RISC-V: Remove unnecessary register class.

Avoid VL_REGS, VTYPE_REGS join register allocation.

gcc/ChangeLog:

* config/riscv/riscv.h: Remove VL_REGS, VTYPE_REGS class.
* config/riscv/riscv.cc: Ditto.

RISC-V: Fix constraint bug for binary operation

Current constraint configuration will generate:
vadd.vv v0,v24,v25,v0.t
vsll.vx v0,v24,a5,v0.t

They are incorrect according to RVV ISA.
This patch fix this obvious issue.

gcc/ChangeLog:

* config/riscv/vector-iterators.md (sll.vi): Fix constraint bug.
(sll.vv): Ditto.
(%3,%4): Ditto.
(%3,%v4): Ditto.
* config/riscv/vector.md: Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/binop_vv_constraint-1.c:
* gcc.target/riscv/rvv/base/shift_vx_constraint-1.c:

RISC-V: Add vsll.vx C++ API tests

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/vsll_vx-1.C: New test.
* g++.target/riscv/rvv/base/vsll_vx-2.C: New test.
* g++.target/riscv/rvv/base/vsll_vx-3.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_mu-1.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_mu-2.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_mu-3.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tu-1.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tu-2.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tu-3.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tum-1.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tum-2.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tum-3.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tumu-1.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tumu-2.C: New test.
* g++.target/riscv/rvv/base/vsll_vx_tumu-3.C: New test.

RISC-V: Add vsra.vx C++ API tests

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/vsra_vx-1.C: New test.
* g++.target/riscv/rvv/base/vsra_vx-2.C: New test.
* g++.target/riscv/rvv/base/vsra_vx-3.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_mu-1.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_mu-2.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_mu-3.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tu-1.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tu-2.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tu-3.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tum-1.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tum-2.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tum-3.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tumu-1.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tumu-2.C: New test.
* g++.target/riscv/rvv/base/vsra_vx_tumu-3.C: New test.

RISC-V: Add vsrl.vx C++ API tests

gcc/testsuite/ChangeLog:

* g++.target/riscv/rvv/base/vsrl_vx-1.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx-2.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx-3.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_mu-1.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_mu-2.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_mu-3.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tu-1.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tu-2.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tu-3.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tum-1.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tum-2.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tum-3.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tumu-1.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tumu-2.C: New test.
* g++.target/riscv/rvv/base/vsrl_vx_tumu-3.C: New test.

RISC-V: Add shift constraint tests

gcc/testsuite/ChangeLog:

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

RISC-V: Add vsll.vx C++ API tests

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vsll_vx-1.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx-2.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx-3.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_m-1.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_m-2.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_m-3.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vsll_vx_tumu-3.c: New test.

RISC-V: Add vsra.vx C API tests

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vsra_vx-1.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx-2.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx-3.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_m-1.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_m-2.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_m-3.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vsra_vx_tumu-3.c: New test.

RISC-V: Add vsrl.vx C API tests

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/vsrl_vx-1.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx-2.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx-3.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_m-1.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_m-2.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_m-3.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_mu-1.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_mu-2.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_mu-3.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tu-1.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tu-2.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tu-3.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tum-1.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tum-2.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tum-3.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tumu-1.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tumu-2.c: New test.
* gcc.target/riscv/rvv/base/vsrl_vx_tumu-3.c: New test.

RISC-V: Add RVV shift.vx C/C++ API support

gcc/ChangeLog:

* config/riscv/predicates.md (pmode_reg_or_uimm5_operand): New predicate.
* config/riscv/riscv-vector-builtins-bases.cc: New class.
* config/riscv/riscv-vector-builtins-functions.def (vsll): Ditto.
(vsra): Ditto.
(vsrl): Ditto.
* config/riscv/riscv-vector-builtins.cc: Ditto.
* config/riscv/vector.md (@pred_<optab><mode>_scalar): New pattern.

Daily bump.

c: Update nullptr_t comparison checks

WG14 has agreed to allow equality comparisons between pointers and
nullptr_t values that are not null pointer constants (this was
previously an exceptional case where such nullptr_t values were
handled differently from null pointer constants; other places in the
standard allowed nullptr_t values, whether or not those values are
null pointer constants, in the same contexts as null pointer
constants); see the wording at the end of N3077.  Update GCC's
implementation to match this change.

There are also changes to allow null pointer constants of integer or
pointer type to be converted to nullptr_t (by assignment, cast or
conversion as if by assignment), which I'll deal with separately.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/c/
* c-typeck.cc (build_binary_op): Allow comparisons between
pointers and nullptr_t values that are not null pointer constants.

gcc/testsuite/
* gcc.dg/c2x-constexpr-3.c: Do not expect comparison of nullptr_t
and pointer to be disallowed.
* gcc.dg/c2x-nullptr-1.c: Test comparisons of nullptr_t and
pointers are allowed.
* gcc.dg/c2x-nullptr-3.c: Do not test that comparisons of
nullptr_t and pointers are disallowed.

libstdc++: Tweak link to ABIcheck project

libstdc++-v3/ChangeLog:

* doc/xml/manual/abi.xml: Tweak link to ABIcheck project.
* doc/html/manual/abi.html: Regenerate.

c: Update checks on constexpr floating-point initializers

WG14 has agreed some changes (detailed at the end of N3082) to the
rules on constexpr initializers for floating types.  Update GCC's
implementation to match: binary initializers are now allowed for
decimal types, and real initializers for complex types, but signaling
NaN initializers can't be used for a different type with the same
mode.

There are also changes to the constexpr rules for pointer types
(allowing null pointer address constants that aren't null pointer
constants), which I'll deal with separately.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/c/
* c-typeck.cc: Include "realmpfr.h".
(constexpr_init_fits_real_type): Do not allow signaling NaN
conversions to different types with the same mode.  Handle
conversions from binary to decimal types.
(check_constexpr_init): Do not disallow real initializers for
complex types.  Do not disallow binary initializers for decimal
floating types.

gcc/testsuite/
* gcc.dg/c2x-constexpr-1.c: Test constexpr initializers of complex
types with real initializers are allowed.
* gcc.dg/c2x-constexpr-3.c: Do not test for constexpr initializers
of complex types with real initializers being disallowed.
* gcc.dg/c2x-constexpr-8.c: Add tests of signaling NaN complex
initializers.
* gcc.dg/c2x-constexpr-9.c: Add more tests.
* gcc.dg/dfp/c2x-constexpr-dfp-1.c: Add tests of binary floating
initializers for decimal types.
* gcc.dg/dfp/c2x-constexpr-dfp-2.c: Change tests of binary
initializers for decimal types.  Add more tests of decimal
initializers for binary types.

libstdc++: Use ENOSYS for unsupported filesystem ops on AVR

Because avr-libc <errno.h> defines most error numbers with duplicate
values it's not sufficient to check #ifdef ENOTSUP when deciding which
std::errc constant to use for the filesystem library's __unsupported()
helper. Add a special case for AVR to always use the ENOSYS value.

libstdc++-v3/ChangeLog:

* src/filesystem/ops-common.h [AVR] (__unsupported): Always use
errc::function_not_supported instead of errc::not_supported.

libstdc++: Define std::basic_stringbuf::view() for old std::string ABI

Unlike the new str()&& members in <sstream>, there is no real difficulty
in supporting the new view() members for the old std::string ABI.
Enabling it fixes errors in <chrono> where std::ostringstream::view() is
used by ostream insertion operators for calendar types.

We just need to use [[gnu::always_inline]] on the view() members for the
old ABI, because the library doesn't contain instantiations of them for
the old ABI. Making them always inline avoids needing to add those
instantiations and export them.

libstdc++-v3/ChangeLog:

* include/std/sstream  (basic_stringbuf::view): Define for old
std::string ABI.
(basic_istringstream::view, basic_0stringstream::view)
(basic_stringstream::view): Likewise.
* testsuite/27_io/basic_istringstream/view/char/1.cc: Remove
{ dg-require-effective-target cxx11_abi }.
* testsuite/27_io/basic_istringstream/view/wchar_t/1.cc:
Likewise.
* testsuite/27_io/basic_ostringstream/view/char/1.cc: Likewise.
* testsuite/27_io/basic_ostringstream/view/wchar_t/1.cc:
Likewise.
* testsuite/27_io/basic_stringbuf/view/char/1.cc: Likewise.
* testsuite/27_io/basic_stringbuf/view/wchar_t/1.cc: Likewise.
* testsuite/27_io/basic_stringstream/view/char/1.cc: Likewise.
* testsuite/27_io/basic_stringstream/view/wchar_t/1.cc:
Likewise.

libstdc++: Fix std::filesystem errors with -fkeep-inline-functions [PR108636]

With -fkeep-inline-functions there are linker errors when including
<filesystem>. This happens because there are some filesystem::path
constructors defined inline which call non-exported functions defined in
the library. That's usually not a problem, because those constructors
are only called by code that's also inside the library. But when the
header is compiled with -fkeep-inline-functions those inline functions
are emitted even though they aren't called. That then creates an
undefined reference to the other library internsl. The fix is to just
move the private constructors into the library where they are called.
That way they are never even seen by users, and so not compiled even if
-fkeep-inline-functions is used.

On trunk there is a second problem, which is that the new equality
operators for comparing directory iterators with default_sentinel use
the shared_ptr::operator bool() conversion operator. The shared_ptr
specializations used by directory iterators are explicitly instantiated
in the library, but the bool conversion operators are not exported. This
causes linker errors at -O0 or with -fkeep-inline-functions. That just
requires the conversion operators to be exported.

libstdc++-v3/ChangeLog:

PR libstdc++/108636
* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Export shared_ptr
conversion operators for directory iterator comparisons with
std::default_sentinel_t.
* include/bits/fs_path.h (path::path(string_view, _Type))
(path::_Cmpt::_Cmpt(string_view, _Type, size_t)): Move inline
definitions to ...
* src/c++17/fs_path.cc: ... here.
* testsuite/27_io/filesystem/path/108636.cc: New test.