We got internally a question about the Spec File syntax, misunderstanding
what is the literal syntax and what are the placeholder variables in
the syntax descriptions.
The following patch attempts to use @var{S} etc. instead of just S
to clarify it stands for any option (or start of option etc.) rather
than literal S, say in %{S:X}. At least in HTML documentation it
then uses italics.
2024-03-27 Jakub Jelinek <jakub@redhat.com>
* doc/invoke.texi (Spec Files): Use @var{S} instead of S,
@var{X} instead of X etc. for other placeholders.
This resolves further failures (-Wreturn-type warnings) and test
failures for where-* tests targeting AVX-512.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd_x86.h (_S_masked_unary):
Cast inputs < 16 bytes to 16 byte vectors before calling the
right subtraction builtin. Before returning, truncate to the
return vector type.
This resolves failures in the "expensive" where-* test of check-simd
when targeting AVX-512.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd_x86.h (_S_masked_unary): Call
the 4- and 8-byte variants of __builtin_ia32_subp[ds] without
rounding direction argument.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add simd_sve.h.
* include/Makefile.in: Add simd_sve.h.
* include/experimental/bits/simd.h: Add new SveAbi.
* include/experimental/bits/simd_builtin.h: Use
__no_sve_deduce_t to support existing Neon Abi.
* include/experimental/bits/simd_converter.h: Convert
sequentially when sve is available.
* include/experimental/bits/simd_detail.h: Define sve
specific macro.
* include/experimental/bits/simd_math.h: Fallback frexp
to execute sequntially when sve is available, to handle
fixed_size_simd return type that always uses sve.
* include/experimental/simd: Include bits/simd_sve.h.
* testsuite/experimental/simd/tests/bits/main.h: Enable
testing for sve128, sve256, sve512.
* include/experimental/bits/simd_sve.h: New file.
Signed-off-by: Srinivas Yadav Singanaboina <vasu.srinivasvasu.14@gmail.com>
The following makes sure to record the scalars we add to the BB
reduction vectorization result as scalar uses for the purpose of
computing live lanes. This restores vectorization in the
bondfree.c TU of 435.gromacs.
PR tree-optimization/114057
* tree-vect-slp.cc (vect_bb_slp_mark_live_stmts): Mark
BB reduction remain defs as scalar uses.
These tests FAIL for quite a while on i686-linux since July last year,
likely r14-2628 . Since that patch gcc claims _Float16 and __bf16
support even without -msse2 because some functions could be using
target attribute.
Later r14-2691 added -msse2 to add_options_for_float16, but didn't do that
for bfloat16, plus ext-floating{3,12}.C tests need the added dg-add-options,
so that float16 and bfloat16 effective targets match the __STDCPP_FLOAT16_T__
or __STDCPP_BFLOAT16_T__ macros.
Fixes
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 144)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 146)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 148)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 150)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 152)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 154)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 144)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 146)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 148)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 150)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 152)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 154)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 107)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 114)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 126)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 79)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 86)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 98)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 22)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 23)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 24)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 25)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 107)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 114)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 126)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 79)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 86)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 98)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 22)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 23)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 24)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 25)
on the latter and changes nothing on the former.
2024-03-27 Jakub Jelinek <jakub@redhat.com>
* lib/target-supports.exp (add_options_for_bfloat16): Add -msse2 on
i?86/x86_64.
* g++.dg/cpp23/ext-floating3.C: Add dg-add-options float16.
* g++.dg/cpp23/ext-floating12.C: Add dg-add-options float16 and
bfloat16.
Due to the Linux kernel exposing the lrcpc3 architectural feature as
"lrcpc3", this patch corrects the relevant FEATURE_STRING entry in the
"rcpc3" AARCH64_OPT_FMV_EXTENSION macro, such that the feature can be
correctly detected when doing native compilation on rcpc3-enabled
targets.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (rcpc3):
Fix FEATURE_STRING field to "lrcpc3".
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/cpunative/info_24: New.
* gcc.target/aarch64/cpunative/native_cpu_24.c: Likewise.
Given how, at present, the choice of using LSE128 atomic instructions
by the toolchain is delegated to run-time selection in the form of
Libatomic ifuncs, responsible for querying target support, the
`+lse128' target architecture compile-time flag is absent from GCC.
This, however, contrasts with the Binutils implementation, which gates
LSE128 instructions behind the `+lse128' flag. This can lead to
problems in GCC for certain use-cases. One such example is in the use
of inline assembly, whereby the inability of enabling the feature in
the command-line prevents the compiler from automatically issuing the
necessary LSE128 `.arch' directive.
This patch therefore brings GCC into alignment with LLVM and Binutils
in adding support for the `+lse128' architectural extension flag.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def: Add LSE128
AARCH64_OPT_EXTENSION, adding it as a dependency for the D128
feature.
* doc/invoke.texi (AArch64 Options): Document +lse128.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/lse128-flag.c: New.
* gcc.target/aarch64/cpunative/info_23: Likewise.
* gcc.target/aarch64/cpunative/native_cpu_23.c: Likewise.
For targets where LOGICAL_OP_NON_SHORT_CIRCUIT evaluates to false, two
conditional jumps are emitted instead of a combined conditional which
this test is all about. Thus, set it to true.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/copy-headers-8.c: Set
LOGICAL_OP_NON_SHORT_CIRCUIT to true.
Per the standard, the return type of a generators ranges iterator op*
should be the reference type rather than the yielded type.
The yielded type was used here by mistake.
libstdc++-v3/ChangeLog:
* include/std/generator (generator::_Iterator::operator*): Fix
return type.
* testsuite/24_iterators/range_generators/iter_deref_return.cc:
New test.
GCC 4.8 complained about the use of const rather than constexpr
for out-of-line static constexprs.
gcc/
* config/aarch64/aarch64-feature-deps.h: Use constexpr for
out-of-line statics.
GCC was defining bts_offset entry to always contain 0.
When comparing with clang, the same entry is instead a label to the
respective variable or function. The assembler emits relocations for
those labels.
gcc/ChangeLog:
PR target/114431
* btfout.cc (get_name_for_datasec_entry): Add function.
(btf_asm_datasec_entry): Print label when possible.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Correct for new
implementation.
* gcc.dg/debug/btf/btf-datasec-2.c: Likewise
* gcc.dg/debug/btf/btf-pr106773.c: Likewise
Apparently I've somehow screwed up the adjustments of the originally tested
testcase, tweaked it so that in the second/third cases it actually see
a MAX_EXPR rather than COND_EXPR the MAX_EXPR has been optimized into,
and didn't update the expected value.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111151
PR testsuite/114486
* gcc.c-torture/execute/pr111151.c (main): Fix up expected value for
f.
We used to hit the "Error reporting routines re-entered." ICE here but
it was fixed by Patrick's r14-3809.
PR c++/100557
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr100557.C: New test.
The SCHEDULER_IDENT for these two CPUs
was incorrectly set to cortexa55.
This can cause sub-optimal asm
to be generated.
gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
Change SCHEDULER_IDENT from cortexa55 to cortexa53
for Cortex-A510 and Cortex-A520.
Rmove the dejagnu code for checking whether std::stacktrace is supported
and just use the new dg-require-cpp-feature-test directive to check for
__cpp_lib_stacktrace instead.
libstdc++-v3/ChangeLog:
* testsuite/19_diagnostics/stacktrace/current.cc: Check for
__cpp_lib_stacktrace instead of check for stacktrace ET.
* testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/hash.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/output.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/synopsis.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/version.cc: Likewise.
* testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
Likewise.
* testsuite/lib/libstdc++.exp (check_effective_target_stacktrace):
Remove.
This adds a new dejagnu directive which can be used to make a test
depend on a feature test macro such as __cpp_lib_text_encoding. This is
mroe flexible than writing a new dg-require-xxx for each feature.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (dg-require-cpp-feature-test):
New proc.
* testsuite/lib/libstdc++.exp (check_v3_target_cpp_feature_test):
New proc.
* testsuite/std/text_encoding/cons.cc: Use new directive to skip
the test if the __cpp_lib_text_encoding feature test macro is
not defined.
* testsuite/std/text_encoding/requirements.cc: Likewise.
I've missed
FAIL: gcc.dg/torture/pr113126.c -O0 (test for excess errors)
etc. regressions on i686-linux since January. The problem is obvious
Excess errors:
.../gcc/testsuite/gcc.dg/torture/pr113126.c:11:1: warning: MMX vector return without MMX enabled changes the ABI [-Wpsabi]
and I've added -Wno-psabi to dg-additional-options to fix that up.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/torture/pr113126.c: Add -Wno-psabi as dg-additional-options.
As I've tried to explain in the comments, the extract_muldiv_1
MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
If the multiplication is done in unsigned type or in signed
type with -fwrapv, it is fairly obvious that max (a, b) * c
in many cases isn't equivalent to max (a * c, b * c) (or min if c is
negative) due to overflows, but even for signed with undefined overflow,
the optimization could turn something without UB in it (where
say a * c invokes UB, but max (or min) picks the other operand where
b * c doesn't).
As for division/modulo, I think it is in most cases safe, except if
the problematic INT_MIN / -1 case could be triggered, but we can
just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN,
we'd pick that operand already. It is just for completeness, match.pd
already has an optimization which turns x / -1 into -x, so the division
by zero is mostly theoretical. That is also why in the testcase the
i case isn't actually miscompiled without the patch, while the c and f
cases are.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111151
* fold-const.cc (extract_muldiv_1) <case MAX_EXPR>: Punt for
MULT_EXPR altogether, or for MAX_EXPR if c is -1.
* gcc.c-torture/execute/pr111151.c: New test.
Similar to the asan and ubsan changes, we shouldn't instrument non-generic
address space accesses with tsan, because we just have library functions
which take address of the objects as generic address space pointers, so they
can't handle anything else.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/111736
* tsan.cc (instrument_expr): Punt on non-generic address space
accesses.
* gcc.dg/tsan/pr111736.c: New test.
The following fixes too lax verification of vector type compatibility
in vectorizable_operation. When we only have a single vector size then
comparing the number of elements is enough but with SLP we mix those
and thus for operations like BIT_AND_EXPR we need to verify compatible
element types as well. Allow sign changes for ABSU_EXPR though.
PR tree-optimization/114471
* tree-vect-stmts.cc (vectorizable_operation): Verify operand
types are compatible with the result type.
* gcc.dg/vect/pr114471.c: New testcase.
The following adds missing verification of vector type compatibility
to recurrence vectorization.
PR tree-optimization/114464
* tree-vect-loop.cc (vectorizable_recurr): Verify the latch
vector type is compatible with what we chose for the recurrence.
* g++.dg/vect/pr114464.cc: New testcase.
I've noticed a comment typo in x86-tune.def and cfgloopmanip.cc has the
same typo as well.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
* cfgloopmanip.cc (update_loop_exit_probability_scale_dom_bbs):
Fix comment typo - multple -> multiple.
* config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS):
Likewise.
I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for warnings, line 15)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for warnings, line 37)
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 43 (test for errors, line 41)
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 (test for warnings, line 45)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/c-c++-common/gomp/depobj-3.c:37:38: warning: the 'destroy' expression ''excess_precision_expr' not supported by dump_expr<expression error>' should
+be the same as the 'depobj' argument 'obj' [-Wopenmp]
The following patch replaces that 'excess_precision_expr' not supported by dump_expr<expression error>
with (float)(((long double)a) + (long double)5)
Still ugly and doesn't actually fix the FAIL (will deal with that
incrementally), but at least valid C/C++ and shows the excess precision
handling in action.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR c++/112724
gcc/c-family/
* c-pretty-print.cc (pp_c_cast_expression,
c_pretty_printer::expression): Handle EXCESS_PRECISION_EXPR like
NOP_EXPR.
gcc/cp/
* error.cc (dump_expr): Handle EXCESS_PRECISION_EXPR like NOP_EXPR.
Arm32 predefines __ARM_FEATURE_UNALIGNED if -mno-unaligned-access,
and RISC-V predefines __riscv_misaligned_avoid.
Let's define __mips_strict_alignment for MIPSr6 and -mstrict-align
is used.
Note that, this macro is always defined for pre-R6.
gcc
* config/mips/mips.h (TARGET_CPU_CPP_BUILTINS): Predefine
__mips_strict_alignment if STRICT_ALIGNMENT.
Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong;
we're dealing with a noexcept-spec there, not a noexcept-expr, so
setting cp_noexcept_operand et al is incorrect. Back to the drawing
board then.
To fix noexcept84.C, we should probably avoid doing push_to_top_level
in certain cases. maybe_push_to_top_level didn't work here as-is, so
I changed it to not push to top level if decl_function_context is
non-null, when we are not dealing with a lambda.
This also fixes c++/114349, introduced by r14-9339.
PR c++/114349
gcc/cp/ChangeLog:
* name-lookup.cc (maybe_push_to_top_level): For a non-lambda,
don't push to top level if decl_function_context is non-null.
* pt.cc (maybe_instantiate_noexcept): Use maybe_push_to_top_level.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept85.C: New test.
* g++.dg/cpp0x/noexcept86.C: New test.
can_init_array_with_p is wrongly saying that the init for 's' here:
struct S {
int *list = arr;
int arr[];
};
struct A {
A() {}
S s[2]{};
};
is invalid. But as process_init_constructor_array says, for "non-constant
initialization of trailing elements with no explicit initializers" we use
a VEC_INIT_EXPR wrapped in a TARGET_EXPR, built in process_init_constructor.
Unfortunately we didn't have a test for this scenario so I didn't
realize can_init_array_with_p must handle it.
PR c++/114439
gcc/cp/ChangeLog:
* init.cc (can_init_array_with_p): Return true for a VEC_INIT_EXPR
wrapped in a TARGET_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/init/array65.C: New test.
This patch rebuilds the documentation for the target independent
library sections.
gcc/m2/ChangeLog:
* Make-lang.in (doc/m2.pdf): Add line break.
* target-independent/m2/Builtins.texi: Rebuilt.
* target-independent/m2/gm2-libs.texi: Rebuilt.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
This patch would like to allow the RVV intrinsic when function is
attributed as target("arch=+v") and build with rv64gc. For example:
vint32m1_t
__attribute__((target("arch=+v")))
test_1 (vint32m1_t a, vint32m1_t b, size_t vl)
{
return __riscv_vadd_vv_i32m1 (a, b, vl);
}
build with -march=rv64gc -mabi=lp64d -O3, we will have asm like below:
test_1:
.option push
.option arch, rv64i2p1_m2p0_a2p1_f2p2_d2p2_c2p0_v1p0_zicsr2p0_\
zifencei2p0_zve32f1p0_zve32x1p0_zve64d1p0_zve64f1p0_zve64x1p0_zvl128b1p0_zvl32b1p0_zvl64b1p0
vsetvli zero,a0,e32,m1,ta,ma
vadd.vv v8,v8,v9
ret
The riscv_vector.h must be included when leverage intrinisc type(s) and
API(s). And the scope of this attribute should not excced the function
body. Meanwhile, to make rvv types and API(s) available for this attribute,
include riscv_vector.h will not report error for now if v is not present
in march.
Below test are passed for this patch:
* The riscv fully regression test.
gcc/ChangeLog:
* config/riscv/riscv-c.cc (riscv_pragma_intrinsic): Remove error
when V is disabled and init the RVV types and intrinic APIs.
* config/riscv/riscv-vector-builtins.cc (expand_builtin): Report
error if V ext is disabled.
* config/riscv/riscv.cc (riscv_return_value_is_vector_type_p):
Ditto.
(riscv_arguments_is_vector_type_p): Ditto.
(riscv_vector_cc_function_p): Ditto.
* config/riscv/riscv_vector.h: Remove error if V is disable.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pragma-1.c: Remove.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-1.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-2.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-3.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-4.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-5.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-6.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-7.c: New test.
* gcc.target/riscv/rvv/base/target_attribute_v_with_intrinsic-8.c: New test.
Signed-off-by: Pan Li <pan2.li@intel.com>
This patch corrects two error format specifiers.
gcc/m2/ChangeLog:
PR modula2/114444
* gm2-compiler/M2Quads.mod (BuildTruncFunction): Correct
error format specifier.
(BuildFloatFunction): Correct error format specifier.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
This patch inserts a missing quotation at the end of a line
if required (after an appropiate error message is generated).
gcc/m2/ChangeLog:
PR modula2/114443
* m2.flex: Call AddTokCharStar with a stringtok if
end of line is reached without a closing quote.
gcc/testsuite/ChangeLog:
PR modula2/114443
* gm2/pim/fail/missingquote.mod: New test.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
gcc/analyzer/ChangeLog:
PR analyzer/114408
* engine.cc (impl_run_checkers): Free up any dominance info that
we may have created.
* kf.cc (class kf_ubsan_handler): New.
(register_sanitizer_builtins): New.
(register_known_functions): Call register_sanitizer_builtins.
gcc/testsuite/ChangeLog:
PR analyzer/114408
* c-c++-common/analyzer/deref-before-check-pr114408.c: New test.
* c-c++-common/ubsan/analyzer-ice-pr114408.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
This bug was hidden since LO_SUM DLTIND14R addresses are normally
handled by the A constraint in the move patterns.
2024-03-23 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
* config/pa/pa.cc (pa_output_global_address): Handle
UNSPEC_DLTIND14R addresses.
* config/pa/pa.h (PRINT_OPERAND_ADDRESS): Output "RT'" for
UNSPEC_DLTIND14R address.
This was just approved in Tokyo as a DR for C++23. It doesn't affect us
yet, because we don't implement the __cpp_lib_format_ranges features. We
can add the disabled specializations and add a testcase now though.
libstdc++-v3/ChangeLog:
* include/std/format (formatter): Disable specializations that
would allow sequences of narrow characters to be formatted as
wchar_t without conversion, as per LWG 3944.
* testsuite/std/format/formatter/lwg3944.cc: New test.
We already have __is_in_place_type_v for in_place_type_t so adding an
equivalent for in_place_index_t allows us avoid a class template
instantiation for the __not_in_place_tag constraint on the most
commonly-used std::variant::variant(T&&) constructor.
For in_place_type_t we also have a __is_in_place_type class template
defined in terms of the variable template, but that isn't actually used
anywhere. I'm not adding an equivalent for the new variable template,
because that wouldn't be used either.
For GCC 15 we should remove the unused __is_in_place_tag and
__is_in_place_type class templates.
libstdc++-v3/ChangeLog:
* include/bits/utility.h (__is_in_place_index_v): New variable
template.
* include/std/variant (__not_in_place_tag): Define in terms of
variable templates not a class template.
The difference between __type_identity_t and std::type_identity_t is
observable, as demonstrated in the PR. Nobody in LWG seems to think this
an example we should really care about, but it seems easy and harmless
to change this.
libstdc++-v3/ChangeLog:
PR libstdc++/114400
* include/std/string_view (operator==): Use std::type_identity_t
in C++20 instead of our own __type_identity_t.
