Alex Coplan [Wed, 24 Jan 2024 09:22:19 +0000 (09:22 +0000)]
aarch64: Re-enable ldp/stp fusion pass
Since, to the best of my knowledge, all reported regressions related to
the ldp/stp fusion pass have now been fixed, and PGO+LTO bootstrap with
--enable-languages=all is working again with the passes enabled, this
patch turns the passes back on by default, as agreed with Jakub here:
Tamar Christina [Wed, 24 Jan 2024 07:37:17 +0000 (07:37 +0000)]
middle-end: fix epilog reductions when vector iters peeled [PR113364]
This fixes a bug where vect_create_epilog_for_reduction does not handle the
case where all exits are early exits. In this case we should do like induction
handling code does and not have a main exit.
This shows that some new miscompiles are happening (stage3 is likely miscompiled)
but that's unrelated to this patch and I'll look at it next.
gcc/ChangeLog:
PR tree-optimization/113364
* tree-vect-loop.cc (vect_create_epilog_for_reduction): If all exits all
early exits then we must reduce from the first offset for all of them.
gcc/testsuite/ChangeLog:
PR tree-optimization/113364
* gcc.dg/vect/vect-early-break_107-pr113364.c: New test.
Huanghui Nie [Mon, 22 Jan 2024 05:45:48 +0000 (06:45 +0100)]
libstdc++: [_Hashtable] Remove useless check for _M_before_begin node
When removing the first node of a bucket it is useless to check if this bucket
is the one containing the _M_before_begin node. The bucket before-begin node is
already transfered to the next pointed-to bucket regardeless if it is the container
before-begin node.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (_Hahstable<>::_M_remove_bucket_begin): Remove
_M_before_begin check and cleanup implementation.
Patrick O'Neill [Wed, 24 Jan 2024 00:36:53 +0000 (16:36 -0800)]
RISC-V: Add regression test for vsetvl bug pr113429
The reduced testcase for pr113429 (cam4 failure) needed additional
modules so it wasn't committed.
The fuzzer found a c testcase that was also fixed with pr113429's fix.
Adding it as a regression test.
PR target/113429
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/vsetvl/pr113429.c: New test.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Juzhe-Zhong [Tue, 23 Jan 2024 10:12:49 +0000 (18:12 +0800)]
RISC-V: Fix large memory usage of VSETVL PASS [PR113495]
SPEC 2017 wrf benchmark expose unreasonble memory usage of VSETVL PASS
that is, VSETVL PASS consume over 33 GB memory which make use impossible
to compile SPEC 2017 wrf in a laptop.
Marek Polacek [Fri, 19 Jan 2024 18:59:41 +0000 (13:59 -0500)]
c++: -Wdangling-reference and lambda false warning [PR109640]
-Wdangling-reference checks if a function receives a temporary as its
argument, and only warns if any of the arguments was a temporary. But
we should not warn when the temporary represents a lambda or we generate
false positives as in the attached testcases.
PR c++/113256
PR c++/111607
PR c++/109640
gcc/cp/ChangeLog:
* call.cc (do_warn_dangling_reference): Don't warn if the temporary
is of lambda type.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wdangling-reference14.C: New test.
* g++.dg/warn/Wdangling-reference15.C: New test.
* g++.dg/warn/Wdangling-reference16.C: New test.
Jakub Jelinek [Tue, 23 Jan 2024 18:59:00 +0000 (19:59 +0100)]
c: Call c_fully_fold on __atomic_* operands in atomic_bitint_fetch_using_cas_loop [PR113518]
As the following testcase shows, I forgot to call c_fully_fold on the
__atomic_*/__sync_* operands called on _BitInt address, the expressions
are then used inside of TARGET_EXPR initializers etc. and are never fully
folded later, which means we can ICE e.g. on C_MAYBE_CONST_EXPR trees
inside of those.
The following patch fixes it, while the function currently is only called
in the C FE because C++ doesn't support BITINT_TYPE, I think guarding the
calls on !c_dialect_cxx () is safer.
2024-01-23 Jakub Jelinek <jakub@redhat.com>
PR c/113518
* c-common.cc (atomic_bitint_fetch_using_cas_loop): Call c_fully_fold
on lhs_addr, val and model for C.
Andrew Pinski [Tue, 23 Jan 2024 17:42:51 +0000 (17:42 +0000)]
aarch64/expr: Use ccmp when the outer expression is used twice [PR100942]
Ccmp is not used if the result of the and/ior is used by both
a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
here by using ccmp in this case.
Two changes is required, first we need to allow the outer statement's
result be used more than once.
The second change is that during the expansion of the gimple, we need
to try using ccmp. This is needed because we don't use expand the ssa
name of the lhs but rather expand directly from the gimple.
A small note on the ccmp_4.c testcase, we should be able to get slightly
better than with this patch but it is one extra instruction compared to
before.
PR target/100942
gcc/ChangeLog:
* ccmp.cc (ccmp_candidate_p): Add outer argument.
Allow if the outer is true and the lhs is used more
than once.
(expand_ccmp_expr): Update call to ccmp_candidate_p.
* expr.h (expand_expr_real_gassign): Declare.
* expr.cc (expand_expr_real_gassign): New function, split out from...
(expand_expr_real_1): ...here.
* cfgexpand.cc (expand_gimple_stmt_1): Use expand_expr_real_gassign.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/ccmp_3.c: New test.
* gcc.target/aarch64/ccmp_4.c: New test.
* gcc.target/aarch64/ccmp_5.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com> Co-Authored-By: Richard Sandiford <richard.sandiford@arm.com>
Alex Coplan [Tue, 16 Jan 2024 21:20:45 +0000 (21:20 +0000)]
aarch64: Fix up debug uses in ldp/stp pass [PR113089]
As the PR shows, we were missing code to update debug uses in the
load/store pair fusion pass. This patch fixes that.
The patch tries to give a complete treatment of the debug uses that will
be affected by the changes we make, and in particular makes an effort to
preserve debug info where possible, e.g. when re-ordering an update of
a base register by a constant over a debug use of that register. When
re-ordering loads over a debug use of a transfer register, we reset the
debug insn. Likewise when re-ordering stores over debug uses of mem.
While doing this I noticed that try_promote_writeback used a strange
choice of move_range for the pair insn, in that it chose the previous
nondebug insn instead of the insn itself. Since the insn is being
changed, these move ranges are equivalent (at least in terms of nondebug
insn placement as far as RTL-SSA is concerned), but I think it is more
natural to choose the pair insn itself. This is needed to avoid
incorrectly updating some debug uses.
gcc/ChangeLog:
PR target/113089
* config/aarch64/aarch64-ldp-fusion.cc (reset_debug_use): New.
(fixup_debug_use): New.
(fixup_debug_uses_trailing_add): New.
(fixup_debug_uses): New. Use it ...
(ldp_bb_info::fuse_pair): ... here.
(try_promote_writeback): Call fixup_debug_uses_trailing_add to
fix up debug uses of the base register that are affected by
folding in the trailing add insn.
gcc/testsuite/ChangeLog:
PR target/113089
* gcc.c-torture/compile/pr113089.c: New test.
Alex Coplan [Mon, 15 Jan 2024 17:13:06 +0000 (17:13 +0000)]
aarch64: Re-parent trailing nondebug base reg uses [PR113089]
While working on PR113089, I realised we where missing code to re-parent
trailing nondebug uses of the base register in the case of cancelling
writeback in the load/store pair pass. This patch fixes that.
gcc/ChangeLog:
PR target/113089
* config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair):
Update trailing nondebug uses of the base register in the case
of cancelling writeback.
Alex Coplan [Mon, 15 Jan 2024 11:07:48 +0000 (11:07 +0000)]
aarch64: Don't record hazards against paired insns [PR113356]
For the testcase in the PR, we try to pair insns where the first has
writeback and the second uses the updated base register. This causes us
to record a hazard against the second insn, thus narrowing the move
range away from the end of the BB.
However, it isn't meaningful to record hazards against the other insn
in the pair, as this doesn't change which pairs can be formed, and also
doesn't change where the pair is formed (from the perspective of
nondebug insns).
To see why this is the case, consider the two cases:
- Suppoe we are finding hazards for insns[0]. If we record a hazard
against insns[1], then range.last becomes
insns[1]->prev_nondebug_insn (), but note that this is equivalent to
inserting after insns[1] (since insns[1] is being changed).
- Now consider finding hazards for insns[1]. Suppose we record
insns[0] as a hazard. Then we set range.first = insns[0], which is a
no-op.
As such, it seems better to never record hazards against the other insn
in the pair, as we check whether the insns themselves are suitable for
combination separately (e.g. for ldp checking that they use distinct
transfer registers). Avoiding unnecessarily narrowing the move range
avoids unnecessarily re-ordering over debug insns.
This should also mean that we can only narrow the move range away from
the end of the BB in the case that we record a hazard for insns[0]
against insns[1]->prev_nondebug_insn () or earlier. This means that for
the non-call-exceptions case, either the move range includes insns[1],
or we reject the pair (thus the assert tripped in the PR should always
hold).
gcc/ChangeLog:
PR target/113356
* config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::try_fuse_pair):
Don't record hazards against the opposite insn in the pair.
gcc/testsuite/ChangeLog:
PR target/113356
* gcc.target/aarch64/pr113356.C: New test.
Xi Ruoyao [Tue, 23 Jan 2024 11:32:38 +0000 (19:32 +0800)]
LoongArch: testsuite: Disable stack protector for got-load.C
When building GCC with --enable-default-ssp, the stack protector is
enabled for got-load.C, causing additional GOT loads for
__stack_chk_guard. So mem/u will be matched more than 2 times and the
test will fail.
Zac Walker [Tue, 23 Jan 2024 15:32:30 +0000 (15:32 +0000)]
Ifdef `.hidden`, `.type`, and `.size` pseudo-ops for `aarch64-w64-mingw32` target
Recent
change (https://gcc.gnu.org/pipermail/gcc-cvs/2023-December/394915.html)
added a generic SME support using `.hidden`, `.type`, and ``.size`
pseudo-ops in the assembly sources, `aarch64-w64-mingw32` does not
support the pseudo-ops though. This patch wraps usage of those
pseudo-ops using macros and ifdefs them for `__ELF__` define.
H.J. Lu [Tue, 23 Jan 2024 13:55:07 +0000 (05:55 -0800)]
m2: Use time_t in time and don't redefine alloca
Fix the m2 build warning and error:
[...]
../../src/gcc/m2/mc/mc.flex:32:9: warning: "alloca" redefined
32 | #define alloca __builtin_alloca
| ^~~~~~
In file included from /usr/include/stdlib.h:587,
from <stdout>:22:
/usr/include/alloca.h:35:10: note: this is the location of the previous definition
35 | # define alloca(size) __builtin_alloca (size)
| ^~~~~~
../../src/gcc/m2/mc/mc.flex: In function 'handleDate':
../../src/gcc/m2/mc/mc.flex:333:25: error: passing argument 1 of 'time' from incompatible point
er type [-Wincompatible-pointer-types]
333 | time_t clock = time ((long *)0);
| ^~~~~~~~~
| |
| long int *
In file included from ../../src/gcc/m2/mc/mc.flex:28:
/usr/include/time.h:76:29: note: expected 'time_t *' {aka 'long long int *'} but argument is of
type 'long int *'
76 | extern time_t time (time_t *__timer) __THROW;
PR bootstrap/113554
* mc/mc.flex (alloca): Don't redefine.
(handleDate): Replace (long *)0 with (time_t *)0 when calling
time.
Alex Coplan [Fri, 12 Jan 2024 10:15:36 +0000 (10:15 +0000)]
aarch64: Fix up uses of mem following stp insert [PR113070]
As the PR shows (specifically #c7) we are missing updating uses of mem
when inserting an stp in the aarch64 load/store pair fusion pass. This
patch fixes that.
RTL-SSA has a simple view of memory and by default doesn't allow stores
to be re-ordered w.r.t. other stores. In the ldp fusion pass, we do our
own alias analysis and so can re-order stores over other accesses when
we deem this is safe. If neither store can be re-purposed (moved into
the required position to form the stp while respecting the RTL-SSA
constraints), then we turn both the candidate stores into "tombstone"
insns (logically delete them) and insert a new stp insn.
As it stands, we implement the insert case separately (after dealing
with the candidate stores) in fuse_pair by inserting into the middle of
the vector of changes. This is OK when we only have to insert one
change, but with this fix we would need to insert the change for the new
stp plus multiple changes to fix up uses of mem (note the number of
fix-ups is naturally bounded by the alias limit param to prevent
quadratic behaviour). If we kept the code structured as is and inserted
into the middle of the vector, that would lead to repeated moving of
elements in the vector which seems inefficient. The structure of the
code would also be a little unwieldy.
To improve on that situation, this patch introduces a helper class,
stp_change_builder, which implements a state machine that helps to build
the required changes directly in program order. That state machine is
reponsible for deciding what changes need to be made in what order, and
the code in fuse_pair then simply follows those steps.
Together with the fix in the previous patch for installing new defs
correctly in RTL-SSA, this fixes PR113070.
We take the opportunity to rename the function decide_stp_strategy to
try_repurpose_store, as that seems more descriptive of what it actually
does, since stp_change_builder is now responsible for the overall change
strategy.
gcc/ChangeLog:
PR target/113070
* config/aarch64/aarch64-ldp-fusion.cc
(struct stp_change_builder): New.
(decide_stp_strategy): Reanme to ...
(try_repurpose_store): ... this.
(ldp_bb_info::fuse_pair): Refactor to use stp_change_builder to
construct stp changes. Fix up uses when inserting new stp insns.
However, I missed that apply_changes_to_insn needed updating to ensure
that the new defs actually got inserted into the main def chain. This
meant that when the aarch64 ldp/stp pass inserted a new stp insn, the
stp would just get skipped over during subsequent alias analysis, as its
def never got inserted into the memory def chain. This (unsurprisingly)
led to wrong code.
This patch fixes the issue by ensuring new user-created defs get
inserted. I would have preferred to have used a flag internal to the
defs instead of a separate data structure to keep track of them, but since
machine_mode increased to 16 bits we're already at 64 bits in access_info,
and we can't really reuse m_is_temp as the logic in finalize_new_accesses
requires it to get cleared.
gcc/ChangeLog:
PR target/113070
* rtl-ssa.h: Include hash-set.h.
* rtl-ssa/changes.cc (function_info::finalize_new_accesses): Add
new_sets parameter and use it to keep track of new user-created sets.
(function_info::apply_changes_to_insn): Also call add_def on new sets.
(function_info::change_insns): Add hash_set to keep track of new
user-created defs. Plumb it through.
* rtl-ssa/functions.h: Add hash_set parameter to finalize_new_accesses and
apply_changes_to_insn.
Alex Coplan [Fri, 12 Jan 2024 10:14:33 +0000 (10:14 +0000)]
rtl-ssa: Support for creating new uses [PR113070]
This exposes an interface for users to create new uses in RTL-SSA.
This is needed for updating uses after inserting a new store pair insn
in the aarch64 load/store pair fusion pass.
gcc/ChangeLog:
PR target/113070
* rtl-ssa/accesses.cc (function_info::create_use): New.
* rtl-ssa/changes.cc (function_info::finalize_new_accesses):
Ensure new uses end up referring to permanent defs.
* rtl-ssa/functions.h (function_info::create_use): Declare.
Alex Coplan [Thu, 11 Jan 2024 16:17:37 +0000 (16:17 +0000)]
rtl-ssa: Run finalize_new_accesses forwards [PR113070]
The next patch in this series exposes an interface for creating new uses
in RTL-SSA. The intent is that new user-created uses can consume new
user-created defs in the same change group. This is so that we can
correctly update uses of memory when inserting a new store pair insn in
the aarch64 load/store pair fusion pass (the affected uses need to
consume the new store pair insn).
As it stands, finalize_new_accesses is called as part of the backwards
insn placement loop within change_insns, but if we want new uses to be
able to depend on new defs in the same change group, we need
finalize_new_accesses to be called on earlier insns first. This is so
that when we process temporary uses and turn them into permanent uses,
we can follow the last_def link on the temporary def to ensure we end up
with a permanent use consuming a permanent def.
gcc/ChangeLog:
PR target/113070
* rtl-ssa/changes.cc (function_info::change_insns): Split out the call
to finalize_new_accesses from the backwards placement loop, run it
forwards in a separate loop.
Richard Biener [Tue, 23 Jan 2024 11:53:04 +0000 (12:53 +0100)]
tree-optimization/113552 - fix num_call accounting in simd clone vectorization
The following avoids using exact_log2 on the number of SIMD clone calls
to be emitted when vectorizing calls since that can easily be not
a power of two in which case it will return -1. For different simd
clones the number of calls will differ by a multiply with a power of two
only so using floor_log2 is good enough here.
PR tree-optimization/113552
* tree-vect-stmts.cc (vectorizable_simd_clone_call): Use
floor_log2 instead of exact_log2 on the number of calls.
Jakub Jelinek [Tue, 23 Jan 2024 12:57:41 +0000 (13:57 +0100)]
ia64: Fix up -Wunused-parameter warning
Since r14-6945-gc659dd8bfb55e02a1b97407c1c28f7a0e8f7f09b
there is a warning
../../gcc/config/ia64/ia64.cc: In function ‘void ia64_start_function(FILE*, const char*, tree)’:
../../gcc/config/ia64/ia64.cc:3889:59: warning: unused parameter ‘decl’ [-Wunused-parameter]
3889 | ia64_start_function (FILE *file, const char *fnname, tree decl)
| ~~~~~^~~~
which presumably for bootstraps breaks the bootstrap.
While the decl parameter is passed to the ASM_OUTPUT_FUNCTION_LABEL macro,
that macro actually doesn't use that argument, so the removal of
ATTRIBUTE_UNUSED was incorrect.
This patch reverts the first ia64.cc hunk from r14-6945.
2024-01-23 Jeff Law <jlaw@ventanamicro.com>
Jakub Jelinek <jakub@redhat.com>
* config/ia64/ia64.cc (ia64_start_function): Add ATTRIBUTE_UNUSED to
decl.
Richard Biener [Mon, 22 Jan 2024 08:17:35 +0000 (09:17 +0100)]
Refactor exit PHI handling in vectorizer epilogue peeling
This refactors the handling of PHIs inbetween the main and the
epilogue loop. Instead of trying to handle the multiple exit
and original single exit case together the following separates
these cases resulting in much easier to understand code.
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Separate single and multi-exit case when creating PHIs between
the main and epilogue.
aarch64: Avoid registering duplicate C++ overloads [PR112989]
In the original fix for this PR, I'd made sure that
including <arm_sme.h> didn't reach the final return in
simulate_builtin_function_decl (which would indicate duplicate
function definitions). But it seems I forgot to do the same
thing for C++, which defines all of its overloads directly.
This patch fixes a case where we still recorded duplicate
functions for C++. Thanks to Iain for reporting the resulting
GC ICE and for help with reproducing it.
gcc/
PR target/112989
* config/aarch64/aarch64-sve-builtins-shapes.cc (build_one): Skip
MODE_single variants of functions that don't take tuple arguments.
Alex Coplan [Thu, 18 Jan 2024 17:53:01 +0000 (17:53 +0000)]
aarch64: Don't assert recog success in ldp/stp pass [PR113114]
The PR shows two different cases where try_promote_writeback produces an
RTL pattern which isn't recognized. Currently this leads to an ICE, as
we assert recog success, but I think it's better just to back out of the
changes gracefully if recog fails (as we do in the main fuse_pair case).
In theory since we check the ranges here recog shouldn't fail (which is
why I had the assert in the first place), but the PR shows an edge case
in the patterns where if we form a pre-writeback pair where the
writeback offset is exactly -S, where S is the size in bytes of one
transfer register, we fail to match the expected pattern as the patterns
look explicitly for plus operands in the mems. I think fixing this
would require adding at least four new special-case patterns to
aarch64.md for what doesn't seem to be a particularly useful variant of
the insns. Even if we were to do that, I think it would be GCC 15
material, and it's better to just punt for GCC 14.
The ILP32 case in the PR is a bit different, as that shows us trying to
combine a pair with DImode base register operands in the mems together
with an SImode trailing update of the base register. This leads to us
forming an RTL pattern which references the base register in both SImode
and DImode, which also fails to recog. Again, I think it's best just to
take the missed optimization for now. If we really want to make this
(try_promote_writeback) work for ILP32, we can try to do it for GCC 15.
gcc/ChangeLog:
PR target/113114
* config/aarch64/aarch64-ldp-fusion.cc (try_promote_writeback):
Don't assert recog success, just punt if the writeback pair
isn't recognized.
gcc/testsuite/ChangeLog:
PR target/113114
* gcc.c-torture/compile/pr113114.c: New test.
* gcc.target/aarch64/pr113114.c: New test.
Jakub Jelinek [Tue, 23 Jan 2024 10:21:00 +0000 (11:21 +0100)]
gcn: Fix a warning
I see
../../gcc/config/gcn/gcn.cc: In function ‘void gcn_hsa_declare_function_name(FILE*, const char*, tree)’:
../../gcc/config/gcn/gcn.cc:6568:67: warning: unused parameter ‘decl’ [-Wunused-parameter]
6568 | gcn_hsa_declare_function_name (FILE *file, const char *name, tree decl)
| ~~~~~^~~~
warning presumably since r14-6945-gc659dd8bfb55e02a1b97407c1c28f7a0e8f7f09b
Previously, the argument was anonymous, but now it is passed to a macro
which ignores it, so I think we should go with ATTRIBUTE_UNUSED.
2024-01-23 Jakub Jelinek <jakub@redhat.com>
* config/gcn/gcn.cc (gcn_hsa_declare_function_name): Add
ATTRIBUTE_UNUSED to decl.
Richard Biener [Tue, 23 Jan 2024 08:51:00 +0000 (09:51 +0100)]
debug/107058 - gracefully handle unexpected DIE contexts
While the bug is persisting that LTO streaming picks up a CONST_DECL
from an attribute argument on a VAR_DECL which with -fdebug-type-section
refers to a DIE in a type unit we can handle this gracefully, at least
with -fno-checking. Do so. The C++ frontend nevetheless should resolve
the CONST_DECL attribute argument to a constant.
PR debug/107058
* dwarf2out.cc (dwarf2out_die_ref_for_decl): Gracefully
handle unexpected but bogus DIE contexts when not checking
enabled.
Nathaniel Shead [Wed, 17 Jan 2024 05:50:39 +0000 (16:50 +1100)]
c++: Fix handling of extern templates in modules [PR112820]
Currently, extern templates are detected by looking for the
DECL_EXTERNAL flag on a TYPE_DECL. However, this is incorrect:
TYPE_DECLs don't actually set this flag, and it happens to work by
coincidence due to TYPE_DECL_SUPPRESS_DEBUG happening to use the same
underlying bit. This however causes issues with other TYPE_DECLs that
also happen to have suppressed debug information.
Instead, this patch reworks the logic so CLASSTYPE_INTERFACE_ONLY is
always emitted into the module BMI and can then be used to check for an
extern template correctly.
Otherwise, for other declarations we always want to redetermine this:
even for declarations from the GMF, we may change our mind on whether to
import or export depending on decisions made later in the TU after
importing so we shouldn't decide this now, or necessarily reuse what the
module we'd imported had decided.
Some of this may need to change in the future to account for
https://github.com/itanium-cxx-abi/cxx-abi/issues/170.
PR c++/112820
PR c++/102607
gcc/cp/ChangeLog:
* module.cc (trees_out::lang_type_bools): Write interface_only
and interface_unknown.
(trees_in::lang_type_bools): Read the above flags.
(trees_in::decl_value): Reset CLASSTYPE_INTERFACE_* except for
extern templates.
(trees_in::read_class_def): Remove buggy extern template
handling.
gcc/testsuite/ChangeLog:
* g++.dg/modules/debug-2_a.C: New test.
* g++.dg/modules/debug-2_b.C: New test.
* g++.dg/modules/debug-2_c.C: New test.
* g++.dg/modules/debug-3_a.C: New test.
* g++.dg/modules/debug-3_b.C: New test.
On Mon, Jan 22, 2024 at 11:27:52AM +0100, Richard Biener wrote:
> We run into
>
> static tree
> native_interpret_int (tree type, const unsigned char *ptr, int len)
> {
> ...
> if (total_bytes > len
> || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT)
> return NULL_TREE;
>
> OTOH using a V_C_E to "truncate" a _BitInt looks wrong? OTOH the
> check doesn't really handle native_encode_expr using the "proper"
> wide_int encoding however that's exactly handled. So it might be
> a pre-existing issue that's only uncovered by large _BitInts
> (__int128 might show similar issues?)
I guess the || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT
conditions make no sense, all we care is whether it fits in the buffer
or not.
But then there is
fold_view_convert_expr
(and other spots) which use
/* We support up to 1024-bit values (for GCN/RISC-V V128QImode). */
unsigned char buffer[128];
or something similar.
This patch fixes even that by using a XALLOCAVEC allocated buffer
if the type size is 129 .. 8192 bytes.
2024-01-22 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113462
* fold-const.cc (native_interpret_int): Don't punt if total_bytes
is larger than HOST_BITS_PER_DOUBLE_INT / BITS_PER_UNIT.
(fold_view_convert_expr): Use XALLOCAVEC buffers for types with
sizes between 129 and 8192 bytes.
Xi Ruoyao [Mon, 22 Jan 2024 10:07:42 +0000 (18:07 +0800)]
LoongArch: Disable explicit reloc for TLS LD/GD with -mexplicit-relocs=auto
Binutils 2.42 supports TLS LD/GD relaxation which requires the assembler
macro.
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_explicit_relocs_p):
If la_opt_explicit_relocs is EXPLICIT_RELOCS_AUTO, return false
for SYMBOL_TLS_LDM and SYMBOL_TLS_GD.
(loongarch_call_tls_get_addr): Do not split symbols of
SYMBOL_TLS_LDM or SYMBOL_TLS_GD if la_opt_explicit_relocs is
EXPLICIT_RELOCS_AUTO.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/explicit-relocs-auto-tls-ld-gd.c: Check
for la.tls.ld and la.tls.gd.
Richard Biener [Mon, 15 Jan 2024 11:55:20 +0000 (12:55 +0100)]
rtl-optimization/113255 - base_alias_check vs. pointer difference
When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination. It computes that via
but as written find_base_term happily picks the first candidate
it finds for the MINUS which means it picks const(`g') rather
than the correct frame:DI. This way find_base_term (but also
the unfixed find_base_value used by init_alias_analysis to
initialize REG_BASE_VALUE) performs pointer analysis isn't
sound. The following restricts the handling of multi-operand
operations to the case we know only one can be a pointer.
This for example causes gcc.dg/tree-ssa/pr94969.c to miss some
RTL PRE (I've opened PR113395 for this). A more drastic patch,
removing base_alias_check results in only gcc.dg/guality/pr41447-1.c
regressing (so testsuite coverage is bad). I've looked at
gcc.dg/tree-ssa tests and mostly scheduling changes are present,
the cc1plus .text size is only 230 bytes worse. With the this
less drastic patch below most scheduling changes are gone.
x86_64 might not the very best target to test for impact, but
test coverage on other targets is unlikely to be very much better.
PR rtl-optimization/113255
* alias.cc (find_base_term): Remove PLUS/MINUS handling
when both operands are not CONST_INT_P.
Richard Biener [Mon, 22 Jan 2024 14:42:59 +0000 (15:42 +0100)]
debug/112718 - reset all type units with -ffat-lto-objects
When mixing -flto, -ffat-lto-objects and -fdebug-type-section we
fail to reset all type units after early output resulting in an
ICE when attempting to add then duplicate sibling attributes.
PR debug/112718
* dwarf2out.cc (dwarf2out_finish): Reset all type units
for the fat part of an LTO compile.
Sandra Loosemore [Mon, 22 Jan 2024 22:38:49 +0000 (22:38 +0000)]
Correct lists of options enabled by -Wall and -Wextra [PR90463]
gcc/ChangeLog
PR c++/90463
* doc/invoke.texi (Warning Options): Correct lists of options
enabled by -Wall and -Wextra by checking against common.opt
and c-family/c.opt.
Sandra Loosemore [Mon, 22 Jan 2024 22:26:59 +0000 (22:26 +0000)]
Sort warning options in c-family/c.opt.
In spite of the plea "Please try to keep this file in ASCII collating
order" at the top of the file, the sorting of the entries for the
various -Wfoo options had increased in entropy. This made it hard to
correlate them against e.g. the list of options enabled by -Wall in
the manual (see PR90463). This patch is at least a step in the right
direction to restore order to the file.
I confirmed that no lines were added or removed by these changes, and
that the output of "gcc -Q --help=warnings" is unchanged both with or
without -Wall added to the command.
gcc/c-family/ChangeLog
* c.opt: Improve sorting of warning options.
Marek Polacek [Mon, 22 Jan 2024 21:12:33 +0000 (16:12 -0500)]
c++: extend Wdangling-reference17.C [PR109642]
This patch extends g++.dg/warn/Wdangling-reference17.C with code
from PR109642. I'm not creating a new test because this one
already #includes the required headers.
Andrew Pinski [Sun, 21 Jan 2024 07:12:31 +0000 (23:12 -0800)]
arm: Fix parsecpu.awk for aliases [PR113030]
So the problem here is the 2 functions check_cpu and check_arch use
the wrong variable to check if an alias is valid for that cpu/arch.
check_cpu uses cpu_optaliases instead of cpu_opt_alias. cpu_optaliases
is an array of index'ed by the cpuname that contains all of the valid aliases
for that cpu but cpu_opt_alias is an double index array which is index'ed
by cpuname and the alias which provides what is the alias for that option.
Similar thing happens for check_arch and arch_optaliases vs arch_optaliases.
PR target/113030
* config/arm/parsecpu.awk (check_cpu): Use cpu_opt_alias
instead of cpu_optaliases.
(check_arch): Use arch_opt_alias instead of arch_optaliases.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Thus, unless gfx803 is explicitly enabled, the following testcases will
fail to link as libgomp is not available for Fiji. Hence, this commit
xfails those testcases.
libgomp/ChangeLog:
* testsuite/libgomp.c/declare-variant-4-fiji.c: Xfail as fiji
support is no longer enabled by default.
* testsuite/libgomp.c/declare-variant-4-gfx803.c: Likewise.
The root cause is register_operand and reg_or_subregno are consistent so we reach the assertion fail.
We shouldn't worry about subreg:...VL_REGNUM since it's impossible that we can have such situation,
that is, we only have (set (reg) (reg:VL_REGNUM)) which generate "csrr vl" ASM for first fault load instructions (vleff).
So, using REG_P and REGNO must be totally solid and robostic.
Since we don't allow VL_RENUM involved into register allocation and we don't have such constraint, we always use this
following pattern to generate "csrr vl" ASM:
With debugging enabled, '*.mkoffload.dbg.o' files are generated. The e_flags
header of all *.o files must be the same - otherwise, the linker complains.
Since r14-4734-g56ed1055b2f40ac162ae8d382280ac07a33f789f the -march= default
is now gfx900. If compiling without any -march= flag, the default value is
used by the compiler but not passed to mkoffload. Hence, mkoffload.cc's uses
its own default for march - unfortunately, it still had gfx803/fiji as default,
leading to the linker error: 'incompatible mach'. Solution: Update the
default to gfx900.
While debugging it, I saw that /tmp/cc*.mkoffload.dbg.o kept accumulating;
there were a couple of issues with the handling:
* dbgobj was always added to files_to_cleanup
* If copy_early_debug_info returned true, dbgobj was added again
-> pointless and in theory a race if the same file was added in the
faction of a second.
* If copy_early_debug_info returned false,
- In exactly one case, it already deleted the file it self
(same potential race as above)
- The pointer dbgobj was freed - such that files_to_cleanup contained
a dangling pointer - probably the reason that stale files remained.
Solution: Only if copy_early_debug_info returns true, dbgobj is added to
files_to_cleanup. If it returns false, the file is unlinked before freeing
the pointer.
When compiling, GCC warned about several fatal_error messages as having
no %<...%> or %qs quotes. This patch now silences several of those warnings
by using those quotes.
gcc/ChangeLog:
PR other/111966
* config/gcn/mkoffload.cc (elf_arch): Change default to gfx900
to match the compiler default.
(simple_object_copy_lto_debug_sections): Never unlink the outfile
on error as the caller does so.
(maybe_unlink, compile_native): Use %<...%> and %qs in fatal_error.
(main): Likewise. Fix 'mkoffload.dbg.o' cleanup.
Richard Biener [Fri, 19 Jan 2024 12:55:09 +0000 (13:55 +0100)]
tree-optimization/113373 - add missing LC PHIs for live operations
The following makes reduction epilogue code generation happy by properly
adding LC PHIs to the exit blocks for multiple exit vectorized loops.
Some refactoring might make the flow easier to follow but I've refrained
from doing that with this patch.
I've kept some fixes in reduction epilogue generation from the earlier
attempt fixing this PR.
PR tree-optimization/113373
* tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg):
Create LC PHIs in the exit blocks where necessary.
* tree-vect-loop.cc (vectorizable_live_operation): Do not try
to handle missing LC PHIs.
(find_connected_edge): Remove.
(vect_create_epilog_for_reduction): Cleanup use of auto_vec.
* gcc.dg/vect/vect-early-break_104-pr113373.c: New testcase.
Juzhe-Zhong [Mon, 22 Jan 2024 02:49:05 +0000 (10:49 +0800)]
RISC-V: Fix vfirst/vmsbf/vmsif/vmsof ratio attributes
vfirst/vmsbf/vmsif/vmsof instructions are supposed to demand ratio instead of demanding sew_lmul.
But my previous typo makes VSETVL PASS miss honor the risc-v v spec.
Consider this following simple case:
int foo4 (void * in, void * out)
{
vint32m1_t v = __riscv_vle32_v_i32m1 (in, 4);
v = __riscv_vadd_vv_i32m1 (v, v, 4);
vbool32_t mask = __riscv_vreinterpret_v_i32m1_b32(v);
mask = __riscv_vmsof_m_b32(mask, 4);
return __riscv_vfirst_m_b32(mask, 4);
}
xuli [Mon, 22 Jan 2024 06:41:49 +0000 (06:41 +0000)]
RISC-V: Bugfix for resolve_overloaded_builtin[PR113420]
v2:
Avoid internal ICE for the case below.
vint8mf8_t test_vle8_v_i8mf8_m(vbool64_t vm, const int32_t *rs1, size_t vl) {
return __riscv_vle8(vm, rs1, vl);
}
v1:
Change the hash value of overloaded intrinsic from considering
all parameter types to:
1. Encoding vector data type
2. In order to distinguish vle8_v_i8mf8_m(vbool64_t vm, const int8_t *rs1, size_t vl)
and vle8_v_u8mf8_m(vbool64_t vm, const uint8_t *rs1, size_t vl), encode the pointer type
3. In order to distinguish vfadd_vv_f32mf2_rm(vfloat32mf2_t vs2, vfloat32mf2_t vs1, size_t vl)
and vfadd_vv_f32mf2(vfloat32mf2_t vs2, vfloat32mf2_t vs1, size_t vl), encode the number of
parameters. The same goes for the vxrm intrinsics.
Jeff Law [Mon, 22 Jan 2024 02:12:21 +0000 (19:12 -0700)]
[committed] Adjust expectations for pr59533-1.c
The change for pr111267 twiddled code generation for sh/pr59533-1.c
We end up eliminating two comparisons, but require two shll instructions to do
so. And in a couple places we're using an addc sequence rather than a subc
sequence. This patch adjusts the expected codegen for the test as all those
are either a wash or a
The fwprop change does cause some code regressions on the same test. I'll file
a distinct but for that issue.
Re: [PATCH] Avoid ICE with m68k-elf -malign-int and libcalls
>> emit_library_call_value_1 calls emit_push_insn with NULL_TREE
>> for TYPE. Sometimes emit_push_insn needs to assign a temp with
>> that TYPE, which causes a segfault.
>>
>> Fixed by computing the TYPE from MODE when needed.
>>
>> Original patch by Thorsten Otto.
>>
[ ... ]
> This really needs to happen in the two call paths which pass in
> NULL_TREE for the type. Note how the type is used to determine padding
> earlier in emit_push_insn. That would also make the code more
> consistent with the comment before emit_push_insn which implies that
> both MODE and TYPE are valid.
>
>
> Additionally you should bootstrap and regression test this patch on at
> least one target.
Updated as requested, and bootstrapped and tested on
{x86_64,aarch64,m68k}-linux-gnu without regressions.
gcc/
PR target/82420
PR target/111279
* calls.cc (emit_library_call_value_1): Pass valid TYPE
to emit_push_insn.
* expr.cc (emit_push_insn): Likewise.
gcc/testsuite/
PR target/82420
* gcc.target/m68k/pr82420.c: New test.
Jeff Law [Sun, 21 Jan 2024 22:41:38 +0000 (15:41 -0700)]
[committed] [NFC] Fix riscv_init_cumulative_args for unused arguments
The signature was still using ATTRIBUTE_UNUSED and actually marked one
of the used arguments with ATTRIBUTE_UNUSED.
This patch drops the decorations and instead remove the name of arguments
which are actually unused which is the preferred way to handle this now
when we can.
Bootstrapped. I didn't have test results on the platform where I
bootstrapped, so no results to compare against. Given its NFC, I
think we're OK without the regression results.
gcc/
* config/riscv/riscv.cc (riscv_init_cumulative_args): Update and
fix bugs in signature.
Jonathan Wakely [Sun, 21 Jan 2024 18:16:14 +0000 (18:16 +0000)]
libstdc++: Fix std::format for floating-point chrono::time_point [PR113500]
Currently trying to use std::format with certain specializations of
std::chrono::time_point is ill-formed, due to one member function of the
__formatter_chrono type which tries to write a time_point to an ostream.
For sys_time<floating-point> or sys_time with a period greater than days
there is no operator<< that can be used.
That operator<< is only needed when using an empty chrono-specs in the
format string, like "{}", but the ill-formed expression gives an error
even if not actually used. This means it's not possible to format some
other specializations of chrono::time_point, even when using a non-empty
chrono-specs.
This fixes it by avoiding using 'os << t' for all chrono::time_point
specializations, and instead using std::format("{:L%F %T}", t). So that
we continue to reject std::format("{}", sys_time{1.0s}) a check for
empty chrono-specs is added to the formatter<sys_time<D>, C>
specialization.
While testing this I noticed that the output for %S with a
floating-point duration was incorrect, as the subseconds part was being
appended to the seconds without a decimal point, and without the correct
number of leading zeros.
libstdc++-v3/ChangeLog:
PR libstdc++/113500
* include/bits/chrono_io.h (__formatter_chrono::_M_S): Fix
printing of subseconds with floating-point rep.
(__formatter_chrono::_M_format_to_ostream): Do not write
time_point specializations directly to the ostream.
(formatter<chrono::sys_time<D>, C>::parse): Do not allow an
empty chrono-spec if the type fails to meet the constraints for
writing to an ostream with operator<<.
* testsuite/std/time/clock/file/io.cc: Check formatting
non-integral times with empty chrono-specs.
* testsuite/std/time/clock/gps/io.cc: Likewise.
* testsuite/std/time/clock/utc/io.cc: Likewise.
* testsuite/std/time/hh_mm_ss/io.cc: Likewise.
Jonathan Wakely [Sun, 21 Jan 2024 18:11:16 +0000 (18:11 +0000)]
libstdc++: Fix std::chrono::file_clock conversions for low-precision times
THe std::chrono::file_clock conversions were not using common_type and
so failed to compile when converting anything that should have increased
precision after arithmetic with a std::chrono::seconds value.
libstdc++-v3/ChangeLog:
* include/bits/chrono.h (__file_clock::from_sys)
(__file_clock::to_sys, __file_clock::_S_from_sys)
(__file_clock::_S_to_sys): Use common_type for return type.
* testsuite/std/time/clock/file/members.cc: Check round trip
conversion for time with lower precision that seconds.
This patch resolves PR rtl-optimization/111267 by improving RTL-level
forward propagation. This x86_64 code quality regression was caused
(exposed) by my changes to improve how x86's (TImode) argument passing
is represented at the RTL-level (reducing the use of SUBREGs to catch
more optimization opportunities in combine). The pitfall is that the
more complex RTL representations expose a limitation in RTL's fwprop
pass.
At the heart of fwprop, in try_fwprop_subst_pattern, the logic can
be summarized as three steps. Step 1 is a heuristic that rejects the
propagation attempt if the expression is too complex, step 2 calls
the backend's recog to see if the propagated/simplified instruction
is recognizable/valid, and step 3 then calls set_src_cost to compare
the rtx costs of the replacement vs. the original, and accepts the
transformation if the final cost is the same of better.
The logic error (or missed optimization opportunity) is that the
step 1 heuristic that attempts to predict (second guess) the
process is flawed. Ultimately the decision on whether to fwprop
or not should depend solely on actual improvement, as measured
by RTX costs. Hence the prototype fix in the bugzilla PR removes
the heuristic of calling prop.profitable_p entirely, relying
entirely on the cost comparison in step 3.
Unfortunately, things are a tiny bit more complicated. The cost
comparison in fwprop uses the older set_src_cost API and not the
newer (preffered) insn_cost API as currently used in combine.
This means that the cost improvement comparisons are only done
for single_set instructions (more complex PARALLELs etc. aren't
supported). Hence we can only rely on skipping step 1 for that
subset of instructions actually evaluated by step 3.
The other subtlety is that to avoid potential infinite loops
in fwprop we should only reply purely on rtx costs when the
transformation is obviously an improvement. If the replacement
has the same cost as the original, we can use the prop.profitable_p
test to preserve the current behavior.
Finally, to answer Richard Biener's remaining question about this
approach: yes, there is an asymmetry between how patterns are
handled and how REG_EQUAL notes are handled. For example, at
the moment propagation into notes doesn't use rtx costs at all,
and ultimately when fwprop is updated to use insn_cost, this
(and recog) obviously isn't applicable to notes. There's no reason
the logic need be identical between patterns and notes, and during
stage4 we only need update propagation into patterns to fix this
P1 regression (notes and use of cost_insn can be done for GCC 15).
For Jakub's reduced testcase:
struct S { float a, b, c, d; };
int bar (struct S x, struct S y) {
return x.b <= y.d && x.c >= y.a;
}
On x86_64-pc-linux-gnu with -O2 gcc currently generates:
with this simple patch to fwprop, we now generate:
bar: shufps $85, %xmm0, %xmm0
shufps $85, %xmm3, %xmm3
comiss %xmm0, %xmm3
jb .L6
xorl %eax, %eax
comiss %xmm2, %xmm1
setnb %al
ret
.L6: xorl %eax, %eax
ret
2024-01-21 Roger Sayle <roger@nextmovesoftware.com>
Richard Biener <rguenther@suse.de>
gcc/ChangeLog
PR rtl-optimization/111267
* fwprop.cc (fwprop_propagation::profitabe_p): Rename
profitable_p method to likely_profitable_p.
(try_fwprop_subst_node): Update call to likely_profitable_p.
Only bail-out early when !prop.likely_profitable_p for instructions
that are not single sets. When comparing costs, bail-out if the
cost is unchanged and !prop.likely_profitable_p.
gcc/testsuite/ChangeLog
PR rtl-optimization/111267
* gcc.target/i386/pr111267.c: New test case.
Sandra Loosemore [Sun, 21 Jan 2024 20:42:59 +0000 (20:42 +0000)]
Make the manual clearer about what options -Wunused enables [PR90464]
gcc/ChangeLog
PR c++/90464
* doc/invoke.texi (Warning Options): Document that -Wunused-parameter
isn't enabled by -Wunused unless -Wextra is provided, and that
-Wunused does enable -Wunused-const-variable=1 for C. Clarify that
-Wunused doesn't enable -Wunused-* options documented as behaving
otherwise, and list them explicitly.
Martin Uecker [Sat, 20 Jan 2024 18:03:57 +0000 (19:03 +0100)]
C23: Fix ICE for composite type for structs with unsigned bitfields [PR113492]
This patch fixes a bug when forming a composite type from structs that
contain an unsigned bitfield declared with int while using -funsigned-bitfields.
In such structs the unsigned integer type was not compatible to the
regular unsigned integer type used elsewhere in the C FE.
PR c/113492
gcc/c:
* c-decl.cc (grokdeclarator): Use c_common_unsigned_type instead of
unsigned_type_for to create the unsigned type for bitfields declared
with int when using -funsigned-bitfields.
Jonathan Wakely [Sat, 20 Jan 2024 00:44:12 +0000 (00:44 +0000)]
libstdc++: Fix std::format floating-point alternate forms [PR113512]
The logic for handling '#' forms was ... not good. The count of
significant figures just counted digits, instead of ignoring leading
zeros. And when moving the result from the stack buffer to a dynamic
string the exponent could get lost in some cases.
libstdc++-v3/ChangeLog:
PR libstdc++/113512
* include/std/format (__formatter_fp::format): Fix logic for
alternate forms.
* testsuite/std/format/functions/format.cc: Check buggy cases of
alternate forms with g presentation type.
Sandra Loosemore [Sun, 21 Jan 2024 02:36:19 +0000 (02:36 +0000)]
Clean up examples for -Wdangling-pointer [PR109708]
gcc/ChangeLog
PR c/109708
* doc/invoke.texi (Warning Options): Fix broken example and
clean up/reorganize the others. Also describe what the short-form
options mean.
Marek Polacek [Fri, 19 Jan 2024 20:27:51 +0000 (15:27 -0500)]
libstdc++: suppress -Wdangling-reference with operator| [PR111410]
It seems to me that we should exclude std::ranges::views::__adaptor::operator|
from the -Wdangling-reference warning. It's commonly used when handling
ranges.
PR c++/111410
libstdc++-v3/ChangeLog:
* include/std/ranges: Add #pragma to disable -Wdangling-reference with
std::ranges::views::__adaptor::operator|.
Andrew Pinski [Sat, 20 Jan 2024 19:39:11 +0000 (11:39 -0800)]
ipa: Add testcase for already fixed case [PR110705]
This testcase was fixed with r13-1695-gb0f02eeb906b63 which
added an Ada testcase for the issue but adding a C testcase
is a good idea and that is what this does.
Committed after making sure it passes on x86_64-linux-gnu.
PR ipa/110705
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr110705-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Mikael Morin [Fri, 19 Jan 2024 17:47:36 +0000 (18:47 +0100)]
fortran: Restore current interface info on error [PR111291]
This change is a followup to the fix for PR48776 (namely r14-3572-gd58150452976c4ca65ddc811fac78ef956fa96b0 AKA
fortran: Restore interface to its previous state on error [PR48776]),
which cleaned up new changes from interfaces upon error.
Unfortunately, there is one case in that fix that is mishandled, visible
on unexpected_interface.f90 with valgrind or an asan-instrumented gfortran.
when an interface statement is found while parsing an interface body (which
is invalid), the current interface is replaced by the one from the new
statement, and as parsing continues, new procedures are added
to the new interface, which has been rejected and freed, instead of the
original one.
This change restores the current interface pointer to its previous value
on each rejected statement.
PR fortran/48776
PR fortran/111291
gcc/fortran/ChangeLog:
* parse.cc: Restore current interface to its previous value on error.
Sandra Loosemore [Sat, 20 Jan 2024 14:30:17 +0000 (14:30 +0000)]
Correct documentation for -Warray-parameter [PR102998]
gcc/ChangeLog
PR c/102998
* doc/invoke.texi (Option Summary): Add -Warray-parameter.
(Warning Options): Correct/edit discussion of -Warray-parameter
to make the first example less confusing, and fill in missing info.
Jakub Jelinek [Sat, 20 Jan 2024 11:36:32 +0000 (12:36 +0100)]
lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
The following patch ICEs because fre3 leaves around unfolded
_1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
statement and in handle_cast I was expecting just SSA_NAMEs for the
large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
we can handle in that case exactly the same, as the handle_operand recursion
handles those.
Of course, maybe we should also try to fold_stmt such cases somewhere in
bitint lowering preparation.
2024-01-20 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113462
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
Handle rhs1 INTEGER_CST like SSA_NAME.
Jakub Jelinek [Sat, 20 Jan 2024 11:35:38 +0000 (12:35 +0100)]
tree-switch-conversion: Bugfixes for _BitInt [PR113491]
The following patch fixes various issues with large/huge _BitInt used as switch
expressions.
In particular:
1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than
sizetype precision, varasm uses wi::to_offset on those and too large
indexes ICE; we've already checked earlier that the cluster is at most
sizetype bits and arrays can't be larger than that anyway
2) some spots were using SCALAR_INT_TYPE_MODE or
lang_hooks.types.type_for_mode on TYPE_MODE to determine types to use,
that obviously doesn't work for the large/huge BITINT_TYPE
3) like the recent change in the C FE, this patch makes sure we don't create
ARRAY_REFs with indexes with precision above sizetype precision, because
bitint lowering isn't prepared for that and because the indexes can't be
larger than sizetype anyway; the subtraction of the cluster minimum from
the index obviously needs to be done in unsigned __int128 or large/huge
BITINT_TYPE, but then we cast to sizetype if the precision is larger than
sizetype
2024-01-20 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113491
* tree-switch-conversion.cc (switch_conversion::build_constructors):
If elt.index has precision higher than sizetype, fold_convert it to
sizetype.
(switch_conversion::array_value_type): Return type if type is
BITINT_TYPE with precision above MAX_FIXED_MODE_SIZE or with BLKmode.
(switch_conversion::build_arrays): Use unsigned_type_for rather than
lang_hooks.types.type_for_mode if utype is BITINT_TYPE with precision
above MAX_FIXED_MODE_SIZE or with BLKmode. If utype has precision
higher than sizetype, use sizetype as tidx type and fold_convert the
subtraction to sizetype.
[PATCH] Avoid ICE on m68k -fzero-call-used-regs -fpic [PR110934]
PR110934 is a problem on m68k where -fzero-call-used-regs -fpic ICEs
when clearing an FP register.
The generic code generates an XFmode move of zero to that register,
which becomes an XFmode load from initialized data, which due to -fpic
uses a non-constant address, which the backend rejects. The
zero-call-used-regs pass runs very late, after register allocation and
frame layout, and at that point we can't allow new uses of the PIC
register or new pseudos.
To clear an FP register on m68k it's enough to do the move in SFmode,
but the generic code can't be told to do that, so this patch updates
m68k to use its own TARGET_ZERO_CALL_USED_REGS.
Bootstrapped and regression tested on m68k-linux-gnu.
Ok for master? (I don't have commit rights.)
gcc/
PR target/110934
* config/m68k/m68k.cc (m68k_zero_call_used_regs): New function.
(TARGET_ZERO_CALL_USED_REGS): Define.
gcc/testsuite/
PR target/110934
* gcc.target/m68k/pr110934.c: New test.
[PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]
When generating RMW logical operations on m68k, the backend
recognizes single-bit operations and rewrites them as bit
instructions on operands adjusted to address the intended byte.
When offsetting the addresses the backend keeps the modes as
SImode, even though the actual access will be in QImode.
The uclinux target defines M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
which adds a check that the adjusted operand is within the bounds
of the original object. Since the address has been offset it is
not, and the compiler ICEs.
The bug is that the modes of the adjusted operands should have been
narrowed to QImode, which is that this patch does. Nearby code
which narrows to HImode gets that right.
Bootstrapped and regression tested on m68k-linux-gnu.
Ok for master? (Note: I don't have commit rights.)
gcc/
PR target/108640
* config/m68k/m68k.cc (output_andsi3): Use QImode for
address adjusted for 1-byte RMW access.
(output_iorsi3): Likewise.
(output_xorsi3): Likewise.
gcc/testsuite/
PR target/108640
* gcc.target/m68k/pr108640.c: New test.
Harald Anlauf [Fri, 19 Jan 2024 20:20:44 +0000 (21:20 +0100)]
Fortran: fix wrong array bounds check [PR113471]
gcc/fortran/ChangeLog:
PR fortran/113471
* trans-array.cc (array_bound_check_elemental): Array bounds check
shall apply here to elemental dimensions of an array section only.
gcc/testsuite/ChangeLog:
PR fortran/113471
* gfortran.dg/bounds_check_24.f90: New test.
Jonathan Wakely [Fri, 19 Jan 2024 12:28:30 +0000 (12:28 +0000)]
libstdc++: Fix P2255R2 dangling checks for std::tuple in C++17 [PR108822]
I accidentally used && in a fold-expression instead of || which meant
that in C++17 the tuple(UElements&&...) constructor only failed its
debug assertion if all tuple elements were dangling references. Some
missing tests (noted as "TODO") meant this wasn't tested.
This fixes the fold expression and adds the missing tests.
libstdc++-v3/ChangeLog:
PR libstdc++/108822
* include/std/tuple (__glibcxx_no_dangling_refs) [C++17]: Fix
wrong fold-operator.
* testsuite/20_util/tuple/dangling_ref.cc: Check tuples with one
element and three elements. Check allocator-extended
constructors.
Jason Merrill [Wed, 17 Jan 2024 22:29:33 +0000 (17:29 -0500)]
c++: alias template argument conversion [PR112632]
We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into them in a way that we don't for other templates. And fixing
that specific problem is a lot simpler than adding IMPLICIT_CONV_EXPR around
all dependent template arguments the way I gave up on for 111357.
The other part of the fix was changing tsubst_expr to actually call
convert_nontype_argument instead of assuming it will eventually happen.
I waffled about stripping the forced conversion when !force_conv
vs. skipping them in iterative_hash_template_arg and
template_args_equal (like we already do for some other conversions) and
decided to go with the former, but that isn't a strong preference if it
turns out to be somehow problematic.
* g++.dg/cpp0x/alias-decl-nontype1.C: New test.
* g++.dg/cpp2a/concepts-narrowing1.C: New test.
* g++.dg/cpp2a/nontype-class63.C: New test.
* g++.dg/cpp2a/nontype-class63a.C: New test.
This patch removes unused parameters and local variables from
M2GenGCC.mod. It required ForeachScopeBlockDo2 to be implemented and
exported affecting any module indirectly calling ConvertQuadsToTree.
gcc/m2/ChangeLog:
* gm2-compiler/M2BasicBlock.mod (InitBasicBlocks): Rename
ForeachScopeBlockDo to ForeachScopeBlockDo3.
* gm2-compiler/M2Code.mod: Import ForeachScopeBlockDo2.
(OptimizeScopeBlock): Call ForeachScopeBlockDo3 for
procedures with three parameters and ForeachScopeBlockDo2
for two parameters.
(CodeBlock): Ditto.
* gm2-compiler/M2GCCDeclare.mod (DeclareTypesConstantsProcedures):
Rename ForeachScopeBlockDo to ForeachScopeBlockDo3.
* gm2-compiler/M2GenGCC.def (ConvertQuadsToTree): Remove Scope
parameter.
* gm2-compiler/M2GenGCC.mod (ConvertQuadsToTree): Remove Scope
parameter.
(MaybeDebugBuiltinMemcpy): Remove parameter tok.
(MaybeDebugBuiltinMemset): Remove.
(MakeCopyUse): Remove tokenno from call to
MaybeDebugBuiltinMemcpy.
(PerformFoldBecomes): Remove desloc and exprloc.
(checkArrayElements): Remove location. Remove virtpos
as a parameter to MaybeDebugBuiltinMemcpy.
(NoWalkProcedure): Add attribute unused.
(CheckElementSetTypes): Remove parameter p.
Remove CurrentQuadToken in call to MaybeDebugBuiltinMemcpy.
Remove NoWalkProcedure from call to CheckElementSetTypes.
Remove tokenno from call to MaybeDebugBuiltinMemcpy.
* gm2-compiler/M2Optimize.mod (RemoveProcedures): Replace
two parameter indirect procedure iterator with
ForeachScopeBlockDo2.
* gm2-compiler/M2SSA.mod: Remove ForeachScopeBlockDo.
* gm2-compiler/M2Scope.def (ForeachScopeBlockDo2): New
declaration.
(ForeachScopeBlockDo): Rename ...
(ForeachScopeBlockDo3): ... to this.
(ScopeProcedure2): New declaration.
* gm2-compiler/M2Scope.mod (ForeachScopeBlockDo2): New
procedure.
(ForeachScopeBlockDo): Rename ...
(ForeachScopeBlockDo3): ... to this.
projects / thirdparty / gcc.git / log
