Revert "sphinx: sync latest changes"

This reverts commit 8857a1e350cf34c4ac06429ec4cb97228489dd07.

Revert "sphinx: support installation if sphinx-build is missing"

This reverts commit e5821d3f62b5bf532db1be661459b7553a956fa2.

Revert "sphinx: add update_web_docs_git.py script"

This reverts commit 6373b1fdf75ea0908dfaebdbfc54d8b55b08d409.

Revert "sphinx: fix building if sphinx-build is missing"

This reverts commit 1f9c79367e136e0ca5b775562e6111e1a0d0046f.

Revert "avr: sphinx: port gen-avr-mmcu to RST"

This reverts commit 79f1313608b468fd6a0f329d2e265fa67bba7cc1.

Revert "sphinx: simplify default in baseconf.py."

This reverts commit 8d7a55b7f4ce37ecc869bd31cadc3f9e059e2f44.

Revert "sphinx: update crontab with new script"

This reverts commit d05a423c1e7b81021a1b6bee93db31a903d87667.

Revert "sphinx: update diagnostics URLs"

This reverts commit 9c3bc557995463fe1dcc37ec503af780a6c1a341.

Revert "docs: fix: WARNING: Parsing of expression failed. Using fallback parser."

This reverts commit a305ac87b46e263a3bc0c886f9dfddf2664f6af8.

Revert "sphinx: add missing trailing newline"

This reverts commit 3ed1b4ce7c9bdf8c777d12da0f5fe4cae8ba7c8e.

Revert "docs: fix links pointing to gcc.gnu.org/install"

This reverts commit 0b3d926d796050468b8a844e5fb8c20bda741c26.

Revert "docs: create sources tarball"

This reverts commit 52eedc1fa3d211f29196eed60e11e6a8738329c2.

Revert "sphinx: add missing HAS_SPHINX_BUILD"

This reverts commit 8f5aa130fa61637baec476119e72849f7e3f8c67.

Revert "docs: Add missing variable name in example"

This reverts commit d8c105810285ad97e8af31a328c8a75d4adc5a19.

Revert "doc: Use a separate directory for new modules we add to PATH"

This reverts commit 70f1c41061b2b55ed4cdc2e83c7cf326c7ebe7a4.

Revert "doc: Modernize baseconf.py."

This reverts commit dd31c6923fbe8352f7efa830c47c6d0ab31cfce8.

Revert "maintainer-scripts: fix superfluous 'sh' for Python script"

This reverts commit 9072763f4f17e600a980ff510b2baf8ad8ada1b5.

Revert "sphinx: add missing newline for conf.py files."

This reverts commit bd044dae51caea3c641f86ec5cb0ebccf7e06de7.

Revert "docs: move label directly before title"

This reverts commit 740cf7d6ab266cf4249fc5c247187622cb6a2c8f.

Partially revert 5c6546ca7d8cab1f1c129f5b55f709e2ceee0f94

gcc/ChangeLog:

* doc/gcc/gcc-command-options/options-that-control-static-analysis.rst:
Revert.

Partially revert d3fe767c16e7c528e4fc71c8a68ac14b4573d880.

gcc/ChangeLog:

* doc/cpp/pragmas.rst: Revert.

Revert "sphinx: stop using parallel mode"

This reverts commit 08fd14f9589b6e0e3155ba728a5e7031b9250f91.

Revert "doc: update sphinx-build -j auto comment"

This reverts commit 02698e21de26c7d4217f856ee64436148e0aede7.

Revert "jit: doc: Use shared Indices and tables"

This reverts commit 3b54cc9d04c2efb2c8f9a0b515e638917636630c.

Partially revert cd9eedb8ac2e904880da8d1e3c87a3557c38a04f

gcc/ChangeLog:

* doc/gcc/gcc-command-options/machine-dependent-options/aarch64-options.rst: Revert.

Partially revert ca1db2725a3232b2e15eaa1bd7fbe33927843476

gcc/ChangeLog:

* doc/gcc/gcc-command-options/machine-dependent-options/aarch64-options.rst: Revert.

Partially revert 12c583a2a3da798e82737c2d0e11fd686636cfeb

gcc/ChangeLog:

* doc/gcc/gcc-command-options/options-that-control-static-analysis.rst: Revert.
* doc/gcc/gcc-command-options/options-to-request-or-suppress-warnings.rst: Revert.

Partially revert 59a63247992eb13153b82c4902aadf111460eac2.

gcc/fortran/ChangeLog:

* doc/gfortran/naming-and-argument-passing-conventions.rst:
Revert.

Revert "doc: Remove outdated reference to "core" and front-end downloads"

This reverts commit 05432288d4e560556ee0455562639b715d8f8b7d.

Revert "configure: always set SPHINX_BUILD"

This reverts commit 5e749ee3019d7917184af30dab8d09c933c0a4a1.

Revert "sphinx: include todolist only if INCLUDE_TODO env. set"

This reverts commit c64fd69420fd153f9fb16a603ff0a711fbde8335.

Revert "doc: Update Jeff Law's email-address in contrib.rst"

This reverts commit 3bf46ea7bce58918ae8da1c936fe4c55456d2b6b.

Partially revert d777b38cde91a87f2345dcd13901862a9513562a

gcc/ChangeLog:

* doc/gcc/gcc-command-options/option-summary.rst: Revert.
* doc/gcc/gcc-command-options/options-that-control-static-analysis.rst: Revert.

i386: Add AMX-TILE dependency for AMX related ISAs

gcc/ChangeLog:

* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AMX_INT8_SET): Add AMX-TILE dependency.
(OPTION_MASK_ISA2_AMX_BF16_SET): Ditto.
(OPTION_MASK_ISA2_AMX_FP16_SET): Ditto.
(OPTION_MASK_ISA2_AMX_TILE_UNSET): Disable AMX_{INT8,
BF16, FP16} when disable AMX_TILE.

gcc/testsuite/ChangeLog:

* gcc.target/i386/amxbf16-dpbf16ps-2.c: Remove -amx-tile.
* gcc.target/i386/amxfp16-dpfp16ps-2.c: Ditto.
* gcc.target/i386/amxint8-dpbssd-2.c: Ditto.
* gcc.target/i386/amxint8-dpbsud-2.c: Ditto.
* gcc.target/i386/amxint8-dpbusd-2.c: Ditto.
* gcc.target/i386/amxint8-dpbuud-2.c: Ditto.

Partially revert 071e428c24ee8c1ed062597a093708bba29509c9

gcc/ChangeLog:

* doc/gcc/gcc-command-options/machine-dependent-options/x86-options.rst:
  Revert.
* doc/gcc/gcc-command-options/option-summary.rst:
  Revert.

restrict gcc.dg/pr107554.c to 64bit platforms

The following avoids exceeding the maximum object size on 32bit
platforms.

* gcc.dg/pr107554.c: Restrict to lp64.

Enable small loop unrolling for O2

Modern processors has multiple way instruction decoders
For x86, icelake/zen3 has 5 uops, so for small loop with <= 4
instructions (usually has 3 uops with a cmp/jmp pair that can be
macro-fused), the decoder would have 2 uops bubble for each iteration
and the pipeline could not be fully utilized.

Therefore, this patch enables loop unrolling for small size loop at O2
to fullfill the decoder as much as possible. It turns on rtl loop
unrolling when targetm.loop_unroll_adjust exists and O2 plus speed only.
In x86 backend the default behavior is to unroll small loops with less
than 4 insns by 1 time.

This improves 548.exchange2 by 9% on icelake and 7.4% on zen3 with
0.9% codesize increment. For other benchmarks the variants are minor
and overall codesize increased by 0.2%.

The kernel image size increased by 0.06%, and no impact on eembc.

gcc/ChangeLog:

* common/config/i386/i386-common.cc (ix86_optimization_table):
Enable small loop unroll at O2 by default.
* config/i386/i386.cc (ix86_loop_unroll_adjust): Adjust unroll
factor if -munroll-only-small-loops enabled and -funroll-loops/
-funroll-all-loops are disabled.
* config/i386/i386.h (struct processor_costs): Add 2 field
small_unroll_ninsns and small_unroll_factor.
* config/i386/i386.opt: Add -munroll-only-small-loops.
* doc/gcc/gcc-command-options/machine-dependent-options/x86-options.rst:
Document -munroll-only-small-loops.
* doc/gcc/gcc-command-options/option-summary.rst: Likewise.
* loop-init.cc (pass_rtl_unroll_loops::gate): Enable rtl
loop unrolling for -O2-speed and above if target hook
loop_unroll_adjust exists.
(pass_rtl_unroll_loops::execute): Set UAP_UNROLL flag
when target hook loop_unroll_adjust exists.
* config/i386/x86-tune-costs.h: Update all processor costs
with small_unroll_ninsns = 4 and small_unroll_factor = 2.

gcc/testsuite/ChangeLog:

* gcc.dg/guality/loop-1.c: Add additional option
-mno-unroll-only-small-loops.
* gcc.target/i386/pr86270.c: Add -mno-unroll-only-small-loops.
* gcc.target/i386/pr93002.c: Likewise.

gcc-changelog: temporarily disable check_line_start

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Temporarily disable
check_line.start.

Daily bump.

analyzer: new warning: -Wanalyzer-tainted-assertion [PR106235]

This patch adds a new -Wanalyzer-tainted-assertion warning to
-fanalyzer's "taint" mode (which also requires -fanalyzer-checker=taint).

It complains about attacker-controlled values being used in assertions,
or in any expression affecting control flow that guards a "noreturn"
function.  As noted in the docs part of the patch, in such cases:

  - when assertion-checking is enabled: an attacker could trigger
    a denial of service by injecting an assertion failure

  - when assertion-checking is disabled, such as by defining NDEBUG,
    an attacker could inject data that subverts the process, since it
    presumably violates a precondition that is being assumed by the code.

For example, given:

#include <assert.h>

int __attribute__((tainted_args))
test_tainted_assert (int n)
{
  assert (n > 0);
  return n * n;
}

compiling with
  -fanalyzer -fanalyzer-checker=taint
gives:

t.c: In function 'test_tainted_assert':
t.c:6:3: warning: use of attacked-controlled value in condition for assertion [CWE-617] [-Wanalyzer-tainted-assertion]
    6 |   assert (n > 0);
      |   ^~~~~~
  'test_tainted_assert': event 1
    |
    |    4 | test_tainted_assert (int n)
    |      | ^~~~~~~~~~~~~~~~~~~
    |      | |
    |      | (1) function 'test_tainted_assert' marked with '__attribute__((tainted_args))'
    |
    +--> 'test_tainted_assert': event 2
           |
           |    4 | test_tainted_assert (int n)
           |      | ^~~~~~~~~~~~~~~~~~~
           |      | |
           |      | (2) entry to 'test_tainted_assert'
           |
         'test_tainted_assert': events 3-6
           |
           |/usr/include/assert.h:106:10:
           |  106 |       if (expr)                                                         \
           |      |          ^
           |      |          |
           |      |          (3) use of attacker-controlled value for control flow
           |      |          (4) following 'false' branch (when 'n <= 0')...
           |......
           |  109 |         __assert_fail (#expr, __FILE__, __LINE__, __ASSERT_FUNCTION);   \
           |      |         ~~~~~~~~~~~~~
           |      |         |
           |      |         (5) ...to here
           |      |         (6) treating '__assert_fail' as an assertion failure handler due to '__attribute__((__noreturn__))'
           |

The testcases have various examples for BUG and BUG_ON from the
Linux kernel; there, the diagnostic treats "panic" as an assertion
failure handler, due to '__attribute__((__noreturn__))'.

gcc/analyzer/ChangeLog:
PR analyzer/106235
* analyzer.opt (Wanalyzer-tainted-assertion): New.
* checker-path.cc (checker_path::fixup_locations): Pass false to
pending_diagnostic::fixup_location.
* diagnostic-manager.cc (get_emission_location): Pass true to
pending_diagnostic::fixup_location.
* pending-diagnostic.cc (pending_diagnostic::fixup_location): Add
bool param.
* pending-diagnostic.h (pending_diagnostic::fixup_location): Add
bool param to decl.
* sm-taint.cc (taint_state_machine::m_tainted_control_flow): New.
(taint_diagnostic::describe_state_change): Drop "final".
(class tainted_assertion): New.
(taint_state_machine::taint_state_machine): Initialize
m_tainted_control_flow.
(taint_state_machine::alt_get_inherited_state): Support
comparisons being tainted, based on their arguments.
(is_assertion_failure_handler_p): New.
(taint_state_machine::on_stmt): Complain about calls to assertion
failure handlers guarded by an attacker-controller conditional.
Detect attacker-controlled gcond conditionals and gswitch index
values.
(taint_state_machine::check_control_flow_arg_for_taint): New.

gcc/ChangeLog:
PR analyzer/106235
* doc/gcc/gcc-command-options/option-summary.rst: Add
-Wno-analyzer-tainted-assertion.
* doc/gcc/gcc-command-options/options-that-control-static-analysis.rst:
Add -Wno-analyzer-tainted-assertion.

gcc/testsuite/ChangeLog:
PR analyzer/106235
* gcc.dg/analyzer/taint-assert-BUG_ON.c: New test.
* gcc.dg/analyzer/taint-assert-macro-expansion.c: New test.
* gcc.dg/analyzer/taint-assert.c: New test.
* gcc.dg/analyzer/taint-assert-system-header.c: New test.
* gcc.dg/analyzer/test-assert.h: New header.
* gcc.dg/plugin/analyzer_gil_plugin.c
(gil_diagnostic::fixup_location): Add bool param.

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

Fortran: diagnostics for actual arguments to pointer dummy arguments [PR94104]

Error message improvement.  In Fortran 2008 actual procedure arguments
associated with a pointer, intent(in) attribute, dummy argument
can also have the target attribute, not just pointer.

gcc/fortran/ChangeLog:

PR fortran/94104
* interface.cc (gfc_compare_actual_formal): Improve error message
dependent on Fortran standard level.

gcc/testsuite/ChangeLog:

PR fortran/94104
* gfortran.dg/parens_2.f90: Adjust to improved error message.
* gfortran.dg/PR94104a.f90: New test.
* gfortran.dg/PR94104b.f90: New test.

Skip guality tests on hppa-hpux.

The guality check command hangs. This causes TCL errors in
other tests and slows testsuite execution.

2022-11-13  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

* g++.dg/guality/guality.exp: Skip on hppa*-*-hpux*.
* gcc.dg/guality/guality.exp: Likewise.
* gfortran.dg/guality/guality.exp: Likewise.

RISC-V: optimize '(a >= 0) ? b : 0' to srai + andn, if compiling for Zbb

If-conversion is turning '(a >= 0) ? b : 0' into a branchless sequence
not a5,a0
srai a5,a5,63
and a0,a1,a5
missing the opportunity to combine the NOT and AND into an ANDN.

This adds a define_split to help the combiner reassociate the NOT with
the AND.

gcc/ChangeLog:

* config/riscv/bitmanip.md: New define_split.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zbb-srai-andn.c: New test.

doc: Update Jeff Law's email-address in contrib.rst

ChangeLog:

* doc/contrib.rst: Update Jeff Law's email address.

sphinx: include todolist only if INCLUDE_TODO env. set

It is confusing that 'Indexes and tables' contains TODO. One gets
Index by clicking to the Index link.

PR web/107643

ChangeLog:

* doc/baseconf.py: Set include_todo tag if INCLUDE_TODO env
is set.
* doc/indices-and-tables.rst: Use include_todo tag.

RISC-V: costs: support shift-and-add in strength-reduction

The strength-reduction implementation in expmed.cc will assess the
profitability of using shift-and-add using a RTL expression that wraps
a MULT (with a power-of-2) in a PLUS.  Unless the RISC-V rtx_costs
function recognizes this as expressing a sh[123]add instruction, we
will return an inflated cost---thus defeating the optimization.

This change adds the necessary idiom recognition to provide an
accurate cost for this for of expressing sh[123]add.

Instead on expanding to
li a5,200
mulw a0,a5,a0
with this change, the expression 'a * 200' is sythesized as:
sh2add a0,a0,a0   // *5 = a + 4 * a
sh2add a0,a0,a0   // *5 = a + 4 * a
slli a0,a0,3    // *8

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_rtx_costs): Recognize shNadd,
if expressed as a plus and multiplication with a power-of-2.
Split costing for MINUS from PLUS.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/zba-shNadd-07.c: New test.

configure: always set SPHINX_BUILD

During the Sphinx-migration development, I used
SPHINX_BUILD='' in order to skip building info and manual
pages in gcc folder. However, we've got HAS_SPHINX_BUILD
which is the correct flag for that.

With the patch, one will get a nicer error message when
sphinx-build is missing and one builds (explicitly) a target which
depends on it.

PR other/107620

gcc/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libgomp/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libiberty/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libitm/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

libquadmath/ChangeLog:

* configure: Regenerate.
* configure.ac: Always set sphinx-build.

ginclude: C2x header version macros

C2x adds __STDC_VERSION_*_H__ macros to individual headers with
interface changes compared to C17.  All the new header features in
headers provided by GCC have now been implemented, so define those
macros to the value given in the current working draft.

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

gcc/
* ginclude/float.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_FLOAT_H__): New macro.
* ginclude/stdarg.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDARG_H__): New macro.
* ginclude/stdatomic.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDATOMIC_H__): New macro.
* ginclude/stddef.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDDEF_H__): New macro.
* ginclude/stdint-gcc.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_STDINT_H__): New macro.
* glimits.h [__STDC_VERSION__ > 201710L]
(__STDC_VERSION_LIMITS_H__): New macro.

gcc/testsuite/
* gcc.dg/c11-float-8.c, gcc.dg/c11-limits-1.c,
gcc.dg/c11-stdarg-4.c, gcc.dg/c11-stdatomic-3.c,
gcc.dg/c11-stddef-1.c, gcc.dg/c11-stdint-1.c,
gcc.dg/c2x-float-13.c, gcc.dg/c2x-limits-1.c,
gcc.dg/c2x-stdarg-5.c, gcc.dg/c2x-stdatomic-1.c,
gcc.dg/c2x-stddef-1.c, gcc.dg/c2x-stdint-1.c: New tests.

doc: Remove outdated reference to "core" and front-end downloads

gcc/ChangeLog:

* doc/install/testing.rst: Remove anachronism about separate
source tarballs.

libstdc++: Add C++20 clocks

Also add the basic types for timezones, without the non-inline
definitions needed to actually use them.

The get_leap_second_info function currently uses a hardcoded list of
leap seconds, correct as of the end of 2022. That needs to be replaced
with a dynamically generated list read from the system tzdata. That will
be done in a later patch.

libstdc++-v3/ChangeLog:

* include/std/chrono (utc_clock, tai_clock, gps_clock): Define.
(clock_time_conversion, clock_cast): Define.
(sys_info, local_info): Define structs for timezone information.
(nonexistent_local_time, ambiguous_local_time): Define
exceptions for invalid times.
(time_zone, time_zone_link, leap_second, zoned_traits, tzdb)
(tzdb_list): Define classes representing time zones.
(get_leap_second_info): Define new function returning leap
second offset for a given time point.
* testsuite/std/time/clock/gps/1.cc: New test.
* testsuite/std/time/clock/tai/1.cc: New test.
* testsuite/std/time/clock/utc/1.cc: New test.

libstdc++: Implement C++20 <format> [PR104166]

This doesn't add the newer C++23 features like formatting ranges
and escaped string prsentation types.

However, C++23 extended floating-point types are supported, as are
128-bit integers.

It could do with more tests.

libstdc++-v3/ChangeLog:

PR libstdc++/104166
* include/Makefile.am (std_headers): Add <format>.
* include/Makefile.in: Regenerate.
* include/precompiled/stdc++.h: Add <format>.
* include/std/format: New file.
* python/libstdcxx/v6/printers.py (StdFormatArgsPrinter): New
printer for std::format_args.
* testsuite/std/format/arguments/args.cc: New test.
* testsuite/std/format/error.cc: New test.
* testsuite/std/format/formatter.cc: New test.
* testsuite/std/format/functions/format.cc: New test.
* testsuite/std/format/functions/format_to_n.cc: New test.
* testsuite/std/format/functions/size.cc: New test.
* testsuite/std/format/functions/vformat_to.cc: New test.
* testsuite/std/format/parse_ctx.cc: New test.
* testsuite/std/format/string.cc: New test.
* testsuite/std/format/string_neg.cc: New test.

libstdc++: Allow std::to_chars for 128-bit integers in strict mode

This allows std::format to support __int128 when __STRICT_ANSI__ is
defined, which previously failed because __int128 is not an integral
type in strict mode.

With these changes, std::to_chars still rejects 128-bit integers in
strict mode, but std::format will be able to use __detail::__to_chars_i
for unsigned __int128.

libstdc++-v3/ChangeLog:

* include/bits/charconv.h (__integer_to_chars_is_unsigned):
New variable template.
(__to_chars_len, __to_chars_10_impl): Use variable template in
assertions to allow unsigned __int128 in strict mode.
* include/std/charconv (__to_chars, __to_chars_16)
(__to_chars_10, __to_chars_8, __to_chars_2): Likewise.

Fortran: Remove unused declaration

This function was removed years ago, remove it's prototype.

gcc/fortran/ChangeLog:

* gfortran.h (gfc_check_include): Remove declaration.

Daily bump.

libstdc++: Fix up to_chars ppc64le _Float128 overloads [PR107636]

As reported, I've misplaced __extension__ keywords in these cases
(wanted not to have them on the whole inlines because _Float128 is
completely standard now while __float128 is not, but before return
it is a syntax error.
I've verified on a short testcase that both g++ and clang++ accept
__extension__ after return keyword.

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

PR libstdc++/107636
* include/std/charconv (to_chars): Fix up powerpc64le _Float128
overload __extension__ placement.

Fortran: fix treatment of character, value, optional dummy arguments [PR107444]

Fix handling of character dummy arguments that have the optional+value
attribute.  Change name of internal symbols that carry the hidden presence
status of optional arguments to distinguish them from the internal hidden
character length.  Update documentation to clarify the gfortran ABI.

gcc/fortran/ChangeLog:

PR fortran/107444
* trans-decl.cc (create_function_arglist): Extend presence status
to all intrinsic types, and change prefix of internal symbol to '.'.
* trans-expr.cc (gfc_conv_expr_present): Align to changes in
create_function_arglist.
(gfc_conv_procedure_call): Fix generation of procedure arguments for
the case of character dummy arguments with optional+value attribute.
* trans-types.cc (gfc_get_function_type): Synchronize with changes
to create_function_arglist.
* doc/gfortran/naming-and-argument-passing-conventions.rst: Clarify
the gfortran argument passing conventions with regard to OPTIONAL
dummy arguments of intrinsic type.

gcc/testsuite/ChangeLog:

PR fortran/107444
* gfortran.dg/optional_absent_7.f90: Adjust regex.
* gfortran.dg/optional_absent_8.f90: New test.

c: C2x constexpr

Implement C2x constexpr (a feature based on the C++ one but much more
minimal, with only constexpr variables, not functions).

I believe this implementation is fully functional for use of this
feature.  However, there are several things that seem unclear about
the specification that I'll need to raise in NB comments.  There are
also areas where there may be followup bug fixes because the
implementation doesn't reject some more obscure cases that ought to be
rejected: cases where a constexpr initializer for floating type meets
the constraints for a constant expression in initializers but not
those for an arithmetic constant expression (previously we haven't had
to track whether something is an arithmetic constant expression in
detail, unlike with integer constant expressions), and some cases
where a tag or struct or union member gets declared indirectly in the
declaration specifiers or declarator of a constexpr declaration, which
is not permitted (modulo lack of clarity in the specification) for
underspecified declarations in general (the cases of a declaration in
the initializer, or a tagged type being directly declared as a type
specifier, are already detected).

Cases of ambiguity in the specification include:

* Many questions (previously raised in WG14 discussions) over the rule
  about what conversions do or do not involve a change of value that's
  not allowed in a constexpr initializer, that aren't properly
  addressed by the normative text (and where the footnote on the
  subject isn't very clear either, and the examples don't necessarily
  follow from the normative text).  I've made a series of choices
  there, that include disallowing all conversions between real and
  complex types or between binary and decimal floating types in
  constexpr initializers, that might not necessarily agree with how
  things end up getting clarified.

  The dfp.cc change also arises here, to allow quiet NaN initializers
  of one DFP type to be used in a constexpr initializer for another
  DFP type (as is possible for signaling NaNs) by ensuring the result
  of such a conversion is properly marked as canonical (note that most
  of the DFP code doesn't actually do anything with NaN payloads at
  all).

* Various issues with what exactly counts as part of a declaration for
  the purposes of the rule on underspecified declarations not
  declaring any identifiers other than ordinary identifiers (and not
  declaring more than one ordinary identifier, though the latter is
  undefined behavior).  These include cases where the declaration of a
  struct / union / enum type appears inside typeof or alignas in the
  declaration specifiers (the latter also applies with auto), or in
  the declarator (e.g. an array size or in a parameter declaration).
  The issues are similar to those involved in C90 DR#115 and C99 DRs
  #277 and #341; the intent may not be the same in all the different
  cases involved, but it's not clear that the normative wording in the
  various places is sufficient to deduce the differences in intent.

* The wording about producing a compound literal constant using member
  access is present in one place but another place only applies that
  to named constants.

* It's not clear when a structure or union constant (a constexpr
  variable or compound literal with structure or union type, or a
  member with such type extracted by a series of member access
  operations) can itself be used in an initializer (constexpr or
  otherwise).  Based on general wording for initializers not having
  been changed, the working draft might only strictly allow it at
  automatic storage duration (but elsewhere it would be undefined
  behavior, not a constraint violation, so no diagnostic required) -
  since that's the only case mentioned where a single expression of
  structure or union type can be used to initialize an object of such
  a type.  But it definitely seems to be allowed in even constexpr
  initializers at automatic storage duration - and since generally
  constexpr initializers (any storage duration) are *more* constrained
  than ordinary static storage duration initializers, it would seem
  odd for it not to be allowed at static storage duration.

* When you do allow such initializers, it's then not entirely clear
  how the constraint that constexpr pointer initializers must be null
  pointer constants should be applied (given that a constexpr object
  of pointer type is a null pointer but *not* a null pointer
  constant).  My guess would be that a constexpr struct or union
  containing such a field should still be allowed as an initializer,
  but the wording could be read otherwise.

* It also becomes important with constexpr exactly what kind of
  constant expression an implicit zero initializer is; the wording for
  default initialization only really deals with the value of the
  initializer and not what kind of constant it is.  In particular,
  this affects whether {} is a valid constexpr initializer for a
  pointer not of type void *, since the wording only talks about a
  null pointer, not whether it's a null pointer *constant*.  I assumed
  that it should be a null pointer constant in that case.

* It's also not entirely clear whether constexpr can be used in the
  declaration part of a for loop (which "shall only declare
  identifiers for objects having storage class auto or register").  I
  interpreted it as allowed (treating such objects as implicitly auto
  just like those with no storage class specifiers), but it could also
  be argued that constexpr is another storage class specifier and so
  not allowed there.

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

gcc/
* dfp.cc (decimal_from_binary): Convert a canonical NaN to a
canonical NaN.

gcc/c-family/
* c-common.cc (c_common_reswords): Use D_C2X instead of D_CXXONLY.

gcc/c/
* c-decl.cc (start_underspecified_init)
(finish_underspecified_init): Handle name == NULL_TREE for
compound literals.
(merge_decls): Merge C_DECL_DECLARED_CONSTEXPR.
(shadow_tag_warned): Check for constexpr.
(start_decl): Add parameter do_push.
(build_compound_literal): Set C_DECL_DECLARED_CONSTEXPR.
(grokdeclarator): Handle constexpr.
(finish_struct): Set C_TYPE_FIELDS_NON_CONSTEXPR.
(declspecs_add_scspec): Handle constexpr.
* c-parser.cc (c_token_starts_compound_literal)
(c_token_starts_declspecs, c_parser_declaration_or_fndef)
(c_parser_declspecs, c_parser_gnu_attribute_any_word)
(c_parser_compound_literal_scspecs)
(c_parser_postfix_expression_after_paren_type): Handle constexpr.
Update calls to start_init.
(c_parser_declaration_or_fndef, c_parser_initializer)
(c_parser_initval): Pass true for new argument of
convert_lvalue_to_rvalue.  Call convert_lvalue_to_rvalue for
constexpr compound literals.
(c_parser_static_assert_declaration_no_semi)
(c_parser_enum_specifier, c_parser_struct_declaration)
(c_parser_alignas_specifier, c_parser_initelt, c_parser_label):
Call convert_lvalue_to_rvalue on expressions required to be
integer constant expressions.
(c_parser_omp_declare_reduction): Update call to start_init.
* c-tree.h (C_TYPE_FIELDS_NON_CONSTEXPR)
(C_DECL_DECLARED_CONSTEXPR): New macros.
(struct c_declspecs): Add constexpr_p.
(start_decl, convert_lvalue_to_rvalue, start_init): Update
prototypes.
* c-typeck.cc (require_constant_value, require_constant_elements):
Change to bool.
(require_constexpr_value, maybe_get_constexpr_init)
(constexpr_init_fits_real_type, check_constexpr_init): New.
(convert_lvalue_to_rvalue): Add new parameter for_init.  Call
maybe_get_constexpr_init.
(store_init_value): Update call to digest_init.
(digest_init): Add parameters int_const_expr, arith_const_expr and
require_constexpr.  Check constexpr initializers.
(constructor_top_level): Remove.
(struct initializer_stack): Remove top_level.  Add
require_constexpr_value.
(start_init): Remove parameter top_level.  Add parameters
init_require_constant and init_require_constexpr.  Save
require_constexpr_value on stack.
(pop_init_level): Use a null pointer constant for zero initializer
of pointer initialized with {}.
(output_init_element): Update call to digest_init.  Avoid passing
null pointer constants of pointer type through digest_init a
second time when initializing a constexpr object.

gcc/testsuite/
* gcc.dg/c11-keywords-1.c: Also test constexpr.
* gcc.dg/c2x-constexpr-1.c, gcc.dg/c2x-constexpr-2a.c,
gcc.dg/c2x-constexpr-2b.c, gcc.dg/c2x-constexpr-3.c,
gcc.dg/c2x-constexpr-4.c, gcc.dg/c2x-constexpr-5.c,
gcc.dg/c2x-constexpr-6.c, gcc.dg/c2x-constexpr-7.c,
gcc.dg/c2x-constexpr-8.c, gcc.dg/c2x-constexpr-9.c,
gcc.dg/dfp/c2x-constexpr-dfp-1.c,
gcc.dg/dfp/c2x-constexpr-dfp-2.c, gcc.dg/gnu2x-constexpr-1.c,
gcc.target/i386/excess-precision-11.c,
gcc.target/i386/excess-precision-12.c: New tests.

[frange] Avoid testing signed zero test for -fno-signed-zeros.

This patch moves a test that is meant to only work for signed zeros
into range_tests_signed_zeros.

I am not aware of any architectures where this is failing, but it is
annoying to see selftests failing when -fno-signed-zeros is used.

gcc/ChangeLog:

* value-range.cc (range_tests_signbit): Move to set from here...
(range_tests_signed_zeros): ...to here.

[range-ops] Add ability to represent open intervals in frange.

Currently we represent < and > with a closed interval.  So < 3.0 is
represented as [-INF, +3.0].  This means 3.0 is included in the range,
and though not ideal, is conservatively correct.  Jakub has found a
couple cases where properly representing < and > would help
optimizations and tests, and this patch allows representing open
intervals with real_nextafter.

There are a few caveats.

First, we leave MODE_COMPOSITE_P types pessimistically as a closed interval.

Second, for -ffinite-math-only, real_nextafter will saturate the
maximum representable number into +INF.  However, this will still do
the right thing, as frange::set() will crop things appropriately.

Finally, and most frustratingly, representing < and > -+0.0 is
problematic because we flush denormals to zero.  Let me explain...

real_nextafter(+0.0, +INF) gives 0x0.8p-148 as expected, but setting a
range to this value yields [+0.0, 0x0.8p-148] because of the flushing.

On the other hand, real_nextafter(+0.0, -INF) (surprisingly) gives
-0.0.8p-148, but setting a range to that value yields [-0.0x8p-148,
-0.0].  I say surprising, because according to cppreference.com,
std::nextafter(+0.0, -INF) should give -0.0.  But that's neither here
nor there because our flushing denormals to zero prevents us from even
representing ranges involving small values around 0.0.  We ultimately
end up with ranges looking like this:

> +0.0 => [+0.0, INF]
> -0.0 => [+0.0, INF]
< +0.0 => [-INF, -0.0]
< -0.0 => [-INF, -0.0]

I suppose this is no worse off that what we had before with closed
intervals.  One could even argue that we're better because we at least
have the right sign now ;-).

gcc/ChangeLog:

* range-op-float.cc (build_lt): Adjust with frange_nextafter
instead of default to a closed range.
(build_gt): Same.

libgomp: Fix up build on mingw [PR107641]

Pointers should be first casted to intptr_t/uintptr_t before casting
them to another integral type to avoid warnings.
Furthermore, the function has code like
  else if (upper <= UINT_MAX)
    something;
  else
    something_else;
so it seems using unsigned type for upper where upper <= UINT_MAX is always
true is not intended.

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

PR libgomp/107641
* env.c (parse_unsigned_long): Cast params[2] to uintptr_t rather than
unsigned long.  Change type of upper from unsigned to unsigned long.

range-op: Implement op[12]_range operators for {PLUS,MINUS,MULT,RDIV}_EXPR

On Wed, Nov 09, 2022 at 04:43:56PM +0100, Aldy Hernandez wrote:
> On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek <jakub@redhat.com> wrote:
> >
> > On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote:
> > > We can implement the op[12]_range entries for plus and minus in terms
> > > of each other.  These are adapted from the integer versions.
> >
> > I think for NANs the op[12]_range shouldn't act this way.
> > For the forward binary operations, we have the (maybe/known) NAN handling
> > of one or both NAN operands resulting in VARYING sign (maybe/known) NAN
> > result, that is the somehow the case for the reverse binary operations too,
> > if result is (maybe/known) NAN and the other op is not NAN, op is
> > VARYING sign (maybe/known) NAN, if other op is (maybe/known) NAN,
> > then op is VARYING sign maybe NAN (always maybe, never known).
> > But then for + we have the -INF + INF or vice versa into NAN, and that
> > is something that shouldn't be considered.  If result isn't NAN, then
> > neither operand can be NAN, regardless of whether result can be
> > +/- INF and the other op -/+ INF.
>
> Heh.  I just ran into this while debugging the problem reported by Xi.
>
> We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN
> + VARYING, which returns op1 = NAN (incorrectly).
>
> I suppose in the above case op1 should ideally be
> [-INF,-INF][+INF,+INF]+-NAN, but since we can't represent that then
> [-INF,+INF] +-NAN, which is actually VARYING.  Do you agree?
>
> I'm reverting this patch as attached, while I sort this out.

Here is a patch which reinstalls your change, add the fixups I've talked
about and also hooks up reverse operators for MULT_EXPR/RDIV_EXPR.

2022-11-12  Aldy Hernandez  <aldyh@redhat.com>
    Jakub Jelinek  <jakub@redhat.com>

* range-op-float.cc (float_binary_op_range_finish): New function.
(foperator_plus::op1_range): New.
(foperator_plus::op2_range): New.
(foperator_minus::op1_range): New.
(foperator_minus::op2_range): New.
(foperator_mult::op1_range): New.
(foperator_mult::op2_range): New.
(foperator_div::op1_range): New.
(foperator_div::op2_range): New.

* gcc.c-torture/execute/ieee/inf-4.c: New test.

range-op: Cleanup floating point multiplication and division fold_range [PR107569]

Admittedly there are many similar spots with the foperator_div case
(but also with significant differences), so perhaps if foperator_{mult,div}
inherit from some derived class from range_operator_float and that class
would define various smaller helper static? methods, like this
discussed in the PR - contains_zero_p, singleton_nan_p, zero_p,
that
+           bool must_have_signbit_zero = false;
+           bool must_have_signbit_nonzero = false;
+           if (real_isneg (&lh_lb) == real_isneg (&lh_ub)
+               && real_isneg (&rh_lb) == real_isneg (&rh_ub))
+             {
+               if (real_isneg (&lh_lb) == real_isneg (&rh_ub))
+                 must_have_signbit_zero = true;
+               else
+                 must_have_signbit_nonzero = true;
+             }
returned as -1/0/1 int, and those set result (based on the above value) to
[+INF, +INF], [-INF, -INF] or [-INF, +INF]
or
[+0, +0], [-0, -0] or [-0, +0]
or
[+0, +INF], [-INF, -0] or [-INF, +INF]
and the
+    for (int i = 1; i < 4; ++i)
+      {
+       if (real_less (&cp[i], &cp[0])
+           || (real_iszero (&cp[0]) && real_isnegzero (&cp[i])))
+         std::swap (cp[i], cp[0]);
+       if (real_less (&cp[4], &cp[i + 4])
+           || (real_isnegzero (&cp[4]) && real_iszero (&cp[i + 4])))
+         std::swap (cp[i + 4], cp[4]);
+      }
block, it could be smaller and more readable.

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

PR tree-optimization/107569
* range-op-float.cc (zero_p, contains_p, singleton_inf_p,
signbit_known_p, zero_range, inf_range, zero_to_inf_range): New
functions.
(foperator_mult_div_base): New class.
(foperator_mult, foperator_div): Derive from that and use
protected static method from it as well as above new functions
to simplify the code.

range-op: Implement floating point division fold_range [PR107569]

Here is the floating point division fold_range implementation,
as I wrote in the last mail, we could outline some of the common parts
into static methods with descriptive names and share them between
foperator_div and foperator_mult.

Regressions are
+FAIL: gcc.dg/pr95115.c execution test
+FAIL: libphobos.phobos/std/math/hardware.d execution test
+FAIL: libphobos.phobos_shared/std/math/hardware.d execution test
The first test is we have:
  # RANGE [frange] double [] +-NAN
  _3 =  Inf /  Inf;
  if (_3 ord _3)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  abort ();

  <bb 4> :
before evrp, the range is correct, Inf / Inf is known NAN of unknown
sign.  evrp correctly folds _3 ord _3 into false and the
  _3 =  Inf /  Inf;
remains in the IL, but then comes dse1 and removes it as dead
statement.  So, I think yet another example of the PR107608 problems
where DCE? removes dead statements which raise floating point exceptions.
And -fno-delete-dead-exceptions doesn't help.

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

PR tree-optimization/107569
* range-op-float.cc (foperator_div): New class.
(floating_op_table::floating_op_table): Use foperator_div
for RDIV_EXPR.

range-op: Implement floating point multiplication fold_range [PR107569]

The following patch implements frange multiplication, including the
special case of x * x.  The callers don't tell us that it is x * x,
just that it is either z = x * x or if (x == y) z = x * y;
For irange that makes no difference, but for frange it can mean
x is -0.0 and y is 0.0 if they have the same range that includes both
signed and unsigned zeros, so we need to assume result could be -0.0.

The patch causes one regression:
+FAIL: gcc.dg/fold-overflow-1.c scan-assembler-times 2139095040 2
but that is already tracked in PR107608 and affects not just the newly
added multiplication, but addition and other floating point operations
(and doesn't seem like a ranger bug but dce or whatever else).

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

PR tree-optimization/107569
PR tree-optimization/107591
* range-op.h (range_operator_float::rv_fold): Add relation_kind
argument.
* range-op-float.cc (range_operator_float::fold_range): Name
last argument trio and pass trio.op1_op2 () as last argument to
rv_fold.
(range_operator_float::rv_fold): Add relation_kind argument.
(foperator_plus::rv_fold, foperator_minus::rv_fold): Likewise.
(foperator_mult): New class.
(floating_op_table::floating_op_table): Use foperator_mult for
MULT_EXPR.

LoongArch: Add flogb.{s,d} instructions and expand logb{sf,df}2

On LoongArch, flogb instructions extract the exponent of a non-negative
floating point value, but produces NaN for negative values.  So we need
to add a fabs instruction when we expand logb.

gcc/ChangeLog:

* config/loongarch/loongarch.md (UNSPEC_FLOGB): New unspec.
(type): Add flogb.
(logb_non_negative<mode>2): New instruction template.
(logb<mode>2): New define_expand.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/flogb.c: New test.

LoongArch: Add fscaleb.{s,d} instructions as ldexp{sf,df}3

This allows optimizing __builtin_ldexp{,f} and __builtin_scalbn{,f} with
-fno-math-errno.

IMODE is added because we can't hard code SI for operand 2: fscaleb.d
instruction always take the high half of both source registers into
account.  See my_ldexp_long in the test case.

gcc/ChangeLog:

* config/loongarch/loongarch.md (UNSPEC_FSCALEB): New unspec.
(type): Add fscaleb.
(IMODE): New mode attr.
(ldexp<mode>3): New instruction template.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/fscaleb.c: New test.

LoongArch: Add ftint{,rm,rp}.{w,l}.{s,d} instructions

This allows to optimize the following builtins if -fno-math-errno:

- __builtin_lrint{,f}
- __builtin_lfloor{,f}
- __builtin_lceil{,f}

Inspired by
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605287.html.

ANYFI is added so the compiler won't try ftint.l.s if -mfpu=32.  If we
simply used GPR here an ICE would be triggered with __builtin_lrintf
and -mfpu=32.

ftint{rm,rp} instructions may raise inexact exception, so they can't be
used if -fno-trapping-math -fno-fp-int-builtin-inexact.

Note that the .w.{s,d} variants are not tested because we don't support
ILP32 for now.

gcc/ChangeLog:

* config/loongarch/loongarch.md (UNSPEC_FTINT): New unspec.
(UNSPEC_FTINTRM): Likewise.
(UNSPEC_FTINTRP): Likewise.
(LRINT): New define_int_iterator.
(lrint_pattern): New define_int_attr.
(lrint_submenmonic): Likewise.
(lrint_allow_inexact): Likewise.
(ANYFI): New define_mode_iterator.
(lrint<ANYF><ANYFI>): New instruction template.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/ftint.c: New test.
* gcc.target/loongarch/ftint-no-inexact.c: New test.

LoongArch: Rename frint_<fmt> to rint<mode>2

Use standard name so __builtin_rint{,f} can be expanded to one
instruction.

gcc/ChangeLog:

* config/loongarch/loongarch.md (frint_<fmt>): Rename to ..
(rint<mode>2): .. this.

gcc/testsuite/ChangeLog:

* gcc.target/loongarch/frint.c: New test.

libstdc++: Simplify build targets for debug library

This rewrites the stamp-debug and build-debug targets in src/Makefile so
that each generated Makefile in the debug/$(SUBDIRS) directories is a
make target, instead of being created by a loop in the stamp-debug
recipe. The final adjustments to debug/Makefile are done as part of the
stamp-debug target instead of the build-debug target.

The advantage is that each $(SUBDIRS)/debug/Makefile now has the
corresponding $(SUBDIRS)/Makefile as a prerequisite, so they will be
regenerated if needed. Generating those can also be parallelized by
make, although those steps are very fast so that doesn't really matter.

This also removes the duplication in the stamp-debug recipe, which was
using exactly the same sed command for debug/Makefile and each
debug/$(SUBDIRS)/Makefile. That is done by adding "." to the list of
subdirectories to process. The recipes can also be simplified to use
separate shell commands per line, instead of using backslashes to join
the whole recipe into a single shell command.

Also replace 'echo `date` > stamp-xxx' with just 'date > stamp-xxx'
which is equivalent but simpler.

libstdc++-v3/ChangeLog:

* src/Makefile.am: Simplify debug build targets.
* src/Makefile.in: Regenerate.

libstdc++: Define INSTANTIATE_FACET_ACCESSORS macro in compat source [PR103755]

compatibility-ldbl-alt128.cc re-includes locale-inst-numeric.h and
locale-inst-monetary.h but wasn't defining the macros added in
r13-3888-gb3ac43a3c05744.

Put those macros in a new internal header that can be included everywhere
they're used.

libstdc++-v3/ChangeLog:

PR libstdc++/103755
* src/c++11/locale-inst-monetary.h: Include new header.
* src/c++11/locale-inst-numeric.h: Likewise.
* src/c++11/locale-inst.cc: Likewise.
(INSTANTIATE_USE_FACET, INSTANTIATE_FACET_ACCESSORS): Move
macro definitions to ...
* src/c++11/facet_inst_macros.h: New file.

Daily bump.

libstdc++: Fix <experimental/filesystem> for Windows [PR95048]

I meant to include this change in r13-3909-gb331bf303bdc1e but I forgot
to sync it from the machine where I did the mingw testing to the one
where I pushed the commit.

libstdc++-v3/ChangeLog:

PR libstdc++/95048
* include/experimental/bits/fs_path.h (path::_Cvt::_S_wconvert):
Construct codecvt directly instead of getting it from the
locale.

analyzer: more state machine documentation

gcc/analyzer/ChangeLog:
* sm-fd.dot: Fix typo in comment.
* sm-file.dot: New file.
* varargs.cc: Fix typo in comment.
* varargs.dot: New file.

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

analyzer: split out checker_event classes to their own header

gcc/analyzer/ChangeLog:
* checker-path.h: Split out checker_event and its subclasses to...
* checker-event.h: ...this new header.

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

analyzer: new warning: -Wanalyzer-infinite-recursion [PR106147]

This patch adds a new -Wanalyzer-infinite-recursion warning to
-fanalyzer, which complains about certain cases of infinite recursion.

Specifically, when it detects recursion during its symbolic execution
of the user's code, it compares the state of memory to that at the
previous level of recursion, and if nothing appears to have effectively
changed, it issues a warning.

Unlike the middle-end warning -Winfinite-recursion (added by Martin
Sebor in GCC 12; r12-5483-g30ba058f77eedf), the analyzer warning
complains if there exists an interprocedural path in which recursion
occurs in which memory has not changed, whereas -Winfinite-recursion
complains if *every* intraprocedural path through the function leads to
a self-call.

Hence the warnings complement each other: there's some overlap, but each
also catches issues that the other misses.

For example, the new warning complains about a guarded recursion in
which the guard is passed unchanged:

void test_guarded (int flag)
{
  if (flag)
    test_guarded (flag);
}

t.c: In function 'test_guarded':
t.c:4:5: warning: infinite recursion [CWE-674] [-Wanalyzer-infinite-recursion]
    4 |     test_guarded (flag);
      |     ^~~~~~~~~~~~~~~~~~~
  'test_guarded': events 1-4
    |
    |    1 | void test_guarded (int flag)
    |      |      ^~~~~~~~~~~~
    |      |      |
    |      |      (1) initial entry to 'test_guarded'
    |    2 | {
    |    3 |   if (flag)
    |      |      ~
    |      |      |
    |      |      (2) following 'true' branch (when 'flag != 0')...
    |    4 |     test_guarded (flag);
    |      |     ~~~~~~~~~~~~~~~~~~~
    |      |     |
    |      |     (3) ...to here
    |      |     (4) calling 'test_guarded' from 'test_guarded'
    |
    +--> 'test_guarded': events 5-6
           |
           |    1 | void test_guarded (int flag)
           |      |      ^~~~~~~~~~~~
           |      |      |
           |      |      (5) recursive entry to 'test_guarded'; previously entered at (1)
           |      |      (6) apparently infinite recursion
           |

whereas the existing warning doesn't complain, since when "flag" is
false the function doesn't recurse.

The new warning doesn't trigger for e.g.:

  void test_param_variant (int depth)
  {
    if (depth > 0)
      test_param_variant (depth - 1);
  }

on the grounds that "depth" is changing, and appears to be a variant
that enforces termination of the recursion.

gcc/ChangeLog:
PR analyzer/106147
* Makefile.in (ANALYZER_OBJS): Add analyzer/infinite-recursion.o.

gcc/analyzer/ChangeLog:
PR analyzer/106147
* analyzer.opt (Wanalyzer-infinite-recursion): New.
* call-string.cc (call_string::count_occurrences_of_function):
New.
* call-string.h (call_string::count_occurrences_of_function): New
decl.
* checker-path.cc (function_entry_event::function_entry_event):
New ctor.
(checker_path::add_final_event): Delete.
* checker-path.h (function_entry_event::function_entry_event): New
ctor.
(function_entry_event::get_desc): Drop "final".
(checker_path::add_final_event): Delete.
* diagnostic-manager.cc
(diagnostic_manager::emit_saved_diagnostic): Create the final
event via a new pending_diagnostic::add_final_event vfunc, rather
than checker_path::add_final_event.
(diagnostic_manager::add_events_for_eedge): Create function entry
events via a new pending_diagnostic::add_function_entry_event
vfunc.
* engine.cc (exploded_graph::process_node): When creating a new
PK_BEFORE_SUPERNODE node, call
exploded_graph::detect_infinite_recursion on it after adding the
in-edge.
* exploded-graph.h (exploded_graph::detect_infinite_recursion):
New decl.
(exploded_graph::find_previous_entry_to): New decl.
* infinite-recursion.cc: New file.
* pending-diagnostic.cc
(pending_diagnostic::add_function_entry_event): New.
(pending_diagnostic::add_final_event): New.
* pending-diagnostic.h
(pending_diagnostic::add_function_entry_event): New vfunc.
(pending_diagnostic::add_final_event): New vfunc.

gcc/ChangeLog:
PR analyzer/106147
* doc/gcc/gcc-command-options/options-that-control-static-analysis.rst:
Add -Wanalyzer-infinite-recursion.
* doc/gcc/gcc-command-options/options-to-request-or-suppress-warnings.rst
(-Winfinite-recursion): Mention -Wanalyzer-infinite-recursion.

gcc/testsuite/ChangeLog:
PR analyzer/106147
* g++.dg/analyzer/infinite-recursion-1.C: New test.
* g++.dg/analyzer/infinite-recursion-2.C: New test, copied from
g++.dg/warn/Winfinite-recursion-2.C.
* g++.dg/analyzer/infinite-recursion-3.C: New test, adapted from
g++.dg/warn/Winfinite-recursion-3.C.
* gcc.dg/analyzer/infinite-recursion-2.c: New test.
* gcc.dg/analyzer/infinite-recursion-3.c: New test.
* gcc.dg/analyzer/infinite-recursion-4-limited-buggy.c: New test.
* gcc.dg/analyzer/infinite-recursion-4-limited.c: New test.
* gcc.dg/analyzer/infinite-recursion-4-unlimited-buggy.c: New test.
* gcc.dg/analyzer/infinite-recursion-4-unlimited.c: New test.
* gcc.dg/analyzer/infinite-recursion-5.c: New test, adapted from
gcc.dg/Winfinite-recursion.c.
* gcc.dg/analyzer/infinite-recursion-alloca.c: New test.
* gcc.dg/analyzer/infinite-recursion-inlining.c: New test.
* gcc.dg/analyzer/infinite-recursion-multiline-1.c: New test.
* gcc.dg/analyzer/infinite-recursion-multiline-2.c: New test.
* gcc.dg/analyzer/infinite-recursion-variadic.c: New test.
* gcc.dg/analyzer/infinite-recursion.c: Add dg-warning directives
where infinite recursions occur.
* gcc.dg/analyzer/malloc-ipa-12.c: Likewise.
* gcc.dg/analyzer/pr105365.c: Likewise.
* gcc.dg/analyzer/pr105366.c: Likewise.
* gcc.dg/analyzer/pr97029.c: Likewise.

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

Don't add dependencies in update_stmt.

gimple_ranger::update_stmt has no idea what the context of an update
is, and should not be adding relations when it re-evaluates a stmt.

PR tree-optimization/107523
gcc/
* gimple-range.cc (gimple_ranger::update_stmt): Use fur_stmt
rather than fur_depend.

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

libstdc++: Set active union member in constexpr std::string [PR103295]

Clang still complains about using std::string in constexpr contexts due
to the changes made in commit 98a0d72a. This patch ensures that we set
the active member of the union as according to [class.union.general] p6.

libstdc++-v3/ChangeLog:

PR libstdc++/103295
* include/bits/basic_string.h (_M_use_local_data): Set active
member to _M_local_buf.

Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

libstdc++: Fix wstring conversions in filesystem::path [PR95048]

In commit r9-7381-g91756c4abc1757 I changed filesystem::path to use
std::codecvt<CharT, char, mbstate_t> for conversions from all wide
strings to UTF-8, instead of using std::codecvt_utf8<CharT>. This was
done because for 16-bit wchar_t, std::codecvt_utf8<wchar_t> only
supports UCS-2 and not UTF-16. The rationale for the change was sound,
but the actual fix was not. It's OK to use std::codecvt for char16_t or
char32_t, because the specializations for those types always use UTF-8 ,
but std::codecvt<wchar_t, char, mbstate_t> uses the current locale's
encodings, and the narrow encoding is probably ASCII and can't support
non-ASCII characters.

The correct fix is to use std::codecvt only for char16_t and char32_t.
For 32-bit wchar_t we could have continued using std::codecvt_utf8
because that uses UTF-32 which is fine, switching to std::codecvt broke
non-Windows targets with 32-bit wchar_t. For 16-bit wchar_t we did need
to change, but should have changed to std::codecvt_utf8_utf16<wchar_t>
instead, as that always uses UTF-16 not UCS-2. I actually noted that in
the commit message for r9-7381-g91756c4abc1757 but didn't use that
option. Oops.

This replaces the unconditional std::codecvt<CharT, char, mbstate_t>
with a type defined via template specialization, so it can vary
depending on the wide character type. The code is also simplified to
remove some of the mess of #ifdef and if-constexpr conditions.

libstdc++-v3/ChangeLog:

PR libstdc++/95048
* include/bits/fs_path.h (path::_Codecvt): New class template
that selects the kind of code conversion done.
(path::_Codecvt<wchar_t>): Select based on sizeof(wchar_t).
(_GLIBCXX_CONV_FROM_UTF8): New macro to allow the same code to
be used for Windows and POSIX.
(path::_S_convert(const EcharT*, const EcharT*)): Simplify by
using _Codecvt and _GLIBCXX_CONV_FROM_UTF8 abstractions.
(path::_S_str_convert(basic_string_view<value_type>, const A&)):
Simplify nested conditions.
* include/experimental/bits/fs_path.h (path::_Cvt): Define
nested typedef controlling type of code conversion done.
(path::_Cvt::_S_wconvert): Use new typedef.
(path::string(const A&)): Likewise.
* testsuite/27_io/filesystem/path/construct/95048.cc: New test.
* testsuite/experimental/filesystem/path/construct/95048.cc: New
test.

process transitive inferred ranges in pre_fold_stmt.

The subst_and_fold engine can perform some folding activity before
calling fold_stmt, so do this work in pre_fold_stmt instead.

* tree-vrp.cc (rvrp_folder::rvrp_folder): Init m_last_bb_stmt.
(rvrp_folder::pre_fold_bb): Set m_last_bb_stmt.
(rvrp_folder::pre_fold_stmt): Check for transitive inferred ranges.
(rvrp_folder::fold_stmt): Check in pre_fold_stmt instead.

aarch64: Add support for Cortex-X1C CPU.

This patch adds support for Cortex-X1C CPU.

Regards,
Srinath.

gcc/ChangeLog:

2022-11-09  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

* config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Cortex-X1C
CPU.
* config/aarch64/aarch64-tune.md: Regenerate.
* doc/gcc/gcc-command-options/machine-dependent-options/aarch64-options.rst:
Document Cortex-X1C CPU.

aarch64: Add support for Cortex-A715 CPU.

This patch adds support for Cortex-A715 CPU.

Regards,
Srinath.

gcc/ChangeLog:

2022-11-09  Srinath Parvathaneni  <srinath.parvathaneni@arm.com>

* config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Cortex-A715
CPU.
* config/aarch64/aarch64-tune.md: Regenerate.
* doc/gcc/gcc-command-options/machine-dependent-options/aarch64-options.rst:
Document Cortex-A715 CPU.

tree-optimization/107554 - fix ICE in stlen optimization

The following fixes a wrongly typed variable causing an ICE.

PR tree-optimization/107554
* tree-ssa-strlen.cc (strlen_pass::count_nonzero_bytes):
Use unsigned HOST_WIDE_INT type for the strlen.

* gcc.dg/pr107554.c: New testcase.

Co-Authored-By: Nikita Voronov <nik_1357@mail.ru>

tree-optimization/105142 - improve maybe_fold_comparisons_from_match_pd fix

The following improves on the fix for PR105142 which restricted the
expression lookup used for maybe_fold_comparisons_from_match_pd to
avoid picking up flow-sensitive info for use in places where guarding
conditions do not hold.  Instead of not allowing to expand SSA
definitions there the following temporarily clears flow-sensitive
info on the SSA names and restores it when finished matching.

PR tree-optimization/105142
* gimple-fold.cc (fosa_unwind): New global.
(follow_outer_ssa_edges): When the SSA definition to follow
is does not dominate fosa_bb, temporarily clear flow-sensitive
info.  Make sure to not expand stmts with not defined overflow.
(maybe_fold_comparisons_from_match_pd): Set up unwind stack
for follow_outer_ssa_edges and unwind flow-sensitive info
clearing after matching.

[range-ops] Remove specialized fold_range methods for various operators.

Remove some specialized fold_range methods that were merely setting
maybe nonzero masks, as these are now subsumed by the generic version.

gcc/ChangeLog:

* range-op.cc (operator_mult::fold_range): Remove.
(operator_div::fold_range): Remove.
(operator_bitwise_and): Remove.

[range-ops] Avoid unnecessary intersection in update_known_bitmask.

All the work for keeping the maybe nonzero masks up to date is being
done by the bit-CCP code now.  Any bitmask inherent in the range that
range-ops may have calculated has no extra information, so the
intersection is unnecessary.

gcc/ChangeLog:

* range-op.cc (update_known_bitmask): Avoid unnecessary intersection.

[range-ops] Update known bitmasks using CCP for all operators.

Use bit-CCP to calculate bitmasks for all integer operators, instead
of the half-assed job we were doing with just a handful of operators.

This sets us up nicely for tracking known-one bitmasks in the next
release, as all we'll have to do is just store them in the irange.

All in all, this series of patches incur a 1.9% penalty to VRP, with
no measurable difference in overall compile time.  The reason is
three-fold:

(a) There's double dispatch going on.  First, the dispatch for the
range-ops virtuals, and now the switch in bit_value_binop.

(b) The maybe nonzero mask is stored as a tree and there is an endless
back and forth with wide-ints.  This will be a non-issue next release,
when we convert irange to wide-ints.

(c) New functionality has a cost.  We were handling 2 cases (plus
casts).  Now we handle 20.

I can play around with moving the bit_value_binop cases into inlined
methods in the different range-op entries, and see if that improves
anything, but I doubt (a) buys us that much.  Certainly something that
can be done in stage3 if it's measurable in any significant way.

p.s It would be nice in the future to teach the op[12]_range methods about
the masks.

gcc/ChangeLog:

* range-op.cc (range_operator::fold_range): Call
update_known_bitmask.
(operator_bitwise_and::fold_range): Avoid setting nonzero bits
when range is undefined.

[range-ops] Use existing tree code for *DIV_EXPR entries.

There is no need for a special tree code in the *DIV_EXPR entries, as
the parent class has one.

gcc/ChangeLog:

* range-op.cc (class operator_div): Remove tree code.
(operator_div::wi_op_overflows): Handle EXACT_DIV_EXPR as
TRUNC_DIV_EXPR.

[range-ops] Add tree code to range_operator.

This patch adds a tree code to range_operator in order to known which
tree code to pass into bit-CCP.

Up to now range-ops has been free of tree details, with the exception
of the div entries which use a tree code to differentiate between
them.  This is still the goal going forward, but this is a stop-gap
until we can merge the CCP and range-op bit handling in the next
release.

No change in performance.

gcc/ChangeLog:

* range-op.cc: (range_op_table::set): Set m_code.
(integral_table::integral_table): Handle shared entries.
(pointer_table::pointer_table): Same.
* range-op.h (class range_operator): Add m_code.

tree-optimization/107618 - enhance copy propagation of constants

The following enhances copy propagation of constants to also see
through simple operations like conversions but also operations with
otherwise constant operands.  That's required to fulfill the promise

      /* Copy propagation also copy-propagates constants, this is necessary
         to forward object-size and builtin folding results properly.  */
      NEXT_PASS (pass_copy_prop);

and avoid false diagnostics as shown in the testcase.  We're
using gimple_fold_stmt_to_constant_1 with not following SSA edges
and accordingly adjust what stmts we simulate during SSA propagation.

PR tree-optimization/107618
* tree-ssa-copy.cc (stmt_may_generate_copy): Simulate all
assignments with a single SSA use.
(copy_prop_visit_assignment): Use gimple_fold_stmt_to_constant_1
to perform simple constant folding.
(copy_prop::visit_stmt): Visit all assignments.

* gcc.dg/pr107618.c: New testcase.

Make last DCE remove empty loops

The following makes the last DCE pass CD-DCE and in turn the
last CD-DCE pass a DCE one.  That ensues we remove empty loops
that become empty between the two.  I've also moved the tail-call
pass after DCE since DCE can only improve things here.

The two testcases were the only ones scanning cddce3 so I've
changed them to scan the dce7 pass that's now in this place.
The testcases scanning dce7 also work when that's in the earlier
position.

PR tree-optimization/84646
* tree-ssa-dce.cc (pass_dce::set_pass_param): Add param
wheter to run update-address-taken.
(pass_dce::execute): Honor it.
* passes.def: Exchange last DCE and CD-DCE invocations.
Swap pass_tail_calls and the last DCE.

* g++.dg/tree-ssa/pr106922.C: Continue to scan earlier DCE dump.
* gcc.dg/tree-ssa/20030808-1.c: Likewise.

jit: doc: Use shared Indices and tables

Apart from that, do not use leading .rst names in toctree.

ChangeLog:

* doc/indices-and-tables.rst: Rename Indexes to Indices.

gcc/jit/ChangeLog:

* doc/cp/index.rst: Remove trailing .rst in toctree.
* doc/cp/intro/index.rst: Likewise.
* doc/cp/topics/index.rst: Likewise.
* doc/index.rst: Likewise.
* doc/intro/index.rst: Likewise.
* doc/topics/index.rst: Likewise.
* doc/indices-and-tables.rst: New file.

doc: update sphinx-build -j auto comment

ChangeLog:

* doc/Makefile: Update comment.

sphinx: stop using parallel mode

Noticed that the documentation build can stuck on a machine with
many cores (160) and I identified a real sphinx problem:
https://github.com/sphinx-doc/sphinx/issues/10969

Note the parallel can help just for some manuals and it is not critical
for us.

ChangeLog:

* doc/Makefile: Disable -j auto.

changelog: check for space after tab

contrib/ChangeLog:

* gcc-changelog/git_commit.py: Check for a space after leading
tab.
* gcc-changelog/test_email.py: Likewise.
* gcc-changelog/test_patches.txt: Likewise.

RISC-V: Add RVV registers register spilling

This patch support RVV scalable register spilling.
prologue && epilogue handling pick up prototype from Monk Chiang <monk.chiang@sifive.com>.
Co-authored-by: Monk Chiang <monk.chiang@sifive.com>
gcc/ChangeLog:

* config/riscv/riscv-v.cc (emit_pred_move): Adjust for scalable register spilling.
(legitimize_move): Ditto.
* config/riscv/riscv.cc (riscv_v_adjust_scalable_frame): New function.
(riscv_first_stack_step): Adjust for scalable register spilling.
(riscv_expand_prologue): Ditto.
(riscv_expand_epilogue): Ditto.
(riscv_dwarf_poly_indeterminate_value): New function.
(TARGET_DWARF_POLY_INDETERMINATE_VALUE): New target hook support for register spilling.
* config/riscv/riscv.h (RISCV_DWARF_VLENB): New macro.
(RISCV_PROLOGUE_TEMP2_REGNUM): Ditto.
(RISCV_PROLOGUE_TEMP2): Ditto.
* config/riscv/vector-iterators.md: New iterators.
* config/riscv/vector.md (*mov<mode>): Fix it for register spilling.
(*mov<mode>_whole): New pattern.
(*mov<mode>_fract): New pattern.
(@pred_mov<mode>): Fix it for register spilling.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/macro.h: New test.
* gcc.target/riscv/rvv/base/spill-1.c: New test.
* gcc.target/riscv/rvv/base/spill-10.c: New test.
* gcc.target/riscv/rvv/base/spill-11.c: New test.
* gcc.target/riscv/rvv/base/spill-12.c: New test.
* gcc.target/riscv/rvv/base/spill-2.c: New test.
* gcc.target/riscv/rvv/base/spill-3.c: New test.
* gcc.target/riscv/rvv/base/spill-4.c: New test.
* gcc.target/riscv/rvv/base/spill-5.c: New test.
* gcc.target/riscv/rvv/base/spill-6.c: New test.
* gcc.target/riscv/rvv/base/spill-7.c: New test.
* gcc.target/riscv/rvv/base/spill-8.c: New test.
* gcc.target/riscv/rvv/base/spill-9.c: New test.

libstdc++: Fix tests with non-const operator==

These tests fail in strict -std=c++20 mode but their equality ops don't
need to be non-const, it looks like an accident.

This fixes two FAILs with -std=c++20:
FAIL: 20_util/tuple/swap.cc (test for excess errors)
FAIL: 26_numerics/valarray/87641.cc (test for excess errors)

libstdc++-v3/ChangeLog:

* testsuite/20_util/tuple/swap.cc (MoveOnly::operator==): Add
const qualifier.
* testsuite/26_numerics/valarray/87641.cc (X::operator==):
Likewise.

libstdc++: Add missing definition for <charconv> in C++14 mode

We support <charconv> in C++14 as an extension, but that means that
constexpr static data members are not implicitly inline. Add an
out-of-class definition for C++14 mode.

This fixes a FAIL when -std=gnu++14 is used:
FAIL: 20_util/from_chars/1.cc (test for excess errors)

libstdc++-v3/ChangeLog:

* include/std/charconv (__from_chars_alnum_to_val_table::value):
[!__cpp_inline_variables]: Add non-inline definition.

libstdc++: Fix test that uses C++17 variable template in C++14

This test fails if run with -std=gnu++14 because it should be using
is_convertible instead of is_convertible_v.

libstdc++-v3/ChangeLog:

* testsuite/experimental/propagate_const/observers/107525.cc:
Use type trait instead of C++17 variable template.

libstdc++: Avoid redundant checks in std::use_facet [PR103755]

We do not need to do bounds checks or a runtime dynamic_cast when using
std::has_facet and std::use_facet to access the default facets that are
guaranteed to be present in every std::locale object. We can just index
straight into the array and use a static_cast for the conversion.

This patch adds a new std::__try_use_facet function that is like
std::use_facet but returns a pointer, so can be used to implement both
std::has_facet and std::use_facet. We can then do the necessary
metaprogramming to skip the redundant checks in std::__try_use_facet.

To avoid having to export (or hide) instantiations of the new function
from libstdc++.so the instantiations are given hidden visibility. This
allows them to be used in the library, but user code will instantiate it
again using the definition in the header. That would happen anyway,
because there are no explicit instantiation declarations for any of
std::has_facet, std::use_facet, or the new std::__try_use_facet.

libstdc++-v3/ChangeLog:

PR libstdc++/103755
* config/abi/pre/gnu.ver: Tighten patterns for facets in the
base version. Add exports for __try_use_facet.
* include/bits/basic_ios.tcc (basic_ios::_M_cache_locale): Use
__try_use_facet instead of has_facet and use_facet.
* include/bits/fstream.tcc (basic_filebuf::basic_filebuf()):
Likewise.
(basic_filebuf::imbue): Likewise.
* include/bits/locale_classes.h (locale, locale::id)
(locale::_Impl): Declare __try_use_facet as a friend.
* include/bits/locale_classes.tcc (__try_use_facet): Define new
function template with special cases for default facets.
(has_facet, use_facet): Call __try_use_facet.
* include/bits/locale_facets.tcc (__try_use_facet): Declare
explicit instantiations.
* include/bits/locale_facets_nonio.tcc (__try_use_facet):
Likewise.
* src/c++11/locale-inst-monetary.h (INSTANTIATE_FACET_ACCESSORS):
Use new macro for facet accessor instantiations.
* src/c++11/locale-inst-numeric.h (INSTANTIATE_FACET_ACCESSORS):
Likewise.
* src/c++11/locale-inst.cc (INSTANTIATE_USE_FACET): Define new
macro for instantiating __try_use_facet and use_facet.
(INSTANTIATE_FACET_ACCESSORS): Define new macro for also
defining has_facet.
* src/c++98/compatibility-ldbl.cc (__try_use_facet):
Instantiate.
* testsuite/22_locale/ctype/is/string/89728_neg.cc: Adjust
expected errors.

c-family: Support #pragma region/endregion [PR85487]

These pragmas are used by some editors to mark regions of code for
grouping and folding. GCC should silently ignore them, rather than
giving -Wunknown-pragmas warnings.

PR c/85487

gcc/ChangeLog:

* doc/cpp/pragmas.rst (Pragmas): Document region pragmas.

gcc/c-family/ChangeLog:

* c-pragma.cc (handle_pragma_ignore): New function.
(init_pragma): Register region and endregion pragmas.

gcc/testsuite/ChangeLog:

* c-c++-common/pragma-region.c: New test.