lra: Updates of biggest mode for hard regs [PR112278]
LRA keeps track of the biggest mode for both hard registers and
pseudos. The updates assume that the modes are ordered, i.e. that
we can tell whether one is no bigger than the other at compile time.
That is (or at least seemed to be) a reasonable restriction for pseudos.
But it isn't necessarily so for hard registers, since the uses of hard
registers can be logically distinct. The testcase is an example of this.
The biggest mode of hard registers is also special for other reasons.
As the existing comment says:
/* A reg can have a biggest_mode of VOIDmode if it was only ever seen as
part of a multi-word register. In that case, just use the reg_rtx
mode. Do the same also if the biggest mode was larger than a register
or we can not compare the modes. Otherwise, limit the size to that of
the biggest access in the function or to the natural mode at least. */
This patch applies the same approach to the updates.
gcc/
PR rtl-optimization/112278
* lra-int.h (lra_update_biggest_mode): New function.
* lra-coalesce.cc (merge_pseudos): Use it.
* lra-lives.cc (process_bb_lives): Likewise.
* lra.cc (new_insn_reg): Likewise.
gcc/testsuite/
PR rtl-optimization/112278
* gcc.target/aarch64/sve/pr112278.c: New test.
Jakub Jelinek [Tue, 5 Dec 2023 08:45:40 +0000 (09:45 +0100)]
lower-bitint: Make temporarily wrong IL less wrong [PR112843]
As discussed in the PR, for the middle (on x86-64 65..128 bit) _BitInt
types like
_1 = x_4(D) * 5;
where _1 and x_4(D) have _BitInt(128) type and x is PARM_DECL, the bitint
lowering pass wants to replace this with
_13 = (int128_t) x_4(D);
_12 = _13 * 5;
_1 = (_BitInt(128)) _12;
where _13 and _12 have int128_t type and the ranger ICEs when the IL is
temporarily invalid:
during GIMPLE pass: bitintlower
pr112843.c: In function ‘foo’:
pr112843.c:7:1: internal compiler error: Segmentation fault
7 | foo (_BitInt (128) x, _BitInt (256) y)
| ^~~
0x152943f crash_signal
../../gcc/toplev.cc:316
0x25c21c8 ranger_cache::range_of_expr(vrange&, tree_node*, gimple*)
../../gcc/gimple-range-cache.cc:1204
0x25cdcf9 fold_using_range::range_of_range_op(vrange&, gimple_range_op_handler&, fur_source&)
../../gcc/gimple-range-fold.cc:671
0x25cf9a0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&, tree_node*)
../../gcc/gimple-range-fold.cc:602
0x25b5520 gimple_ranger::update_stmt(gimple*)
../../gcc/gimple-range.cc:564
0x16f1234 update_stmt_operands(function*, gimple*)
../../gcc/tree-ssa-operands.cc:1150
0x117a5b6 update_stmt_if_modified(gimple*)
../../gcc/gimple-ssa.h:187
0x117a5b6 update_stmt_if_modified(gimple*)
../../gcc/gimple-ssa.h:184
0x117a5b6 update_modified_stmt
../../gcc/gimple-iterator.cc:44
0x117a5b6 gsi_insert_after(gimple_stmt_iterator*, gimple*, gsi_iterator_update)
../../gcc/gimple-iterator.cc:544
0x25abc2f gimple_lower_bitint
../../gcc/gimple-lower-bitint.cc:6348
What the code does right now is, it first creates a new SSA_NAME (_12
above), adds the
_1 = (_BitInt(128)) _12;
stmt after it (where it crashes, because _12 has no SSA_NAME_DEF_STMT yet),
then sets lhs of the previous stmt to _12 (this is also temporarily
incorrect, there are incompatible types involved in the stmt), later on
changes also operands and finally update_stmt it.
The following patch instead changes the lhs of the stmt before adding the
cast after it. The question is if this is less or more wrong temporarily
(but the ICE is gone). In addition to that the patch moves the operand
adjustments before the lhs adjustment.
The reason I tweaked the lhs first is that it then just uses gimple_op and
iterates over all ops, if that is done before lhs it would need to special
case which op to skip because it is lhs (I'm using gimple_get_lhs for the
lhs, but this isn't done for GIMPLE_CALL nor GIMPLE_PHI, so GIMPLE_ASSIGN
or say GIMPLE_GOTO etc. are the only options).
2023-12-05 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/112843
* gimple-lower-bitint.cc (gimple_lower_bitint): Change lhs of stmt
to lhs2 before building and inserting lhs = (cast) lhs2; assignment.
Adjust stmt operands before adjusting lhs.
On the testcase I've recently fixed I've noticed bad code generation,
we emit
pxor %xmm1, %xmm1
psrld $31, %xmm0
pcmpeqd %xmm1, %xmm0
pcmpeqd %xmm1, %xmm0
or
vpxor %xmm1, %xmm1, %xmm1
vpsrld $31, %xmm0, %xmm0
vpcmpeqd %xmm1, %xmm0, %xmm0
vpcmpeqd %xmm1, %xmm0, %xmm2
rather than
psrad $31, %xmm2
or
vpsrad $31, %xmm1, %xmm2
The following patch fixes that using a combiner splitter.
2023-12-05 Jakub Jelinek <jakub@redhat.com>
PR target/112816
* config/i386/sse.md ((eq (eq (lshiftrt x elt_bits-1) 0) 0)): New
splitter to turn psrld $31; pcmpeq; pcmpeq into psrad $31.
Richard Biener [Mon, 4 Dec 2023 13:03:37 +0000 (14:03 +0100)]
c/89270 - honor registered_builtin_types in type_for_size
The following fixes the intermediate conversions inserted by
convert_to_integer when facing address-spaces and converts
to their effective [u]intptr_t when they are registered_builtin_types
by considering those also from c_common_type_for_size and not
only from c_common_type_for_mode.
Richard Biener [Mon, 4 Dec 2023 14:46:38 +0000 (15:46 +0100)]
tree-optimization/112827 - more SCEV cprop fixes
The insert iteration can be corrupted by foldings of replace_uses_by,
within this particular PHI replacement but also with subsequent ones.
Recompute the insert location before insertion instead.
This fixes an obvserved ICE of gcc.dg/tree-ssa/ssa-sink-16.c.
PR tree-optimization/112827
PR tree-optimization/112848
* tree-scalar-evolution.cc (final_value_replacement_loop):
Compute the insert location for each insert.
liuhongt [Mon, 27 Nov 2023 05:35:41 +0000 (13:35 +0800)]
Take register pressure into account for vec_construct/scalar_to_vec when the components are not loaded from memory.
For vec_contruct, the components must be live at the same time if
they're not loaded from memory, when the number of those components
exceeds available registers, spill happens. Try to account that with a
rough estimation.
??? Ideally, we should have an overall estimation of register pressure
if we know the live range of all variables.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_vector_costs::add_stmt_cost):
Count sse_reg/gpr_regs for components not loaded from memory.
(ix86_vector_costs:ix86_vector_costs): New constructor.
(ix86_vector_costs::m_num_gpr_needed[3]): New private memeber.
(ix86_vector_costs::m_num_sse_needed[3]): Ditto.
(ix86_vector_costs::finish_cost): Estimate overall register
pressure cost.
(ix86_vector_costs::ix86_vect_estimate_reg_pressure): New
function.
Marek Polacek [Tue, 19 Sep 2023 20:31:17 +0000 (16:31 -0400)]
c++: implement P2564, consteval needs to propagate up [PR107687]
This patch implements P2564, described at <wg21.link/p2564>, whereby
certain functions are promoted to consteval. For example:
consteval int id(int i) { return i; }
template <typename T>
constexpr int f(T t)
{
return t + id(t); // id causes f<int> to be promoted to consteval
}
void g(int i)
{
f (3);
}
now compiles. Previously the code was ill-formed: we would complain
that 't' in 'f' is not a constant expression. Since 'f' is now
consteval, it means that the call to id(t) is in an immediate context,
so doesn't have to produce a constant -- this is how we allow consteval
functions composition. But making 'f<int>' consteval also means that
the call to 'f' in 'g' must yield a constant; failure to do so results
in an error. I made the effort to have cc1plus explain to us what's
going on. For example, calling f(i) produces this neat diagnostic:
w.C:11:11: error: call to consteval function 'f<int>(i)' is not a constant expression
11 | f (i);
| ~~^~~
w.C:11:11: error: 'i' is not a constant expression
w.C:6:22: note: 'constexpr int f(T) [with T = int]' was promoted to an immediate function because its body contains an immediate-escalating expression 'id(t)'
6 | return t + id(t); // id causes f<int> to be promoted to consteval
| ~~^~~
which hopefully makes it clear what's going on.
Implementing this proposal has been tricky. One problem was delayed
instantiation: instantiating a function can set off a domino effect
where one call promotes a function to consteval but that then means
that another function should also be promoted, etc.
In v1, I addressed the delayed instantiation problem by instantiating
trees early, so that we can escalate functions right away. That caused
a number of problems, and in certain cases, like consteval-prop3.C, it
can't work, because we need to wait till EOF to see the definition of
the function anyway. Overeager instantiation tends to cause diagnostic
problems too.
In v2, I attempted to move the escalation to the gimplifier, at which
point all templates have been instantiated. That attempt flopped,
however, because once we've gimplified a function, its body is discarded
and as a consequence, you can no longer evaluate a call to that function
which is required for escalating, which needs to decide if a call is
a constant expression or not.
Therefore, we have to perform the escalation before gimplifying, but
after instantiate_pending_templates. That's not easy because we have
no way to walk all the trees. In the v2 patch, I use two vectors: one
to store function decls that may become consteval, and another to
remember references to immediate-escalating functions. Unfortunately
the latter must also stash functions that call immediate-escalating
functions. Consider:
int g(int i)
{
f<int>(i); // f is immediate-escalating
}
where g itself is not immediate-escalating, but we have to make sure
that if f gets promoted to consteval, we give an error.
A new option, -fno-immediate-escalation, is provided to suppress
escalating functions.
v2 also adds a new flag, DECL_ESCALATION_CHECKED_P, so that we don't
escalate a function multiple times, and so that we can distinguish between
explicitly consteval functions and functions that have been promoted
to consteval.
In v3, I removed one of the new vectors and changed the other one
to a hash set. This version also contains numerous cleanups.
v4 merges find_escalating_expr_r into cp_fold_immediate_r. It also
adds a new optimization in cp_fold_function.
v5 greatly simplifies the code.
v6 simplifies the code further and removes an ff_ flag.
v7 removes maybe_promote_function_to_consteval and further simplifies
cp_fold_immediate_r logic.
* call.cc (in_immediate_context): No longer static.
* constexpr.cc (cxx_eval_call_expression): Adjust assert.
* cp-gimplify.cc (deferred_escalating_exprs): New vec.
(remember_escalating_expr): New.
(enum fold_flags): Remove ff_fold_immediate.
(immediate_escalating_function_p): New.
(unchecked_immediate_escalating_function_p): New.
(promote_function_to_consteval): New.
(cp_fold_immediate): Move above. Return non-null if any errors were
emitted.
(maybe_explain_promoted_consteval): New.
(cp_gimplify_expr) <case CALL_EXPR>: Assert we've handled all
immediate invocations.
(taking_address_of_imm_fn_error): New.
(cp_fold_immediate_r): Merge ADDR_EXPR and PTRMEM_CST cases. Implement
P2564 - promoting functions to consteval.
<case CALL_EXPR>: Implement P2564 - promoting functions to consteval.
(cp_fold_r): If an expression turns into a CALL_EXPR after cp_fold,
call cp_fold_immediate_r on the CALL_EXPR.
(cp_fold_function): Set DECL_ESCALATION_CHECKED_P if
deferred_escalating_exprs does not contain current_function_decl.
(process_and_check_pending_immediate_escalating_fns): New.
* cp-tree.h (struct lang_decl_fn): Add escalated_p bit-field.
(DECL_ESCALATION_CHECKED_P): New.
(immediate_invocation_p): Declare.
(process_pending_immediate_escalating_fns): Likewise.
* decl2.cc (c_parse_final_cleanups): Set at_eof to 2 after all
templates have been instantiated; and to 3 at the end of the function.
Call process_pending_immediate_escalating_fns.
* error.cc (dump_template_bindings): Check at_eof against an updated
value.
* module.cc (trees_out::lang_decl_bools): Stream escalated_p.
(trees_in::lang_decl_bools): Likewise.
* pt.cc (push_tinst_level_loc): Set at_eof to 3, not 2.
* typeck.cc (cp_build_addr_expr_1): Don't check
DECL_IMMEDIATE_FUNCTION_P.
Andrew Pinski [Sun, 12 Nov 2023 04:33:28 +0000 (20:33 -0800)]
MATCH: Fix zero_one_valued_p's convert pattern
While working on PR 111972, I was getting a regression
due to zero_one_valued_p matching a signed 1 bit integer
when it came to convert. This patch fixes that by checking
the outer type too.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/ChangeLog:
* match.pd (zero_one_valued_p): For convert
make sure type is not a signed 1-bit integer.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Jeff Law [Mon, 4 Dec 2023 17:06:49 +0000 (10:06 -0700)]
[committed] Fix HImode load mnemonic on microblaze port
The tester recently started failing va-arg-22.c on microblaze-linux:
gcc.c-torture/execute/va-arg-22.c -O0 (test for excess errors)
It was failing with an undefined reference to "r7" at link time. This was
ultimately tracked down to a HImode load using (reg+reg) addressing mode, but
which used the lhui instruction instead of lhu. The "i" means it's supposed to
be (reg+disp) so the assembler tried to interpret "r7" as an immediate/symbol.
The port uses %i<opnum> as an output modifier to select between sh/shi and
various other mnemonics for loads/stores. The movhi pattern simply failed to
use it for the two cases where it's loading from memory (interestingly enough
it was used for stores).
Clearly we aren't using reg+reg much for HImode loads as this didn't fix
anything else in the testsuite.
gcc/
* config/microblaze/microblaze.md (movhi): Use %i for half-word
loads to properly select between lhu/lhui.
Robin Dapp [Fri, 1 Dec 2023 08:45:29 +0000 (09:45 +0100)]
RISC-V: Fix rawmemchr implementation.
This fixes a bug in the rawmemchr implementation by incrementing the
source address by vl * element_size instead of just vl.
This is normally harmless as we will just scan the same region more than
once but, in combination with an older qemu version, will lead to
an execution failure in SPEC2017.
gcc/ChangeLog:
* config/riscv/riscv-string.cc (expand_rawmemchr): Increment
source address by vl * element_size.
Robin Dapp [Fri, 1 Dec 2023 08:30:17 +0000 (09:30 +0100)]
RISC-V: Rename and unify stringop strategy handling.
In preparation for the vectorized strlen and strcmp support this NFC
patch unifies the stringop strategy handling a bit. The "auto"
strategy now is a combination of scalar and vector and an expander
should try the strategies in their preferred order.
For the block_move expander this patch does just that.
gcc/ChangeLog:
* config/riscv/riscv-opts.h (enum riscv_stringop_strategy_enum):
Rename...
(enum stringop_strategy_enum): ... to this.
* config/riscv/riscv-string.cc (riscv_expand_block_move): New
wrapper expander handling the strategies and delegation.
(riscv_expand_block_move_scalar): Rename function and make
static.
(expand_block_move): Remove strategy handling.
* config/riscv/riscv.md: Call expander wrapper.
* config/riscv/riscv.opt: Rename.
Richard Biener [Mon, 4 Dec 2023 13:50:59 +0000 (14:50 +0100)]
middle-end/112785 - guard against last_clique overflow
The PR shows that we'll ICE eventually when last_clique wraps. The
following avoids this by refusing to hand out new cliques after
exhausting them. We then use zero (no clique) as conservative
fallback.
PR middle-end/112785
* function.h (get_new_clique): New inline function handling
last_clique overflow.
* cfgrtl.cc (duplicate_insn_chain): Use it.
* tree-cfg.cc (gimple_duplicate_bb): Likewise.
* tree-inline.cc (remap_dependence_clique): Likewise.
This patch documents the optimization parameter
riscv-strcmp-inline-limit, which can be used to tweak the behaviour
of -minline-strcmp and -minline-strncmp.
Juzhe-Zhong [Mon, 4 Dec 2023 13:44:56 +0000 (21:44 +0800)]
RISC-V: Fix overlap group incorrect overlap on v0
In serious high register pressure case (appended in this patch):
We see vluxei8.v v0,(s1),v1,v0.t which is not allowed.
Since according to RVV ISA:
+;; The destination vector register group for a masked vector instruction cannot overlap the source mask register (v0),
+;; unless the destination vector register is being written with a mask value (e.g., compares) or the scalar result of a reduction.
Such case doesn't have spillings, however, we expect such case should be spilled and reload data.
The rootcause is I made a mistake in previous patch on matching dest operand and mask operand constraints:
dest: "=vr"
mask: "vmWc1"
After this patch:
dest: "vd,vr"
mask: "vm,Wc1"
make EEW widening pattern are same as other instruction patterns.
PR target/112431
gcc/ChangeLog:
* config/riscv/vector.md: Fix incorrect overlap in v0.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-34.c: New test.
Richard Biener [Mon, 4 Dec 2023 09:46:11 +0000 (10:46 +0100)]
tree-optimization/112827 - corrupt SCEV cache during SCCP
The following avoids corrupting the SCEV cache by my last change
to propagate constant final values immediately. The easiest fix
is to keep a dead initialization around.
PR tree-optimization/112827
* tree-scalar-evolution.cc (final_value_replacement_loop):
Do not release SSA name but keep a dead initialization around.
* gcc.dg/torture/pr112827-1.c: New testcase.
* gcc.dg/torture/pr112827-2.c: Likewise.
Juzhe-Zhong [Mon, 4 Dec 2023 08:51:06 +0000 (16:51 +0800)]
RISC-V: Remove earlyclobber from widen reduction
Since the destination of reduction is not a vector register group, there
is no need to apply overlap constraint.
Also confirm Clang:
The mir in LLVM has early clobber:
early-clobber %49:vrm2 = PseudoVWADD_VX_M1 $noreg(tied-def 0), killed %17:vr, %48:gpr, %0:gprnox0, 3, 0; example.c:59:24
The mir in LLVM doesn't have early clobber:
%48:vr = PseudoVWREDSUM_VS_M2_E8 $noreg(tied-def 0), %17:vrm2, killed %33:vr, %0:gprnox0, 3, 1; example.c:60:26
And also confirm both:
vwredsum.vs v24, v8, v24 and vwredsum.vs v8, v8, v24 all legal on LLVM.
Align with LLVM and honor RISC-V V spec, remove earlyclobber.
Indu Bhagat [Mon, 4 Dec 2023 09:57:34 +0000 (01:57 -0800)]
BTF: fix PR debug/112656
PR debug/112656 - btf: function prototypes generated with name
With this patch, all BTF_KIND_FUNC_PROTO will appear anonymous in the
generated BTF section.
As noted in the discussion in the bugzilla, the number of
BTF_KIND_FUNC_PROTO types output varies across targets (BPF with -mco-re
vs non-BPF targets). Hence the check in the test case merely checks
that all BTF_KIND_FUNC_PROTO appear anonymous.
gcc/ChangeLog:
PR debug/112656
* btfout.cc (btf_asm_type): Fixup ctti_name for all
BTF types of kind BTF_KIND_FUNC_PROTO.
gcc/testsuite/ChangeLog:
PR debug/112656
* gcc.dg/debug/btf/btf-function-7.c: New test.
The patch adds a small function to abstract out the detail and return
the name of the type. The patch also fixes the issue of BTF_KIND_FUNC
appearing in the comments with a 'null' string.
PR debug/112768
* btfout.cc (get_btf_type_name): New definition.
(btf_collect_datasec): Update dtd_name to the original type name
string.
(btf_asm_type_ref): Use the new get_btf_type_name function
instead.
(btf_asm_type): Likewise.
(btf_asm_func_type): Likewise.
gcc/testsuite/ChangeLog:
PR debug/112768
* gcc.dg/debug/btf/btf-function-6.c: Empty string expected with
BTF_KIND_FUNC_PROTO.
Jakub Jelinek [Mon, 4 Dec 2023 08:01:09 +0000 (09:01 +0100)]
i386: Fix rtl checking ICE in ix86_elim_entry_set_got [PR112837]
The following testcase ICEs with RTL checking, because it sets if
XINT (SET_SRC (set), 1) is UNSPEC_SET_GOT without checking if SET_SRC (set)
is actually an UNSPEC, so any time we see any other insn with PARALLEL
and a SET in it which is not an UNSPEC we ICE during RTL checking or
access there some other union member as if it was an rt_int.
The rest is just small cleanup.
2023-12-04 Jakub Jelinek <jakub@redhat.com>
PR target/112837
* config/i386/i386.cc (ix86_elim_entry_set_got): Before checking
for UNSPEC_SET_GOT check that SET_SRC is UNSPEC. Use SET_SRC and
SET_DEST macros instead of XEXP, rename vec variable to set.
Jakub Jelinek [Mon, 4 Dec 2023 08:00:18 +0000 (09:00 +0100)]
i386: Fix up signbit<mode>2 expander [PR112816]
The following testcase ICEs, because the signbit<mode>2 expander uses an
explicit SUBREG in the pattern around match_operand with register_operand
predicate. If we are unlucky enough that expansion tries to expand it
with some SUBREG as operands[1], we have two nested SUBREGs in the IL,
which is not valid and causes ICE later.
2023-12-04 Jakub Jelinek <jakub@redhat.com>
PR target/112816
* config/i386/sse.md (signbit<mode>2): Force operands[1] into a REG.
Jakub Jelinek [Mon, 4 Dec 2023 07:59:15 +0000 (08:59 +0100)]
c++: #pragma GCC unroll C++ fixes [PR112795]
foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll
during parsing calls maybe_constant_value unconditionally, which is
fine if !processing_template_decl, but can ICE otherwise.
While just calling fold_non_dependent_expr there instead could be enough
to fix the ICE (and I guess the right thing to do for backports if any),
I don't see a reason why we couldn't handle a dependent #pragma GCC unroll
argument as well, the unrolling isn't done in the FE and all the middle-end
cares about is that ANNOTATE_EXPR has a 1..65534 last operand when it is
annot_expr_unroll_kind.
So, the following patch changes all the unsigned short unroll arguments
to tree unroll (and thus avoids the tree -> unsigned short -> tree
conversions), does the type and value checking during parsing only if
the argument isn't dependent and repeats it during instantiation.
2023-12-04 Jakub Jelinek <jakub@redhat.com>
PR c++/112795
gcc/cp/
* cp-tree.h (cp_convert_range_for): Change UNROLL type from
unsigned short to tree.
(finish_while_stmt_cond, finish_do_stmt, finish_for_cond): Likewise.
* parser.cc (cp_parser_statement): Pass NULL_TREE rather than 0 to
cp_parser_iteration_statement UNROLL argument.
(cp_parser_for, cp_parser_c_for): Change UNROLL type from
unsigned short to tree.
(cp_parser_range_for): Likewise. Set RANGE_FOR_UNROLL to just UNROLL
rather than build_int_cst from it.
(cp_convert_range_for, cp_parser_iteration_statement): Change UNROLL
type from unsigned short to tree.
(cp_parser_omp_loop_nest): Pass NULL_TREE rather than 0 to
cp_parser_range_for UNROLL argument.
(cp_parser_pragma_unroll): Return tree rather than unsigned short.
If parsed expression is type dependent, just return it, don't diagnose
issues with value if it is value dependent.
(cp_parser_pragma): Change UNROLL type from unsigned short to tree.
* semantics.cc (finish_while_stmt_cond): Change UNROLL type from
unsigned short to tree. Build ANNOTATE_EXPR with UNROLL as its last
operand rather than build_int_cst from it.
(finish_do_stmt, finish_for_cond): Likewise.
* pt.cc (tsubst_stmt) <case RANGE_FOR_STMT>: Change UNROLL type from
unsigned short to tree and set it to RECUR on RANGE_FOR_UNROLL (t).
(tsubst_expr) <case ANNOTATE_EXPR>: For annot_expr_unroll_kind repeat
checks on UNROLL value from cp_parser_pragma_unroll.
gcc/testsuite/
* g++.dg/ext/unroll-5.C: New test.
* g++.dg/ext/unroll-6.C: New test.
Kito Cheng [Mon, 27 Nov 2023 14:01:44 +0000 (22:01 +0800)]
RISC-V: Refactor riscv_implied_info_t to make it able to handle conditional implication [NFC]
RISC-V ISA implication rules become little bit complicated than before,
it may come with condition, so this commit extend the capability of
riscv_implied_info_t, also make it more...C++ize.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_implied_predicator_t): New.
(riscv_implied_info_t::riscv_implied_info_t): New.
(riscv_implied_info_t::match): New.
(riscv_implied_info): New entry for zcf.
(riscv_subset_list::handle_implied_ext): Use
riscv_implied_info_t::match.
(riscv_subset_list::check_implied_ext): Ditto.
(riscv_subset_list::handle_combine_ext): Ditto.
(riscv_subset_list::parse): Move zcf implication handling to
riscv_implied_infos.
Gaius Mulley [Mon, 4 Dec 2023 01:35:46 +0000 (01:35 +0000)]
PR modula2/112825: modula2 builds target objects as part of all-gcc
This patch fixes the PR modula2/112825 which fails if the target
assembler is not present on the host. This can be seen if the
build invokes make all-gcc. m2 should not attempt to generate
target libraries when performing make all-gcc.
Prior to this patch it generated build/gcc/m2/gm2-libs/SYSTSEM.def
using the script gcc/m2/tools-src/makeSystem (and gm2 -c).
makeSystem should exec gm2 -S instead (and other flags)
to generate the list of target data types without requiring any
target tools. The target types emitted are textually converted
into SYSTEM.def.
gcc/m2/ChangeLog:
PR modula2/112825
* tools-src/makeSystem: Change all occurrences of -c to -S.
Jakub Jelinek [Sun, 3 Dec 2023 19:03:27 +0000 (20:03 +0100)]
testsuite: Fix up gcc.target/aarch64/pr112406.c for modern C [PR112406]
On Fri, Nov 17, 2023 at 02:04:01PM +0100, Robin Dapp wrote:
> > Yes, your version is also OK.
>
> The attached was bootstrapped and regtested on aarch64, x86 and
> regtested on riscv. Going to commit it later unless somebody objects.
Unfortunately the aarch64/pr112406.c was reduced too much and is rejected
since the switch to modern C patchset.
The following patch fixes that, I've verified the testcase
before/after the changes still ICEs in r14-5563 and doesn't with
r14-5564 and after the changes compiles fine with even latest trunk.
Everything admittedly with a cross-compiler, but that shouldn't change
anything.
Note, one of the modern C changes is that at least when people use
cvise/creduce/delta scripts which ensure no further errors are introduced
during the reduction then expected originally such reductions will not
appear anymore.
2023-12-03 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112406
* gcc.target/aarch64/pr112406.c (MagickPixelPacket): Add missing
semicolon.
(GetImageChannelMoments_image): Avoid using implicit int.
(SetMagickPixelPacket): Use void return type instead of implicit int.
(GetImageChannelMoments): Likewise. Use __builtin_atan instead of
atan.
Jakub Jelinek [Sun, 3 Dec 2023 16:54:03 +0000 (17:54 +0100)]
lower-bitint: Fix up lower_addsub_overflow [PR112807]
lower_addsub_overflow uses handle_cast or handle_operand to extract current
limb from the operands. Both of those functions heavily assume that they
return a large or huge BITINT_TYPE. The problem in the testcase is that
this is violated. Normally, lower_addsub_overflow isn't even called if
neither the return's type element type nor any of the operand is large/huge
BITINT_TYPE (on x86_64 129+ bits), for middle BITINT_TYPE (on x86_64 65-128
bits) some other code casts such operands to {,unsigned }__int128.
In the testcase the result is complex unsigned, so small, but one of the
arguments is _BitInt(256), so lower_addsub_overflow is called. But
range_for_prec asks the ranger for ranges of the operands and in this
case the first argument has [0, 0xffffffff] range and second [-2, 1], so
unsigned 32-bit and signed 2-bit, and in such case the code for
handle_operand/handle_cast purposes would use the _BitInt(256) type for the
first operand (ok), but because prec3 aka maximum of result precision and
the VRP computes ranges of the arguments is 32, use cast to 32-bit
BITINT_TYPE, which is why it didn't work correctly.
The following patch ensures that in such cases we use handle_cast to the
type of the other argument.
Perhaps incrementally, we could try to optimize this in an earlier phase,
see that while the .{ADD,SUB}_OVERFLOW has large/huge _BitInt argument, as
ranger says it fits into a smaller type, add a cast of the larger argument
to the smaller precision type in which it fits. Either in
gimple_lower_bitint, or match.pd. An argument for the latter is that e.g.
complex unsigned .ADD_OVERFLOW (unsigned_long_long_arg, unsigned_arg)
where ranger says unsigned_long_long_arg fits into unsigned 32-bit could
be also more efficient as
.ADD_OVERFLOW ((unsigned) unsigned_long_long_arg, unsigned_arg)
2023-12-03 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112807
* gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow):
When choosing type0 and type1 types, if prec3 has small/middle bitint
kind, use maximum of type0 and type1's precision instead of prec3.
Jeff Law [Sun, 3 Dec 2023 05:54:46 +0000 (22:54 -0700)]
[committed] Fix gnu23-builtins-no-dfp
Last patch for the night. There's still a bit of minor fallout left in GCC
(loongarch testsuite for example). But things are looking good on the targets
I test. The plan is to start submitting the various newlib/libgloss fixes
tomorrow.
Anyway, this test was the one I was most concerned about. Basically we're
testing that on a !dfp target that the builtins are not available. It expects
a warning, but gets an error by default now. I just changed the test to use
-fpermissive, so that the test behaves as it did previously.
Jeff Law [Sun, 3 Dec 2023 05:45:48 +0000 (22:45 -0700)]
[committed] Fix build of libgcc on ports using FDPIC
read_encoded_value_with_base has an ifdef'd code path conditional on __FDPIC__
which was calling _Unwind_gnu_Find_got without a prototype. This naturally
caused various build failures.
Jeff Law [Sun, 3 Dec 2023 05:16:33 +0000 (22:16 -0700)]
[committed] Fix a few arc tests
Similar to others. Where it's easy to fix the implicit types or add prototypes
I did. One was just ugly and I didn't want to think too hard, so I just added
-fpermissive.
Jeff Law [Sun, 3 Dec 2023 05:12:55 +0000 (22:12 -0700)]
[committed] Fix nios2 tests
The nios2 port has two tests that are affected by the recent changes. In
cdx-ldstwm-1.c it was easiest to just add -fpermissive. for cdx-ldstwm-2.c
adding an prototype for exit and abort is all that's needed.
Jeff Law [Sun, 3 Dec 2023 05:07:59 +0000 (22:07 -0700)]
[committed] Fix rx build failure in libgcc
The rx port has a bunch of what I presume are ABI compatibility functions in
libgcc. Those compatibility functions routines such as __eqdf2 from libgcc,
but without a prototype. This patch adds the missing prototypes.
Jeff Law [Sun, 3 Dec 2023 05:03:28 +0000 (22:03 -0700)]
[committed] Fix minor testsuite problems on H8 after C99 changes
Two minor regressions on the H8 were triggered by the C99 changes. First
pr58400.c has several functions without prototypes. I just added -fpermissive
to that test. Second pr17306-2.c has a single call to an unprototyped function
for which I added the prototype.
Jeff Law [Sun, 3 Dec 2023 04:54:36 +0000 (21:54 -0700)]
[committed] Fix frv build after C99 changes
Two issues prevent the frv-elf port from building after the C99 changes. First
the trampoline code emitted into libgcc has calls to exit, but no prototype.
Adding a trivial prototype for exit() into the macro fixes that little goof.
Second, frvbegin.c has a call to atexit, so a quick prototype is added into
frvbegin.c to fix that problem.
That's enough to get the compiler building again.
gcc/
* config/frv/frv.h (TRANSFER_FROM_TRAMPOLINE): Add prototype for exit.
Alexandre Oliva [Sat, 2 Dec 2023 17:14:02 +0000 (14:14 -0300)]
libsupc++: try cxa_thread_atexit_impl at runtime
g++.dg/tls/thread_local-order2.C fails when the toolchain is built for
a platform that lacks __cxa_thread_atexit_impl, even if the program is
built and run using that toolchain on a (later) platform that offers
__cxa_thread_atexit_impl.
This patch adds runtime testing for __cxa_thread_atexit_impl on
platforms that support weak symbols.
for libstdc++-v3/ChangeLog
* libsupc++/atexit_thread.cc [__GXX_WEAK__]: Add dynamic
detection of __cxa_thread_atexit_impl.
Harald Anlauf [Fri, 1 Dec 2023 21:44:30 +0000 (22:44 +0100)]
Fortran: deferred-length character optional dummy arguments [PR93762,PR100651]
gcc/fortran/ChangeLog:
PR fortran/93762
PR fortran/100651
* trans-array.cc (gfc_trans_deferred_array): Add presence check
for optional deferred-length character dummy arguments.
* trans-expr.cc (gfc_conv_missing_dummy): The character length for
deferred-length dummy arguments is passed by reference, so that
its value can be returned. Adjust handling for optional dummies.
gcc/testsuite/ChangeLog:
PR fortran/93762
PR fortran/100651
* gfortran.dg/optional_deferred_char_1.f90: New test.
This patch does the same for other callers in the file.
gcc/
* attribs.cc (comp_type_attributes): Pass the full TREE_PURPOSE
to lookup_attribute_spec, rather than just the name.
(remove_attributes_matching): Likewise.
attribs: Consider namespaces when comparing attributes
decl_attributes and comp_type_attributes both had code that
iterated over one list of attributes and looked for coresponding
attributes in another list. This patch makes those lookups
namespace-aware.
gcc/
* attribs.cc (find_same_attribute): New function.
(decl_attributes, comp_type_attributes): Use it when looking
up one list's attributes in another list.
Later patches add more calls to get_attribute_namespace.
For scoped attributes, this is a simple operation on tree pointers.
But for normal GNU attributes (the vast majority), it involves a
call to get_identifier ("gnu"). This patch caches the identifier
for speed.
gcc/
* Makefile.in (GTFILES): Add attribs.cc.
* attribs.cc (gnu_namespace_cache): New variable.
(get_gnu_namespace): New function.
(lookup_attribute_spec): Use it instead of get_identifier ("gnu").
(get_attribute_namespace, attribs_cc_tests): Likewise.
When I tried to use config-list.mk, the build for every triple except
the build machine's failed for m2. This is because, unlike other
languages, m2 builds target objects during all-gcc. The build will
therefore fail unless you have access to an appropriate binutils
(or an equivalent). That's quite a big ask for over 100 targets. :)
This patch therefore makes m2 an optional inclusion.
Doing that wasn't entirely straightforward though. The current
configure line includes "--enable-languages=all,...", which means
that the "..." can only force languages to be added that otherwise
wouldn't have been. (I.e. the only effect of the "..." is to
override configure autodetection.)
The choice of all,ada and:
# Make sure you have a recent enough gcc (with ada support) in your path so
# that --enable-werror-always will work.
make it clear that lack of GNAT should be a build failure rather than
silently ignored. This predates the D frontend, which requires GDC
in the same way that Ada requires GNAT. I don't know of a reason
why D should be treated differently.
The patch therefore expands the "all" into a specific list of
languages.
That in turn meant that Fortran had to be handled specially,
since bpf and mmix don't support Fortran.
Perhaps there's an argument that m2 shouldn't build target objects
during all-gcc, but (a) it works for practical usage and (b) the
patch is an easy workaround. I'd be happy for the patch to be
reverted if the build system changes.
contrib/
* config-list.mk (OPT_IN_LANGUAGES): New variable.
($(LIST)): Replace --enable-languages=all with a specifc list.
Disable fortran on bpf and mmix. Enable the languages in
OPT_IN_LANGUAGES.
All of the attributes in these tables go in the "gnu" namespace.
This means that they can use the traditional GNU __attribute__((...))
syntax and the standard [[gnu::...]] syntax.
Standard attributes are registered dynamically with a null namespace.
There are no supported attributes in other namespaces (clang, vendor
namespaces, etc.).
This patch tries to generalise things by making the namespace
part of the attribute specification.
It's usual for multiple attributes to be defined in the same namespace,
so rather than adding the namespace to each individual definition,
it seemed better to group attributes in the same namespace together.
This would also allow us to reuse the same table for clang attributes
that are written with the GNU syntax, or other similar situations
where the attribute can be accessed via multiple "spellings".
The patch therefore adds a scoped_attribute_specs that contains
a namespace and a list of attributes in that namespace.
It's still possible to have multiple scoped_attribute_specs
for the same namespace. E.g. it makes sense to keep the
C++-specific, C/C++-common, and format-related attributes in
separate tables, even though they're all GNU attributes.
Current lists of attributes are terminated by a null name.
Rather than keep that for the new structure, it seemed neater
to use an array_slice. This also makes the tables slighly more
compact.
In general, a target might want to support attributes in multiple
namespaces. Rather than have a separate hook for each possibility
(like the three langhooks above), it seemed better to make
TARGET_ATTRIBUTE_TABLE a table of tables. Specifically, it's
an array_slice of scoped_attribute_specs.
We can do the same thing for langhooks, which allows the three hooks
above to be merged into a single LANG_HOOKS_ATTRIBUTE_TABLE.
It also allows the standard attributes to be registered statically
and checked by the usual attribs.cc checks.
The patch adds a TARGET_GNU_ATTRIBUTES helper for the common case
in which a target wants a single table of gnu attributes. It can
only be used if the table is free of preprocessor directives.
There are probably other things we need to do to make vendor namespaces
work smoothly. E.g. in principle it would be good to make exclusion
sets namespace-aware. But to some extent we have that with standard
vs. gnu attributes too. This patch is just supposed to be a first step.
gcc/
* attribs.h (scoped_attribute_specs): New structure.
(register_scoped_attributes): Take a reference to a
scoped_attribute_specs instead of separate namespace and array
parameters.
* plugin.h (register_scoped_attributes): Likewise.
* attribs.cc (register_scoped_attributes): Likewise.
(attribute_tables): Change into an array of scoped_attribute_specs
pointers. Reduce to 1 element for frontends and 1 element for targets.
(empty_attribute_table): Delete.
(check_attribute_tables): Update for changes to attribute_tables.
Use a hash_set to identify duplicates.
(handle_ignored_attributes_option): Update for above changes.
(init_attributes): Likewise.
(excl_pair): Delete.
(test_attribute_exclusions): Update for above changes. Don't
enforce symmetry for standard attributes in the top-level namespace.
* langhooks-def.h (LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Delete.
(LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Likewise.
(LANG_HOOKS_INITIALIZER): Update accordingly.
(LANG_HOOKS_ATTRIBUTE_TABLE): Define to an empty constructor.
* langhooks.h (lang_hooks::common_attribute_table): Delete.
(lang_hooks::format_attribute_table): Likewise.
(lang_hooks::attribute_table): Redefine to an array of
scoped_attribute_specs pointers.
* target-def.h (TARGET_GNU_ATTRIBUTES): New macro.
* target.def (attribute_spec): Redefine to return an array of
scoped_attribute_specs pointers.
* tree-inline.cc (function_attribute_inlinable_p): Update accordingly.
* doc/tm.texi: Regenerate.
* config/aarch64/aarch64.cc (aarch64_attribute_table): Define using
TARGET_GNU_ATTRIBUTES.
* config/alpha/alpha.cc (vms_attribute_table): Likewise.
* config/avr/avr.cc (avr_attribute_table): Likewise.
* config/bfin/bfin.cc (bfin_attribute_table): Likewise.
* config/bpf/bpf.cc (bpf_attribute_table): Likewise.
* config/csky/csky.cc (csky_attribute_table): Likewise.
* config/epiphany/epiphany.cc (epiphany_attribute_table): Likewise.
* config/gcn/gcn.cc (gcn_attribute_table): Likewise.
* config/h8300/h8300.cc (h8300_attribute_table): Likewise.
* config/loongarch/loongarch.cc (loongarch_attribute_table): Likewise.
* config/m32c/m32c.cc (m32c_attribute_table): Likewise.
* config/m32r/m32r.cc (m32r_attribute_table): Likewise.
* config/m68k/m68k.cc (m68k_attribute_table): Likewise.
* config/mcore/mcore.cc (mcore_attribute_table): Likewise.
* config/microblaze/microblaze.cc (microblaze_attribute_table):
Likewise.
* config/mips/mips.cc (mips_attribute_table): Likewise.
* config/msp430/msp430.cc (msp430_attribute_table): Likewise.
* config/nds32/nds32.cc (nds32_attribute_table): Likewise.
* config/nvptx/nvptx.cc (nvptx_attribute_table): Likewise.
* config/riscv/riscv.cc (riscv_attribute_table): Likewise.
* config/rl78/rl78.cc (rl78_attribute_table): Likewise.
* config/rx/rx.cc (rx_attribute_table): Likewise.
* config/s390/s390.cc (s390_attribute_table): Likewise.
* config/sh/sh.cc (sh_attribute_table): Likewise.
* config/sparc/sparc.cc (sparc_attribute_table): Likewise.
* config/stormy16/stormy16.cc (xstormy16_attribute_table): Likewise.
* config/v850/v850.cc (v850_attribute_table): Likewise.
* config/visium/visium.cc (visium_attribute_table): Likewise.
* config/arc/arc.cc (arc_attribute_table): Likewise. Move further
down file.
* config/arm/arm.cc (arm_attribute_table): Update for above changes,
using...
(arm_gnu_attributes, arm_gnu_attribute_table): ...these new globals.
* config/i386/i386-options.h (ix86_attribute_table): Delete.
(ix86_gnu_attribute_table): Declare.
* config/i386/i386-options.cc (ix86_attribute_table): Replace with...
(ix86_gnu_attributes, ix86_gnu_attribute_table): ...these two globals.
* config/i386/i386.cc (ix86_attribute_table): Define as an array of
scoped_attribute_specs pointers.
* config/ia64/ia64.cc (ia64_attribute_table): Update for above changes,
using...
(ia64_gnu_attributes, ia64_gnu_attribute_table): ...these new globals.
* config/rs6000/rs6000.cc (rs6000_attribute_table): Update for above
changes, using...
(rs6000_gnu_attributes, rs6000_gnu_attribute_table): ...these new
globals.
gcc/ada/
* gcc-interface/gigi.h (gnat_internal_attribute_table): Change
type to scoped_attribute_specs.
* gcc-interface/utils.cc (gnat_internal_attribute_table): Likewise,
using...
(gnat_internal_attributes): ...this as the underlying array.
* gcc-interface/misc.cc (gnat_attribute_table): New global.
(LANG_HOOKS_ATTRIBUTE_TABLE): Use it.
gcc/c-family/
* c-common.h (c_common_attribute_table): Replace with...
(c_common_gnu_attribute_table): ...this.
(c_common_format_attribute_table): Change type to
scoped_attribute_specs.
* c-attribs.cc (c_common_attribute_table): Replace with...
(c_common_gnu_attributes, c_common_gnu_attribute_table): ...these
new globals.
(c_common_format_attribute_table): Change type to
scoped_attribute_specs, using...
(c_common_format_attributes): ...this as the underlying array.
gcc/c/
* c-tree.h (std_attribute_table): Declare.
* c-decl.cc (std_attribute_table): Change type to
scoped_attribute_specs, using...
(std_attributes): ...this as the underlying array.
(c_init_decl_processing): Remove call to register_scoped_attributes.
* c-objc-common.h (c_objc_attribute_table): New global.
(LANG_HOOKS_ATTRIBUTE_TABLE): Use it.
(LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Delete.
(LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Delete.
gcc/cp/
* cp-tree.h (cxx_attribute_table): Delete.
(cxx_gnu_attribute_table, std_attribute_table): Declare.
* cp-objcp-common.h (LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Delete.
(LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Delete.
(cp_objcp_attribute_table): New table.
(LANG_HOOKS_ATTRIBUTE_TABLE): Redefine.
* tree.cc (cxx_attribute_table): Replace with...
(cxx_gnu_attributes, cxx_gnu_attribute_table): ...these globals.
(std_attribute_table): Change type to scoped_attribute_specs, using...
(std_attributes): ...this as the underlying array.
(init_tree): Remove call to register_scoped_attributes.
gcc/d/
* d-tree.h (d_langhook_attribute_table): Replace with...
(d_langhook_gnu_attribute_table): ...this.
(d_langhook_common_attribute_table): Change type to
scoped_attribute_specs.
* d-attribs.cc (d_langhook_common_attribute_table): Change type to
scoped_attribute_specs, using...
(d_langhook_common_attributes): ...this as the underlying array.
(d_langhook_attribute_table): Replace with...
(d_langhook_gnu_attributes, d_langhook_gnu_attribute_table): ...these
new globals.
(uda_attribute_p): Update accordingly, and update for new
targetm.attribute_table type.
* d-lang.cc (d_langhook_attribute_table): New global.
(LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Delete.
gcc/fortran/
* f95-lang.cc: Include attribs.h.
(gfc_attribute_table): Change to an array of scoped_attribute_specs
pointers, using...
(gfc_gnu_attributes, gfc_gnu_attribute_table): ...these new globals.
gcc/jit/
* dummy-frontend.cc (jit_format_attribute_table): Change type to
scoped_attribute_specs, using...
(jit_format_attributes): ...this as the underlying array.
(jit_attribute_table): Change to an array of scoped_attribute_specs
pointers, using...
(jit_gnu_attributes, jit_gnu_attribute_table): ...these new globals
for the original array. Include the format attributes.
(LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Delete.
(LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Delete.
(LANG_HOOKS_ATTRIBUTE_TABLE): Define.
gcc/lto/
* lto-lang.cc (lto_format_attribute_table): Change type to
scoped_attribute_specs, using...
(lto_format_attributes): ...this as the underlying array.
(lto_attribute_table): Change to an array of scoped_attribute_specs
pointers, using...
(lto_gnu_attributes, lto_gnu_attribute_table): ...these new globals
for the original array. Include the format attributes.
(LANG_HOOKS_COMMON_ATTRIBUTE_TABLE): Delete.
(LANG_HOOKS_FORMAT_ATTRIBUTE_TABLE): Delete.
(LANG_HOOKS_ATTRIBUTE_TABLE): Define.
Roger Sayle [Sat, 2 Dec 2023 11:15:14 +0000 (11:15 +0000)]
RISC-V: Improve style to work around PR 60994 in host compiler.
This simple patch allows me to build a cross-compiler to riscv using
older versions of RedHat's system compiler. The issue is PR c++/60994
where g++ doesn't like the same name (demand_flags) to be used by both
a variable and a (enumeration) type, which is also undesirable from a
(GNU) coding style perspective. One solution is to rename the type
to demand_flags_t, but a less invasive change is to simply use another
identifier for the problematic local variable, renaming demand_flags
to dflags.
2023-12-02 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/riscv/riscv-vsetvl.cc (csetvl_info::parse_insn): Rename
local variable from demand_flags to dflags, to avoid conflicting
with (enumeration) type of the same name.
For vector constant extract-{even/odd} permutation replace the default
[x]vshuf instruction combination with [x]vilv{l/h} instruction, which
can reduce instructions and improves performance.
Li Wei [Tue, 28 Nov 2023 07:38:37 +0000 (15:38 +0800)]
LoongArch: Accelerate optimization of scalar signed/unsigned popcount.
In LoongArch, the vector popcount has corresponding instructions, while
the scalar does not. Currently, the scalar popcount is calculated
through a loop, and the value of a non-power of two needs to be iterated
several times, so the vector popcount instruction is considered for
optimization.
gcc/ChangeLog:
* config/loongarch/loongarch.md (v2di): Used to simplify the
following templates.
(popcount<mode>2): New.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/popcnt.c: New test.
* gcc.target/loongarch/popcount.c: New test.
chenxiaolong [Tue, 28 Nov 2023 08:23:53 +0000 (16:23 +0800)]
LoongArch: Added vectorized hardware inspection for testsuite.
When GCC regression tests are executed on a cpu that does not support
vectorization, the loongarch/vector directory will have some FAIL entries for
all test cases related to vectorization runs. In order to solve this kind
of problem, a vectorized hardware detection function was added to the code,
which can only be compiled but not run.
Li Wei [Tue, 28 Nov 2023 07:56:35 +0000 (15:56 +0800)]
LoongArch: Remove duplicate definition of CLZ_DEFINED_VALUE_AT_ZERO.
In the r14-5547 commit, C[LT]Z_DEFINED_VALUE_AT_ZERO were defined at
the same time, but in fact, CLZ_DEFINED_VALUE_AT_ZERO has already been
defined, so remove the duplicate definition.
We first force_reg such CONST_INT (within 32bit value) into a SImode reg.
Then use such special patterns.
Those pattern with this operand match should only value on! TARGET_64BIT.
The PR112801 combine into such patterns on RV64 incorrectly (Those patterns should be only value on RV32).
This is the bug:
andi a2,a2,2
vsetivli zero,2,e64,m1,ta,ma
sext.w a3,a4
vmv.v.x v1,a2
vslide1down.vx v1,v1,a4 -> it should be a3 instead of a4.
Such incorrect codegen is caused by
...
(sign_extend:DI (subreg:SI (reg:DI 135 [ f.0_3 ]) 0))
] UNSPEC_VSLIDE1DOWN)) 16935 {*pred_slide1downv2di_extended}
...
Incorretly combine into the patterns should not be valid on RV64 system.
So add !TARGET_64BIT to all same type patterns which can fix such issue as well as robostify the vector.md.
PR target/112801
gcc/ChangeLog:
* config/riscv/vector.md: Add !TARGET_64BIT.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr112801.c: New test.
Pan Li [Thu, 30 Nov 2023 07:08:50 +0000 (15:08 +0800)]
RISC-V: Bugfix for legitimize move when get vec mode in zve32f
If we want to extract 64bit value but ELEN < 64, we use RVV
vector mode with EEW = 32 to extract the highpart and lowpart.
However, this approach doesn't honor DFmode when movdf pattern
when ZVE32f and of course results in ICE when zve32f.
This patch would like to reuse the approach with some additional
handing, consider lowpart bits is meaningless for FP mode, we need
one int reg as bridge here. For example:
rtx tmp = gen_rtx_reg (DImode)
reg:DI = reg:DF (fmv.d.x) // Move DF reg to DI
...
perform the extract for high and low parts
...
reg:DF = reg:DI (fmv.x.d) // Move DI reg back to DF after all done
PR target/112743
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_move): Take the
exist (U *mode) and handle DFmode like DImode when EEW is
32bits for ZVE32F.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112743-2.c: New test.
Harald Anlauf [Thu, 30 Nov 2023 20:53:21 +0000 (21:53 +0100)]
Fortran: copy-out for possibly missing OPTIONAL CLASS arguments [PR112772]
gcc/fortran/ChangeLog:
PR fortran/112772
* trans-expr.cc (gfc_conv_class_to_class): Make copy-out conditional
on the presence of an OPTIONAL CLASS argument passed to an OPTIONAL
CLASS dummy.
gcc/testsuite/ChangeLog:
PR fortran/112772
* gfortran.dg/missing_optional_dummy_7.f90: New test.
Jason Merrill [Mon, 25 Sep 2023 09:15:02 +0000 (10:15 +0100)]
c++: mangle function template constraints
Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and
https://github.com/itanium-cxx-abi/cxx-abi/pull/166
We need to mangle constraints to be able to distinguish between function
templates that only differ in constraints. From the latter link, we want to
use the template parameter mangling previously specified for lambdas to also
make explicit the form of a template parameter where the argument is not a
"natural" fit for it, such as when the parameter is constrained or deduced.
I'm concerned about how the latter link changes the mangling for some C++98
and C++11 patterns, so I've limited template_parm_natural_p to avoid two
cases found by running the testsuite with -Wabi forced on:
template <class T, T V> T f() { return V; }
int main() { return f<int,42>(); }
template <int i> int max() { return i; }
template <int i, int j, int... rest> int max()
{
int sub = max<j, rest...>();
return i > sub ? i : sub;
}
int main() { return max<1,2,3>(); }
A third C++11 pattern is changed by this patch:
template <template <typename...> class TT, typename... Ts> TT<Ts...> f();
template <typename> struct A { };
int main() { f<A,int>(); }
I aim to resolve these with the ABI committee before GCC 14.1.
We also need to resolve https://github.com/itanium-cxx-abi/cxx-abi/issues/38
(mangling references to dependent template-ids where the name is fully
resolved) as references to concepts in std:: will consistently run into this
area. This is why mangle-concepts1.C only refers to concepts in the global
namespace so far.
The library changes are to avoid trying to mangle builtins, which fails.
Demangler support and test coverage is not complete yet.
Alexandre Oliva [Fri, 1 Dec 2023 17:31:22 +0000 (14:31 -0300)]
hardcfr: make builtin_return tests more portable [PR112334]
Rework __builtin_return tests to explicitly call __builtin_apply and
use its return value rather than anything else. Also require
untyped_assembly. Avoid the noise out of exceptions escaping the
builtin-applied function, but add a test to cover their effects as
well.
[PR112445][LRA]: Fix "unable to find a register to spill" error
PR112445 is a very complicated bug occurring from interaction of
constraint subpass, inheritance, and hard reg live range splitting.
It is hard to debug this PR only from LRA standard logs. Therefore I
added dumping all func insns at the end of complicated sub-passes
(constraint, inheritance, undoing inheritance, hard reg live range
splitting, and rematerialization). As such output can be quite big,
it is switched only one level 7 of -fira-verbose value. The reason
for the bug is a skip of live-range splitting of hard reg (dx) on the
1st live range splitting subpass. Splitting is done for reload
pseudos around an original insn and its reload insns but the subpass
did not recognize such insn pattern because previous inheritance and
undoing inheritance subpasses extended a bit reload pseudo live range.
Although we undid inheritance in question, the result code was a bit
different from a code before the corresponding inheritance pass. The
following fixes the bug by restoring exact code before the
inheritance.
gcc/ChangeLog:
PR target/112445
* lra.h (lra): Add one more arg.
* lra-int.h (lra_verbose, lra_dump_insns): New externals.
(lra_dump_insns_if_possible): Ditto.
* lra.cc (lra_dump_insns): Dump all insns.
(lra_dump_insns_if_possible): Dump all insns for lra_verbose >= 7.
(lra_verbose): New global.
(lra): Add new arg. Setup lra_verbose from its value.
* lra-assigns.cc (lra_split_hard_reg_for): Dump insns if rtl
was changed.
* lra-remat.cc (lra_remat): Dump insns if rtl was changed.
* lra-constraints.cc (lra_inheritance): Dump insns.
(lra_constraints, lra_undo_inheritance): Dump insns if rtl
was changed.
(remove_inheritance_pseudos): Use restore reg if it is set up.
* ira.cc: (lra): Pass internal_flag_ira_verbose.
gcc/testsuite/ChangeLog:
PR target/112445
* gcc.target/i386/pr112445.c: New test.
Jakub Jelinek [Fri, 1 Dec 2023 15:57:30 +0000 (16:57 +0100)]
extend.texi: Fix up defbuiltin* with spaces in return type
In https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fstdc_005fbit_005ffloor
I've noticed that while e.g. __builtin_stdc_bit_floor builtin is properly
rendered in bold and bigger size, for the __builtin_stdc_bit_width builtin
it is not the builtin name which is marked like that, but the keyword int
before it. Also, seems such builtins are missing from the index.
I've read the texinfo docs and they seem to suggest in
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Line-Macros.html
that return types of functions with spaces in the return type should be
wrapped with {}s and we already use that e.g. in
@defbuiltin{{void *} __builtin_thread_pointer (void)}
The following patch adjusts builtins I found which contained one or two
spaces in the return type name (plus two spots which used 2 spaces after
single keyword return type instead of 1 which triggered my search regex as
well).
2023-12-01 Jakub Jelinek <jakub@redhat.com>
* doc/extend.texi (__builtin_addc, __builtin_addcl, __builtin_addcll,
__builtin_subc, __builtin_subcl, __builtin_subcll,
__builtin_stdc_bit_width, __builtin_stdc_count_ones,
__builtin_stdc_count_zeros, __builtin_stdc_first_leading_one,
__builtin_stdc_first_leading_zero, __builtin_stdc_first_trailing_one,
__builtin_stdc_first_trailing_zero, __builtin_stdc_has_single_bit,
__builtin_stdc_leading_ones, __builtin_stdc_leading_zeros,
__builtin_stdc_trailing_ones, __builtin_stdc_trailing_zeros,
__builtin_nvptx_brev, __builtin_nvptx_brevll, __builtin_darn,
__builtin_darn_raw, __builtin_ia32_vec_ext_v2di,
__builtin_ia32_crc32qi, __builtin_ia32_crc32hi,
__builtin_ia32_crc32si, __builtin_ia32_crc32di): Put {}s around
return type with spaces in it.
(__builtin_rx_mvfachi, __builtin_rx_mvfacmi): Remove superfluous
whitespace.
Rainer Orth [Fri, 1 Dec 2023 15:47:28 +0000 (16:47 +0100)]
ada: Fix Ada bootstrap on macOS
The recent warning changes broke Ada bootstrap on macOS:
adaint.c: In function '__gnat_copy_attribs':
adaint.c:3336:10: error: implicit declaration of function 'utimes'; did you
mean 'utime'? [-Wimplicit-function-declaration]
3336 | if (utimes (to, tbuf) == -1) {
| ^~~~~~
| utime
adaint.c: In function '__gnat_kill':
adaint.c:3597:3: error: implicit declaration of function 'kill'
[-Wimplicit-function-declaration]
3597 | kill (pid, sig);
| ^~~~
terminals.c: In function 'allocate_pty_desc':
terminals.c:1196:12: error: implicit declaration of function 'openpty'; did
you mean 'openat'? [-Wimplicit-function-declaration]
1196 | status = openpty (&master_fd, &slave_fd, NULL, NULL, NULL);
| ^~~~~~~
| openat
terminals.c: In function '__gnat_setup_winsize':
terminals.c:1392:6: error: implicit declaration of function 'kill'
[-Wimplicit-function-declaration]
1392 | kill (desc->child_pid, SIGWINCH);
| ^~~~
This patch fixes this by including the necessary headers: <sys/time.h>
for utimes, <signal.h> for kill, and <util.h> for openpty. With those
changes, the build completed on x86_64-apple-darwin2[0-3] (make check
still running).
David Malcolm [Fri, 1 Dec 2023 13:47:41 +0000 (08:47 -0500)]
diagnostics, analyzer: add optional per-diagnostic property bags to SARIF
I've found it useful in debugging the analyzer for the SARIF output to
contain extra analyzer-specific data in each diagnostic.
This patch:
* adds a way for a diagnostic_metadata to populate a property
bag within a SARIF "result" object based on a new vfunc
* reworks how diagnostics are emitted within the analyzer so
that a custom diagnostic_metadata subclass is used, which populates
the property bag with information from the saved_diagnostic, and with
a vfunc hook allowing for per-pending_diagnotic-subclass extra
properties.
Doing so makes it trivial to go from the SARIF output back to
pertinent parts of the analyzer's internals (e.g. the index of
the diagnostic within the ana::diagnostic_manager, the index of
the ana::exploded_node, etc).
It also replaces a lot of boilerplate in the "emit" implementations
in the various pending_diagnostics subclasses. In particular, doing
so fixes missing CVE metadata for -Wanalyzer-fd-phase-mismatch (where
sm-fd.cc's fd_phase_mismatch::emit was failing to use its
diagnostic_metadata instance).
gcc/analyzer/ChangeLog:
* analyzer.h (class saved_diagnostic): New forward decl.
* bounds-checking.cc: Update for changes to
pending_diagnostic::emit.
* call-details.cc: Likewise.
* diagnostic-manager.cc: Include "diagnostic-format-sarif.h".
(saved_diagnostic::maybe_add_sarif_properties): New.
(class pending_diagnostic_metadata): New.
(diagnostic_manager::emit_saved_diagnostic): Create a
pending_diagnostic_metadata and a diagnostic_emission_context.
Pass the latter to the pending_diagnostic::emit vfunc.
* diagnostic-manager.h
(saved_diagnostic::maybe_add_sarif_properties): New decl.
* engine.cc: Update for changes to pending_diagnostic::emit.
* infinite-loop.cc: Likewise.
* infinite-recursion.cc: Likewise.
* kf-analyzer.cc: Likewise.
* kf.cc: Likewise.
* pending-diagnostic.cc
(diagnostic_emission_context::get_pending_diagnostic): New.
(diagnostic_emission_context::warn): New.
(diagnostic_emission_context::inform): New.
* pending-diagnostic.h (class diagnostic_emission_context): New.
(pending_diagnostic::emit): Update params.
(pending_diagnostic::maybe_add_sarif_properties): New vfunc.
* region.cc: Don't include "diagnostic-metadata.h".
* region-model.cc: Include "diagnostic-format-sarif.h". Update
for changes to pending_diagnostic::emit.
(exposure_through_uninit_copy::maybe_add_sarif_properties): New.
* sm-fd.cc: Update for changes to pending_diagnostic::emit.
* sm-file.cc: Likewise.
* sm-malloc.cc: Likewise.
* sm-pattern-test.cc: Likewise.
* sm-sensitive.cc: Likewise.
* sm-signal.cc: Likewise.
* sm-taint.cc: Likewise.
* store.cc: Don't include "diagnostic-metadata.h".
* varargs.cc: Update for changes to pending_diagnostic::emit.
gcc/ChangeLog:
* diagnostic-core.h (emit_diagnostic_valist): New overload decl.
* diagnostic-format-sarif.cc (sarif_builder::make_result_object):
When we have metadata, call its maybe_add_sarif_properties vfunc.
* diagnostic-metadata.h (class sarif_object): Forward decl.
(diagnostic_metadata::~diagnostic_metadata): New.
(diagnostic_metadata::maybe_add_sarif_properties): New vfunc.
* diagnostic.cc (emit_diagnostic_valist): New overload.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/fd-accept.c: Update for fix to missing CWE
metadata for -Wanalyzer-fd-phase-mismatch.
* gcc.dg/analyzer/fd-bind.c: Likewise.
* gcc.dg/analyzer/fd-socket-misuse.c: Likewise.
* gcc.dg/plugin/analyzer_cpython_plugin.c: Update for changes to
pending_diagnostic::emit.
* gcc.dg/plugin/analyzer_gil_plugin.c: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
* config/riscv/vector.md: Support highpart overlap for vx/vf.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-22.c: New test.
* gcc.target/riscv/rvv/base/pr112431-23.c: New test.
* gcc.target/riscv/rvv/base/pr112431-24.c: New test.
* gcc.target/riscv/rvv/base/pr112431-25.c: New test.
* gcc.target/riscv/rvv/base/pr112431-26.c: New test.
* gcc.target/riscv/rvv/base/pr112431-27.c: New test.
* config/riscv/vector.md: Support highpart overlap for indexed load.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr112431-28.c: New test.
* gcc.target/riscv/rvv/base/pr112431-29.c: New test.
* gcc.target/riscv/rvv/base/pr112431-30.c: New test.
* gcc.target/riscv/rvv/base/pr112431-31.c: New test.
* gcc.target/riscv/rvv/base/pr112431-32.c: New test.
* gcc.target/riscv/rvv/base/pr112431-33.c: New test.
Richard Biener [Fri, 1 Dec 2023 10:14:53 +0000 (11:14 +0100)]
Fix ambiguity between vect_get_vec_defs with/without vectype
When querying a single set of vector defs with the overloaded
vect_get_vec_defs API then when you try to use the overload with
the vector type specified the call will be ambiguous with the
variant without the vector type. The following fixes this by
re-ordering the vector type argument to come before the output
def vector argument.
I've changed vectorizable_conversion as that triggered this
so it has coverage showing this works. The motivation is to
reduce the number of (redundant) get_vectype_for_scalar_type
calls.
* tree-vectorizer.h (vect_get_vec_defs): Re-order arguments.
* tree-vect-stmts.cc (vect_get_vec_defs): Likewise.
(vectorizable_condition): Update caller.
(vectorizable_comparison_1): Likewise.
(vectorizable_conversion): Specify the vector type to be
used for invariant/external defs.
* tree-vect-loop.cc (vect_transform_reduction): Update caller.
Jakub Jelinek [Fri, 1 Dec 2023 11:45:58 +0000 (12:45 +0100)]
testsuite: Tweak some further tests for modern C changes
On IRC Richi mentioned some FAILs in gcc.target/x86_64 and in pr83126.c.
The following patch fixes the former ones (they need recent binutils to
be enabled), for pr83126.c because I didn't have graphite configured I've
just verified that the test compiles (didn't without the patch) and that
the gimple dump is identical with one from yesterday's gcc (as it was a
tree-parloops.cc ICE, I guess identical gimple is all we care about
and no need to verify it further).
2023-12-01 Jakub Jelinek <jakub@redhat.com>
* gcc.target/x86_64/abi/avx512fp16/m512h/test_passing_m512.c
(fun_check_passing_m512_8_values, fun_check_passing_m512h_8_values):
Add missing void return type.
* gcc.target/x86_64/abi/avx512fp16/m256h/test_passing_m256.c
(fun_check_passing_m256_8_values, fun_check_passing_m256h_8_values):
Likewise.
* gcc.dg/graphite/pr83126.c (ew): Add missing casts to __INTPTR_TYPE__
and then to int *.
Jakub Jelinek [Fri, 1 Dec 2023 09:56:52 +0000 (10:56 +0100)]
lower-bitint: Fix lowering of middle sized _BitInt operations which can throw [PR112770]
The middle kind _BitInt lowering is mostly done by casting the BITINT_TYPE
operands (if any) to a signed/unsigned integer type which has larger/equal
precision, using such integer type also for the lhs (if BITINT_TYPE) and
and adding a cast after the statement from that new lhs to the old
(BITINT_TYPE) lhs. Note, for middle kind this isn't done for GIMPLE_CALLs.
Most of the time that works nicely, the exception as the following testcase
shows is -fnon-call-exceptions and some operations which can trap. Because
inserting the cast to a new lhs after the statement results in a trapping
statement in the middle of a basic block.
The following patch fixes that by emitting the cast on the fallthru edge
instead.
2023-12-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112770
* gimple-lower-bitint.cc (gimple_lower_bitint): When adjusting
lhs of middle _BitInt setter which ends bb, insert cast on
the fallthru edge rather than after stmt.
Jakub Jelinek [Fri, 1 Dec 2023 09:55:49 +0000 (10:55 +0100)]
lower-bitint: Fix up handle_operand_addr for 0 constants [PR112771]
handle_operand_addr for INTEGER_CSTs uses wi::min_precision (UNSIGNED
for non-negative constants, SIGNED for negative ones) and from that
computes mp as minimum number of limbs which can represent that value,
and in some cases creates a test BITINT_TYPE with that precision to
categorize it and decide based on that what types to use on the constant
emitted into memory. For the actual precisions (what will be passed
to libgcc) it actually already uses MAX/MIN to adjust the corner cases:
*prec = MAX (min_prec, 1);
...
*prec = MIN ((int) -min_prec, -2);
but for integer_zerop min_prec will be 0,
mp = CEIL (min_prec, limb_prec) * limb_prec;
will be also 0 and we ICE trying to build unsigned BITINT_TYPE with
0 precision.
Fixed thusly by noting even 0 has to be encoded at least as one limb.
2023-12-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112771
* gimple-lower-bitint.cc (bitint_large_huge::handle_operand_addr):
Use mp = 1 if it is zero.
bpf: quote section names whenever necessary in assembly output
In BPF section names are used to encode the kind of BPF program and
other metadata, involving all sort of non alphanumeric characters.
For example:
/* use auto-attach format for section definition. */
SEC("uretprobe//proc/self/exe:trigger_func2")
int handle_uretprobe_byname(struct pt_regs *ctx)
{
uretprobe_byname_res = 6;
return 0;
}
The above requires to quote the section name in the output assembly
file, since otherwise the // in the name would be interpreted by the
assembler lexer as the beginning of a line comment.
This patch makes the BPF backend to emit quoted section names in
.section directives if the name requires to be quoted. Simple section
names whose constituent characters are in the set [0-9a-zA-Z_] are
still emitted unquoted.
Tested in target bpf-unknown-none-gcc and host x86_64-linux-gnu.
gcc/ChangeLog
* config/bpf/bpf.cc (bpf_asm_named_section): New function.
(TARGET_ASM_NAMED_SECTION): Set to bpf_asm_named_section.
gcc/testsuite/ChangeLog
* gcc.target/bpf/section-name-quoting-1.c: New test.
Di Zhao [Fri, 1 Dec 2023 08:16:40 +0000 (16:16 +0800)]
aarch64: modify Ampere CPU tunings on reassociation/FMA
1. Allow reassociation on FP additions.
2. Avoid generating loop-dependant FMA chains. Added a tuning
option 'AARCH64_EXTRA_TUNE_AVOID_CROSS_LOOP_FMA' for this.
gcc/ChangeLog:
* config/aarch64/aarch64-tuning-flags.def
(AARCH64_EXTRA_TUNING_OPTION): New tuning option to avoid
cross-loop FMA.
* config/aarch64/aarch64.cc
(aarch64_override_options_internal): Set
param_avoid_fma_max_bits according to tuning option.
* config/aarch64/tuning_models/ampere1.h (ampere1_tunings):
Modify tunings related with FMA.
* config/aarch64/tuning_models/ampere1a.h (ampere1a_tunings):
Likewise.
* config/aarch64/tuning_models/ampere1b.h (ampere1b_tunings):
Likewise.
SME will add more intrinsics whose expansion code requires
the mode of the function return value. This patch adds an
associated helper routine.
gcc/
* config/aarch64/aarch64-sve-builtins.h
(function_expander::result_mode): New member function.
* config/aarch64/aarch64-sve-builtins-base.cc
(svld234_impl::expand): Use it.
* config/aarch64/aarch64-sve-builtins.cc
(function_expander::get_reg_target): Likewise.
Jakub Jelinek [Fri, 1 Dec 2023 08:26:56 +0000 (09:26 +0100)]
lower-bitint: Fix up maximum addition/subtraction/multiplication result computations
When debugging PR112750, I've noticed some issues in the computation
of precisions and the following patch attempts to fix those.
The pass uses range_to_prec function, which possibly using ranger returns
minimum precision of some operand in the style that libgcc _BitInt
entrypoints expect, i.e. for operands with unsigned types either the
precision of that type or with help of ranger
wi::min_precision (upper_bound, UNSIGNED) (done both if the types
are really unsigned or even when lower_bound is non-negative), while
for operands with signed types either negated precision of that type or
with help of ranger negated value of maximum of SIGNED min_precisions
of lower and upper bound.
Because _BitInt in C only supports unsigned precisions >= 1 and signed
precisions >= 2, the function also ensures that 0 is never returned (returns
1 instead) and should ensure that -1 is never returned (should return -2).
That is the first bug I found though, for the ranger case it ensured that,
but if an operand would be signed 1-bit precision (that means
non-BITINT_TYPE) operand, it could return -1.
Another thing is that both lower_addsub_overflow and lower_mul_overflow
compute from the prec0 and prec1 of the operands (returned by range_to_prec
with the above value meanings) prec2, which is how many bits of the result
we actually need to compute to know the infinite precision result.
This is then used by arith_overflow function together with prec
(TYPE_PRECISION (type)), type (type of the result), prec0 and prec1 to
compute which range of bits should be tested (if any, or that there is never
an overflow) and with which kind (require those bits to be zero vs.
check if all those bits together all all zeros/ones).
The arith_overflow function has one special case, when
prec0 >= 0 && prec1 >= 0 and operation is not .SUB_OVERFLOW; in that case
we treat prec2 as minimum precision to express any infinite precision
unsigned result (the result is never negative in that case), while
in all other cases prec2 is treated as minimum precision to express
any infinite precision signed result (because the result can be also
negative).
The computations of those values were apparently incorrect for all of
.{ADD,SUB}_OVERFLOW (in that case only if one operand was signed and
the other unsigned) and for .MUL_OVERFLOW it was sometimes too large.
It took me a while to get to the right expression how to compute that,
I've started with writing into the comment the possible results for
different prec0 and prec1 values (used just 8/-8/10/-10 as placeholders
for equal or different absolute values of the 2 precisions and cases
with positive and/or negative signs) and then turned into the attached
test program that actually printed what I was writing to make sure
I didn't make mistakes in it and in the end also verified the computation,
this time for all combinations of 1..14 and -2..-14 precisions.
The UNSIGNED vs. SIGNED in the table is what arith_overflow expects
the prec2 to be (see above mentioned exception).
2023-12-01 Jakub Jelinek <jakub@redhat.com>
* gimple-lower-bitint.cc (range_to_prec): Don't return -1 for
signed types.
(bitint_large_huge::lower_addsub_overflow): Fix up computation of
prec2.
(bitint_large_huge::lower_mul_overflow): Likewise.
Jakub Jelinek [Fri, 1 Dec 2023 08:26:24 +0000 (09:26 +0100)]
lower-bitint: Fix ICE on bitint-39.c
torture/bitint-39.c ICEs with -O1; the problem is that the
finish_arith_overflow code in one spot replaces use_stmt with an
assignment or cast, but if unlucky and m_gsi iterator is the same statement,
when the code later
tree clobber = build_clobber (TREE_TYPE (var), CLOBBER_EOL);
g = gimple_build_assign (var, clobber);
gsi_insert_after (&m_gsi, g, GSI_SAME_STMT);
it will insert after iterator which contains already replaced statement and
that causes the gimple chain corruption.
2023-12-01 Jakub Jelinek <jakub@redhat.com>
* gimple-lower-bitint.cc (bitint_large_huge::finish_arith_overflow):
When replacing use_stmt which is gsi_stmt (m_gsi), update m_gsi to
the new statement.
The .{ADD,SUB}_OVERFLOW lowering is implemented by performing normal
addition/subtraction (perhaps extended to even more bits than normally by
continuing with extended values of operands after running of normal bits)
and in addition to that trying to compute if certain sets of bits are either
all zero or all sign extensions of the least significant bit.
That code is in a lot of cases guarded just by a single condition (which
can be idx > startlimb, idx >= startlimb or idx == startlimb) or by
2 conditions - if (idx >= startlimb) { if (idx == startlimb) ... else ... }
Now, if_then_if_then_else when the second argument is NULL works just as
if_then and sets m_gsi to be within the initially empty then block and that is
where we emit code for constant tidx startlimb + (cmp_code == GT_EXPR).
But in the 2 conditions case, m_gsi is set to the initially empty else
block, so using EQ_EXPR for the condition was incorrect (and strangely
nothing in the testsuite caught that), because the code for extracting the
lowest set of bits (i.e. when tidx is startlimb) is then done when idx
is not startlimb rather than when it is.
The following patch fixes that.
Note, when developing the lowering, I was using gcov to make sure all code
is covered by the testsuite with minimum exceptions, so no idea how this
slipped out.
2023-12-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/112750
* gimple-lower-bitint.cc (bitint_large_huge::lower_addsub_overflow):
Use NE_EXPR rather than EQ_EXPR for g2 if !single_comparison and
adjust probabilities.
* gcc.dg/bitint-41.c: Use -std=c23 rather than -std=c2x.
* gcc.dg/torture/bitint-43.c: Likewise.
* gcc.dg/torture/bitint-44.c: Likewise.
* gcc.dg/torture/bitint-45.c: New test.
Xi Ruoyao [Thu, 30 Nov 2023 09:35:10 +0000 (17:35 +0800)]
doc: Update the status of build directory not fully separated
Recently there are some people building GCC with srcdir == objdir and
the attempts just failed [1]. So stop to say "it should work". OTOH
objdir as a subdirectory of srcdir works: we've built GCC in LFS [2]
and BLFS [3] this way for decades and this is confirmed during the
review of a previous version of this patch [4].
projects / thirdparty / gcc.git / log
