Daily bump.

Daily bump.

Regenerate gcc.pot

* gcc.pot: Regenerate.

PR106342 - IBM zSystems: Provide vsel for all vector modes

dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
produces an insn that vsel<mode> is supposed to recognize, but can't,
because it's not defined for V2SF.  Fix by defining it for all vector
modes supported by copysign<mode>3.

gcc/ChangeLog:

* config/s390/vector.md (V_HW_FT): New iterator.
* config/s390/vx-builtins.md (vsel<mode>): Use V_HW_FT instead
of V_HW.

(cherry picked from commit 2f17f489de47d46626ed85804c3b810547ef550e)

Daily bump.

d: Update DIP links in gdc documentation to point at upstream repository

The wiki links probably worked at some point in the distant past, but
now the official location of tracking all D Improvement Proposals is on
the upstream dlang/DIPs GitHub repository.

PR d/106638

gcc/d/ChangeLog:

* gdc.texi: Update DIP links to point at upstream dlang/DIPs
repository.

(cherry picked from commit e56b695aa3aed3c0c80616bba569bbeb4a06b5e5)

Daily bump.

d: Defer compiling inline definitions until after the module has finished.

This is to prevent the case of when generating the methods of a struct
type, we don't accidentally emit an inline function that references it,
as the outer struct itself would still be incomplete.

gcc/d/ChangeLog:

* d-tree.h (d_defer_declaration): Declare.
* decl.cc (function_needs_inline_definition_p): Defer checking
DECL_UNINLINABLE and DECL_DECLARED_INLINE_P.
(maybe_build_decl_tree): Call d_defer_declaration instead of
build_decl_tree.
* modules.cc (deferred_inline_declarations): New variable.
(build_module_tree): Set deferred_inline_declarations and a handle
declarations pushed to it.
(d_defer_declaration): New function.

(cherry picked from commit 8db5b71e212debcc4f6a17f80191ca187c307fcb)

d: Fix internal compiler error: Segmentation fault at gimple-expr.cc:88

Because complex types are deprecated in the language, the new way to
expose native complex types is by defining an enum with a basetype of a
library-defined struct that is implicitly treated as-if it is native.
As casts are not implicitly added by the front-end when downcasting from
enum to its underlying type, we must insert an explicit cast during the
code generation pass.

PR d/106623

gcc/d/ChangeLog:

* d-codegen.cc (underlying_complex_expr): New function.
(d_build_call): Handle passing native complex objects as the
library-defined equivalent.
* d-tree.h (underlying_complex_expr): Declare.
* expr.cc (ExprVisitor::visit (DotVarExp *)): Call
underlying_complex_expr instead of build_vconvert.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr106623.d: New test.

(cherry picked from commit e206fecaac29f559f4990312b875604eb1ce3ef3)

Daily bump.

Daily bump.

Daily bump.

c++: constexpr, empty base after non-empty [PR106369]

Here the CONSTRUCTOR we were providing for D{} had an entry for the B base
subobject at offset 0 following the entry for the C base, causing
output_constructor_regular_field to ICE due to going backwards.  It might be
nice for that function to be more tolerant of empty fields, but it also
seems reasonable for the front end to prune the useless entry.

PR c++/106369

gcc/cp/ChangeLog:

* constexpr.cc (reduced_constant_expression_p): Return false
if a CONSTRUCTOR initializes an empty field.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-lambda27.C: New test.

(cherry picked from commit 9efe4e153d994974afcbba09c3c683f5f4a19c63)

c++: pedwarn for empty unnamed enum in decl [PR67048]

[dcl.dcl]/5 says that

  enum { };

is ill-formed, and since r197742 we issue a pedwarn.  However, the
pedwarn also fires for

   enum { } x;

which is well-formed.  So only warn when {} is followed by a ;.  This
should be correct since you can't have "enum {}, <whatever>" -- that
produces "expected unqualified-id before ',' token".

PR c++/67048

gcc/cp/ChangeLog:

* parser.cc (cp_parser_enum_specifier): Warn about empty unnamed enum
only when it's followed by a semicolon.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit fd0d3e9121c5aa65150d242676be6bbdc8d4a92a)

c: Handle initializations of opaque types [PR106016]

The initial commit that added opaque types thought that there couldn't
be any valid initializations for variables of these types, but the test
case in the bug report shows that isn't true.  The solution is to handle
OPAQUE_TYPE initializations like the other scalar types.

2022-06-17  Peter Bergner  <bergner@linux.ibm.com>

gcc/
PR c/106016
* expr.cc (count_type_elements): Handle OPAQUE_TYPE.

gcc/testsuite/
PR c/106016
* gcc.target/powerpc/pr106016.c: New test.

(cherry picked from commit 975658b782f36dcf6eb190966d5b705977bfd5eb)

Daily bump.

aarch64: Implement ACLE Data Intrinsics

This patch adds support for the ACLE Data Intrinsics to the AArch64 port.

gcc/ChangeLog:

2022-07-25  Andre Vieira  <andre.simoesdiasvieira@arm.com>

* config/aarch64/aarch64.md (rbit<mode>2): Rename this ...
(@aarch64_rbit<mode>): ... to this and change it in...
(ffs<mode>2,ctz<mode>2): ... here.
(@aarch64_rev16<mode>): New.
* config/aarch64/aarch64-builtins.cc: (aarch64_builtins):
Define the following enum AARCH64_REV16, AARCH64_REV16L,
AARCH64_REV16LL, AARCH64_RBIT, AARCH64_RBITL, AARCH64_RBITLL.
(aarch64_init_data_intrinsics): New.
(aarch64_general_init_builtins): Add call to
aarch64_init_data_intrinsics.
(aarch64_expand_builtin_data_intrinsic): New.
(aarch64_general_expand_builtin): Add call to
aarch64_expand_builtin_data_intrinsic.
* config/aarch64/arm_acle.h (__clz, __clzl, __clzll, __cls, __clsl,
__clsll, __rbit, __rbitl, __rbitll, __rev, __revl, __revll, __rev16,
__rev16l, __rev16ll, __ror, __rorl, __rorll, __revsh): New.

gcc/testsuite/ChangeLog:

2022-07-25  Andre Vieira  <andre.simoesdiasvieira@arm.com>

* gcc.target/aarch64/acle/data-intrinsics.c: New test.

(cherry picked from commit eb966d393dfdfd2c80994e4bfcc0dddf85828a73)

Daily bump.

OpenMP: Fix folding with simd's linear clause [PR106492]

gcc/ChangeLog:

PR middle-end/106492
* omp-low.cc (lower_rec_input_clauses): Add missing folding
to data type of linear-clause list item.

gcc/testsuite/ChangeLog:

PR middle-end/106492
* g++.dg/gomp/pr106492.C: New test.

(cherry picked from commit 8a16b9f983824b6b9a25275cd23b6bba8c98b800)

tree-optimization/106513 - fix mistake in bswap symbolic number shifts

This fixes a mistake in typing a local variable in the symbolic
shift routine.

PR tree-optimization/106513
* gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
for head_marker.

* gcc.dg/torture/pr106513.c: New testcase.

(cherry picked from commit f675afa4eeac9910a2c085a95aa04d6d9f2fd8d6)

lto/106540 - fix LTO tree input wrt dwarf2out_register_external_die

I've revisited the earlier two workarounds for dwarf2out_register_external_die
getting duplicate entries.  It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SCC then gets thrown away we can end up with debug nodes
registered which isn't supposed to happen.  The following adjusts
the DECL_INITIAL streaming to go the in-SCC way, using lto_input_tree_1,
since no SCCs are expected at this point, just refs.

PR lto/106540
PR lto/106334
* lto-streamer-in.cc (lto_read_tree_1): Use lto_input_tree_1
to input DECL_INITIAL, avoiding to commit drefs.

(cherry picked from commit 2a1448f2763a72c83e2ec496f78243a975b0d44e)

Daily bump.

libgccjit.h: Uncomment macro definition for testing gcc_jit_context_new_bitcast support

(cherry-picked from r13-2004-g9385cd9c74cf66)

The macro definition for LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast
was earlier located in the documentation comment for
gcc_jit_context_new_bitcast, making it unavailable to code that
consumed libgccjit.h. This commit moves the definition out of the
comment, making it effective.

gcc/jit/ChangeLog:
* libgccjit.h (LIBGCCJIT_HAVE_gcc_jit_context_new_bitcast): Move
definition out of comment.

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

d: Fix undefined reference to pragma(inline) symbol (PR106563)

Functions that are declared `pragma(inline)' should be treated as if
they are defined in every translation unit they are referenced from,
regardless of visibility protection.  Ensure they always get
DECL_ONE_ONLY linkage, and start emitting them into other modules that
import them.

PR d/106563

gcc/d/ChangeLog:

* decl.cc (DeclVisitor::visit (FuncDeclaration *)): Set semanticRun
before generating its symbol.
(function_defined_in_root_p): New function.
(function_needs_inline_definition_p): New function.
(maybe_build_decl_tree): New function.
(get_symbol_decl): Call maybe_build_decl_tree before returning symbol.
(start_function): Use function_defined_in_root_p instead of inline
test for locally defined symbols.
(set_linkage_for_decl): Check for inline functions before private or
protected symbols.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/torture.exp (srcdir): New proc.
* gdc.dg/torture/imports/pr106563math.d: New test.
* gdc.dg/torture/imports/pr106563regex.d: New test.
* gdc.dg/torture/imports/pr106563uni.d: New test.
* gdc.dg/torture/pr106563.d: New test.

(cherry picked from commit 04284176d549ff2565406406a6d53ab4ba8e507d)

Daily bump.

d: Fix ICE in in add_stack_var, at cfgexpand.cc:476

The type that triggers the ICE never got completed by the semantic
analysis pass.  Checking for size forces it to be done, or issue a
compile-time error.

PR d/106555

gcc/d/ChangeLog:

* d-target.cc (Target::isReturnOnStack): Check for return type size.

gcc/testsuite/ChangeLog:

* gdc.dg/imports/pr106555.d: New test.
* gdc.dg/pr106555.d: New test.

(cherry picked from commit 4b0253b019943abf2cc5f4db0b7ed67caedffe4a)

Daily bump.

Daily bump.

Daily bump.

Do not enable -mblock-ops-vector-pair.

Testing has shown that using the load vector pair and store vector pair
instructions for block moves has some performance issues on power10.

A patch on June 11th modified the code so that GCC would not set
-mblock-ops-vector-pair by default if we are tuning for power10, but it would
set the option if we were tuning for a different machine and have load and store
vector pair instructions enabled.

This patch eliminates the code setting -mblock-ops-vector-pair.  If you want to
generate load vector pair and store vector pair instructions for block moves,
you must use -mblock-ops-vector-pair.

2022-08-05   Michael Meissner  <meissner@linux.ibm.com>

gcc/

* config/rs6000/rs6000.cc (rs6000_option_override_internal): Remove code
setting -mblock-ops-vector-pair.  Back port patch from trunk on 8/3.

libstdc++: Make std::string_view(Range&&) constructor explicit

The P2499R0 paper was recently approved for C++23.

libstdc++-v3/ChangeLog:

* include/std/string_view (basic_string_view(Range&&)): Add
explicit as per P2499R0.
* testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc:
Adjust implicit conversions. Check implicit conversions fail.
* testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc:
Likewise.

(cherry picked from commit 2678386df2cc3505da85e95643327aa928e66a8e)

libstdc++: Rename data members of std::unexpected and std::bad_expected_access

The P2549R1 paper was accepted for C++23. I already implemented it for
our <expected>, but I didn't rename the private daata members, only the
public member functions. This renames the data members for consistency
with the working draft.

libstdc++-v3/ChangeLog:

* include/std/expected (unexpected::_M_val): Rename to _M_unex.
(bad_expected_access::_M_val): Likewise.

(cherry picked from commit 07c7ee4d2d42f4728928556dbbe0700f9a13db90)

libstdc++: Update value of __cpp_lib_ios_noreplace macro

My P2467R1 proposal was accepted for C++23 so there's an official value
for this macro now.

libstdc++-v3/ChangeLog:

* include/bits/ios_base.h (__cpp_lib_ios_noreplace): Update
value to 202207L.
* include/std/version (__cpp_lib_ios_noreplace): Likewise.
* testsuite/27_io/basic_ofstream/open/char/noreplace.cc: Check
for new value.
* testsuite/27_io/basic_ofstream/open/wchar_t/noreplace.cc:
Likewise.

(cherry picked from commit 3e9bd6b2b1782891639fa5d49b7d2a933b8e85cd)

Daily bump.

Daily bump.

libstdc++: Improve directory iterator abstractions for openat

Currently the _Dir::open_subdir function decides whether to construct a
_Dir_base with just a pathname, or a file descriptor and pathname. But
that means it is tightly coupled to the implementation of
_Dir_base::openat, which is what actually decides whether to use a file
descriptor or not. If the derived class passes a file descriptor and
filename, but the base class expects a full path and ignores the file
descriptor, then recursive_directory_iterator cannot recurse.

This change introduces a new type that provides the union of all the
information available to the derived class (the full pathname, as well
as a file descriptor for a directory and another pathname relative to
that directory). This allows the derived class to be agnostic to how the
base class will use that information.

libstdc++-v3/ChangeLog:

* src/c++17/fs_dir.cc (_Dir::dir_and_pathname):: Replace with
current() returning _At_path.
(_Dir::_Dir, _Dir::open_subdir, _Dir::do_unlink): Adjust.
* src/filesystem/dir-common.h (_Dir_base::_At_path): New class.
(_Dir_base::_Dir_Base, _Dir_base::openat): Use _At_path.
* src/filesystem/dir.cc (_Dir::dir_and_pathname): Replace with
current() returning _At_path.
(_Dir::_Dir, _Dir::open_subdir): Adjust.

(cherry picked from commit 198781144f33b0ef17dd2094580b5c77ad97d6e8)

libstdc++: Tweak common_iterator::operator-> return type [PR104443]

This adjusts the return type to match the resolution of LWG 3672. There
is no functional difference, because decltype(auto) always deduced a
value anyway, but this makes it simpler and consistent with the working
draft.

libstdc++-v3/ChangeLog:

PR libstdc++/104443
* include/bits/stl_iterator.h (common_iterator::operator->):
Change return type to just auto.

(cherry picked from commit b5f5d1b36edbcd7d923f2e2653e54e52637c715b)

libstdc++: Check for EOF if extraction avoids buffer overflow [PR106248]

In r11-2581-g17abcc77341584 (for LWG 2499) I added overflow checks to
the pre-C++20 operator>>(istream&, char*) overload.  Those checks can
cause extraction to stop after filling the buffer, where previously it
would have tried to extract another character and stopped at EOF. When
that happens we no longer set eofbit in the stream state, which is
consistent with the behaviour of the new C++20 overload, but is an
observable and unexpected change in the C++17 behaviour. What makes it
worse is that the behaviour change is dependent on optimization, because
__builtin_object_size is used to detect the buffer size and that only
works when optimizing.

To avoid the unexpected and optimization-dependent change in behaviour,
set eofbit manually if we stopped extracting because of the buffer size
check, but had reached EOF anyway. If the stream's rdstate() != goodbit
or width() is non-zero and smaller than the buffer, there's nothing to
do. Otherwise, we filled the buffer and need to check for EOF, and maybe
set eofbit.

The new check is guarded by #ifdef __OPTIMIZE__ because otherwise
__builtin_object_size is useless. There's no point compiling and
emitting dead code that can't be eliminated because we're not
optimizing.

We could add extra checks that the next character in the buffer is not
whitespace, to detect the case where we stopped early and prevented a
buffer overflow that would have happened otherwise. That would allow us
to assert or set badbit in the stream state when undefined behaviour was
prevented. However, those extra checks would increase the size of the
function, potentially reducing the likelihood of it being inlined, and
so making the buffer size detection less reliable. It seems preferable
to prevent UB and silently truncate, rather than miss the UB and allow
the overflow to happen.

libstdc++-v3/ChangeLog:

PR libstdc++/106248
* include/std/istream [C++17] (operator>>(istream&, char*)):
Set eofbit if we stopped extracting at EOF.
* testsuite/27_io/basic_istream/extractors_character/char/pr106248.cc:
New test.
* testsuite/27_io/basic_istream/extractors_character/wchar_t/pr106248.cc:
New test.

(cherry picked from commit 5ae74944af1de032d4a27fad4a2287bd3a2163fd)

libstdc++: Add nodiscard attribute to filesystem operations

Some of these are not truly "pure" because they access the file system,
e.g. exists and file_size, but they do not modify anything and are only
useful for the return value.

If you really want to use one of those functions just to check whether
an error is reported (either via an exception or an error_code&
argument) you can still do so, but you need to cast the discarded result
to void.  Several tests need such a change, because they were indeed
only calling the functions to check for expected errors.

libstdc++-v3/ChangeLog:

* include/bits/fs_ops.h: Add nodiscard to all pure functions.
* include/experimental/bits/fs_ops.h: Likewise.
* testsuite/27_io/filesystem/operations/all.cc: Do not discard
results of absolute and canonical.
* testsuite/27_io/filesystem/operations/absolute.cc: Cast
discarded result to void.
* testsuite/27_io/filesystem/operations/canonical.cc: Likewise.
* testsuite/27_io/filesystem/operations/exists.cc: Likewise.
* testsuite/27_io/filesystem/operations/is_empty.cc: Likewise.
* testsuite/27_io/filesystem/operations/read_symlink.cc:
Likewise.
* testsuite/27_io/filesystem/operations/status.cc: Likewise.
* testsuite/27_io/filesystem/operations/symlink_status.cc:
Likewise.
* testsuite/27_io/filesystem/operations/temp_directory_path.cc:
Likewise.
* testsuite/experimental/filesystem/operations/canonical.cc:
Likewise.
* testsuite/experimental/filesystem/operations/exists.cc:
Likewise.
* testsuite/experimental/filesystem/operations/is_empty.cc:
Likewise.
* testsuite/experimental/filesystem/operations/read_symlink.cc:
Likewise.
* testsuite/experimental/filesystem/operations/temp_directory_path.cc:
Likewise.

(cherry picked from commit f7a148304a71f3d3ad6845b7966fdc3af88c9e45)

libstdc++: Support constexpr global std::string for size < 15 [PR105995]

I don't think this is required by the standard, but it's easy to
support.

libstdc++-v3/ChangeLog:

PR libstdc++/105995
* include/bits/basic_string.h (_M_use_local_data): Initialize
the entire SSO buffer.
* testsuite/21_strings/basic_string/cons/char/105995.cc: New test.

(cherry picked from commit 98a0d72a610a87e8e383d366e50253ddcc9a51dd)

libstdc++: Fix indentation in allocator base classes

libstdc++-v3/ChangeLog:

* include/bits/new_allocator.h: Fix indentation.
* include/ext/malloc_allocator.h: Likewise.

(cherry picked from commit 29da01709facbcc7efef4fd6767660d417f44531)

libstdc++: Check for size overflow in constexpr allocation [PR105957]

libstdc++-v3/ChangeLog:

PR libstdc++/105957
* include/bits/allocator.h (allocator::allocate): Check for
overflow in constexpr allocation.
* testsuite/20_util/allocator/105975.cc: New test.

(cherry picked from commit 0a9af7b4ef1b8aa85cc8820acf54d41d1569fc10)

libstdc++: Make std::lcm and std::gcd detect overflow [PR105844]

When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(50000, 49999) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu<unsigned>(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.

To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(500000u, 499999u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.

libstdc++-v3/ChangeLog:

PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.

(cherry picked from commit 671970a5621e18e7079b4ca113e56434c858db66)

libfortran: Fix up boz_15.f90 on powerpc64le with -mabi=ieeelongdouble [PR106079]

The boz_15.f90 test FAILs on powerpc64le-linux when -mabi=ieeelongdouble
is used (either default through --with-long-double-format=ieee or
when used explicitly).
The problem is that the read/write transfer routines are called with
BT_REAL (or BT_COMPLEX) type and kind 17 which is magic we use to say
it is the IEEE quad real(kind=16) rather than the IBM double double
real(kind=16).  For the floating point input/output we then handle kind
17 specially, but for B/O/Z we just treat the bytes of the floating point
value as binary blob and using 17 in that case results in unexpected
behavior, for write it means we don't estimate right how many chars we'll
need and print ******************** etc. rather than what we should, and
even with explicit size we'd print one further byte than intended.
For read it would even mean overwriting some unrelated byte after the
floating point object.

Fixed by using 16 instead of 17 in the read_radix and write_{b,o,z} calls.

2022-08-01  Jakub Jelinek  <jakub@redhat.com>

PR libfortran/106079
* io/transfer.c (formatted_transfer_scalar_read,
formatted_transfer_scalar_write): For type BT_REAL with kind 17
change kind to 16 before calling read_radix or write_{b,o,z}.

(cherry picked from commit 82ac4cd213867be939aedee15347e8fd3f200b6a)

Daily bump.

rs6000: Adjust -mdejagnu-cpu to filter out -mtune [PR106345]

As PR106345 shows, when configuring compiler with an explicit
option --with-tune=<value>, it would cause some test cases to
fail if their test points are sensitive to tune setting, such
as: group_ending_nop, loop align etc.  It doesn't help that
even to specify one explicit -mcpu=.

This patch is to adjust the behavior of -mdejagnu-cpu by
filtering out all -mcpu= and -mtune= options, then test cases
would use <cpu> as tune as the one specified by -mdejagnu-cpu.

2022-07-25  Peter Bergner  <bergner@linux.ibm.com>
    Kewen Lin  <linkw@linux.ibm.com>

PR testsuite/106345

gcc/ChangeLog:

* config/rs6000/rs6000.h (DRIVER_SELF_SPECS): Adjust -mdejagnu-cpu
to filter out all -mtune options.

(cherry picked from commit 75d20d6c84c12bedd65a904e462f02f0b9eb3f77)

rs6000: Preserve REG_EH_REGION when replacing load/store [PR106091]

As test case in PR106091 shows, rs6000 specific pass swaps
doesn't preserve the reg_note REG_EH_REGION when replacing
some load insn at the end of basic block, it causes the
flow info verification to fail unexpectedly.  Since memory
reference rtx may trap, this patch is to ensure we copy
REG_EH_REGION reg_note while replacing swapped aligned load
or store.

PR target/106091

gcc/ChangeLog:

* config/rs6000/rs6000-p8swap.cc (replace_swapped_aligned_store): Copy
REG_EH_REGION when replacing one store insn having it.
(replace_swapped_aligned_load): Likewise.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit f4286601933406142b46693660f7f4b682cb50a5)

Daily bump.

c: Fix location for _Pragma tokens [PR97498]

The handling of #pragma GCC diagnostic uses input_location, which is not always
as precise as needed; in particular the relative location of some tokens and a
_Pragma directive will crucially determine whether a given diagnostic is enabled
or suppressed in the desired way. PR97498 shows how the C frontend ends up with
input_location pointing to the beginning of the line containing a _Pragma()
directive, resulting in the wrong behavior if the diagnostic to be modified
pertains to some tokens found earlier on the same line. This patch fixes that by
addressing two issues:

    a) libcpp was not assigning a valid location to the CPP_PRAGMA token
    generated by the _Pragma directive.
    b) C frontend was not setting input_location to something reasonable.

With this change, the C frontend is able to change input_location to point to
the _Pragma token as needed.

This is just a two-line fix (one for each of a) and b)), the testsuite changes
were needed only because the location on the tested warnings has been somewhat
improved, so the tests need to look for the new locations.

gcc/c/ChangeLog:

PR preprocessor/97498
* c-parser.cc (c_parser_pragma): Set input_location to the
location of the pragma, rather than the start of the line.

libcpp/ChangeLog:

PR preprocessor/97498
* directives.cc (destringize_and_run): Override the location of
the CPP_PRAGMA token from a _Pragma directive to the location of
the expansion point, as is done for the tokens lexed from it.

gcc/testsuite/ChangeLog:

PR preprocessor/97498
* c-c++-common/pr97498.c: New test.
* c-c++-common/gomp/pragma-3.c: Adapt for improved warning locations.
* c-c++-common/gomp/pragma-5.c: Likewise.
* gcc.dg/pragma-message.c: Likewise.

libgomp/ChangeLog:

* testsuite/libgomp.oacc-c-c++-common/reduction-5.c: Adapt for
improved warning locations.
* testsuite/libgomp.oacc-c-c++-common/vred2d-128.c: Likewise.

(cherry picked from commit 0587cef3d7962a8b0f44779589ba2920dd3d71e5)

Daily bump.

Daily bump.

openmp: Fix up handling of non-rectangular simd loops with pointer type iterators [PR106449]

There were 2 issues visible on this new testcase, one that we didn't have
special POINTER_TYPE_P handling in a few spots of expand_omp_simd - for
pointers we need to use POINTER_PLUS_EXPR and need to have the non-pointer
part in sizetype, for non-rectangular loop on the other side we can rely on
multiplication factor 1, pointers can't be multiplied, without those changes
we'd ICE.  The other issue was that we put n2 expression directly into a
comparison in a condition and regimplified that, for the &a[512] case that
and with gimplification being destructed that unfortunately meant modification
of original fd->loops[?].n2.  Fixed by unsharing the expression.  This was
causing a runtime failure on the testcase.

2022-07-29  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/106449
* omp-expand.cc (expand_omp_simd): Fix up handling of pointer
iterators in non-rectangular simd loops.  Unshare fd->loops[i].n2
or n2 before regimplifying it inside of a condition.

* testsuite/libgomp.c-c++-common/pr106449.c: New test.

(cherry picked from commit 97d32048c04e9787fccadc4bae1c042754503e34)

cgraphunit: Don't emit asm thunks for -dx [PR106261]

When -dx option is used (didn't know we have it and no idea what is it
useful for), we just expand functions to RTL and then omit all further
RTL passes, so the normal functions aren't actually emitted into assembly,
just variables.
The following testcase ICEs, because we don't emit the methods, but do
emit thunks pointing to that and those thunks have unwind info and rely on
at least some real functions to be emitted (which is normally the case,
thunks are only emitted for locally defined functions) because otherwise
there are no CIEs, only FDEs and dwarf2out is upset about it.

The following patch fixes that by not emitting assembly thunks for -dx
either.

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

PR debug/106261
* cgraphunit.cc (cgraph_node::assemble_thunks_and_aliases): Don't
output asm thunks for -dx.

* g++.dg/debug/pr106261.C: New test.

(cherry picked from commit f9671b60f9395cb1dca128b92f5dd215f5aeaae1)

wide-int: Fix up wi::shifted_mask [PR106144]

As the following self-test testcase shows, wi::shifted_mask sometimes
doesn't create canonicalized wide_ints, which then fail to compare equal
to canonicalized wide_ints with the same value.
In particular, wi::mask (128, false, 128) gives { -1 } with len 1 and prec 128,
while wi::shifted_mask (0, 128, false, 128) gives { -1, -1 } with len 2
and prec 128.
The problem is that the code is written with the assumption that there are
3 bit blocks (or 2 if start is 0), but doesn't consider the possibility
where there are 2 bit blocks (or 1 if start is 0) where the highest block
isn't present.  In that case, there is the optional block of negate ? 0 : -1
elts, followed by just one elt (either one from the if (shift) or just
negate ? -1 : 0) and the rest is implicit sign-extension.
Only if end < prec there is 1 or more bits above it that have different bit
value and so we need to emit all the elts till end and then one more elt.

if (end == prec) would work too, because we have:
  if (width > prec - start)
    width = prec - start;
  unsigned int end = start + width;
so end is guaranteed to be end <= prec, dunno what is preferred.

2022-07-01  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/106144
* wide-int.cc (wi::shifted_mask): If end >= prec, return right after
emitting element for shift or if shift is 0 first element after start.
(wide_int_cc_tests): Add tests for equivalency of wi::mask and
wi::shifted_mask with 0 start.

(cherry picked from commit e52592073f6df3d7a3acd9f0436dcc32a8b7493d)

Daily bump.

Daily bump.

Daily bump.

analyzer: fix stray get_element decls

(cherry picked from r13-1847-g0460ba622e833d)

These were copy&paste errors.

gcc/analyzer/ChangeLog:
* region.h (code_region::get_element): Remove stray decl.
(function_region::get_element): Likewise.

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

analyzer: fix false positives from -Wanalyzer-tainted-divisor [PR106225]

(cherry picked from r13-1562-g897b3b31f0a94b)

gcc/analyzer/ChangeLog:
PR analyzer/106225
* sm-taint.cc (taint_state_machine::on_stmt): Move handling of
assignments from division to...
(taint_state_machine::check_for_tainted_divisor): ...this new
function.  Reject warning when the divisor is known to be non-zero.
* sm.cc: Include "analyzer/program-state.h".
(sm_context::get_old_region_model): New.
* sm.h (sm_context::get_old_region_model): New decl.

gcc/testsuite/ChangeLog:
PR analyzer/106225
* gcc.dg/analyzer/taint-divisor-1.c: Add test coverage for various
correct and incorrect checks against zero.

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

analyzer: fix uninit false positive with -ftrivial-auto-var-init= [PR106204]

(cherry picked from r13-1517-gb33dd7874523af)

-fanalyzer handles -ftrivial-auto-var-init= by special-casing
IFN_DEFERRED_INIT to be a no-op, so that e.g.:

  len_2 = .DEFERRED_INIT (4, 2, &"len"[0]);

is treated as a no-op, so that len_2 is still uninitialized after the
stmt.

PR analyzer/106204 reports that -fanalyzer gives false positives from
-Wanalyzer-use-of-uninitialized-value on locals that have their address
taken, due to e.g.:

  _1 = .DEFERRED_INIT (4, 2, &"len"[0]);
  len = _1;

where -fanalyzer leaves _1 uninitialized, and then complains about
the assignment to "len".

Fixed thusly by suppressing the warning when assigning from such SSA
names.

gcc/analyzer/ChangeLog:
PR analyzer/106204
* region-model.cc (within_short_circuited_stmt_p): Move extraction
of assign_stmt to caller.
(due_to_ifn_deferred_init_p): New.
(region_model::check_for_poison): Move extraction of assign_stmt
from within_short_circuited_stmt_p to here.  Share logic with
call to due_to_ifn_deferred_init_p.

gcc/testsuite/ChangeLog:
PR analyzer/106204
* gcc.dg/analyzer/torture/uninit-pr106204.c: New test.
* gcc.dg/analyzer/uninit-pr106204.c: New test.

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

analyzer: show saved diagnostics as nodes in .eg.dot dumps

(cherry picked from r13-1117-gc540077a3bf600)

I've been using this tweak to the output of
-fdump-analyzer-exploded-graph in my working copies for a while;
the extra red nodes make it *much* easier to find the places where
diagnostics are being emitted (or rejected by the diagnostic_manager).

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (saved_diagnostic::dump_dot_id): New.
(saved_diagnostic::dump_as_dot_node): New.
* diagnostic-manager.h (saved_diagnostic::dump_dot_id): New decl.
(saved_diagnostic::dump_as_dot_node): New decl.
* engine.cc (exploded_node::dump_dot): Add nodes for saved
diagnostics.

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

analyzer: add more uninit test coverage

(cherry picked from r13-1116-g44681d45473883)

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/uninit-1.c: Add test coverage of attempts
to jump through an uninitialized function pointer, and of attempts
to pass an uninitialized value to a function call.

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

json: fix escaping of '\'

(cherry picked from r13-965-g4f9ad0b4b0a8c7)

gcc/ChangeLog:
* json.cc (string::print): Fix escaping of '\'.

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

analyzer: fix memory leaks

(cherry picked from r13-334-g99988b0e8b57b3)

These leaks all relate to logging within -fdump-analyzer[-stderr]
or are one-time leaks; seen with valgrind.

gcc/analyzer/ChangeLog:
* checker-path.cc (state_change_event::get_desc): Call maybe_free
on label_text temporaries.
* diagnostic-manager.cc
(diagnostic_manager::prune_for_sm_diagnostic): Likewise.
* engine.cc (exploded_graph::~exploded_graph): Fix leak of
m_per_point_data and m_per_call_string_data values.  Simplify
cleanup of m_per_function_stats and m_per_point_data values.
(feasibility_state::maybe_update_for_edge): Fix leak of result of
superedge::get_description.
* region-model-manager.cc
(region_model_manager::~region_model_manager): Move cleanup of
m_setjmp_values to match the ordering of the fields within
region_model_manager.  Fix leak of values within
m_repeated_values_map, m_bits_within_values_map,
m_asm_output_values_map, and m_const_fn_result_values_map.

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

analyzer: handle repeated accesses after init of unknown size [PR105285]

(cherry-picked from r13-7-g00c4405cd7f6a144d0a439e4d848d246920e6ff3)

PR analyzer/105285 reports a false positive from
-Wanalyzer-null-dereference on git.git's reftable/reader.c.

A reduced version of the problem can be seen in test_1a of
gcc.dg/analyzer/symbolic-12.c in the following:

void test_1a (void *p, unsigned next_off)
{
  struct st_1 *r = p;

  external_fn();

  if (next_off >= r->size)
    return;

  if (next_off >= r->size)
    /* We should have already returned if this is the case.  */
    __analyzer_dump_path (); /* { dg-bogus "path" } */
}

where the analyzer erroneously considers this path, where
(next_off >= r->size) is both false and then true:

symbolic-12.c: In function ‘test_1a’:
symbolic-12.c:22:5: note: path
   22 |     __analyzer_dump_path (); /* { dg-bogus "path" } */
      |     ^~~~~~~~~~~~~~~~~~~~~~~
  ‘test_1a’: events 1-5
    |
    |   17 |   if (next_off >= r->size)
    |      |      ^
    |      |      |
    |      |      (1) following ‘false’ branch...
    |......
    |   20 |   if (next_off >= r->size)
    |      |      ~            ~~~~~~~
    |      |      |             |
    |      |      |             (2) ...to here
    |      |      (3) following ‘true’ branch...
    |   21 |     /* We should have already returned if this is the case.  */
    |   22 |     __analyzer_dump_path (); /* { dg-bogus "path" } */
    |      |     ~~~~~~~~~~~~~~~~~~~~~~~
    |      |     |
    |      |     (4) ...to here
    |      |     (5) here
    |

The root cause is that, at the call to the external function, the
analyzer considers the cluster for *p to have been touched, binding it
to a conjured_svalue, but because p is void * no particular size is
known for the write, and so the cluster is bound using a symbolic key
covering the base region.  Later, the accesses to r->size are handled by
binding_cluster::get_any_binding, but binding_cluster::get_binding fails
to find a match for the concrete field lookup, due to the key for the
binding being symbolic, and reaching this code:

1522  /* If this cluster has been touched by a symbolic write, then the content
1523     of any subregion not currently specifically bound is "UNKNOWN".  */
1524  if (m_touched)
1525    {
1526      region_model_manager *rmm_mgr = mgr->get_svalue_manager ();
1527      return rmm_mgr->get_or_create_unknown_svalue (reg->get_type ());
1528    }

Hence each access to r->size is an unknown svalue, and thus the
condition (next_off >= r->size) isn't tracked, leading to the path with
contradictory conditions being treated as satisfiable.

In the original reproducer in git's reftable/reader.c, the call to the
external fn is:
  reftable_record_type(rec)
which is considered to possibly write to *rec, which is *tab, where tab
is the void * argument to reftable_reader_seek_void, and thus after the
call to reftable_record_type some arbitrary amount of *rec could have
been written to.

This patch fixes things by detecting the "this cluster has been 'filled'
with a conjured value of unknown size" case, and handling
get_any_binding on it by returning a sub_svalue of the conjured_svalue,
so that repeated accesses to r->size give the same symbolic value, so
that the constraint manager rejects the bogus execution path, fixing the
false positive.

gcc/analyzer/ChangeLog:
PR analyzer/105285
* store.cc (binding_cluster::get_any_binding): Handle accessing
sub_svalues of clusters where the base region has a symbolic
binding.

gcc/testsuite/ChangeLog:
PR analyzer/105285
* gcc.dg/analyzer/symbolic-12.c: New test.

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

analyzer: add .fpath.txt dumps to -fdump-analyzer-feasibility

(cherry picked from r13-6-gd8586b00dd00a1783862da5f0c8811a740400074)

I found this extension to -fdump-analyzer-feasibility very helpful when
debugging PR analyzer/105285.

gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (epath_finder::process_worklist_item):
Call dump_feasible_path when a path that reaches the the target
enode is found.
(epath_finder::dump_feasible_path): New.
* engine.cc (feasibility_state::dump_to_pp): New.
* exploded-graph.h (feasibility_state::dump_to_pp): New decl.
* feasible-graph.cc (feasible_graph::dump_feasible_path): New.
* feasible-graph.h (feasible_graph::dump_feasible_path): New
decls.
* program-point.cc (function_point::print): Fix missing trailing
newlines.
* program-point.h (program_point::print_source_line): Remove
unimplemented decl.

gcc/ChangeLog:
* doc/invoke.texi (-fdump-analyzer-feasibility): Mention the
fpath.txt output.

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

RISC-V: Remove duplicate backslashes from `stack_protect_set_<mode>'

Remove redundant duplicate backslash characters from \t sequences in the
output pattern of the `stack_protect_set_<mode>' RTL insn.

gcc/
* config/riscv/riscv.md (stack_protect_set_<mode>): Remove
duplicate backslashes.

(cherry picked from commit 3cf07cc5e51c833f39f5bad5ca6fbe23c853a214)

tree-optimization/106189 - avoid division by zero exception

The diagnostic code can end up with zero sized array elements
with T[][0] and the wide-int code nicely avoids exceptions when
dividing by zero in one codepath but not in another.  The following
fixes the exception by using wide-int in both paths.

PR tree-optimization/106189
* gimple-array-bounds.cc (array_bounds_checker::check_mem_ref):
Divide using offset_ints.

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

(cherry picked from commit bb04f9f23ac0dee2c003118c85372ece50a52220)

lto: Fix option merging [PR106129]

The LTO merging of options from different input files was broken by:

commit 227a2ecf663d69972b851f51f1934d18927b62cd
Author: Martin Liska <mliska@suse.cz>
Date:   Fri Mar 12 11:53:47 2021 +0100

    lto-wrapper: Use vec<cl_decoded_option> data type.

Previously, find_and_merge_options would merge options it read into
those in *opts. After this commit, options in *opts on entry to
find_and_merge_options are ignored; the only merging that takes place
is between multiple sets of options in the same input file that are
read in the same call to this function (not sure how that case can
occur at all). The effects include, for example, that if some objects
are built with PIC enabled and others with it disabled, and the last
LTO object processed has PIC enabled, the choice of PIC for the last
object will result in the whole program being built as PIC, when the
merging logic is intended to ensure that a mixture of PIC and non-PIC
objects results in the whole program being built as non-PIC.

Fix this with an extra argument to find_and_merge_options to determine
whether merging should take place.  This shows up a second issue with
that commit (which I think wasn't actually intended to change code
semantics at all): once merging is enabled again, the check for
-Xassembler options became an infinite loop in the case where both
inputs had -Xassembler options, with the same first option, so fix
that loop to restore the previous semantics.

Note that I'm not sure how LTO option merging might be tested in the
testsuite (clearly there wasn't sufficient, if any, coverage to detect
these bugs).

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

PR lto/106129
* lto-wrapper.cc (find_option): Add argument start.
(merge_and_complain): Loop over existing_opt_index and
existing_opt2_index for Xassembler check.  Update calls to
find_option.
(find_and_merge_options): Add argument first to determine whether
to merge options with those passed in *opts.
(run_gcc): Update calls to find_and_merge_options.

(cherry picked from commit 8a8ee37a3325f1009034245676ef4e482c0444a2)

Fix tree-opt/PR106087: ICE with inline-asm with multiple output and assigned only static vars

The problem here is that when we mark the ssa name that was referenced in the now removed
dead store (to a write only static variable), the inline-asm would also be removed
even though it was defining another ssa name. This fixes the problem by checking
to make sure that the statement was only defining one ssa name.

Committed as approved after a bootstrapped and tested on x86_64 with no regressions.

PR tree-optimization/106087

gcc/ChangeLog:

* tree-ssa-dce.cc (simple_dce_from_worklist): Check
to make sure the statement is only defining one operand.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 71e3daa31cfa35ee58e5899cb00767be92227fd2)

testsuite: Require int128 for gcc.dg/pr106063.c

Require effective target int128 for gcc.dg/pr106063.c.

PR tree-optimization/106063

gcc/testsuite/ChangeLog:

* gcc.dg/pr106063.c: Require effective target int128.

Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
(cherry picked from commit 4ebbf3906895bcb40d7ff2729cf46deae66bc268)

middle-end: don't lower past veclower [PR106063]

Hi All,

My previous patch can cause a problem if the pattern matches after veclower
as it may replace the construct with a vector sequence which the target may not
directly support.

As such don't perform the rewriting if after veclower unless the target supports
the operation.  If before veclower do the rewriting as well if the target didn't
support the original operation either.

gcc/ChangeLog:

PR tree-optimization/106063
* match.pd: Do not apply pattern after veclower is not supported.

gcc/testsuite/ChangeLog:

PR tree-optimization/106063
* gcc.dg/pr106063.c: New test.

(cherry picked from commit f7854e2faf7640230062dec3596e71773ca500ed)

[PR105665] ivopts: check defs of names in base for undefs

The patch for PR 100810 tested for undefined SSA_NAMEs appearing
directly in the base expression of the potential IV candidate, but
that's not enough.  The testcase for PR105665 shows an undefined
SSA_NAME has the same ill effect if it's referenced as an PHI_NODE arg
in the referenced SSA_NAME.  The variant of that test shows it can be
further removed from the referenced SSA_NAME.

To avoid deep recursion, precompute maybe-undefined SSA_NAMEs: start
from known-undefined nonvirtual default defs, and propagate them to
any PHI nodes reached by a maybe-undefined arg, as long as there
aren't intervening non-PHI uses, that would imply the maybe-undefined
name must be defined at that point, otherwise it would invoke
undefined behavior.  Also test for intervening non-PHI uses of DEFs in
the base expr.

The test for intervening uses implemented herein relies on dominance;
this could be further extended, regarding conditional uses in every
path leading to a point as an unconditional use dominating that point,
but I haven't implemented that.

for  gcc/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* tree-ssa-loop-ivopts.cc
(ssa_name_maybe_undef_p, ssa_name_set_maybe_undef): New.
(ssa_name_any_use_dominates_bb_p, mark_ssa_maybe_undefs): New.
(find_ssa_undef): Check precomputed flag and intervening uses.
(tree_ssa_iv_optimize): Call mark_ssa_maybe_undefs.

for  gcc/testsuite/ChangeLog

PR tree-optimization/105665
PR tree-optimization/100810
* gcc.dg/torture/pr105665.c: New.

(cherry picked from commit be2861fe8c527a5952257462ceca899bb43b1452)

Daily bump.

libstdc++: Minor codegen improvement for atomic wait spinloop

This patch merges the spin loops in the atomic wait implementation which is a
minor codegen improvement.

libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__atomic_spin): Merge spin loops.

(cherry picked from commit e75da2ace6b6f634237259ef62cfb2d3d34adb10)

d: Merge upstream dmd 76e3b41375, druntime 1462ebd1, phobos 5fef0d28f.

Updates D language version to v2.100.1.

D front-end changes:

    - Fix delegate literal with inferred return value that requires
      following alias-this to not use class cast.
    - Fix internal error on variadic template type instantiated with two
      arrays of classes.
    - `scope(failure)' blocks that contain `return' statements are now
      deprecated.
    - Fix regression where wrong cast was inserted for ternary operator
      and non-int enums.
    - Fix internal error in code generation trying to reference
      _d_arraysetctor.
    - Fix memory corruption when array literal is passed to map in
      lambda, then returned from nested function.
    - Generate invariant id on the basis of location rather than a
      global counter.
    - Make `noreturn' conversions work.
    - Fix segfault when `.stringof' of template alias overloaded with
      function accessed by trait.
    - Empty array literal passed to scope param not 'falsey' anymore.

Phobos changes:

    - Avoid copying ranges in std.algorithm.comparison.equal.

gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 76e3b41375.
* dmd/VERSION: Bump version to v2.100.1.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Evaluate RHS
  of noreturn declaration expressions first.
* expr.cc (ExprVisitor::visit (AssignExp *)): Don't generate
  assignment for noreturn types.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime 1462ebd1.
* src/MERGE: Merge upstream phobos 5fef0d28f.

Fortran: error recovery from calculation of storage size of a symbol [PR103504]

gcc/fortran/ChangeLog:

PR fortran/103504
* interface.cc (get_sym_storage_size): Array bounds and character
length can only be of integer type.

gcc/testsuite/ChangeLog:

PR fortran/103504
* gfortran.dg/pr103504.f90: New test.

(cherry picked from commit 600956c81c784f4a0cc9d10f6e03e01847afd961)

c++: ICE with erroneous template redeclaration [PR106311]

Here we ICE trying to get DECL_SOURCE_LOCATION of the parm that happens
to be error_mark_node in this ill-formed test.  I kept running into this
while reducing code, so it'd be good to have it fixed.

PR c++/106311

gcc/cp/ChangeLog:

* pt.cc (redeclare_class_template): Check DECL_P before accessing
DECL_SOURCE_LOCATION.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit 2333b58c9892667545d0c2c3ecd2d7b947197511)

c++: aggregate prvalue as for range [PR106230]

Since my PR94041 work on temporary lifetime in aggregate initialization, we
end up calling build_vec_init to initialize the reference-extended temporary
for the artificial __for_range variable.  And build_vec_init uses
finish_for_stmt to implement its loop.  That function assumes that if
__for_range is in current_binding_level, we're finishing a range-for, and we
should fix up the variable as it goes out of scope.  But when called from
build_vec_init we aren't finishing a range-for, and do_poplevel doesn't
remove the variable from scope because stmts_are_full_exprs_p is false.  So
let's check that here as well, and leave the DECL_NAME alone.

PR c++/106230

gcc/cp/ChangeLog:

* semantics.cc (finish_for_stmt): Check stmts_are_full_exprs_p.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/range-for38.C: New test.

Daily bump.

RTEMS: Do not define _GNU_SOURCE by default

gcc/ChangeLog:

* config/rs6000/rtems.h (CPLUSPLUS_CPP_SPEC): Undef.

(cherry picked from commit 556b816b820f6749910784cbaca8bb0bb822a970)

Daily bump.

Daily bump.

Daily bump.

libstdc++: Do not optimize away storing pathname if it's needed

libstdc++-v3/ChangeLog:

* src/c++17/fs_dir.cc (_Dir::_Dir) [!_GLIBCXX_HAVE_OPENAT]:
Always store pathname if we don't have openat or unlinkat,
because the full path is needed to open sub-directories and
remove entries.

(cherry picked from commit 835b19936bf30d693783bfa39145a4ce243bbd7c)

libstdc++: check for openat with dirfd in std::filesystem

In the recent patch to check for openat, I missed an occurrence of
dirfd in std::filesystem.

for  libstdc++-v3/ChangeLog

* src/c++17/fs_dir.cc (dir_and_pathname): Use dirfd if
_GLIBCXX_HAVE_OPENAT.

(cherry picked from commit 486893b1d325d22d54c1380937943913a7501f91)

libstdc++: check for openat

rtems6.0 has fdopendir, and fcntl.h defines AT_FDCWD and declares
openat, but there's no openat in libc.  Adjust dir-common.h to not
assume ::openat just because of AT_FDCWD.

for  libstdc++-v3/ChangeLog

* acinclude.m4 (GLIBCXX_CHECK_FILESYSTEM_DEPS): Check for
openat.
* configure, config.h.in: Rebuilt.
* src/filesystem/dir-common.h (openat): Use ::openat if
_GLIBCXX_HAVE_OPENAT.
* src/filesystem/dir.cc (dir_and_pathname): Use dirfd if
_GLIBCXX_HAVE_OPENAT.

(cherry picked from commit 93070671eae44f24ba822383e17571a39257c637)

libstdc++: Do not include <cxxabi.h> in <stacktrace>

This avoids polluting the global namespace with the "abi" namespace
alias.

libstdc++-v3/ChangeLog:

* include/std/stacktrace: Do not include <cxxabi.h>.
(__cxa_demangle): Declare.

(cherry picked from commit e112e37f2920bcc9185e53b754d9145aac912c72)

Daily bump.

c++: defaulted friend op== [PR106361]

Now non-member functions can be defaulted, so this assert is wrong.
move_signature_fn_p already checks for ctor or op=.

PR c++/106361

gcc/cp/ChangeLog:

* decl.cc (move_fn_p): Remove assert.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/spaceship-eq14.C: New test.

c++: non-dependent call to consteval operator [PR105912]

Here we're crashing when substituting a non-dependent call to a
consteval operator, whose CALL_EXPR_OPERATOR_SYNTAX flag we try to
propagate to the result, but the result isn't a CALL_EXPR since the
selected function is consteval.  This patch fixes this by checking the
result of extract_call_expr accordingly.  (Note that we can't check
DECL_IMMEDIATE_FUNCTION_P here because we don't know which function was
selected by overload resolution from here.)

PR c++/105912

gcc/cp/ChangeLog:

* call.cc (extract_call_expr): Return a NULL_TREE on failure
instead of asserting.
* pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Guard against
NULL_TREE extract_call_expr result.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/consteval31.C: New test.

(cherry picked from commit f70c18524221dcefa6cd26cee7b55503181bd912)

c++: dependence of constrained memfn from current inst [PR105842]

Here we incorrectly deem the calls to func1, func2 and tmpl2 as
ambiguous ahead of time ultimately because we mishandle dependence
of a constrained member function from the current instantiation.

In type_dependent_expression_p, we already consider dependence of a
TEMPLATE_DECL's constraints (via uses_outer_template_parms), but
neglect to do the same for a FUNCTION_DECL (such as that for func1).

And in satisfy_declaration_constraints, we give up if _any_ template
argument is dependent, but for non-dependent member functions from
the current instantiation (such as func2 and tmpl2), we can and must
check constraints as long as the innermost arguments aren't dependent.

PR c++/105842

gcc/cp/ChangeLog:

* constraint.cc (satisfy_declaration_constraints): Refine early
exit test for argument dependence.
* cp-tree.h (uses_outer_template_parms_in_constraints): Declare.
* pt.cc (template_class_depth): Handle TI_TEMPLATE being a
FIELD_DECL.
(usse_outer_template_parms): Factor out constraint dependence
test into ...
(uses_outer_template_parms_in_constraints): ... here.
(type_dependent_expression_p): Use it for FUNCTION_DECL.

gcc/testsuite/ChangeLog:

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

(cherry picked from commit f07778f6f92111aa0abfd0f669b148a0bda537a9)

c++: function NTTP argument considered unused [PR53164, PR105848]

Here at parse time the template argument f (an OVERLOAD) in A<f> gets
resolved ahead of time to the FUNCTION_DECL f<int>, and we defer marking
f<int> as used until instantiation (of g) as usual.

Later when instantiating g the type A<f> (where f has already been
resolved) is non-dependent, so tsubst_aggr_type avoids re-processing its
template arguments, and we end up never actually marking f<int> as used
(which means we never instantiate it) even though A<f>::h() later calls
it, leading to a link error.

This patch works around this issue by looking through ADDR_EXPR when
calling mark_used on the substituted callee of a CALL_EXPR.

PR c++/53164
PR c++/105848

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build) <case CALL_EXPR>: Look through an
ADDR_EXPR callee when calling mark_used.

gcc/testsuite/ChangeLog:

* g++.dg/template/fn-ptr3.C: New test.

(cherry picked from commit 733a792a2b2e1662e738fa358b45a2720a8618a7)

c++: cv-quals of dummy obj for non-dep memfn call [PR105637]

In non-dependent23.C below we expect the Base::foo calls to
resolve to the second, third and fourth overloads respectively in light
of the cv-qualifiers of 'this' in each case.  But ever since
r12-6075-g2decd2cabe5a4f, the calls incorrectly resolve to the first
overload at instantiation time.

This happens because the calls to Base::foo are all deemed
non-dependent (ever since r7-755-g23cb72663051cd made us ignore 'this'
dependence when considering the dependence of a non-static memfn call),
hence we end up checking the call ahead of time, using as the object
argument a dummy object of type Base.  Since this object argument is
cv-unqualified, the calls in turn resolve to the unqualified overload
of baseDevice.  Before r12-6075 this incorrect result would just get
silently discarded and we'd end up redoing OR at instantiation time
using 'this' as the object argument.  But after r12-6075 we now reuse
this incorrect result at instantiation time.

This patch fixes this by making maybe_dummy_object respect the cv-quals
of (the non-lambda) 'this' when returning a dummy object.  Thus, ahead
of time OR using a dummy object will give us the right answer that's
consistent with the instantiation time answer.

An earlier version of this patch didn't handle 'this'-capturing lambdas
correctly, which broke lambda-this22.C below.

PR c++/105637

gcc/cp/ChangeLog:

* tree.cc (maybe_dummy_object): When returning a dummy
object, respect the cv-quals of 'this' if available.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-this22.C: New test.
* g++.dg/template/non-dependent23.C: New test.

(cherry picked from commit 44a5bd6d933d86ed988fc4695aa00f122cf83eb4)

c++: don't substitute TEMPLATE_PARM_CONSTRAINTS [PR100374]

This patch makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINTS
of each template parameter except as necessary for declaration matching,
like we already do for the other constituent constraints of a declaration.

This patch also improves the CA104 implementation of explicit
specialization matching of a constrained function template inside a
class template, by considering the function's combined constraints
instead of just its trailing constraints.  This allows us to correctly
handle the first three explicit specializations in concepts-spec2.C
below, but because we compare the constraints as a whole, it means we
incorrectly accept the fourth explicit specialization which writes #3's
constraints in a different way.  For complete correctness here,
determine_specialization should use tsubst_each_template_parm_constraints
and template_parameter_heads_equivalent_p.

PR c++/100374

gcc/cp/ChangeLog:

* pt.cc (determine_specialization): Compare overall constraints
not just the trailing constraints.
(tsubst_each_template_parm_constraints): Define.
(tsubst_friend_function): Use it.
(tsubst_friend_class): Use it.
(tsubst_template_parm): Don't substitute TEMPLATE_PARM_CONSTRAINTS.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-spec2.C: New test.
* g++.dg/cpp2a/concepts-template-parm11.C: New test.

(cherry picked from commit 43c013df02fdb07f9b7a5e7e6669e6d69769d451)

c++: non-dep call with empty TYPE_BINFO [PR105758]

Here the out-of-line definition of Z<T>::z causes duplicate_decls to
change z's type from using the primary template type Z<T> (which is also
the type of the injected class name) to the implicit instantiation Z<T>,
and this latter type lacks a TYPE_BINFO (although its TYPE_CANONICAL was
set by a special case in lookup_template_class to point to the former).

Later, when processing the non-dependent call z->foo(0), build_over_call
relies on the object argument's TYPE_BINFO to build the templated form
for this call, which fails because the object argument type has empty
TYPE_BINFO due to the above.

It seems weird that the implicit instantiation Z<T> doesn't have the
same TYPE_BINFO as the primary template type Z<T>, despite them being
proclaimed equivalent via TYPE_CANONICAL.  So I tried also setting
TYPE_BINFO in the special case in lookup_template_class, but that led to
some problems with constrained partial specializations of the form Z<T>.
I'm not sure what, if anything, we ought to do about the subtle
differences between these two versions of the same type.

Fortunately it seems we don't need to rely on TYPE_BINFO at all in
build_over_call here -- the z_candidate struct already contains the
exact binfos we need to rebuild the BASELINK for the templated form.

PR c++/105758

gcc/cp/ChangeLog:

* call.cc (build_over_call): Use z_candidate::conversion_path
and ::access_path instead of TYPE_BINFO when building the
BASELINK for the templated form.

gcc/testsuite/ChangeLog:

* g++.dg/template/non-dependent24.C: New test.

(cherry picked from commit 4f84f12066953186cce4328b7f178d3daa2fe96e)

c++: constrained partial spec forward decl [PR96363]

Here during cp_parser_single_declaration for #2, we were calling
associate_classtype_constraints for TPL<T> (the primary template type)
before maybe_process_partial_specialization could get a chance to
notice that we're in fact declaring a distinct constrained partial
spec and not redeclaring the primary template.  This caused us to
emit a bogus error about differing constraints b/t the primary template
and #2's constraints.  This patch fixes this by moving the call to
associate_classtype_constraints after the call to shadow_tag (which
calls maybe_process_partial_specialization) and adjusting shadow_tag to
use the return value of m_p_p_s.

Moreover, if we later try to define a constrained partial specialization
that's been declared earlier (as in the third testcase), then
maybe_new_partial_specialization correctly notices it's a redeclaration
and returns NULL_TREE.  But in this case we also need to update TYPE to
point to the redeclared partial spec (it'll otherwise continue pointing
to the primary template type, eventually leading to a bogus error).

PR c++/96363

gcc/cp/ChangeLog:

* decl.cc (shadow_tag): Use the return value of
maybe_process_partial_specialization.
* parser.cc (cp_parser_single_declaration): Call shadow_tag
before associate_classtype_constraints.
* pt.cc (maybe_new_partial_specialization): Change return type
to bool.  Take 'type' argument by mutable reference.  Set 'type'
to point to the correct constrained specialization when
appropriate.
(maybe_process_partial_specialization): Adjust accordingly.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-partial-spec12.C: New test.
* g++.dg/cpp2a/concepts-partial-spec12a.C: New test.
* g++.dg/cpp2a/concepts-partial-spec13.C: New test.

(cherry picked from commit 97dc78d705a90c1ae83c78a7f2e24942cc3a6257)

libgo: don't include <linux/fs.h> when building gen-sysinfo.go

Removing this doesn't change anything at least with glibc 2.33.
The include was added in https://go.dev/cl/6100049 but it's not
clear why.

Fixes PR go/106266

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/417294
(cherry picked from commit f35d65517a59565758107c5b1a51a5fa382f8d1a)

libsanitizer: cherry-pick 9cf13067cb5088626ba7 from upstream

9cf13067cb5088626ba7ee1ec4c42ec59c7995a0 [sanitizer] Remove #include <linux/fs.h> to resolve fsconfig_command/mount_attr conflict with glibc 2.36

(cherry picked from commit 2701442d0cf6292f6624443c15813d6d1a3562fe)

libstdc++: Fix std::common_iterator assignment [PR100823]

This fixes the following conformance problems reported in the PR:

- Move constructor and move assignment should be defined.
- Copy assignment from a valueless object should be allowed.

Assignment is completely rewritten by this patch, as the previous
version had a number of problems. The converting assignment failed to
handle the case of assigning a new value to a valueless object, which
should work. It only accepted lvalue arguments, so wasn't usable to
implement the move assignment operator. Finally, it enforced the
precondition that the argument is not valueless, which is correct for
the converting assignment but not for the copy assignment.

A new _M_assign member is added to handle all cases of assignment
(copying from an lvalue, moving from an rvalue, and converting from a
different type). The not valueless precondition is checked in the
converting assignment before calling _M_assign, so isn't enforced for
copy and move assignment. The new function no longer uses a switch, so
handles valueless objects as the LHS or RHS of the assignment.

libstdc++-v3/ChangeLog:

PR libstdc++/100823
* include/bits/stl_iterator.h (common_iterator): Define move
constructor and move assignment operator.
(common_iterator::_M_assign): New function implementing
assignment.
(common_iterator::operator=): Use _M_assign.
(common_iterator::_S_valueless): New constant.
* testsuite/24_iterators/common_iterator/100823.cc: New test.

(cherry picked from commit 56c999860bbbb2fd5091ba0985e2e5eaa90c6478)