Iain Sandoe [Fri, 26 Jan 2024 15:23:19 +0000 (15:23 +0000)]
testsuite, ubsan: Add libstdc++ deps where required.
We use the ubsan tests from both C, C++, D and Fortran.
thee sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver, and the target might
require a path to the libstdc++ (e.g. for handing -static-xxxx or
for embedded runpaths), we need to add a suitable option (or we get
fails at execution time because of the missing paths).
Conversely, we do not want to add multiple instances of these
paths (since that leads to failures on tools that report warnings
for duplicate runpaths).
This patch modifies the _init function to allow a sigle parameter
that determines whether the *asan_init should add a path for
libstdc++ (yes for C driver, no for C++ driver).
gcc/testsuite/ChangeLog:
* g++.dg/ubsan/ubsan.exp:Add a parameter to init to say that
we expect the C++ driver to provide paths for libstdc++.
* gcc.dg/ubsan/ubsan.exp: Add a parameter to init to say that
we need a path added for libstdc++.
* gdc.dg/ubsan/ubsan.exp: Likewise.
* gfortran.dg/ubsan/ubsan.exp: Likewise.
* lib/ubsan-dg.exp: Handle a single parameter to init that
requests addition of a path to libstdc++ to link flags.
Iain Sandoe [Fri, 26 Jan 2024 15:22:44 +0000 (15:22 +0000)]
testsuite, asan, hwsan: Add libstdc++ deps where required.
We use the shared asan/hwasan rom both C,C++,D and Fortran.
The sanitizer libraries link to libstdc++.
When we are using the C/gdc/gfortran driver, and the target might
require a path to the libstdc++ (e.g. for handing -static-xxxx or
for embedded runpaths), we need to add a suitable option (or we get
fails at execution time because of the missing paths).
Conversely, we do not want to add multiple instances of these
paths (since that leads to failures on tools that report warnings
for duplicate runpaths).
This patch modifies the _init function to allow a single parameter
that determines whether the *asan_init should add a path for
libstdc++ (yes for C driver, no for C++ driver).
gcc/testsuite/ChangeLog:
* g++.dg/asan/asan.exp: Add a parameter to init to say that
we expect the C++ driver to provide paths for libstdc++.
* g++.dg/hwasan/hwasan.exp: Likewise
* gcc.dg/asan/asan.exp: Add a parameter to init to say that
we need a path added for libstdc++.
* gcc.dg/hwasan/hwasan.exp: Likewise.
* gdc.dg/asan/asan.exp: Likewise.
* gfortran.dg/asan/asan.exp: Likewise.
* lib/asan-dg.exp: Handle a single parameter to init that
requests addition of a path to libstdc++ to link flags.
* lib/hwasan-dg.exp: Likewise.
Jonathan Wakely [Fri, 2 Feb 2024 10:03:12 +0000 (10:03 +0000)]
libstdc++: Make std::function deduction guide support explicit object functions [PR113335]
This makes the deduction guides for std::function and std::packaged_task
work for explicit object member functions, i.e. "deducing this", as per
LWG 3617.
libstdc++-v3/ChangeLog:
PR libstdc++/113335
* include/bits/std_function.h (__function_guide_helper): Add
partial specialization for explicit object member functions, as
per LWG 3617.
* testsuite/20_util/function/cons/deduction_c++23.cc: Check
explicit object member functions.
* testsuite/30_threads/packaged_task/cons/deduction_c++23.cc:
Likewise.
Jakub Jelinek [Fri, 2 Feb 2024 10:46:34 +0000 (11:46 +0100)]
libgcc: Export XF, TF, HF and BFmode specific _BitInt symbols from libgcc_s.so.1 [PR113700]
Rainer pointed out that __PFX__ and __FIXPTPFX__ prefix replacement is done
solely for libgcc-std.ver.in and not for the *.ver files in config.
I've used the __PFX__ prefix even in config/i386/libgcc-glibc.ver because it
was used for similar symbols in libgcc-std.ver.in, and that results in those
symbols being STB_LOCAL in libgcc_s.so.1. Tests still work because gcc by
default uses -static-libgcc when linking (unlike g++ etc.), but would
have failed when using -shared-libgcc (but I see nothing in the testsuite
actually testing with -shared-libgcc, so am not adding tests).
With the patch, libgcc_s.so.1 now exports
__fixtfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__fixxfbitint@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitintbf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitinthf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitinttf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
__floatbitintxf@@GCC_14.0.0 FUNC GLOBAL DEFAULT
on x86_64-linux which it wasn't before.
2024-02-02 Jakub Jelinek <jakub@redhat.com>
PR target/113700
* config/i386/libgcc-glibc.ver (GCC_14.0.0): Remove __PFX prefixes
from symbol names.
Jakub Jelinek [Fri, 2 Feb 2024 10:28:31 +0000 (11:28 +0100)]
lower-bitint: Handle casts from large/huge _BitInt to pointer/reference types [PR113692]
I thought one needs to cast first to pointer-sized integer before casting to
pointer, but apparently that is not the case.
So the following patch arranges for the large/huge _BitInt to
pointer/reference conversions to use the same code as for conversions
of them to small integral types.
2024-02-02 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113692
* gimple-lower-bitint.cc (bitint_large_huge::lower_stmt): Handle casts
from large/huge BITINT_TYPEs to POINTER_TYPE/REFERENCE_TYPE as
final_cast_p.
Jakub Jelinek [Fri, 2 Feb 2024 10:27:37 +0000 (11:27 +0100)]
lower-bitint: Handle uninitialized large/huge SSA_NAMEs as inline asm inputs [PR113699]
Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME
arguments, var_to_partition will not work for those, but unlike calls
where we just create a new uninitialized SSA_NAME here we need to change
the inline asm input to be an uninitialized VAR_DECL.
Jonathan Wakely [Thu, 1 Feb 2024 10:08:05 +0000 (10:08 +0000)]
libstdc++: Implement some missing functions for net::ip::network_v6
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v6::network): Define.
(network_v6::hosts): Finish implementing.
(network_v6::to_string): Do not concatenate std::string to
arbitrary std::basic_string specialization.
* testsuite/experimental/net/internet/network/v6/cons.cc: New
test.
Jonathan Wakely [Wed, 31 Jan 2024 10:41:49 +0000 (10:41 +0000)]
libstdc++: Avoid reusing moved-from iterators in PSTL tests [PR90276]
The reverse_invoker utility for PSTL tests uses forwarding references for
all parameters, but some of those parameters get forwarded to move
constructors which then leave the objects in a moved-from state. When
the parameters are forwarded a second time that results in making new
copies of moved-from iterators. For libstdc++ debug mode iterators, the
moved-from state is singular, which means copying them will abort at
runtime.
The fix is to make copies of iterator arguments instead of forwarding
them.
The callers of reverse_invoker::operator() also forward the iterators
multiple times, but that's OK because reverse_invoker accepts them by
forwarding reference but then breaks the chain of forwarding and copies
them as lvalues.
libstdc++-v3/ChangeLog:
PR libstdc++/90276
* testsuite/util/pstl/test_utils.h (reverse_invoker): Do not use
perfect forwarding for iterator arguments.
This change broke bootstrap on aarch64-linux.
The problem can be seen even on the reduced testcase.
The IL on the unreduced testcase before widening_mul has:
# val_583 = PHI <val_26(13), val_164(40)>
...
pretmp_266 = MEM[(const struct wide_int_storage *)&D.160657].len;
_264 = pretmp_266 & 65535;
...
_176 = (sizetype) val_583;
_439 = (sizetype) _264;
_284 = _439 * 8;
_115 = _176 + _284;
where 583/266/264 have unsigned int type and 176/439/284/115 have sizetype.
widening_mul first turns that into:
# val_583 = PHI <val_26(13), val_164(40)>
...
pretmp_266 = MEM[(const struct wide_int_storage *)&D.160657].len;
_264 = pretmp_266 & 65535;
...
_176 = (sizetype) val_583;
_439 = (sizetype) _264;
_284 = _264 w* 8;
_115 = _176 + _284;
and then is_widening_mult_rhs_p is called, with type sizetype (64-bit),
rhs _264, hprec 32 and prec 64. Now tree_nonzero_bits (rhs) is
65535, so bits is 64-bit wide_int 65535, stmt is BIT_AND_EXPR,
but we ICE on the
wi::to_wide (gimple_assign_rhs2 (stmt)) == wi::mask (hprec, false, prec)
comparison because wi::to_wide on gimple_assign_rhs2 (stmt) - unsigned int
65535 gives 32-bit wide_int 65535, while wi::mask (hprec, false, prec)
gives 64-bit wide_int 0xffffffff and comparison between different precision
wide_ints is forbidden.
The following patch fixes it the same way how bits is computed earlier,
by calling wide_int::from on the wi::to_wide (gimple_assign_rhs2 (stmt)),
so we compare 64-bit 65535 with 64-bit 0xffffffff.
2024-02-02 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113705
* tree-ssa-math-opts.cc (is_widening_mult_rhs_p): Use wide_int_from
around wi::to_wide in order to compare value in prec precision.
The problem is that /bin/as doesn't fully support cfi directives, so the
.eh_frame section is specified explicitly, which includes ".long 0".
The regular expression above includes ".*", which does multiline
matches. AFAICS those aren't needed here.
This patch changes the RE not to use multiline patches.
Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.
Jonathan Wakely [Thu, 1 Feb 2024 21:40:33 +0000 (21:40 +0000)]
libstdc++: Allow explicit conversion of string views with different traits
This was changed by LWG 3857.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(R&&)): Remove
constraint that traits_type must be the same, as per LWG 3857.
* testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc:
Explicit conversion between different specializations should be
allowed.
* testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc:
Likewise.
Jonathan Wakely [Thu, 1 Feb 2024 21:15:20 +0000 (21:15 +0000)]
libstdc++: Remove noexcept from std::generator::promise_type::yield_value
This overload of std::generator::promise_type::yield_value calls things
which might throw, so should not be noexcept. The noexcept was remove by
LWG 3894.
libstdc++-v3/ChangeLog:
* include/std/generator (promise_type::yield_value): Remove
noexcept from fourth overload, as per LWG 3894.
Iain Sandoe [Wed, 24 Jan 2024 08:05:41 +0000 (08:05 +0000)]
testsuite, Objective-C++: Update link flags [PR112863].
These regressions are caused by missing or duplicate runpaths which
now fire linker warnings.
We need to add options to locate libobjc (and on Darwin libobjc-gnu)
along with libstdc++.
Usually '-L' options are added to point to the relevant directories for
the uninstalled libraries.
In cases where libraries are available as both shared and convenience
some additional checks are made.
For some targets -static-xxxx options are handled by specs substitution
and need a '-B' option rather than '-L'. For Darwin, when embedded
runpaths are in use (the default for all versions after macOS 10.11),
'-B' is also needed to provide the runpath.
When '-B' is used, this results in a '-L' for each path that exists (so
that appending a '-L' as well is a needless duplicate). There are also
cases where tools warn for duplicates, leading to spurious fails.
PR target/112863
gcc/testsuite/ChangeLog:
* lib/obj-c++.exp: Decide on whether to present -B or -L to
reference the paths to uninstalled libobjc/libobjc-gnu and
libstdc++ and use that to generate the link flags.
Iain Sandoe [Wed, 24 Jan 2024 08:05:30 +0000 (08:05 +0000)]
testsuite, gfortran: Update link flags [PR112862].
The regressions here are caused by two issues:
1. In some cases there is no generated runpath for libatomic
2. In other cases there are duplicate paths.
This patch simplifies the addition of the options in the main
gfortran exp and removes the duplicates elewhere.
We need to add options to locate libgfortran and the dependent libs
libquadmath (supporting REAL*16) and libatomic (supporting operations
used by coarrays). Usually '-L' options are added to point to the
relevant directories for the uninstalled libraries.
In cases where libraries are available as both shared and convenience
some additional checks are made.
For some targets -static-xxxx options are handled by specs substitution
and need a '-B' option rather than '-L'. For Darwin, when embedded
runpaths are in use (the default for all versions after macOS 10.11),
'-B' is also needed to provide the runpath.
When '-B' is used, this results in a '-L' for each path that exists (so
that appending a '-L' as well is a needless duplicate). There are also
cases where tools warn for duplicates, leading to spurious fails.
PR target/112862
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/caf.exp: Remove duplicate additions of
libatomic handling.
* gfortran.dg/dg.exp: Likewise.
* lib/gfortran.exp: Decide on whether to present -B or -L to
reference the paths to uninstalled libgfortran, libqadmath and
libatomic and use that to generate the link flags.
Realize in recent benchmark evaluation (coremark-pro zip-test):
vid.v v2
vmv.v.i v5,0
.L9:
vle16.v v3,0(a4)
vrsub.vx v4,v2,a6 ---> LICM failed to hoist it outside the loop.
The root cause is:
(insn 56 47 57 4 (set (subreg:DI (reg:HI 220) 0)
(reg:DI 223)) "rvv.c":11:9 208 {*movdi_64bit} -> Its result used by the following vrsub.vx then supress the hoist of the vrsub.vx
(nil))
Jason Merrill [Thu, 1 Feb 2024 22:23:53 +0000 (17:23 -0500)]
c++: no_unique_address and constexpr [PR112439]
Here, because we don't build a CONSTRUCTOR for an empty base, we were
wrongly marking the Foo CONSTRUCTOR as complete after initializing the Empty
member. Fixed by checking empty_base here as well.
PR c++/112439
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_store_expression): Check empty_base
before marking a CONSTRUCTOR readonly.
Li Wei [Fri, 26 Jan 2024 08:41:11 +0000 (16:41 +0800)]
LoongArch: Adjust cost of vector_stmt that match multiply-add pattern.
We found that when only 128-bit vectorization was enabled, 549.fotonik3d_r
failed to vectorize effectively. For this reason, we adjust the cost of
128-bit vector_stmt that match the multiply-add pattern to facilitate 128-bit
vectorization.
The experimental results show that after the modification, 549.fotonik3d_r
performance can be improved by 9.77% under the 128-bit vectorization option.
Xi Ruoyao [Mon, 29 Jan 2024 07:20:07 +0000 (15:20 +0800)]
LoongArch: Don't split the instructions containing relocs for extreme code model.
The ABI mandates the pcalau12i/addi.d/lu32i.d/lu52i.d instructions for
addressing a symbol to be adjacent. So model them as "one large
instruction", i.e. define_insn, with two output registers. The real
address is the sum of these two registers.
The advantage of this approach is the RTL passes can still use ldx/stx
instructions to skip an addi.d instruction.
gcc/ChangeLog:
* config/loongarch/loongarch.md (unspec): Add
UNSPEC_LA_PCREL_64_PART1 and UNSPEC_LA_PCREL_64_PART2.
(la_pcrel64_two_parts): New define_insn.
* config/loongarch/loongarch.cc (loongarch_tls_symbol): Fix a
typo in the comment.
(loongarch_call_tls_get_addr): If -mcmodel=extreme
-mexplicit-relocs={always,auto}, use la_pcrel64_two_parts for
addressing the TLS symbol and __tls_get_addr. Emit an REG_EQUAL
note to allow CSE addressing __tls_get_addr.
(loongarch_legitimize_tls_address): If -mcmodel=extreme
-mexplicit-relocs={always,auto}, address TLS IE symbols with
la_pcrel64_two_parts.
(loongarch_split_symbol): If -mcmodel=extreme
-mexplicit-relocs={always,auto}, address symbols with
la_pcrel64_two_parts.
(loongarch_output_mi_thunk): Clean up unreachable code. If
-mcmodel=extreme -mexplicit-relocs={always,auto}, address the MI
thunks with la_pcrel64_two_parts.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/func-call-extreme-1.c (dg-options):
Use -O2 instead of -O0 to ensure the pcalau12i/addi/lu32i/lu52i
instruction sequences are not reordered by the compiler.
(NOIPA): Disallow interprocedural optimizations.
* gcc.target/loongarch/func-call-extreme-2.c: Remove the content
duplicated from func-call-extreme-1.c, include it instead.
(dg-options): Likewise.
* gcc.target/loongarch/func-call-extreme-3.c (dg-options):
Likewise.
* gcc.target/loongarch/func-call-extreme-4.c (dg-options):
Likewise.
* gcc.target/loongarch/cmodel-extreme-1.c: New test.
* gcc.target/loongarch/cmodel-extreme-2.c: New test.
* g++.target/loongarch/cmodel-extreme-mi-thunk-1.C: New test.
* g++.target/loongarch/cmodel-extreme-mi-thunk-2.C: New test.
* g++.target/loongarch/cmodel-extreme-mi-thunk-3.C: New test.
Lulu Cheng [Fri, 26 Jan 2024 02:46:51 +0000 (10:46 +0800)]
LoongArch: Enable explicit reloc for extreme TLS GD/LD with -mexplicit-relocs=auto.
Binutils does not support relaxation using four instructions to obtain
symbol addresses
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_explicit_relocs_p):
When the code model of the symbol is extreme and -mexplicit-relocs=auto,
the macro instruction loading symbol address is not applicable.
(loongarch_call_tls_get_addr): Adjust code.
(loongarch_legitimize_tls_address): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/explicit-relocs-extreme-auto-tls-ld-gd.c: New test.
* gcc.target/loongarch/explicit-relocs-medium-auto-tls-ld-gd.c: New test.
Lulu Cheng [Thu, 25 Jan 2024 11:10:46 +0000 (19:10 +0800)]
LoongArch: Add the macro implementation of mcmodel=extreme.
gcc/ChangeLog:
* config/loongarch/loongarch-protos.h (loongarch_symbol_extreme_p):
Add function declaration.
* config/loongarch/loongarch.cc (loongarch_symbolic_constant_p):
For SYMBOL_PCREL64, non-zero addend of "la.local $rd,$rt,sym+addend"
is not allowed
(loongarch_load_tls): Added macro support in extreme mode.
(loongarch_call_tls_get_addr): Likewise.
(loongarch_legitimize_tls_address): Likewise.
(loongarch_force_address): Likewise.
(loongarch_legitimize_move): Likewise.
(loongarch_output_mi_thunk): Likewise.
(loongarch_option_override_internal): Remove the code that detects
explicit relocs status.
(loongarch_handle_model_attribute): Likewise.
* config/loongarch/loongarch.md (movdi_symbolic_off64): New template.
* config/loongarch/predicates.md (symbolic_off64_operand): New predicate.
(symbolic_off64_or_reg_operand): Likewise.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/attr-model-5.c: New test.
* gcc.target/loongarch/func-call-extreme-5.c: New test.
* gcc.target/loongarch/func-call-extreme-6.c: New test.
* gcc.target/loongarch/tls-extreme-macro.c: New test.
Lulu Cheng [Tue, 30 Jan 2024 07:02:32 +0000 (15:02 +0800)]
LoongArch: Modify the address calculation logic for obtaining array element values through fp.
Modify address calculation logic from (((a x C) + fp) + offset) to ((fp + offset) + a x C).
Thereby modifying the register dependencies and optimizing the code.
The value of C is 2 4 or 8.
The following is the assembly code before and after a loop modification in spec2006 401.bzip:
Marek Polacek [Thu, 1 Feb 2024 21:11:43 +0000 (16:11 -0500)]
c++: -Wdangling-reference tweak to unbreak aarch64
My recent -Wdangling-reference change to not warn on std::span-like classes
unfortunately caused a new warning: extending reference_like_class_p also
opens the door to new warnings since we use reference_like_class_p for
checking the return type of the function: either it must be a reference
or a reference_like_class_p.
We can consider even non-templates as std::span-like to get rid of the
warning here.
gcc/cp/ChangeLog:
* call.cc (reference_like_class_p): Consider even non-templates for
std::span-like classes.
The fix for PR70321 introduced a splitter that split a doubleword
comparison into a pair of XORs followed by an IOR to set the (zero)
flags register. To help the reload, splitter forced SUBREG pieces of
double-word input values to a pseudo, but this regressed
gcc.target/i386/pr82580.c:
To mitigate the regression, remove this legacy heuristic (workaround?).
There have been many incremental changes and improvements to x86 TImode
and register allocation, so this legacy workaround is not only no longer
useful, but it actually hurts register allocation. The patched compiler
now produces:
Jakub Jelinek [Thu, 1 Feb 2024 20:07:01 +0000 (21:07 +0100)]
libgcc: Avoid warnings on __gcc_nested_func_ptr_created [PR113402]
I'm seeing hundreds of
In file included from ../../../libgcc/libgcc2.c:56:
../../../libgcc/libgcc2.h:32:13: warning: conflicting types for built-in function ‘__gcc_nested_func_ptr_created’; expected ‘void(void *, void *, void *)’
+[-Wbuiltin-declaration-mismatch]
32 | extern void __gcc_nested_func_ptr_created (void *, void *, void **);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
warnings.
Either we need to add like in r14-6218
#pragma GCC diagnostic ignored "-Wbuiltin-declaration-mismatch"
(but in that case because of the libgcc2.h prototype (why is it there?)
it would need to be also with #pragma GCC diagnostic push/pop around),
or we could go with just following how the builtins are prototyped on the
compiler side and only cast to void ** when dereferencing (which is in
a single spot in each TU).
2024-02-01 Jakub Jelinek <jakub@redhat.com>
PR libgcc/113402
* libgcc2.h (__gcc_nested_func_ptr_created): Change type of last
argument from void ** to void *.
* config/i386/heap-trampoline.c (__gcc_nested_func_ptr_created):
Change type of dst from void ** to void * and cast dst to void **
before dereferencing it.
* config/aarch64/heap-trampoline.c (__gcc_nested_func_ptr_created):
Likewise.
Patrick Palka [Thu, 1 Feb 2024 19:59:46 +0000 (14:59 -0500)]
libstdc++: Implement P2165R4 changes to std::pair/tuple/etc [PR113309]
This implements the C++23 paper P2165R4 Compatibility between tuple,
pair and tuple-like objects, which builds upon many changes from the
earlier C++23 paper P2321R2 zip.
Some declarations had to be moved around so that they're visible from
<bits/stl_pair.h> without introducing new includes and bloating the
header. In the end, the only new include is for <bits/utility.h> from
<bits/stl_iterator.h>, for tuple_element_t.
PR libstdc++/113309
PR libstdc++/109203
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (__detail::__pair_like): Don't
define in C++23 mode.
(__detail::__pair_like_convertible_from): Adjust as per P2165R4.
(__detail::__is_subrange<subrange>): Moved from <ranges>.
(__detail::__is_tuple_like_v<subrange>): Likewise.
* include/bits/stl_iterator.h: Include <bits/utility.h> for
C++23.
(__different_from): Move to <concepts>.
(__iter_key_t): Adjust for C++23 as per P2165R4.
(__iter_val_t): Likewise.
* include/bits/stl_pair.h (pair, array): Forward declare.
(get): Forward declare all overloads relevant to P2165R4
tuple-like constructors.
(__is_tuple_v): Define for C++23.
(__is_tuple_like_v): Define for C++23.
(__tuple_like): Define for C++23 as per P2165R4.
(__pair_like): Define for C++23 as per P2165R4.
(__eligibile_tuple_like): Define for C++23.
(__eligibile_pair_like): Define for C++23.
(pair::_S_constructible_from_pair_like): Define for C++23.
(pair::_S_convertible_from_pair_like): Define for C++23.
(pair::_S_dangles_from_pair_like): Define for C++23.
(pair::pair): Define overloads taking a tuple-like type for
C++23 as per P2165R4.
(pair::_S_assignable_from_tuple_like): Define for C++23.
(pair::_S_const_assignable_from_tuple_like): Define for C++23.
(pair::operator=): Define overloads taking a tuple-like type for
C++23 as per P2165R4.
* include/bits/utility.h (ranges::__detail::__is_subrange):
Moved from <ranges>.
* include/bits/version.def (tuple_like): Define for C++23.
* include/bits/version.h: Regenerate.
* include/std/concepts (__different_from): Moved from
<bits/stl_iterator.h>.
(ranges::__swap::__adl_swap): Clarify which __detail namespace.
* include/std/map (__cpp_lib_tuple_like): Define C++23.
* include/std/ranges (__detail::__is_subrange): Moved to
<bits/utility.h>.
(__detail::__is_subrange<subrange>): Moved to <bits/ranges_util.h>
(__detail::__has_tuple_element): Adjust for C++23 as per P2165R4.
(__detail::__tuple_or_pair): Remove as per P2165R4. Replace all
uses with plain tuple as per P2165R4.
* include/std/tuple (__cpp_lib_tuple_like): Define for C++23.
(__tuple_like_tag_t): Define for C++23.
(__tuple_cmp): Forward declare for C++23.
(_Tuple_impl::_Tuple_impl): Define overloads taking
__tuple_like_tag_t and a tuple-like type for C++23.
(_Tuple_impl::_M_assign): Likewise.
(tuple::__constructible_from_tuple_like): Define for C++23.
(tuple::__convertible_from_tuple_like): Define for C++23.
(tuple::__dangles_from_tuple_like): Define for C++23.
(tuple::tuple): Define overloads taking a tuple-like type for
C++23 as per P2165R4.
(tuple::__assignable_from_tuple_like): Define for C++23.
(tuple::__const_assignable_from_tuple_like): Define for C++23.
(tuple::operator=): Define overloads taking a tuple-like type
for C++23 as per P2165R4.
(tuple::__tuple_like_common_comparison_category): Define for C++23.
(tuple::operator<=>): Define overload taking a tuple-like type
for C++23 as per P2165R4.
(array, get): Forward declarations moved to <bits/stl_pair.h>.
(tuple_cat): Constrain with __tuple_like for C++23 as per P2165R4.
(apply): Likewise.
(make_from_tuple): Likewise.
(__tuple_like_common_reference): Define for C++23.
(basic_common_reference): Adjust as per P2165R4.
(__tuple_like_common_type): Define for C++23.
(common_type): Adjust as per P2165R4.
* include/std/unordered_map (__cpp_lib_tuple_like): Define for
C++23.
* include/std/utility (__cpp_lib_tuple_like): Define for C++23.
* testsuite/std/ranges/zip/1.cc (test01): Adjust to handle pair
and 2-tuple interchangeably.
(test05): New test.
* testsuite/20_util/pair/p2165r4.cc: New test.
* testsuite/20_util/tuple/p2165r4.cc: New test.
The first alternative stores the floating-point status register
in the destination. It should store zero. We need to copy %fr0
to another floating-point register to initialize it to zero.
2024-02-01 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
* config/pa/pa.md (atomic_storedi_1): Fix bug in
alternative 1.
Patrick Palka [Thu, 1 Feb 2024 18:17:48 +0000 (13:17 -0500)]
c++: ttp TEMPLATE_DECL equivalence [PR112737]
Here during declaration matching we undesirably consider the two TT{42}
CTAD expressions to be non-equivalent ultimately because for CTAD
placeholder equivalence we compare the TEMPLATE_DECLs via pointer identity,
and here the corresponding TEMPLATE_DECLs for TT are different since
they're from different scopes. On the other hand, the corresponding
TEMPLATE_TEMPLATE_PARMs are deemed equivalent according to cp_tree_equal
(since they have the same position and template parameters). This turns
out to be the root cause of some of the xtreme-header modules regressions.
So this patch relaxes ttp CTAD placeholder equivalence accordingly, by
comparing the TEMPLATE_TEMPLATE_PARM instead of the TEMPLATE_DECL. It
turns out this issue also affects function template-id equivalence as
with g<TT> in the second testcase, so it makes sense to relax TEMPLATE_DECL
equivalence more generally in cp_tree_equal. In passing this patch
improves ctp_hasher::hash for CTAD placeholders, so that they don't
all get the same hash.
PR c++/112737
gcc/cp/ChangeLog:
* pt.cc (iterative_hash_template_arg) <case TEMPLATE_DECL>:
Adjust hashing to match cp_tree_equal.
(ctp_hasher::hash): Also hash CLASS_PLACEHOLDER_TEMPLATE.
* tree.cc (cp_tree_equal) <case TEMPLATE_DECL>: Return true
for ttp TEMPLATE_DECLs if their TEMPLATE_TEMPLATE_PARMs are
equivalent.
* typeck.cc (structural_comptypes) <case TEMPLATE_TYPE_PARM>:
Use cp_tree_equal to compare CLASS_PLACEHOLDER_TEMPLATE.
gcc/testsuite/ChangeLog:
* g++.dg/template/ttp42.C: New test.
* g++.dg/template/ttp43.C: New test.
Richard Ball [Thu, 1 Feb 2024 17:18:28 +0000 (17:18 +0000)]
middle-end: Fix ICE in poly-int.h due to SLP.
Adds a check to ensure that the input vector arguments
to a function are not variable length. Previously, only the
output vector of a function was checked.
The ICE in question is within the neon-sve-bridge.c test,
and is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268
gcc/ChangeLog:
PR tree-optimization/111268
* tree-vect-slp.cc (vectorizable_slp_permutation_1):
Add variable-length check for vector input arguments
to a function.
Jonathan Wakely [Thu, 1 Feb 2024 11:05:52 +0000 (11:05 +0000)]
libstdc++: Do not use def-file-line for each macro in <bits/version.h>
These line markers are not needed, because searching <bits/version.def>
for a macro name works fine. Removing them means that small changes to
<bits/version.def> do not result in large diffs to <bits/version.h>
because of all the changed line numbers.
libstdc++-v3/ChangeLog:
* include/bits/version.tpl: Do not use def-file-line for each
macro being defined.
* include/bits/version.h: Regenerate.
Jonathan Wakely [Tue, 23 Jan 2024 15:35:29 +0000 (15:35 +0000)]
libstdc++: Fix -Wdeprecated warning about implicit capture of 'this'
In C++20 it's deprecated for a [=] lambda capture to capture the 'this'
pointer. Using resize_and_overwrite with a lambda seems like overkill to
write three chars to the string anyway. Just resize the string and
overwrite the end of it directly.
libstdc++-v3/ChangeLog:
* include/experimental/internet (network_v4::to_string()):
Remove lambda and use of resize_and_overwrite.
Thomas Schwinge [Wed, 31 Jan 2024 10:56:59 +0000 (11:56 +0100)]
GCN: Don't hard-code number of SGPR/VGPR/AVGPR registers
Also add 'STATIC_ASSERT's for number of SGPR/VGPR/AVGPR registers (in
'#ifndef USED_FOR_TARGET', as otherwise 'STATIC_ASSERT' isn't available).
gcc/
* config/gcn/gcn.cc (gcn_hsa_declare_function_name): Don't
hard-code number of SGPR/VGPR/AVGPR registers.
* config/gcn/gcn.h: Add a 'STATIC_ASSERT's for number of
SGPR/VGPR/AVGPR registers.
Lewis Hyatt [Wed, 31 Jan 2024 20:50:11 +0000 (15:50 -0500)]
libcpp: Stabilize the location for macros restored after PCH load [PR105608]
libcpp currently lacks the infrastructure to assign correct locations to
macros that were defined prior to loading a PCH and then restored
afterwards. While I plan to address that fully for GCC 15, this patch
improves things by using at least a valid location, even if it's not the
best one. Without this change, libcpp uses pfile->directive_line as the
location for the restored macros, but this location_t applies to the old
line map, not the one that was just restored from the PCH, so the resulting
location is unpredictable and depends on what was stored in the line maps
before. With this change, all restored macros get assigned locations at the
line of the #include that triggered the PCH restore. A future patch will
store the actual file name and line number of each definition and then
synthesize locations in the new line map pointing to the right place.
gcc/c-family/ChangeLog:
PR preprocessor/105608
* c-pch.cc (c_common_read_pch): Adjust line map so that libcpp
assigns a location to restored macros which is the same location
that triggered the PCH include.
libcpp/ChangeLog:
PR preprocessor/105608
* pch.cc (cpp_read_state): Set a valid location for restored
macros.
Monk Chiang [Thu, 1 Feb 2024 03:01:20 +0000 (11:01 +0800)]
RISC-V: Support scheduling for sifive p600 series
Add sifive p600 series scheduler module. For more information
see https://www.sifive.com/cores/performance-p650-670.
Add sifive-p650, sifive-p670 for mcpu option will come in separate patches.
gcc/ChangeLog:
* config/riscv/riscv.md: Add "fcvt_i2f", "fcvt_f2i" type
attribute, and include sifive-p600.md.
* config/riscv/generic-ooo.md: Update type attribute.
* config/riscv/generic.md: Update type attribute.
* config/riscv/sifive-7.md: Update type attribute.
* config/riscv/sifive-p600.md: New file.
* config/riscv/riscv-cores.def (RISCV_TUNE): Add parameter.
* config/riscv/riscv-opts.h (enum riscv_microarchitecture_type):
Add sifive_p600.
* config/riscv/riscv.cc (sifive_p600_tune_info): New.
* config/riscv/riscv.h (TARGET_SFB_ALU): Update.
* doc/invoke.texi (RISC-V Options): Add sifive-p600-series
Monk Chiang [Thu, 1 Feb 2024 09:14:18 +0000 (17:14 +0800)]
RISC-V: Add minimal support for 7 new unprivileged extensions
The RISC-V Profiles specification here:
https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc#7-new-isa-extensions
These extensions don't add any new features but
describe existing features. So this patch only adds parsing.
Za64rs: Reservation set size of 64 bytes
Za128rs: Reservation set size of 128 bytes
Ziccif: Main memory supports instruction fetch with atomicity requirement
Ziccrse: Main memory supports forward progress on LR/SC sequences
Ziccamoa: Main memory supports all atomics in A
Zicclsm: Main memory supports misaligned loads/stores
Zic64b: Cache block size isf 64 bytes
This happens because libasan makes unportable assumptions about
initialization order that don't hold on Solaris. The problem has
already been fixed in clang by
[Driver] Link shared asan runtime lib with -z now on Solaris/x86
https://reviews.llvm.org/D156325
where it was way more prevalent.
This patch applies the same fix to gcc.
Tested on i386-pc-solaris2.11 (ld and gld) and sparc-sun-solaris2.11.
For OpenACC/GCN '-march=gfx1100', a lot of libgomp OpenACC test cases FAIL:
/tmp/ccGfLJ8a.mkoffload.2.s:406:2: error: instruction not supported on this GPU
ds_cmpst_rtn_b32 v0, v0, v4, v3
^
In RDNA 3, 'ds_cmpst_[...]' has been replaced by 'ds_cmpstore_[...]', and the
notes for 'ds_cmpst_[...]' in pre-RDNA 3 ISA manuals:
Caution, the order of src and cmp are the *opposite* of the BUFFER_ATOMIC_CMPSWAP opcode.
..., have been resolved for 'ds_cmpstore_[...]' in the RDNA 3 ISA manual:
In this architecture the order of src and cmp agree with the BUFFER_ATOMIC_CMPSWAP opcode.
..., and therefore '%2', '%3' now swapped with regards to GCC operand order.
Most of the affected libgomp OpenACC test cases then PASS their execution test.
Gaius Mulley [Thu, 1 Feb 2024 10:24:02 +0000 (10:24 +0000)]
PR modula2/111627 defend against ICE
Although PR 111627 can be fixed by renaming testsuite modules it
highlighted that a possible ICE can occur if a malformed
implementation module is actually a program module. This small
patch defends against this ICE and checks to see whether the module
is a DefImp before testing IsDefinitionForC.
gcc/m2/ChangeLog:
PR modula2/111627
PR modula2/112506
* gm2-compiler/M2Comp.mod (Pass0CheckMod): Test IsDefImp before
checking IsDefinitionForC.
Richard Biener [Thu, 1 Feb 2024 08:18:47 +0000 (09:18 +0100)]
tree-optimization/113693 - LC SSA and region VN
The following fixes LC SSA preserving with region VN which was broken
when availability checking was enhanced to treat not visited value
numbers as available. The following makes sure to honor availability
data we put in place for LC SSA preserving instead.
PR tree-optimization/113693
* tree-ssa-sccvn.cc (rpo_elim::eliminate_avail): Honor avail
data when available.
Jakub Jelinek [Thu, 1 Feb 2024 08:16:57 +0000 (09:16 +0100)]
gimple-low: Remove .ASAN_MARK calls on TREE_STATIC variables [PR113531]
Since the r14-1500-g4d935f52b0d5c0 commit we promote an initializer_list
backing array to static storage where appropriate, but this happens after
we decided to add it to asan_poisoned_variables. As a result we add
unpoison/poison for it to the gimple. But then sanopt removes the unpoison.
So the second time we call the function and want to load from the array asan
still considers it poisoned.
The following patch fixes it by removing the .ASAN_MARK internal calls
during gimple lowering if they refer to TREE_STATIC vars.
2024-02-01 Jakub Jelinek <jakub@redhat.com>
Jason Merrill <jason@redhat.com>
PR c++/113531
* gimple-low.cc (lower_stmt): Remove .ASAN_MARK calls
on variables which were promoted to TREE_STATIC.
Roger Sayle [Thu, 1 Feb 2024 06:10:42 +0000 (06:10 +0000)]
PR target/113560: Enhance is_widening_mult_rhs_p.
This patch resolves PR113560, a code quality regression from GCC12
affecting x86_64, by enhancing the middle-end's tree-ssa-math-opts.cc
to recognize more instances of widening multiplications.
The widening multiplication perception code identifies cases like:
_1 = (unsigned __int128) x;
__res = _1 * 100;
but in the reported test case, the original input looks like:
where the BIT_AND_EXPR hides (has consumed) the extension operation.
This reveals the more general deficiency (missed optimization
opportunity) in widening multiplication perception that additionally
both
should be recognized as widening multiplications. Hence rather than
test explicitly for BIT_AND_EXPR (as in the first version of this patch)
the more general solution is to make use of range information, as
provided by tree_non_zero_bits.
As a demonstration of the observed improvements, function foo above
currently with -O2 compiles on x86_64 to:
2023-02-01 Roger Sayle <roger@nextmovesoftware.com>
Richard Biener <rguenther@suse.de>
gcc/ChangeLog
PR target/113560
* tree-ssa-math-opts.cc (is_widening_mult_rhs_p): Use range
information via tree_non_zero_bits to check if this operand
is suitably extended for a widening (or highpart) multiplication.
(convert_mult_to_widen): Insert explicit casts if the RHS or LHS
isn't already of the claimed type.
gcc/testsuite/ChangeLog
PR target/113560
* g++.target/i386/pr113560.C: New test case.
* gcc.target/i386/pr113560.c: Likewise.
* gcc.dg/pr87954.c: Update test case.
Edwin Lu [Wed, 31 Jan 2024 18:45:43 +0000 (10:45 -0800)]
RISC-V: Use default cost model for insn scheduling
Use default cost model scheduling on these test cases. All these tests
introduce scan dump failures with -mtune generic-ooo. Since the vector
cost models are the same across all three tunes, some of the tests
in PR113249 will be fixed with this patch series.
Edwin Lu [Wed, 31 Jan 2024 18:43:09 +0000 (10:43 -0800)]
RISC-V: Add vector related pipelines
Creates new generic vector pipeline file common to all cpu tunes.
Moves all vector related pipelines from generic-ooo to generic-vector-ooo.
Creates new vector crypto related insn reservations.
Edwin Lu [Wed, 31 Jan 2024 18:40:15 +0000 (10:40 -0800)]
RISC-V: Add non-vector types to dfa pipelines
This patch adds non-vector related insn reservations and updates/creates
new insn reservations so all non-vector typed instructions have a reservation.
Andrew Pinski [Tue, 30 Jan 2024 08:50:56 +0000 (00:50 -0800)]
aarch64: -mstrict-align vs __arm_data512_t [PR113657]
After r14-1187-gd6b756447cd58b, simplify_gen_subreg can return
NULL for "unaligned" memory subreg. Since V8DI has an alignment of 8 bytes,
using TImode causes simplify_gen_subreg to return NULL.
This fixes the issue by using DImode instead for the loop. And then we will have
later on the STP/LDP pass combine it back into STP/LDP if needed.
Since strict align is less important (usually used for firmware and early boot only),
not doing LDP/STP here is ok.
Built and tested for aarch64-linux-gnu with no regressions.
PR target/113657
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (split for movv8di):
For strict aligned mode, use DImode instead of TImode.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/acle/ls64_strict_align.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
David Malcolm [Wed, 31 Jan 2024 23:26:26 +0000 (18:26 -0500)]
analyzer: fix skipping of debug stmts [PR113253]
PR analyzer/113253 reports a case where the analyzer output varied
with and without -g enabled.
The root cause was that debug stmts were in the
FOR_EACH_IMM_USE_FAST list for SSA names, leading to the analyzer's
state purging logic differing between the -g and non-debugging cases,
and thus leading to differences in the exploration of the user's code.
Fix by skipping such stmts in the state-purging logic, and removing
debug stmts when constructing the supergraph.
gcc/analyzer/ChangeLog:
PR analyzer/113253
* region-model.cc (region_model::on_stmt_pre): Add gcc_unreachable
for debug statements.
* state-purge.cc
(state_purge_per_ssa_name::state_purge_per_ssa_name): Skip any
debug stmts in the FOR_EACH_IMM_USE_FAST list.
* supergraph.cc (supergraph::supergraph): Don't add debug stmts
to the supernodes.
gcc/testsuite/ChangeLog:
PR analyzer/113253
* gcc.dg/analyzer/deref-before-check-pr113253.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Joseph Myers [Wed, 31 Jan 2024 21:39:53 +0000 (21:39 +0000)]
c: Fix ICE for nested enum redefinitions with/without fixed underlying type [PR112571]
Bug 112571 reports an ICE-on-invalid for cases where an enum is
defined, without a fixed underlying type, inside the enum type
specifier for a definition of that same enum with a fixed underlying
type.
The ultimate cause is attempting to access ENUM_UNDERLYING_TYPE in a
case where it is NULL. Avoid this by clearing
ENUM_FIXED_UNDERLYING_TYPE_P in thie case of inconsistent definitions.
Bootstrapped wth no regressions for x86_64-pc-linux-gnu.
PR c/112571
gcc/c/
* c-decl.cc (start_enum): Clear ENUM_FIXED_UNDERLYING_TYPE_P when
defining without a fixed underlying type an enumeration previously
declared with a fixed underlying type.
gcc/testsuite/
* gcc.dg/c23-enum-9.c, gcc.dg/c23-enum-10.c: New tests.
Marek Polacek [Tue, 30 Jan 2024 22:11:34 +0000 (17:11 -0500)]
c++: add deprecation notice for -fconcepts-ts
We plan to remove -fconcepts-ts in GCC 15 and thus remove the flag_concepts_ts
code. This note is an admonishing reminder to convert the Concepts TS
code to C++20 Concepts.
gcc/c-family/ChangeLog:
* c-opts.cc (c_common_post_options): Add an inform saying that
-fconcepts-ts is deprecated and will be removed in GCC 15.
gcc/ChangeLog:
* doc/invoke.texi: Mention that -fconcepts-ts was deprecated in GCC 14.
Gaius Mulley [Wed, 31 Jan 2024 15:44:32 +0000 (15:44 +0000)]
PR modula2/111627 Excess test fails with a case-preserving-case-insensitive source tree
This patch renames gm2 testsuite modules whose names conflict with library
modules. The conflict is not seen on case preserving case sensitive file
systems.
gcc/testsuite/ChangeLog:
PR modula2/111627
* gm2/pim/pass/stdio.mod: Moved to...
* gm2/pim/pass/teststdio.mod: ...here.
* gm2/pim/run/pass/builtins.mod: Moved to...
* gm2/pim/run/pass/testbuiltins.mod: ...here.
* gm2/pim/run/pass/math.mod: Moved to...
* gm2/pim/run/pass/testmath.mod: ...here.
* gm2/pim/run/pass/math2.mod: Moved to...
* gm2/pim/run/pass/testmath2.mod: ...here.
Tamar Christina [Wed, 31 Jan 2024 14:52:59 +0000 (14:52 +0000)]
AArch64: relax cbranch tests to accepted inverted branches [PR113502]
Recently something in the midend had started inverting the branches by inverting
the condition and the branches.
While this is fine, it makes it hard to actually test. In RTL I disable
scheduling and BB reordering to prevent this. But in GIMPLE there seems to be
nothing I can do. __builtin_expect seems to have no impact on the change since
I suspect this is happening during expand where conditions can be flipped
regardless of probability during compare_and_branch.
Since the mid-end has plenty of correctness tests, this weakens the backend
tests to just check that a correct looking sequence is emitted.
Tamar Christina [Wed, 31 Jan 2024 14:51:36 +0000 (14:51 +0000)]
hwasan: Remove testsuite check for a complaint message [PR112644]
With recent updates to hwasan runtime libraries, the error reporting for
this particular check is has been reworked.
I would question why it has lost this message. To me it looks strange
that num_descriptions_printed is incremented whenever we call
PrintHeapOrGlobalCandidate whether that function prints anything or not.
(See PrintAddressDescription in libsanitizer/hwasan/hwasan_report.cpp).
The message is no longer printed because we increment this
num_descriptions_printed variable indicating that we have found some
description.
I would like to question this upstream, but it doesn't look that much of
a problem and if pressed for time we should just change our testsuite.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Tamar Christina [Wed, 31 Jan 2024 14:50:33 +0000 (14:50 +0000)]
hwasan: instrument new memory and string functions [PR112644]
Recent libhwasan updates[1] intercept various string and memory functions.
These functions have checking in them, which means there's no need to
inline the checking.
This patch marks said functions as intercepted, and adjusts a testcase
to handle the difference. It also looks for HWASAN in a check in
expand_builtin. This check originally is there to avoid using expand to
inline the behaviour of builtins like memset which are intercepted by
ASAN and hence which we rely on the function call staying as a function
call. With the new reliance on function calls in HWASAN we need to do
the same thing for HWASAN too.
HWASAN and ASAN don't seem to however instrument the same functions.
Looking into libsanitizer/sanitizer_common/sanitizer_common_interceptors_memintrinsics.inc
it looks like the common ones are memset, memmove and memcpy.
The rest of the routines for asan seem to be defined in
compiler-rt/lib/asan/asan_interceptors.h however compiler-rt/lib/hwasan/
does not have such a file but it does have
compiler-rt/lib/hwasan/hwasan_platform_interceptors.h which it looks like is
forcing off everything but memset, memmove, memcpy, memcmp and bcmp.
As such I've taken those as the final list that hwasan currently supports.
This also means that on future updates this list should be cross checked.
As mentioned in the PR the last sync brought in a bug from upstream[1] where
operations became non-recoverable and as such the tests in AArch64 started
failing. This cherry picks the fix and there are minor updates needed to GCC
after this to fix the cases.
The following fixes a wrong pattern that didn't match the behavior
of the original fold_widened_comparison in that get_unwidened
returned a constant always in the wider type. But here we're
using (int) 4294967295u without the conversion applied. Fixed
by doing as earlier in the pattern - matching constants only
if the conversion was actually applied.
PR middle-end/110176
* match.pd (zext (bool) <= (int) 4294967295u): Make sure
to match INTEGER_CST only without outstanding conversion.
The PR shows us ICEing due to an unrecognizable TFmode save emitted by
aarch64_process_components. The problem is that for T{I,F,D}mode we
conservatively require mems to be in range for x-register ldp/stp. That
is because (at least for TImode) it can be allocated to both GPRs and
FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
a q-register load/store.
As Richard pointed out in the PR, aarch64_get_separate_components
already checks that the offsets are suitable for a single load, so we
just need to choose a mode in aarch64_reg_save_mode that gives the full
q-register range. In this patch, we choose V16QImode as an alternative
16-byte "bag-of-bits" mode that doesn't have the artificial range
restrictions imposed on T{I,F,D}mode.
For T{F,D}mode in GCC 15 I think we could consider relaxing the
restriction imposed in aarch64_classify_address, as typically T{F,D}mode
should be allocated to FPRs. But such a change seems too invasive to
consider for GCC 14 at this stage (let alone backports).
Fortunately the new flexible load/store pair patterns in GCC 14 allow
this mode change to work without further changes. The backports are
more involved as we need to adjust the load/store pair handling to cater
for V16QImode in a few places.
Note that for the testcase we are relying on the torture options to add
-funroll-loops at -O3 which is necessary to trigger the ICE on trunk
(but not on the 13 branch).
gcc/ChangeLog:
PR target/111677
* config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
V16QImode for the full 16-byte FPR saves in the vector PCS case.
gcc/testsuite/ChangeLog:
PR target/111677
* gcc.target/aarch64/torture/pr111677.c: New test.
/bin/as doesn't fully support the CFI directives, so the .eh_frame
sections are emitted directly and contain .long. Since .eh_frame
doesn't matter for those tests, this patch disables its generation in
the first place.
Tested on i386-pc-solaris2.11 (as and gas) and i686-pc-linux-gnu.
projects / thirdparty / gcc.git / log
