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.
Richard Biener [Wed, 31 Jan 2024 09:42:48 +0000 (10:42 +0100)]
tree-optimization/111444 - avoid insertions when skipping defs
The following avoids inserting expressions for IPA CP discovered
equivalences into the VN hashtables when we are optimistically
skipping may-defs in the attempt to prove it's redundant.
PR tree-optimization/111444
* tree-ssa-sccvn.cc (vn_reference_lookup_3): Do not use
vn_reference_lookup_2 when optimistically skipping may-defs.
Rainer Orth [Wed, 31 Jan 2024 12:34:07 +0000 (13:34 +0100)]
testsuite: Require ucn in g++.dg/cpp0x/udlit-extended-id-1.C
g++.dg/cpp0x/udlit-extended-id-1.C FAILs on Solaris/SPARC and x86 with
the native assembler:
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++14 compilation failed to produce executable
FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 (test for excess errors)
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++17 compilation failed to produce executable
FAIL: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 (test for excess errors)
UNRESOLVED: g++.dg/cpp0x/udlit-extended-id-1.C -std=c++20 compilation failed to produce executable
/bin/as doesn't support UCN identifiers:
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: invalid character (0xcf)
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: invalid character (0x80)
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: statement syntax
/usr/ccs/bin/as: "/var/tmp//ccCl_9fa.s", line 4: error: statement syntax
[...]
To avoid this, this patch requires ucn support.
Tested on i386-pc-solaris2.11 (as and gas), sparc-sun-solaris2.11 (as
and gas), and i686-pc-linux-gnu.
Richard Biener [Wed, 31 Jan 2024 10:28:50 +0000 (11:28 +0100)]
tree-optimization/113630 - invalid code hoisting
The following avoids code hoisting (but also PRE insertion) of
expressions that got value-numbered to another one that are not
a valid replacement (but still compute the same value). This time
because the access path ends in a structure with different size,
meaning we consider a related access as not trapping because of the
size of the base of the access.
PR tree-optimization/113630
* tree-ssa-pre.cc (compute_avail): Avoid registering a
reference with a representation with not matching base
access size.
Jakub Jelinek [Wed, 31 Jan 2024 09:56:56 +0000 (10:56 +0100)]
simplify-rtx: Fix up last argument to simplify_gen_unary [PR113656]
When simplifying e.g. (float_truncate:SF (float_truncate:DF (reg:XF))
or (float_truncate:SF (float_extend:XF (reg:DF)) etc. into
(float_truncate:SF (reg:XF)) or (float_truncate:SF (reg:DF)) we call
simplify_gen_unary with incorrect op_mode argument, it should be
the argument's mode, but we call it with the outer mode instead.
As these are all floating point operations, the argument always
has non-VOIDmode and so we can just use that mode (as done in similar
simplifications a few lines later), but neither FLOAT_TRUNCATE nor
FLOAT_EXTEND are operations that should have the same modes of operand
and result. This bug hasn't been a problem for years because normally
op_mode is used only if the mode of op is VOIDmode, otherwise it is
redundant, but r10-2139 added an assertion in some spots that op_mode
is right even in such cases.
2024-01-31 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/113656
* simplify-rtx.cc (simplify_context::simplify_unary_operation_1)
<case FLOAT_TRUNCATE>: Fix up last argument to simplify_gen_unary.
Jakub Jelinek [Wed, 31 Jan 2024 09:56:15 +0000 (10:56 +0100)]
dwarf2out: Fix ICE on large _BitInt in loc_list_from_tree_1 [PR113637]
This spot uses SCALAR_INT_TYPE_MODE which obviously ICEs for large/huge
BITINT_TYPE types which have BLKmode. But such large BITINT_TYPEs certainly
don't fit into DWARF2_ADDR_SIZE either, so we can just assume it would be
false if type has BLKmode.
2024-01-31 Jakub Jelinek <jakub@redhat.com>
PR debug/113637
* dwarf2out.cc (loc_list_from_tree_1): Assume integral types
with BLKmode are larger than DWARF2_ADDR_SIZE.
Jonathan Wakely [Tue, 30 Jan 2024 14:28:09 +0000 (14:28 +0000)]
libstdc++: Enable std::text_encoding for darwin and FreeBSD
The <xlocale.h> header is needed for newlocale and locale_t on these
targets.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CHECK_TEXT_ENCODING): Use <xlocale.h> if
needed for newlocale.
* configure: Regenerate.
* src/c++26/text_encoding.cc: Use <xlocale.h>.
Jonathan Wakely [Tue, 23 Jan 2024 14:57:15 +0000 (14:57 +0000)]
libstdc++: Add "ASCII" as an alias for std::text_encoding::id::ASCII
As noted in LWG 4043, "ASCII" is not an alias for any known registered
character encoding, so std::text_encoding("ASCII").mib() == id::other.
Add the alias "ASCII" to the implementation-defined superset of aliases
for that encoding.
Jonathan Wakely [Sat, 20 Jan 2024 21:09:28 +0000 (21:09 +0000)]
libstdc++: Fix -Wshift-count-overflow warning in std::bitset
This shift only happens if the unsigned long long type is wider than
unsigned long but the compiler warns when it sees the shift, without
caring if it's reachable.
Use the preprocessor to compare the sizes and just reuse _M_to_ulong()
if sizeof(long) == sizeof(long long).
Alexandre Oliva [Wed, 31 Jan 2024 03:13:36 +0000 (00:13 -0300)]
0From: Alexandre Oliva <oliva@adacore.com>
strub: introduce STACK_ADDRESS_OFFSET
Since STACK_POINTER_OFFSET is not necessarily at the boundary between
caller- and callee-owned stack, as desired by
__builtin_stack_address(), and using it as if it were or not causes
problems, introduce a new macro so that ports can define it suitably,
without modifying STACK_POINTER_OFFSET.
Joseph Myers [Wed, 31 Jan 2024 01:24:21 +0000 (01:24 +0000)]
c: Fix ICEs casting expressions with integer constant operands to bool [PR111059, PR111911]
C front-end bugs 111059 and 111911 both report ICEs with conversions
to boolean of expressions with integer constant operands that can
appear in an integer constant expression as long as they are not
evaluated (such as division by zero).
The issue is a nested C_MAYBE_CONST_EXPR, with the inner one generated
in build_binary_op to indicate that a subexpression has been fully
folded and should not be folded again, and the outer one in
build_c_cast to indicate that the expression has integer constant
operands. To avoid the inner one from build_binary_op,
c_objc_common_truthvalue_conversion should be given an argument
properly marked as having integer constant operands rather than that
information having been removed by the caller - but because c_convert
would then also wrap a C_MAYBE_CONST_EXPR with a NOP_EXPR converting
to boolean, it seems most convenient to have
c_objc_common_truthvalue_conversion produce the NE_EXPR directly in
the desired type (boolean in this case), before generating any
C_MAYBE_CONST_EXPR there, rather than it always producing a comparison
in integer_type_node and doing a conversion to boolean in the caller.
The same issue as in those PRs also applies for conversion to enums
with a boolean fixed underlying type; that case is also fixed and
tests added for it. Note that not all the tests added failed before
the patch (in particular, the issue was specific to casts and did not
apply for implicit conversions, but some tests of those are added as
well).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
PR c/111059
PR c/111911
gcc/c/
* c-tree.h (c_objc_common_truthvalue_conversion): Add third
argument.
* c-convert.cc (c_convert): For conversions to boolean, pass third
argument to c_objc_common_truthvalue_conversion rather than
converting here.
* c-typeck.cc (build_c_cast): Ensure arguments with integer
operands are marked as such for conversion to boolean.
(c_objc_common_truthvalue_conversion): Add third argument TYPE.
machine dep reorg : 0.10 ( 0%) 0.00 ( 0%) 0.11 ( 0%) 4138k ( 0%)
real 6m5.780s
user 6m2.396s
sys 0m2.373s
The machine dep reorg is the compile time of VSETVL PASS (424 seconds) which counts 53% of
the compilation time, spends much more time than scheduling.
After investigation, the critical patch of VSETVL pass is compute_lcm_local_properties which
is called every iteration of phase 2 (earliest fusion) and phase 3 (global lcm).
This patch optimized the codes of compute_lcm_local_properties to reduce the compilation time.
The optimization of this patch is very obvious, lazy VSETVL PASS: 424s (53%) -> 80s (18%) which
spend less time than scheduling.
Tested on both RV32 and RV64 no regression. Ok for trunk ?
PR target/113495
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc (extract_single_source): Remove.
(pre_vsetvl::compute_vsetvl_def_data): Fix compile time issue.
(pre_vsetvl::compute_transparent): New function.
(pre_vsetvl::compute_lcm_local_properties): Fix compile time time issue.
Fangrui Song [Thu, 11 Jan 2024 18:24:25 +0000 (10:24 -0800)]
i386: Add "Ws" constraint for symbolic address/label reference [PR105576]
Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name). Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).
There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large. This patch adds "Ws". Here are possible use cases:
Marek Polacek [Thu, 25 Jan 2024 17:08:14 +0000 (12:08 -0500)]
c++: avoid -Wdangling-reference for std::span-like classes [PR110358]
Real-world experience shows that -Wdangling-reference triggers for
user-defined std::span-like classes a lot. We can easily avoid that
by considering classes like
to be std::span-like, and not warning for them. Unlike the previous
patch, this one considers a non-union class template that has a pointer
data member and a trivial destructor as std::span-like.
PR c++/110358
PR c++/109640
gcc/cp/ChangeLog:
* call.cc (reference_like_class_p): Don't warn for std::span-like
classes.
* config/xtensa/constraints.md (R, T, U):
Change define_constraint to define_memory_constraint.
* config/xtensa/predicates.md (move_operand): Don't check that a
constant pool operand size is a multiple of UNITS_PER_WORD.
* config/xtensa/xtensa.cc
(xtensa_lra_p, TARGET_LRA_P): Remove.
(xtensa_emit_move_sequence): Remove "if (reload_in_progress)"
clause as it can no longer be true.
(fixup_subreg_mem): Drop function.
(xtensa_output_integer_literal_parts): Consider 16-bit wide
constants.
(xtensa_legitimate_constant_p): Add short-circuit path for
integer load instructions. Don't check that mode size is
at least UNITS_PER_WORD.
* config/xtensa/xtensa.md (movsf): Use can_create_pseudo_p()
rather reload_in_progress and reload_completed.
(doloop_end): Drop operand 2.
(movhi_internal): Add alternative loading constant from a
literal pool.
(define_split for DI register_operand): Don't limit to
!TARGET_AUTO_LITPOOLS.
* config/xtensa/xtensa.opt (mlra): Change to no effect.
Patrick Palka [Tue, 30 Jan 2024 15:44:56 +0000 (10:44 -0500)]
c++: duplicated side effects of xobj arg [PR113640]
We miscompile the below testcase because keep_unused_object_arg thinks
the object argument of an xobj member function is unused, and so it ends
up duplicating the argument's side effects.
PR c++/113640
gcc/cp/ChangeLog:
* call.cc (keep_unused_object_arg): Punt for an xobj member
function.
When the mode size of vls integer mode is less than 2 * XLEN, we will
take the gpr for both the args and the return values. Instead of the
reference. For example the below code:
typedef short v8hi __attribute__ ((vector_size (16)));
v8hi __attribute__((noinline))
add (v8hi a, v8hi b)
{
v8hi r = a + b;
return r;
}
Before this patch:
add:
vsetivli zero,8,e16,m1,ta,ma
vle16.v v1,0(a1) <== arg by reference
vle16.v v2,0(a2) <== arg by reference
vadd.vv v1,v1,v2
vse16.v v1,0(a0) <== return by reference
ret
After this patch:
add:
addi sp,sp,-32
sd a0,0(sp) <== arg by register a0 - a3
sd a1,8(sp)
sd a2,16(sp)
sd a3,24(sp)
addi a5,sp,16
vsetivli zero,8,e16,m1,ta,ma
vle16.v v2,0(sp)
vle16.v v1,0(a5)
vadd.vv v1,v1,v2
vse16.v v1,0(sp)
ld a0,0(sp) <== return by a0 - a1.
ld a1,8(sp)
addi sp,sp,32
jr ra
For vls floating point, we take the same rules as integer and passed by
the gpr or reference.
The riscv regression passed for this patch.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_v_vls_mode_aggregate_gpr_count): New function to
calculate the gpr count required by vls mode.
(riscv_v_vls_to_gpr_mode): New function convert vls mode to gpr mode.
(riscv_pass_vls_aggregate_in_gpr): New function to return the rtx of gpr
for vls mode.
(riscv_get_arg_info): Add vls mode handling.
(riscv_pass_by_reference): Return false if arg info has no zero gpr count.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vls/def.h: Add new helper macro.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-10.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-6.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-7.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-8.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-9.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-run-1.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-run-2.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-run-3.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-run-4.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-run-5.c: New test.
* gcc.target/riscv/rvv/autovec/vls/calling-convention-run-6.c: New test.
Robert Goss [Sun, 14 Jan 2024 17:34:22 +0000 (17:34 +0000)]
gccrs: Add improved error when no fields in initializer
If a struct type with a variant that has fields is initialized with some fields the expression HIR StructExprStructFields is checked that all the fields are assigned. However, if no fields are initialized the HIR StructExprStruct is generated. This doesn't check if the struct is a unit during typechekc and only fails at the compile stage with a ICE.
Add a check at the typecheck stage that makes sure the struct does not have a variant with fields and give an error message based on the rustc one.
We have also updated the message given in the case where one field was present to list the missing fields and match more closely the new message.
gcc/rust/ChangeLog:
* typecheck/rust-hir-type-check-expr.cc (TypeCheckExpr::visit) Add additional check
* typecheck/rust-hir-type-check-struct-field.h: A helper method to make error added
* typecheck/rust-hir-type-check-struct.cc (TypeCheckStructExpr::resolve) Update message
gcc/testsuite/ChangeLog:
* rust/compile/missing_constructor_fields.rs: Added case with no initializers
Signed-off-by: Robert Goss <goss.robert@gmail.com>
git://gcc.gnu.org / gcc.git / log