testsuite: Add testcase for dangling pointer equality bogus warning [PR104492]

On Wed, Apr 27, 2022 at 12:02:33PM +0200, Richard Biener wrote:
> I did that but the reduction result did not resemble the same failure
> mode.  I've failed to manually construct a testcase as well.  Possibly
> a testcase using libstdc++ but less Qt internals might be possible.

Here is a testcase that I've managed to reduce, FAILs with:
FAIL: g++.dg/warn/pr104492.C  -std=gnu++14  (test for bogus messages, line 111)
FAIL: g++.dg/warn/pr104492.C  -std=gnu++17  (test for bogus messages, line 111)
FAIL: g++.dg/warn/pr104492.C  -std=gnu++20  (test for bogus messages, line 111)
on both x86_64-linux and i686-linux without your commit and passes with it.

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

PR middle-end/104492
* g++.dg/warn/pr104492.C: New test.

Split test to remove failing run time test and add check for ICE.

gcc/testsuite/ChangeLog:

PR fortran/70673
PR fortran/78054
* gfortran.dg/pr70673.f90: Remove invalid statement.
* gfortran.dg/pr70673_2.f90: New test to check that
ICE does not re-appear.

libstdc++: Update {x86_64,i?86,aarch64,s390x,ppc{,64,64le}} baseline_symbols.txt

The following patch updates baseline_symbols.txt on arches where I have
latest libstdc++ builds (my ws + Fedora package builds).
I've manually excluded:
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
additions on ppc64le as those look unexpected.
Those symbols didn't show up in Fedora 11.3.1 build with recent glibc,
while other GLIBCXX_IEEE128_3.4.29 symbols are in 11.x already.

What this patch includes are only @@GLIBCXX_3.4.30 symbol additions, same
symbols on all files, except that powerpc64 adds also
_ZNSt17__gnu_cxx_ieee12816__convert_from_vERKP15__locale_structPciPKcz@@GLIBCXX_IEEE128_3.4.30
so everything included in the patch looks right to me.

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

* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update.

libstdc++: Add pretty printer for std::atomic

For the atomic specializations for shared_ptr and weak_ptr we can reuse
the existing SharedPointerPrinter, with a small tweak.

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (SharedPointerPrinter): Add
support for atomic<shared_ptr<T>> and atomic<weak_ptr<T>>.
(StdAtomicPrinter): New printer.
(build_libstdcxx_dictionary): Register new printer.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Test std::atomic.
* testsuite/libstdc++-prettyprinters/cxx20.cc: Test atomic smart
pointers.

ada: Fix build for RTEMS

Commit 621cccba3f8b0cd2757feda171e66e3820b55c2c broke the Ada build for all
RTEMS targets except aarch64.

gcc/ada/

* tracebak.c: Add support for ARM RTEMS. Add support for RTEMS to PPC
ELF.  Add support for RTEMS to SPARC.  Merge aarch64 support of Linux
and RTEMS.

LoongArch: Add fdiv define_expand template.

gcc/ChangeLog:

* config/loongarch/loongarch.md: Add fdiv define_expand template,
then generate floating-point division and floating-point reciprocal
instructions.

LoongArch: Add '(clobber (mem:BLK (scratch)))' to PLV instruction templates.

gcc/ChangeLog:

* config/loongarch/loongarch.md: Add '(clobber (mem:BLK (scratch)))'
to PLV instruction templates.

middle-end/104492 - avoid all equality compare dangling pointer diags

The following extends the equality compare dangling pointer diagnostics
suppression for uses following free or realloc to also cover those
following invalidation of auto variables via CLOBBERs.  That avoids
diagnosing idioms like

  return std::find(std::begin(candidates), std::end(candidates), s)
           != std::end(candidates);

for auto candidates which are prone to forwarding of the final
comparison across the storage invalidation as then seen by the
late run access warning pass.

2022-04-25  Richard Biener  <rguenther@suse.de>

PR middle-end/104492
* gimple-ssa-warn-access.cc
(pass_waccess::warn_invalid_pointer): Exclude equality compare
diagnostics for all kind of invalidations.
(pass_waccess::check_dangling_uses): Fix post-dominator query.
(pass_waccess::check_pointer_uses): Likewise.

fortran: Compare non-constant bound expressions. [PR105379]

Starting with r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e,
class descriptor types are compared to detect duplicate declarations.

This caused ICEs as the comparison of array spec supported only constant
explicit bounds, but dummy class variable descriptor types can have a
_data field with non-constant array spec bounds.

This change adds support for non-constant bounds.  For that,
gfc_dep_compare_expr is used.  It does probably more than strictly
necessary, but using it avoids rewriting a specific comparison function,
making mistakes and forgetting cases.

PR fortran/103662
PR fortran/105379

gcc/fortran/ChangeLog:

* array.cc (compare_bounds): Use bool as return type.
Support non-constant expressions.
(gfc_compare_array_spec): Update call to compare_bounds.

gcc/testsuite/ChangeLog:

* gfortran.dg/class_dummy_8.f90: New test.
* gfortran.dg/class_dummy_9.f90: New test.

fortran: Avoid infinite self-recursion [PR105381]

Dummy array decls are local decls different from the argument decl
accessible through GFC_DECL_SAVED_DESCRIPTOR.  If the argument decl has
a DECL_LANG_SPECIFIC set, it is copied over to the local decl at the
time the latter is created, so that the DECL_LANG_SPECIFIC object is
shared between local dummy decl and argument decl, and thus the
GFC_DECL_SAVED_DESCRIPTOR of the argument decl is the argument decl
itself.

The r12-8230-g7964ab6c364c410c34efe7ca2eba797d36525349 change introduced
the non_negative_strides_array_p predicate which recurses through
GFC_DECL_SAVED_DESCRIPTOR to avoid seeing dummy decls as purely local
decls.  As the GFC_DECL_SAVED_DESCRIPTOR of the argument decl is itself,
this can cause infinite recursion.

This change adds a check to avoid infinite recursion.

PR fortran/102043
PR fortran/105381

gcc/fortran/ChangeLog:

* trans-array.cc (non_negative_strides_array_p): Inline variable
orig_decl and merge nested if conditions.  Add condition to not
recurse if the next argument is the same as the current.

gcc/testsuite/ChangeLog:

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

testsuite: Add arm testcase for PR105374

As discussed in the PR, here is the testcase with the appropriate dg-*
directives.

Tested on arm-none-eabi with
1 -mcpu=cortex-a7/-mfloat-abi=soft/-march=armv7ve+simd
2 -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
3 -mthumb/-mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
4 -mthumb/-mfloat-abi=soft/-march=armv6s-m
5 -mthumb/-mfloat-abi=soft/-march=armv7-m
6 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp
7 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp.dp
8 -mthumb/-mfloat-abi=hard/-march=armv8-m.main+fp+dsp
9 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve.fp+fp.dp
10 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve

The test is UNSUPPORTED with the first three ones (because of
-mcpu=cortex-a7), ignored with armv6s-m, and PASSes with all the other
ones, while it used crash without Jakub's fix (r12-8263), ie. FAIL
with options 5,6,7,8,10. The test passed without Jakub's fix with
option 9 because the problem happens only with an integer-only MVE.

2022-04-26  Christophe Lyon  <christophe.lyon@arm.com>

gcc/testsuite/

PR tree-optimization/105374
* gcc.target/arm/simd/pr105374.C: New.

[Ada] Revert r12-6599 (Fix up handling of ghost units [PR104027])

gcc/ada/

PR ada/104027
* gnat1drv.adb: Remove the goto End_Of_Program.

PR102024 - IBM Z: Add psabi diagnostics

For IBM Z in particular there is a problem with structs like:

struct A { float a; int :0; };

Our ABI document allows passing a struct in an FPR only if it has
exactly one member. On the other hand it says that structs of 1,2,4,8
bytes are passed in a GPR. So this struct is expected to be passed in
a GPR. Since we don't return structs in registers (regardless of the
number of members) it is always returned in memory.

Situation is as follows:

All compiler versions tested return it in memory - as expected.

gcc 11, gcc 12, g++ 12, and clang 13 pass it in a GPR - as expected.

g++ 11 as well as clang++ 13 pass in an FPR

For IBM Z we stick to the current GCC 12 behavior, i.e. zero-width
bitfields are NOT ignored.  A struct as above will be passed in a
GPR. Rational behind this is that not affecting the C ABI is more
important here.

A patch for clang is in progress: https://reviews.llvm.org/D122388

In addition to the usual regression test I ran the compat and
struct-layout-1 testsuites comparing the compiler before and after the
patch.

gcc/ChangeLog:
PR target/102024
* config/s390/s390-protos.h (s390_function_arg_vector): Remove
prototype.
* config/s390/s390.cc (s390_single_field_struct_p): New function.
(s390_function_arg_vector): Invoke s390_single_field_struct_p.
(s390_function_arg_float): Likewise.

gcc/testsuite/ChangeLog:
PR target/102024
* g++.target/s390/pr102024-1.C: New test.
* g++.target/s390/pr102024-2.C: New test.
* g++.target/s390/pr102024-3.C: New test.
* g++.target/s390/pr102024-4.C: New test.
* g++.target/s390/pr102024-5.C: New test.
* g++.target/s390/pr102024-6.C: New test.

asan: Fix up asan_redzone_buffer::emit_redzone_byte [PR105396]

On the following testcase, we have in main's frame 3 variables,
some red zone padding, 4 byte d, followed by 12 bytes of red zone padding, then
8 byte b followed by 24 bytes of red zone padding, then 40 bytes c followed
by some red zone padding.
The intended content of shadow memory for that is (note, each byte describes
8 bytes of memory):
f1 f1 f1 f1 04 f2 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3
left red    d  mr b  middle r c              right red zone

f1 is left red zone magic
f2 is middle red zone magic
f3 is right red zone magic
00 when all 8 bytes are accessible
01-07 when only 1 to 7 bytes are accessible followed by inaccessible bytes

The -fdump-rtl-expand-details dump makes it clear that it misbehaves:
Flushing rzbuffer at offset -160 with: f1 f1 f1 f1
Flushing rzbuffer at offset -128 with: 04 f2 00 00
Flushing rzbuffer at offset -128 with: 00 00 00 f2
Flushing rzbuffer at offset -96 with: f2 f2 00 00
Flushing rzbuffer at offset -64 with: 00 00 00 f3
Flushing rzbuffer at offset -32 with: f3 f3 f3 f3
In the end we end up with
f1 f1 f1 f1 00 00 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3
shadow bytes because at offset -128 there are 2 overlapping stores
as asan_redzone_buffer::emit_redzone_byte has flushed the temporary 4 byte
buffer in the middle.

The function is called with an offset and value.  If the passed offset is
consecutive with the prev_offset + buffer size (off == offset), then
we handle it correctly, similarly if the new offset is far enough from the
old one (we then flush whatever was in the buffer and if needed add up to 3
bytes of 00 before actually pushing value.

But what isn't handled correctly is when the offset isn't consecutive to
what has been added last time, but it is in the same 4 byte word of shadow
memory (32 bytes of actual memory), like the above case where
we have consecutive 04 f2 and then skip one shadow memory byte (aka 8 bytes
of real memory) and then want to emit f2.  Emitting that as a store
of little-endian 0x0000f204 followed by a store of 0xf2000000 to the same
address doesn't work, we want to emit 0xf200f204.

The following patch does that by pushing 1 or 2 00 bytes.
Additionally, as a small cleanup, instead of using
      m_shadow_bytes.safe_push (value);
      flush_if_full ();
in all of if, else if and else bodies it sinks those 2 stmts to the end
of function as all do the same thing.

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

PR sanitizer/105396
* asan.cc (asan_redzone_buffer::emit_redzone_byte): Handle the case
where offset is bigger than off but smaller than m_prev_offset + 32
bits by pushing one or more 0 bytes.  Sink the
m_shadow_bytes.safe_push (value); flush_if_full (); statements from
all cases to the end of the function.

* gcc.dg/asan/pr105396.c: New test.

rs6000: Move V2DI vec_neg under power8-vector [PR105271]

As PR105271 shows, __builtin_altivec_neg_v2di requires option
-mpower8-vector as its pattern expansion relies on subv2di which
has guard VECTOR_UNIT_P8_VECTOR_P (V2DImode).  This fix is to move
the related lines for __builtin_altivec_neg_v2di to the section
of stanza power8-vector.

PR target/105271

gcc/ChangeLog:

* config/rs6000/rs6000-builtins.def (NEG_V2DI): Move to [power8-vector]
stanza.

gcc/testsuite/ChangeLog:

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

Daily bump.

c++: pack init-capture of unresolved overload [PR102629]

Here we were failing to diagnose that the initializer for the capture pack
is an unresolved overload.  It turns out that the reason we didn't recognize
the deduction failure in do_auto_deduction was that the individual 'auto' in
the expansion of the capture pack was still marked as a parameter pack, so
we were deducing it to an empty pack instead of failing.

PR c++/102629

gcc/cp/ChangeLog:

* pt.cc (gen_elem_of_pack_expansion_instantiation): Clear
TEMPLATE_TYPE_PARAMETER_PACK on auto.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/lambda-pack-init7.C: New test.

GCN: Make "gang-private data-share memory exhausted" error more verbose

    [...]: error: 512 bytes of gang-private data-share memory exhausted (increase with ‘-mgang-private-size=560’, for example)

gcc/
* config/gcn/gcn.cc (gcn_print_lds_decl): Make "gang-private
data-share memory exhausted" error more verbose.

Update gcc sv.po

* sv.po: Update.

c++: decltype of non-dependent call of class type [PR105386]

We need to pass tf_decltype when instantiating a non-dependent decltype
operand, like tsubst does in the dependent case, so that we don't force
completion of a prvalue operand's class type.

PR c++/105386

gcc/cp/ChangeLog:

* semantics.cc (finish_decltype_type): Pass tf_decltype to
instantiate_non_dependent_expr_sfinae.

gcc/testsuite/ChangeLog:

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

lto: use diagnostics_context in print_lto_docs_link

Properly parse OPT_fdiagnostics_urls_ and then initialize both urls
and colors for global_dc. Doing that we would follow the configure
option --with-documentation-root-url, -fdiagnostics-urls is respected.
Plus we'll print colored warning and note messages.

PR lto/105364

gcc/ChangeLog:

* lto-wrapper.cc (print_lto_docs_link): Use global_dc.
(run_gcc): Parse OPT_fdiagnostics_urls_.
(main): Initialize global_dc.

libphobos: Don't call free on the TLS array in the emutls destroy function.

Fixes a segfault seen on Darwin when a GC scan is ran after a thread has
been destroyed.  As the global emutlsArrays hash still has a reference
to the array itself, and tries to iterate all elements.

Setting the length to zero frees all allocated elements in the array,
and ensures that it is skipped when the _d_emutls_scan is called.

libphobos/ChangeLog:

* libdruntime/gcc/emutls.d (emutlsDestroyThread): Clear the per-thread
TLS array, don't call free().

libstdc++: Add std::atomic<shared_ptr>(nullptr_t) constructor (LWG 3661)

This DR was approved at the February 2022 plenary.

libstdc++-v3/ChangeLog:

* include/bits/shared_ptr_atomic.h (atomic<shared_ptr>): Add
constructor for constant initialization from nullptr_t.
* testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc:
Check for new constructor.

libstdc++: Define std::hash<std::filesystem::path> (LWG 3657)

This DR was approved at the February 2022 plenary.

libstdc++-v3/ChangeLog:

* include/bits/fs_path.h (hash<filesystem::path>): Define.
* testsuite/27_io/filesystem/path/nonmember/hash_value.cc:
Check std::hash specialization.

rs6000: Make the has_arch target selectors actually work

2022-04-26  Segher Boessenkoool  <segher@kernel.crashing.org>

gcc/testsuite/
PR target/105349
* lib/target-supports.exp (check_effective_target_has_arch_pwr5): Use
the specified dg-options.
(check_effective_target_has_arch_pwr6): Ditto.
(check_effective_target_has_arch_pwr7): Ditto.
(check_effective_target_has_arch_pwr8): Ditto.
(check_effective_target_has_arch_pwr9): Ditto.
(check_effective_target_has_arch_pwr10): Ditto.
(check_effective_target_has_arch_ppc64): Ditto.

ifcvt: Improve noce_try_store_flag_mask [PR105314]

The following testcase regressed on riscv due to the splitting of critical
edges in the sink pass, similarly to x86_64 compared to GCC 11 we now swap
the edges, whether true or false edge goes to an empty forwarded bb.
From GIMPLE POV, those 2 forms are equivalent, but as can be seen here, for
some ifcvt opts it matters one way or another.

On this testcase, noce_try_store_flag_mask used to trigger and transformed
if (pseudo2) pseudo1 = 0;
into
pseudo1 &= -(pseudo2 == 0);
But with the swapped edges ifcvt actually sees
if (!pseudo2) pseudo3 = pseudo1; else pseudo3 = 0;
and noce_try_store_flag_mask punts.  IMHO there is no reason why it
should punt those, it is equivalent to
pseudo3 = pseudo1 & -(pseudo2 == 0);
and especially if the target has 3 operand AND, it shouldn't be any more
costly (and even with 2 operand AND, it might very well happen that RA
can make it happen without any extra moves).

Initially I've just removed the rtx_equal_p calls from the conditions
and didn't add anything there, but that broke aarch64 bootstrap and
regressed some testcases on x86_64, where if_info->a or if_info->b could be
some larger expression that we can't force into a register.
Furthermore, the case where both if_info->a and if_info->b are constants is
better handled by other ifcvt optimizations like noce_try_store_flag
or noce_try_inverse_constants or noce_try_store_flag_constants.
So, I've restricted it to just a REG (perhaps SUBREG of REG might be ok too)
next to what has been handled previously.

2022-04-26  Jakub Jelinek  <jakub@redhat.com>

PR rtl-optimization/105314
* ifcvt.cc (noce_try_store_flag_mask): Don't require that the non-zero
operand is equal to if_info->x, instead use the non-zero operand
as one of the operands of AND with if_info->x as target.

* gcc.target/riscv/pr105314.c: New test.

reassoc: Don't call fold_convert if !fold_convertible_p [PR105374]

As mentioned in the PR, we ICE because maybe_fold_*_comparisons returns
an expression with V4SImode type and we try to fold_convert it to
V4BImode, which isn't allowed.

IMHO no matter whether we change maybe_fold_*_comparisons we should
play safe on the reassoc side and punt if we can't convert like
we punt for many other reasons.  This fixes the testcase on ARM.

Testcase not included, not exactly sure where and what directives it
should have in gcc.target/arm/ testsuite.  Christophe, do you think you
could handle that incrementally?

2022-04-26  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/105374
* tree-ssa-reassoc.cc (eliminate_redundant_comparison): Punt if
!fold_convertible_p rather than assuming fold_convert must succeed.

testsuite: Fix up g++.target/i386/vec-tmpl1.C testcase [PR65211]

This test fails on i686-linux:
Excess errors:
.../gcc/testsuite/g++.target/i386/vec-tmpl1.C:13:27: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]

2022-04-26  Jakub Jelinek  <jakub@redhat.com>

PR c++/65211
* g++.target/i386/vec-tmpl1.C: Add -Wno-psabi as
dg-additional-options.

i386: Fix up ICE with -mveclibabi={acml,svml} [PR105367]

The following testcase ICEs, because conversion between scalar float types
which have the same mode are useless in GIMPLE, but for mathfn_built_in the
exact type matters (it treats say double and _Float64 or float and _Float32
differently, using different suffixes and for the _Float* sometimes
returning NULL when float/double do have a builtin).

In ix86_veclibabi_{svml,acml} we are using mathfn_built_in just so that
we don't have to translate the combined_fn and SFmode vs. DFmode into
strings ourselfs, and we already earlier punt on anything but SFmode and
DFmode.  So, this patch just uses the double or float types depending
on the modes, rather than the types we actually got and which might be
_Float64 or _Float32 etc.

2022-04-26  Jakub Jelinek  <jakub@redhat.com>

PR target/105367
* config/i386/i386.cc (ix86_veclibabi_svml, ix86_veclibabi_acml): Pass
el_mode == DFmode ? double_type_node : float_type_node instead of
TREE_TYPE (type_in) as first arguments to mathfn_built_in.

* gcc.target/i386/pr105367.c: New test.

testsuite: Improve unlimited_polymorphic_3.f03 [PR103662]

On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
> hadn’t seen.

I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not check the dse dump at -O0 like in the following patch?

Even better would be to check that the z._data = stores are both present
in *.optimized dump, but that doesn't really work at -O2 or above because
we inline the functions and optimize it completely away (both the stores
and corresponding reads).

The first hunk is needed so that __OPTIMIZE__ effective target works in
Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
is considered not to match at all.

2022-04-26  Jakub Jelinek  <jakub@redhat.com>

PR fortran/103662
* lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add
a var definition to avoid pedwarn about empty translation unit.
* gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse from
dg-additional-options, guard scan-tree-dump-not directives on
__OPTIMIZE__ target.

libgomp: Fix up two non-GOMP_USE_ALIGNED_WORK_SHARES related issues [PR105358]

Last fall I've changed struct gomp_work_share, so that it doesn't have
__attribute__((aligned (64))) lock member in the middle unless the target has
non-emulated aligned allocator, otherwise it just makes sure the first and
second halves are 64 bytes appart for cache line reasons, but doesn't make
the struct 64-byte aligned itself and so we can use normal allocators for it.

When the struct isn't 64-byte aligned, the amount of tail padding significantly
decreases, to 0 or 4 bytes or so.  The library uses that tail padding when
the ordered_teams_ids array (array of uints) and/or the memory for lastprivate
conditional temporaries (the latter wants to guarantee long long alignment).
The problem with it on ia32 darwin9 is that while the struct contains
long long members, long long is just 4 byte aligned while __alignof__(long long)
is 8.  That causes problems in gomp_init_work_share, where we currently rely on
if offsetof (struct gomp_work_share, inline_ordered_team_ids) is long long
aligned, then that tail array will be aligned at runtime and so no extra
memory for dynamic realignment will be needed (that is false when the whole
struct doesn't have long long alignment).  And also in the remaining hunks
causes another problem, where we compute INLINE_ORDERED_TEAM_IDS_OFF
as the above offsetof aligned up to long long boundary and subtract
sizeof (struct gomp_work_share) and INLINE_ORDERED_TEAM_IDS_OFF.
When unlucky, the former isn't multiple of 8 and the latter is 4 bigger
than that and as the subtraction is done in size_t, we end up with (size_t) -4,
so the comparison doesn't really work.

The fixes add additional conditions to make it work properly, but all of them
should be evaluated at compile time when optimizing and so shouldn't slow
anything.

2022-04-26  Jakub Jelinek  <jakub@redhat.com>

PR libgomp/105358
* work.c (gomp_init_work_share): Don't mask of adjustment for
dynamic long long realignment if struct gomp_work_share has smaller
alignof than long long.
* loop.c (GOMP_loop_start): Don't use inline_ordered_team_ids if
struct gomp_work_share has smaller alignof than long long or if
sizeof (struct gomp_work_share) is smaller than
INLINE_ORDERED_TEAM_IDS_OFF.
* loop_ull.c (GOMP_loop_ull_start): Likewise.
* sections.c (GOMP_sections2_start): Likewise.

c++: generic lambda fn parm pack [PR104624]

Parameter packs from the enclosing context can be used unexpanded in a
lambda that is itself part of a pack expansion, but not packs that are part
of the lambda itself.  We already check for capture packs; we also need to
check for function parameter packs of the lambda call operator.

PR c++/104624

gcc/cp/ChangeLog:

* pt.cc (check_for_bare_parameter_packs): Check for lambda
function parameter pack.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-variadic22.C: New test.

c++: ICE with requires-expr and -Wsequence-point [PR105304]

Here we're crashing from verify_sequence_points for this requires-expr
condition because it contains a templated CAST_EXPR with empty operand,
and verify_tree doesn't ignore this empty operand only because the
manual tail recursion that it performs for unary expression trees skips
the NULL test.

PR c++/105304

gcc/c-family/ChangeLog:

* c-common.cc (verify_tree) [restart]: Move up to before the
NULL test.

gcc/testsuite/ChangeLog:

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

c++: partial ordering with dependent NTTP type [PR105289]

Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
on (respectively) two testcases that we used to accept in C++17 mode
since r8-1437-g3da557ec145823.  Both testcases declare a partial
specialization of a primary template that has an NTTP with dependent
type, and the validity of these partial specializations is unclear and
the subject of PR86193 / CWG 455.

So for now, this minimal patch just aims to fix the crash in the second
testcase.  During deduction, when checking whether the type of an NTTP
uses still-undeduced parameters, we were incorrectly substituting into
the previously substituted type instead of into its original type.

In passing this patch also downgrades the "not more specialized"
diagnostic from a permerror to a pedwarn.

PR c++/105289
PR c++/86193

gcc/cp/ChangeLog:

* pt.cc (process_partial_specialization): Downgrade "partial
specialization isn't more specialized" diagnostic from permerror
to an on-by-default pedwarn.
(unify) <case TEMPLATE_PARM_INDEX>: When substituting into the
NTTP type a second time, use the original type not the
substituted type.

gcc/testsuite/ChangeLog:

* g++.dg/template/partial-specialization11.C: New test.
* g++.dg/template/partial-specialization12.C: New test.

Daily bump.

analyzer: fix ICEs on complex constants [PR105365,105366]

gcc/analyzer/ChangeLog:
PR analyzer/105365
PR analyzer/105366
* svalue.cc
(cmp_cst): Rename to...
(cmp_csts_same_type): ...this.  Convert all recursive calls to
calls to...
(cmp_csts_and_types): ....this new function.
(svalue::cmp_ptr): Update for renaming of cmp_cst

gcc/testsuite/ChangeLog:
PR analyzer/105365
PR analyzer/105366
* gcc.dg/analyzer/pr105365.c: New test.
* gcc.dg/analyzer/pr105366.c: New test.

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

gimple-fold: fix further missing stmt locations [PR104308]

PR analyzer/104308 initially reported about a
-Wanalyzer-use-of-uninitialized-value diagnostic using UNKNOWN_LOCATION
when complaining about certain memmove operations where the source
is uninitialized.

In r12-7856-g875342766d4298 I fixed the missing location for
a stmt generated by gimple_fold_builtin_memory_op, but the reporter
then found another way to generate such a stmt with UNKNOWN_LOCATION.

I've now gone through gimple_fold_builtin_memory_op looking at all
statement creation, and found three places in which a new statement
doesn't have a location set on it (either directly via
gimple_set_location, or indirectly via gsi_replace), one of which is
the new reproducer.

This patch adds a gimple_set_location to these three cases, and adds
test coverage for one of them (the third hunk within the patch), fixing
the new reproducer for PR analyzer/104308.

gcc/ChangeLog:
PR analyzer/104308
* gimple-fold.cc (gimple_fold_builtin_memory_op): Explicitly set
the location of new_stmt in all places that don't already set it,
whether explicitly, or via a call to gsi_replace.

gcc/testsuite/ChangeLog:
PR analyzer/104308
* gcc.dg/analyzer/pr104308.c: Add test coverage.

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

fortran: Fix up gfc_trans_oacc_construct [PR104717]

So that move_sese_region_to_fn works properly, OpenMP/OpenACC constructs
for which that function is invoked need an extra artificial BIND_EXPR
around their body so that we move all variables of the bodies.

The C/C++ FEs do that both for OpenMP constructs like OMP_PARALLEL, OMP_TASK
or OMP_TARGET and for OpenACC constructs that behave similarly to
OMP_TARGET, but the Fortran FE only does that for OpenMP constructs.

The following patch does that for OpenACC constructs too.

PR fortran/104717
gcc/fortran/
* trans-openmp.cc (gfc_trans_oacc_construct): Wrap construct body
in an extra BIND_EXPR.
gcc/testsuite/
* gfortran.dg/goacc/pr104717.f90: New test.
* gfortran.dg/goacc/privatization-1-compute-loop.f90: Adjust.
libgomp/
* testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Adjust.

Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>

contrib: filter out a new Clang warning

Filter out:
libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-attribute-extensions]

contrib/ChangeLog:

* filter-clang-warnings.py: Filter out
-Wc++20-attribute-extensions in lex.cc.

libstdc++: Implement constexpr std::unique_ptr for C++23 (P2273R3)

libstdc++-v3/ChangeLog:

* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define
conditionally.
* include/bits/unique_ptr.h (__cpp_lib_constexpr_memory):
Define for C++23.
(default_delete, default_delete<T[]>, __uniq_ptr_impl)
(unique_ptr, unique_ptr<T[], D>): Add constexpr to all member
functions.
* include/std/version (__cpp_lib_constexpr_memory): Define new
value for C++23.
* testsuite/20_util/unique_ptr/assign/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/comparison/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/cons/constexpr_c++20.cc: New test.
* testsuite/20_util/unique_ptr/creation/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/modifiers/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/specialized_algorithms/constexpr.cc:
New test.

libstdc++: Add deduction guides for std::packaged_task [PR105375]

This change was LWG 3117.

The test is copied from 20_util/function/cons/deduction.cc

libstdc++-v3/ChangeLog:

PR libstdc++/105375
* include/std/future (packaged_task): Add deduction guides.
* testsuite/30_threads/packaged_task/cons/deduction.cc: New test.

c++: __builtin_shufflevector with value-dep expr [PR105353]

Here we issue an error from c_build_shufflevector while parsing a template
because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs
(except the first two arguments).  It checks if any of the arguments are
type-dependent, if so, we leave the processing for later, but it should
also check value-dependency for the 3rd+ arguments, so as to avoid the
problem above.

This is not a regression -- __builtin_shufflevector was introduced in
GCC 12, but it looks safe enough.

PR c++/105353

gcc/cp/ChangeLog:

* typeck.cc (build_x_shufflevector): Use
instantiation_dependent_expression_p except for the first two
arguments.

gcc/testsuite/ChangeLog:

* g++.dg/ext/builtin-shufflevector-3.C: New test.

docs: Fix 'modff' reference in extend.texi

In commit a2a919aa501e3 (2003), built-ins for modf and modff were added.
In extend.texi, section "Other Builtins", "modf" was added to the paragraph
"There are also built-in versions of the ISO C99 functions [...]" and
"modf" was also added to the paragraph "The ISO C90 functions [...]".
"modff" was not added to either paragraph.

Based on the context clues about where "modfl" and other similar function
pairs like "powf/powl" appear, I believe the reference to "modf" in the
first paragraph (C99) should instead be "modff".

2022-04-25  Paul A. Clarke  <pc@us.ibm.com>

gcc
* doc/extend.texi (Other Builtins): Correct reference to 'modff'.

Retain existing range knowledge when prefilling statements.

When range_of_stmt was adjusted to avoid large recursion depth, we need to
intersect the calculated range whth the any known range to avoid losing
info.  Range_of_stmt does this, but the new prefill code missed it.

PR tree-optimization/105276
gcc/
* gimple-range.cc (gimple_ranger::prefill_stmt_dependencies): Include
existing global range with calculated value.

gcc/testsuite/
* g++.dg/pr105276.C: New.

contrib: filter out a new Clang warning

contrib/ChangeLog:

* filter-clang-warnings.py: Filter out
-Wbitwise-instead-of-logical.

libstdc++: Add pretty printer for std::initializer_list

Re-using the std::span printer, this now shows the contents of the
initializer list instead of the pointer and length members.

Signed-off-by: Philipp Fent <fent@in.tum.de>
libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (StdSpanPrinter._iterator):
Rename as iterator.
(StdInitializerListPrinter): Define new printer.
(build_libstdcxx_dictionary): Register new printer.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Check printer for
initializer_list.

testsuite: add additional option to force DSE execution [PR103662]

This fixes a dump tree match check that is UNRESOLVED with the -O0
optimization option, as the optimization pass corresponding to the
dump file is not run at -O0, and the dump is not generated.

PR fortran/103662

gcc/testsuite/ChangeLog:

* gfortran.dg/unlimited_polymorphic_3.f03: Force execution of
the DSE optimization pass.

tree-optimization/105368 - avoid overflow in powi_cost

The following avoids undefined signed overflow when computing
the absolute of the exponent in powi_cost.

2022-04-25  Richard Biener  <rguenther@suse.de>

PR tree-optimization/105368
* tree-ssa-math-opts.cc (powi_cost): Use absu_hwi.

tree-optimization/100810 - avoid undefs in IVOPT rewrites

The following attempts to avoid IVOPTs rewriting uses using
IV candidates that involve undefined behavior by using uninitialized
SSA names.  First we restrict the set of candidates we produce
for such IVs to the original ones and mark them as not important.
Second we try to only allow expressing uses with such IV if they
originally use them.  That is to avoid rewriting all such uses
in terms of other IVs.  Since cand->iv and use->iv seem to never
exactly match up we resort to comparing the IV bases.

The approach ends up similar to the one posted by Roger at
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578441.html
but it marks IV candidates rather than use groups and the cases
we allow in determine_group_iv_cost_generic are slightly different.

2022-01-04  Richard Biener  <rguenther@suse.de>

PR tree-optimization/100810
* tree-ssa-loop-ivopts.cc (struct iv_cand): Add involves_undefs flag.
(find_ssa_undef): New function.
(add_candidate_1): Avoid adding derived candidates with
undefined SSA names and mark the original ones.
(determine_group_iv_cost_generic): Reject rewriting
uses with a different IV when that involves undefined SSA names.

* gcc.dg/torture/pr100810.c: New testcase.
* gcc.dg/torture/pr105337.c: Likewise.

target/89125 - BSD and math functions

Back story: When GCC is configured and built on non-glibc platforms,
it seems very little to no effort is made to enumerate the available
C99 libm functions.  It is all or nothing for C99 libm.  The patch
introduces a new function, used on only FreeBSD, to inform gcc that
it has C99 libm functions (minus a few which clearly GCC does not check
nor test).

2022-04-15  Steven G. Kargl  <kargl@gcc.gnu.org>

PR target/89125
* config/freebsd.h: Define TARGET_LIBC_HAS_FUNCTION to be
bsd_libc_has_function.
* targhooks.cc (bsd_libc_has_function): New function.
Expand the supported math functions to inclue C99 libm.
* targhooks.h (bsd_libc_has_function): New Prototype.

rtl-optimization/105231 - distribute_notes and REG_EH_REGION

The following mitigates a problem in combine distribute_notes which
places an original REG_EH_REGION based on only may_trap_p which is
good to test whether a non-call insn can possibly throw but not if
actually it does or we care.  That's something we decided at RTL
expansion time where we possibly still know the insn evaluates
to a constant.

In fact, the REG_EH_REGION note with lp > 0 can only come from the
original i3 and an assert is added to that effect.  That means we only
need to retain the note on i3 or, if that cannot trap, drop it but we
should never move it to i2.

The following places constraints on the insns to combine with
non-call exceptions since we cannot handle the case where we
have more than one EH side-effect in the IL.  The patch also
makes sure we can accumulate that on i3 and do not split
a possible exception raising part of it to i2.  As a special
case we do not place any restriction on all externally
throwing insns when there is no REG_EH_REGION present.

2022-04-22  Richard Biener  <rguenther@suse.de>

PR rtl-optimization/105231
* combine.cc (distribute_notes): Assert that a REG_EH_REGION
with landing pad > 0 is from i3.  Put any REG_EH_REGION note
on i3 or drop it if the insn can not trap.
(try_combine): Ensure that we can merge REG_EH_REGION notes
with non-call exceptions.  Ensure we are not splitting a
trapping part of an insn with non-call exceptions when there
is any REG_EH_REGION note to preserve.

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

AVX512F: Add missing macro for mask(z?)_scalf_s[sd] [PR 105339]

Add missing macro under O0 and adjust macro format for scalf
intrinsics.

gcc/ChangeLog:

PR target/105339
* config/i386/avx512fintrin.h (_mm512_scalef_round_pd):
Add parentheses for parameters and djust format.
(_mm512_mask_scalef_round_pd): Ditto.
(_mm512_maskz_scalef_round_pd): Ditto.
(_mm512_scalef_round_ps): Ditto.
(_mm512_mask_scalef_round_ps): Ditto.
(_mm512_maskz_scalef_round_ps): Ditto.
(_mm_scalef_round_sd): Use _mm_undefined_pd.
(_mm_scalef_round_ss): Use _mm_undefined_ps.
(_mm_mask_scalef_round_sd): New macro.
(_mm_mask_scalef_round_ss): Ditto.
(_mm_maskz_scalef_round_sd): Ditto.
(_mm_maskz_scalef_round_ss): Ditto.

gcc/testsuite/ChangeLog:

PR target/105339
* gcc.target/i386/sse-14.c: Add tests for new macro.

Daily bump.

[committed] exec-stack warning for test which wants executable stacks

gcc/testsuite
* gcc.dg/lto/pr94157_0.c: Also request executable stack from
the linker.

fortran: Detect duplicate unlimited polymorphic types [PR103662]

This fixes a type-based alias analysis issue with unlimited polymorphic
class descriptors (types behind class(*)) causing data initialisation to
be removed by optimization.

The fortran front-end may create multiple declarations for types, for
example if a type is redeclared in each program unit it is used in.
To avoid optimization seeing them as non-aliasing, a list of derived
types is created at resolution time, and used at translation to set
the same TYPE_CANONICAL type for each duplicate type declaration.

This mechanism didn’t work for unlimited polymorphic descriptors types,
as there is a short-circuit return skipping all the resolution handling
for them, including the type registration.

This change adds type registration at the short-circuit return, and
updates type comparison to handle specifically unlimited polymorphic
fake symbols, class descriptor types and virtual table types.

The test, which exhibited mismatching dynamic types had to be fixed as
well.

PR fortran/103662

gcc/fortran/ChangeLog:

* interface.cc (gfc_compare_derived_types): Support comparing
unlimited polymorphic fake symbols.  Recursively compare class
descriptor types and virtual table types.
* resolve.cc (resolve_fl_derived): Add type to the types list
on unlimited polymorphic short-circuit return.

gcc/testsuite/ChangeLog:

* gfortran.dg/unlimited_polymorphic_3.f03 (foo): Separate
bind(c) and sequence checks to...
(foo_bc, foo_sq): ... two different procedures.
(main, foo*): Change type declarations so that type name,
component name, and either bind(c) or sequence attribute match
between the main type declarations and the procedure type
declarations.
(toplevel): Add optimization dump checks.

Co-Authored-By: Jakub Jelinek <jakub@redhat.com>

Daily bump.

i386: Improve ix86_expand_int_movcc [PR105338]

The following testcase regressed on x86_64 on the trunk, due to some GIMPLE
pass changes (r12-7687) we end up an *.optimized dump difference of:
@@ -8,14 +8,14 @@ int foo (int i)

   <bb 2> [local count: 1073741824]:
   if (i_2(D) != 0)
-    goto <bb 4>; [35.00%]
+    goto <bb 3>; [35.00%]
   else
-    goto <bb 3>; [65.00%]
+    goto <bb 4>; [65.00%]

-  <bb 3> [local count: 697932184]:
+  <bb 3> [local count: 375809640]:

   <bb 4> [local count: 1073741824]:
-  # iftmp.0_1 = PHI <5(2), i_2(D)(3)>
+  # iftmp.0_1 = PHI <5(3), i_2(D)(2)>
   return iftmp.0_1;

 }
and similarly for the other functions.  That is functionally equivalent and
there is no canonical form for those.  The reason for i_2(D) in the PHI
argument as opposed to 0 is the uncprop pass, that is in many cases
beneficial for expansion as we don't need to load the value into some pseudo
in one of the if blocks.
Now, for the 11.x ordering we have the pseudo = i insn in the extended basic
block (it comes first) and so forwprop1 undoes what uncprop does by
propagating constant 0 there.  But for the 12.x ordering, the extended basic
block contains pseudo = 5 and pseudo = i is in the other bb and so fwprop1
doesn't change it.
During the ce1 pass, we attempt to emit a conditional move and we have very
nice code for the cases where both last operands of ?: are constant, and yet
another for !TARGET_CMOVE if at least one of them is.

The following patch will undo the uncprop behavior during
ix86_expand_int_movcc, but just for those spots that can benefit from both
or at least one operands being constant, leaving the pure cmov case as is
(because then it is useful not to have to load a constant into a pseudo
as it already is in one).  We can do that in the
op0 == op1 ? op0 : op3
or
op0 != op1 ? op2 : op0
cases if op1 is a CONST_INT by pretending it is
op0 == op1 ? op1 : op3
or
op0 != op1 ? op2 : op1

2022-04-23  Jakub Jelinek  <jakub@redhat.com>

PR target/105338
* config/i386/i386-expand.cc (ix86_expand_int_movcc): Handle
op0 == cst1 ? op0 : op3 like op0 == cst1 ? cst1 : op3 for the non-cmov
cases.

* gcc.target/i386/pr105338.c: New test.

Daily bump.

libstdc++: Make atomic notify_one and notify_all non-const

<recording this here for future reference>
PR102994 "atomics: std::atomic<ptr>::wait is not marked const" raises the
issue that the current libstdc++ implementation marks the notify members
const, the implementation strategy used by libstdc++, as well as libc++
and the Microsoft STL, do not require the atomic to be mutable (it is hard
to conceive of a desirable implementation approach that would require it).
The original paper proposing the wait/notify functionality for atomics
(p1185) also had these members marked const for the first three revisions,
but that was changed without explanation in r3 and subsequent revisions of
the paper.

After raising the issue to the authors of p1185 and the author of the
libc++ implementation, the consensus seems to be "meh, it's harmless" so
there seems little appetite for an LWG issue to revisit the subject.

This patch changes the libstdc++ implementation to be in agreement with
the standard by removing const from those notify_one/notify_all members.

libstdc++-v3/ChangeLog:

PR libstdc++/102994
* include/bits/atomic_base.h (atomic_flag::notify_one,
notify_all): Remove const qualification.
(__atomic_base::notify_one, notify_all): Likewise.
* include/std/atomic (atomic<bool>::notify_one, notify_all):
Likewise.
(atomic::notify_one, notify_all): Likewise.
(atomic<T*>::notify_one, notify_all): Likewise.
(atomic_notify_one, atomic_notify_all): Likewise.
* testsuite/29_atomics/atomic/wait_notify/102994.cc: Adjust test
to account for change in notify_one/notify_all signature.

fortran: Use pointer arithmetic to index arrays [PR102043]

The code generated for array references used to be ARRAY_REF trees as
could be expected.  However, the middle-end may conclude from those
trees that the indexes used are non-negative (more precisely not below
the lower bound), which is a wrong assumption in the case of "reversed-
order" arrays.

The problematic arrays are those with a descriptor and having a negative
stride for at least one dimension.  The descriptor data points to the
first element in array order (which is not the first in memory order in
that case), and the negative stride(s) makes walking the array backwards
(towards lower memory addresses), and we can access elements with
negative index wrt data pointer.

With this change, pointer arithmetic is generated by default for array
references, unless we are in a case where negative indexes can’t happen
(array descriptor’s dim element, substrings, explicit shape,
allocatable, or assumed shape contiguous).  A new flag is added to
choose between array indexing and pointer arithmetic, and it’s set
if the context can tell array indexing is safe (descriptor dim
element, substring, temporary array), or a new method is called
to decide on whether the flag should be set for one given array
expression.

PR fortran/102043

gcc/fortran/ChangeLog:

* trans.h (gfc_build_array_ref): Add non_negative_offset
argument.
* trans.cc (gfc_build_array_ref): Ditto. Use pointer arithmetic
if non_negative_offset is false.
* trans-expr.cc (gfc_conv_substring): Set flag in the call to
gfc_build_array_ref.
* trans-array.cc (gfc_get_cfi_dim_item,
gfc_conv_descriptor_dimension): Same.
(build_array_ref): Decide on whether to set the flag and update
the call.
(gfc_conv_scalarized_array_ref): Same.  New argument tmp_array.
(gfc_conv_tmp_array_ref): Update call to
gfc_conv_scalarized_ref.
(non_negative_strides_array_p): New function.

gcc/testsuite/ChangeLog:

* gfortran.dg/array_reference_3.f90: New.
* gfortran.dg/negative_stride_1.f90: New.
* gfortran.dg/vector_subscript_8.f90: New.
* gfortran.dg/vector_subscript_9.f90: New.
* gfortran.dg/c_loc_test_22.f90: Update dump patterns.
* gfortran.dg/finalize_10.f90: Same.

Co-Authored-By: Richard Biener <rguenther@suse.de>

fortran: Generate an array temporary reference [PR102043]

This avoids regressing on char_cast_1.f90 and char_cast_2.f90 later in
the patch series when the code generation for array references is
changed to use pointer arithmetic.

The regressing testcases match part of an array reference in the
generated tree dump and it’s not clear how the pattern should be
rewritten to match the equivalent with pointer arithmetic.

This change uses a method specific to array temporaries to generate
array-references, so that these array references are flagged as safe
for array indexing and will not be updated to use pointer arithmetic.

PR fortran/102043

gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_expr_descriptor): Use
gfc_conv_tmp_array_ref.

fortran: Update index extraction code. [PR102043]

This avoids a regression on hollerith4.f90 and hollerith6.f90 later in
the patch series when code generation for array references is changed
to use pointer arithmetic.

The problem comes from the extraction of the array index from an
ARRAY_REF tree, which doesn’t work if the tree is not an ARRAY_REF
any more.

This updates the code generated for remaining size evaluation to work
with a source tree that uses either array indexing or pointer
arithmetic.

PR fortran/102043

gcc/fortran/ChangeLog:

* trans-io.cc: Add handling for the case where the array
is referenced using pointer arithmetic.

fortran: Pre-evaluate string pointers. [PR102043]

This avoids a regression on deferred_character_23.f90 later in the
patch series when array references are rewritten to use pointer
arithmetic.

The problem is a SAVE_EXPR tree as TYPE_SIZE_UNIT of one array element
type, which is used by the pointer arithmetic expressions.  As these
expressions appear in both branches of an if-then-else block, the tree
is lowered to a variable in one of the branches but it’s used in both
branches, which is invalid middle-end code.

This change pre-evaluates the array references or pointer arithmetics
to variables before the if-then-else block, so that the SAVE_EXPR are
expanded to variables in the parent scope of the if-then-else block,
and expressions referencing the variables remain valid in both
branches.

PR fortran/102043

gcc/fortran/ChangeLog:
* trans-expr.cc: Pre-evaluate src and dest to variables
before using them.

gcc/testsuite/ChangeLog:
* gfortran.dg/dependency_49.f90: Update variable occurence
count.

rs6000: Fix pack for soft-float (PR105334)

For PR103623 I fixed unpack, but pack is broken as well, as reported in
PR105334.  Fixing that is a bit more code, but it is pretty simple code
nonetheless.

2022-04-22  Segher Boessenkool  <segher@kernel.crashing.org>

PR target/105334
* config/rs6000/rs6000.md (pack<mode> for FMOVE128): New expander.
(pack<mode> for FMOVE128): Rename and split the insn_and_split to...
(pack<mode>_hard for FMOVE128): ... this...
(pack<mode>_soft for FMOVE128): ... and this.

docs: Correct "This functions" to "These functions"

2022-04-22  Paul A. Clarke  <pc@us.ibm.com>

gcc
* doc/extend.texi: Correct "This" to "These".

rtlanal: Fix up replace_rtx [PR105333]

The following testcase FAILs, because replace_rtx replaces a REG with
CONST_WIDE_INT inside of a SUBREG, which is an invalid transformation
because a SUBREG relies on SUBREG_REG having non-VOIDmode but
CONST_WIDE_INT has VOIDmode.

replace_rtx already has code to deal with it, but it was doing
it only for CONST_INTs.  The following patch does it also for
VOIDmode CONST_DOUBLE or CONST_WIDE_INT.

2022-04-22  Jakub Jelinek  <jakub@redhat.com>

PR rtl-optimization/105333
* rtlanal.cc (replace_rtx): Use simplify_subreg or
simplify_unary_operation if CONST_SCALAR_INT_P rather than just
CONST_INT_P.

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

Daily bump.

rs6000/testsuite: xfail bswap-brw.c

This testcase does not generate anywhere near optimal code for 32-bit
code.  For p10 it actually now fails this testcase, after the previous
patch.  Let's xfail it.

2022-04-21  Segher Boessenkool  <segher@kernel.crashing.org>

gcc/testsuite/
PR target/103197
PR target/102146
* gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for -m32.

rs6000: Disparage lfiwzx and similar

RA now chooses GEN_OR_VSX_REGS in most cases.  This is great in most
cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is
problematic because the integer load and store insns can use cheaper
addressing modes.  We can fix that by putting a small penalty on the
instruction alternatives for those.

2022-04-21  Segher Boessenkool  <segher@kernel.crashing.org>

PR target/103197
PR target/102146
* config/rs6000/rs6000.md (zero_extendqi<mode>2 for EXTQI): Disparage
the "Z" alternatives in {l,st}{f,xs}iwzx.
(zero_extendhi<mode>2 for EXTHI): Ditto.
(zero_extendsi<mode>2 for EXTSI): Ditto.
(*movsi_internal1): Ditto.
(*mov<mode>_internal1 for QHI): Ditto.
(movsd_hardfloat): Ditto.

rs6000: Add effective target has_arch_ppc64

This is true if we have -mpowerpc64.

2022-04-21  Segher Boessenkool  <segher@kernel.crashing.org>

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_has_arch_ppc64): New.

d: Merge upstream dmd eb7bee331, druntime 27834edb, phobos ac296f80c.

D front-end changes:

    - Import dmd v2.100.0-beta.1.
    - Print deprecation messages for scope violations unless
      `-frevert=dip1000' is used.
    - Fixed a missed case of switch case fallthrough not being caught by
      the compiler.

D runtime changes:

    - Import druntime v2.100.0-beta.1.

Phobos changes:

    - Import phobos v2.100.0-beta.1.

gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd eb7bee331.
* dmd/VERSION: Update version to v2.100.0-beta.1.
* d-lang.cc (d_handle_option): Handle OPT_frevert_dip1000.
* lang.opt (frevert=dip1000): New option.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime 27834edb.
* src/MERGE: Merge upstream phobos ac296f80c.
* src/Makefile.am (PHOBOS_DSOURCES): Add std/int128.d.
* src/Makefile.in: Regenerate.

libstdc++: Avoid ASCII assumptions in floating_from_chars.cc

In starts_with_ci and in __floating_from_chars_hex's inf/nan handling,
we were assuming that the letters are contiguous and that 'A' + 32 == 'a'
which is true for ASCII but not for other character encodings.

This patch fixes starts_with_ci by using a constexpr lookup table that
maps uppercase letters to lowercase, and fixes __floating_from_chars_hex
by using __from_chars_alnum_to_val.

libstdc++-v3/ChangeLog:

* include/std/charconv (__from_chars_alnum_to_val_table):
Simplify initialization of __lower/__upper_letters.
(__from_chars_alnum_to_val): Default the template parameter to
false.
* src/c++17/floating_from_chars.cc (starts_with_ci): Don't
assume the uppercase and lowercase letters are contiguous.
(__floating_from_chars_hex): Likewise.

c++: Remove unused parameter

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_logical_expression): Remove unused
parameter.
(cxx_eval_constant_expression) <case TRUTH_ANDIF_EXPR>,
<case TRUTH_OR_EXPR>: Adjust calls to cxx_eval_logical_expression.

c++: wrong error with constexpr COMPOUND_EXPR [PR105321]

Here we issue a bogus error for the first assert in the test.  Therein
we have

<retval> = (void) (VIEW_CONVERT_EXPR<bool>(yes) || handle_error ());, VIEW_CONVERT_EXPR<int>(value);

which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression
<case COMPOUND_EXPR>.  The problem here is that we call

7044             /* Check that the LHS is constant and then discard it.  */
7045             cxx_eval_constant_expression (ctx, op0,
7046                                           true, non_constant_p, overflow_p,
7047                                           jump_target);

where lval is always true, so the PARM_DECL 'yes' is not evaluated into
its value.

Fixed by always passing false for 'lval' in cxx_eval_logical_expression;
there's no case where we actually expect an lvalue from a TRUTH_*.

PR c++/105321

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_logical_expression): Always pass false for lval
to cxx_eval_constant_expression.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-105321.C: New test.

fortran: Fix conv of UNION constructors [PR105310]

This fixes an ICE when a UNION is the (1+8*2^n)-th field in a DEC
STRUCTURE when compiled with -finit-derived -finit-local-zero.
The problem was CONSTRUCTOR_APPEND_ELT from within gfc_conv_union_initializer
modified the vector pointer, but the pointer was passed by-value,
so the old pointer from the caller (gfc_conv_structure) pointed to freed
memory.

PR fortran/105310

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_union_initializer): Pass vec* by reference.

gcc/testsuite/ChangeLog:

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

libstdc++: Work around modules ICE in <charconv> [PR105297]

This makes the initializer for __table in __from_chars_alnum_to_val
dependent in an artificial way, which works around the reported modules
testsuite ICE by preventing the compiler from evaluating the initializer
parse time.

Compared to the alternative workaround of using a non-local class type
for __table, this workaround has the advantage of slightly speeding up
compilation of <charconv>, since now the table won't get built (via
constexpr evaluation) until the integer std::from_chars overload is
instantiated.

PR c++/105297
PR c++/105322

libstdc++-v3/ChangeLog:

* include/std/charconv (__from_chars_alnum_to_val): Make
initializer for __table dependent in an artificial way.

libstdc++: Remove bogus assertion in std::from_chars [PR105324]

I'm not sure what I was thinking when I added this assertion, maybe it
was supposed to be alignment == 1 (which is what the pmr::string actually
uses). The simplest fix is to just remove the assertion.

The assertion is no longer enabled by default on trunk, but it's still
there for the --enablke-libstdcxx-debug build, and is still wrong. The
fix is needed on the gcc-11 branch.

libstdc++-v3/ChangeLog:

PR libstdc++/105324
* src/c++17/floating_from_chars.cc (buffer_resource::do_allocate):
Remove assertion.
* testsuite/20_util/from_chars/pr105324.cc: New test.

Support --compress-debug-sections for ld.mold.

gcc/ChangeLog:

* configure.ac: Enable compressed debug sections for mold
linker.
* configure: Regenerate.

emit-rtl: Fix -fcompare-debug bug with label references in debug insns [PR105203]

When we compute LABEL_NUSES from scratch, mark_all_labels doesn't call
mark_jump_label on DEBUG_INSNs:
              if (NONDEBUG_INSN_P (insn))
                mark_jump_label (PATTERN (insn), insn, 0);
and so doesn't increment LABEL_NUSES from references in DEBUG_INSNs.
But, when we call emit_copy_of_insn_after e.g. when duplicating some
DEBUG_INSNs, we call it even on those, which then results in LABEL_NUSES
differences and -fcompare-debug failures.

The following patch makes sure we don't call it on DEBUG_INSNs.

2022-04-21  Jakub Jelinek  <jakub@redhat.com>

PR debug/105203
* emit-rtl.cc (emit_copy_of_insn_after): Don't call mark_jump_label
on DEBUG_INSNs.

* gfortran.dg/g77/pr105203.f: New test.

runtime: use correct field name for PPC32 GLIBC registers

One of these days we will get this right.

Fixes PR go/105315

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/401374

Daily bump.

c++: Fall through for arrays of T vs T cv [PR104996]

If two arrays do not have the exact same element type including
qualification, this could be e.g. f(int (&&)[]) vs. f(int const (&)[]),
which can still be distinguished by the lvalue-rvalue tiebreaker.

By tightening this branch (in accordance with the letter of the Standard) we
fall through to the next branch, which tests whether they have different
element type ignoring qualification and returns 0 in that case; thus we only
actually fall through in the T[...] vs. T cv[...] case, eventually
considering the lvalue-rvalue tiebreaker at the end of compare_ics.

Signed-off-by: Ed Catmur <ed@catmur.uk>
PR c++/104996

gcc/cp/ChangeLog:

* call.cc (compare_ics): When comparing list-initialization
sequences, do not return early.

gcc/testsuite/ChangeLog:

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

libstdc++: Fix macro checked by test

The macro being tested here is wrong, but just happens to have the same
value as the one supposed to be tests.

libstdc++-v3/ChangeLog:

* testsuite/21_strings/basic_string_view/operations/copy/char/constexpr.cc:
Check correct feature test macro.

libstdc++: Use LTLIBICONV when linking libstdc++.so [PR93602]

This fixes missing libiconv symbols when libstdc++ is built on a system
that has libiconv installed. If the libiconv headers are found then
libstdc++ depends on libiconv_open etc instead of libc's iconv_open. But
without this fix libstdc++ is not linked to the libiconv library that
provides the definitions of those symbols.

As discussed in PR 93602 this changed means that libstdc++.so.6 might
have an rpath pointing to the location of the libiconv.so library. If
that is not desired, then GCC must be configured to link to a static
libiconv.a instead, using either --with-libiconv-type=static or an
in-tree build of libiconv.

libstdc++-v3/ChangeLog:

PR libstdc++/93602
* doc/xml/manual/prerequisites.xml: Document libiconv
workarounds.
* doc/html/manual/setup.html: Regenerate.
* src/Makefile.am (CXXLINK): Add $(LTLIBICONV).
* src/Makefile.in: Regenerate.

tree-optimization/104912 - ensure cost model is checked first

The following makes sure that when we build the versioning condition
for vectorization including the cost model check, we check for the
cost model and branch over other versioning checks.  That is what
the cost modeling assumes, since the cost model check is the only
one accounted for in the scalar outside cost.  Currently we emit
all checks as straight-line code combined with bitwise ops which
can result in surprising ordering of checks in the final assembly.

Since loop_version accepts only a single versioning condition
the splitting is done after the fact.

The result is a 1.5% speedup of 416.gamess on x86_64 when compiling
with -Ofast and tuning for generic or skylake.  That's not enough
to recover from the slowdown when vectorizing but it now cuts off
the expensive alias versioning test.

2022-03-21  Richard Biener  <rguenther@suse.de>

PR tree-optimization/104912
* tree-vect-loop-manip.cc (vect_loop_versioning): Split
the cost model check to a separate BB to make sure it is
checked first and not combined with other version checks.

tree-optimization/105312 - fix ISEL VCOND expansion

The following aligns ISEL VEC_COND_EXPR expansion using VCOND
with the optab query done by vector lowering.  Instead of only
allowing the signed optab to provide EQ/NE compares we allow both
here though since there seems to be no documented canonicalization.

2022-04-20  Richard Biener  <rguenther@suse.de>

PR tree-optimization/105312
* gimple-isel.cc (gimple_expand_vec_cond_expr): Query both
VCOND and VCONDU for EQ and NE.

* gcc.target/arm/pr105312.c: New testcase.

Fix overflows in ipa-modref-tree.cc

gcc/ChangeLog:

2022-04-20  Jan Hubicka  <hubicka@ucw.cz>

PR ipa/103818

* ipa-modref-tree.cc (modref_access_node::closer_pair_p): Use
poly_offset_int to avoid overflow.
(modref_access_node::update2): likewise.

gcc/testsuite/ChangeLog:

2022-04-20  Jan Hubicka  <hubicka@ucw.cz>

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

cgraph: Fix up semantic_interposition handling [PR105306]

cgraph_node has a semantic_interposition flag which should mirror
opt_for_fn (decl, flag_semantic_interposition).  But it actually is
initialized not from that, but from flag_semantic_interposition in the
  explicit symtab_node (symtab_type t)
    : type (t), resolution (LDPR_UNKNOWN), definition (false), alias (false),
...
      semantic_interposition (flag_semantic_interposition),
...
      x_comdat_group (NULL_TREE), x_section (NULL)
  {}
ctor.  I think that might be fine for varpool nodes, but since
flag_semantic_interposition is now implied from -Ofast it isn't correct
for cgraph nodes, unless we guarantee that cgraph node for a particular
function decl is always created while that function is
current_function_decl.  That is often the case, but not always as the
following function shows.
Because symtab_node's ctor doesn't know for which decl the cgraph node
is being created, the following patch keeps that as is, but updates it from
opt_for_fn (decl, flag_semantic_interposition) when we know that, or for
clones copies that flag (often it is then overridden in
set_new_clone_decl_and_node_flags, but not always).

2022-04-20  Jakub Jelinek  <jakub@redhat.com>

PR ipa/105306
* cgraph.cc (cgraph_node::create): Set node->semantic_interposition
to opt_for_fn (decl, flag_semantic_interposition).
* cgraphclones.cc (cgraph_node::create_clone): Copy over
semantic_interposition flag.

* g++.dg/opt/pr105306.C: New test.

Daily bump.

libgo: make a couple of sed uses POSIX compliant

Patch from Jonathan Wakely.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/401054

gcov-profile: Allow negative counts of indirect calls [PR105282]

TOPN metrics are histograms that contain overall count and per-bucket
count. Overall count can be negative when two profiles merge and some
of per-bucket metrics are disacarded.

Noticed as an ICE on python PGO build where gcc crashes as:

    during IPA pass: modref
    a.c:36:1: ICE: in stream_out_histogram_value, at value-prof.cc:340
       36 | }
          | ^
    stream_out_histogram_value(output_block*, histogram_value_t*)
            gcc/value-prof.cc:340

gcc/ChangeLog:

PR gcov-profile/105282
* value-prof.cc (stream_out_histogram_value): Allow negative counts
on HIST_TYPE_INDIR_CALL.

MAINTAINERS: Update my email address.

2022-04-19  Richard Henderson  <rth@gcc.gnu.org>

* MAINTAINERS: Update my email address.

sparc: Preserve ORIGINAL_REGNO in epilogue_renumber [PR105257]

The following testcase ICEs, because the pic register is
(reg:DI 24 %i0 [109]) and is used in the delay slot of a return.
We invoke epilogue_renumber and that changes it to
(reg:DI 8 %o0) which no longer satisfies sparc_pic_register_p
predicate, so we don't recognize the insn anymore.

The following patch fixes that by preserving ORIGINAL_REGNO if
specified, so we get (reg:DI 8 %o0 [109]) instead.

2022-04-19  Jakub Jelinek  <jakub@redhat.com>

PR target/105257
* config/sparc/sparc.cc (epilogue_renumber): If ORIGINAL_REGNO,
use gen_raw_REG instead of gen_rtx_REG and copy over also
ORIGINAL_REGNO.  Use return 0; instead of /* fallthrough */.

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

c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
run on the whole TARGET_EXPR slot.

So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).

2022-04-19  Jakub Jelinek  <jakub@redhat.com>

PR c++/105256
* typeck2.cc (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union): Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
containing CONSTRUCTOR.

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

tree-optimization/104010 - fix SLP scalar costing with patterns

When doing BB vectorization the scalar cost compute is derailed
by patterns, causing lanes to be considered live and thus not
costed on the scalar side.  For the testcase in PR104010 this
prevents vectorization which was done by GCC 11.  PR103941
shows similar cases of missed optimizations that are fixed by
this patch.

2022-04-13  Richard Biener  <rguenther@suse.de>

PR tree-optimization/104010
PR tree-optimization/103941
* tree-vect-slp.cc (vect_bb_slp_scalar_cost): When
we run into stmts in patterns continue walking those
for uses outside of the vectorized region instead of
marking the lane live.

* gcc.target/i386/pr103941-1.c: New testcase.
* gcc.target/i386/pr103941-2.c: Likewise.

libstdc++: Stop defining _GLIBCXX_ASSERTIONS in floating_to_chars.cc

Assertions were originally enabled in the compiled-in floating-point
std::to_chars implementation to help shake out any bugs, but they
apparently impose a significant performance penalty, most notably for
the hex formatting which is around 25% slower with assertions enabled.
This seems too high a cost for unconditionally enabling them.

The newly added calls to __builtin_unreachable work around the compiler
no longer knowing that the set of valid values of 'fmt' is limited (which
was previously upheld by an assert).

libstdc++-v3/ChangeLog:

* src/c++17/floating_to_chars.cc (_GLIBCXX_ASSERTIONS): Don't
define.
(__floating_to_chars_shortest): Add __builtin_unreachable calls to
squelch false-positive -Wmaybe-uninitialized and -Wreturn-type
warnings.
(__floating_to_chars_precision): Likewise.

libstdc++: Add pretty printer for std::span

This improves the debug output for C++20 spans.

Before:
{static extent = 18446744073709551615, _M_ptr = 0x7fffffffb9a8, _M_extent = {_M_extent_value = 2}}
Now with StdSpanPrinter:
std::span of length 2 = {1, 2}

Signed-off-by: Philipp Fent <fent@in.tum.de>
libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (StdSpanPrinter): Define.
* testsuite/libstdc++-prettyprinters/cxx20.cc: Test it.

tree-optimization/104880 - move testcase

This renames the testcase to something picked up by the suites regexp.

2022-04-19  Richard Biener  <rguenther@suse.de>

PR tree-optimization/104880
* g++.dg/opt/pr104880.cc: Rename to ...
* g++.dg/opt/pr104880.C: ... this.

libstdc++: Fix syntax error in libbacktrace configuration

Using == instead of = causes a configuration error with dash as the
shell:

checking whether to build libbacktrace support... /home/devel/building/work/src/gcc-12-20220417/libstdc++-v3/configure: 77471: test: auto: unexpected operator
/home/devel/building/work/src/gcc-12-20220417/libstdc++-v3/configure: 77474: test: auto: unexpected operator
auto

This means we fail to change the value from "auto" to "no" and so this
test passes:
GLIBCXX_CONDITIONAL(ENABLE_BACKTRACE, [test "$enable_libstdcxx_backtrace" != no])

This leads to the libbacktrace directory being included in the build
without being configured properly, and bootstrap fails.

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Fix shell operators.
* configure: Regenerate.

Daily bump.