Jakub Jelinek [Thu, 19 Jan 2023 22:27:34 +0000 (23:27 +0100)]
c++: Fix up handling of references to anon union members in initializers [PR53932]
For anonymous union members we create artificial VAR_DECLs which
have DECL_VALUE_EXPR for the actual COMPONENT_REF. That works
just fine inside of functions (including global dynamic constructors),
because during gimplification such VAR_DECLs are gimplified as
their DECL_VALUE_EXPR. This is also done during regimplification.
But references to these artificial vars in DECL_INITIAL expressions
aren't ever replaced by the DECL_VALUE_EXPRs, so we end up either
with link failures like on the testcase below, or worse ICEs with
LTO.
The following patch fixes those during cp_fully_fold_init where we
already walk all the trees (!data->genericize means that
function rather than cp_fold_function).
2023-01-19 Jakub Jelinek <jakub@redhat.com>
PR c++/53932
* cp-gimplify.cc (cp_fold_r): During cp_fully_fold_init replace
DECL_ANON_UNION_VAR_P VAR_DECLs with their corresponding
DECL_VALUE_EXPR.
Jakub Jelinek [Thu, 19 Jan 2023 20:00:08 +0000 (21:00 +0100)]
openmp: Fix up OpenMP expansion of non-rectangular loops [PR108459]
expand_omp_for_init_counts was using for the case where collapse(2)
inner loop has init expression dependent on non-constant multiple of
the outer iterator and the condition upper bound expression doesn't
depend on the outer iterator fold_unary (NEGATE_EXPR, ...). This
will just return NULL if it can't be folded, we need fold_build1
instead.
2023-01-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/108459
* omp-expand.cc (expand_omp_for_init_counts): Use fold_build1 rather
than fold_unary for NEGATE_EXPR.
Jakub Jelinek [Wed, 11 Jan 2023 21:18:42 +0000 (22:18 +0100)]
c: Don't emit DEBUG_BEGIN_STMTs for K&R function argument declarations [PR105972]
K&R function parameter declarations are handled by calling
recursively c_parser_declaration_or_fndef in a loop, where each such
call will add_debug_begin_stmt at the start.
Now, if the K&R function definition is not a nested function,
building_stmt_list_p () is false and so we don't emit the DEBUG_BEGIN_STMTs
anywhere, but if it is a nested function, we emit it in the containing
function at the point of the nested function definition.
As the following testcase shows, it can cause ICEs if the containing
function has var-tracking disabled but nested function has them enabled,
as the DEBUG_BEGIN_STMTs are added to the containing function which
shouldn't have them but MAY_HAVE_DEBUG_MARKER_STMTS is checked already
for the nested function, or just wrong experience in the debugger.
The following patch ensures we don't emit any such DEBUG_BEGIN_STMTs for the
K&R function parameter declarations even in nested functions.
2023-01-11 Jakub Jelinek <jakub@redhat.com>
PR c/105972
* c-parser.cc (c_parser_declaration_or_fndef): Disable debug non-bind
markers for K&R function parameter declarations of nested functions.
Jakub Jelinek [Wed, 11 Jan 2023 09:40:54 +0000 (10:40 +0100)]
fortran: Fix up function types for realloc and sincos{,f,l} builtins [PR108349]
As reported in the PR, the FUNCTION_TYPE for __builtin_realloc in the
Fortran FE is wrong since r0-100026-gb64fca63690ad which changed
- tmp = tree_cons (NULL_TREE, pvoid_type_node, void_list_node);
- tmp = tree_cons (NULL_TREE, size_type_node, tmp);
- ftype = build_function_type (pvoid_type_node, tmp);
+ ftype = build_function_type_list (pvoid_type_node,
+ size_type_node, pvoid_type_node,
+ NULL_TREE);
gfc_define_builtin ("__builtin_realloc", ftype, BUILT_IN_REALLOC,
"realloc", false);
The return type is correct, void *, but the first argument should be
void * too and only second one size_t, while the above change changed
realloc to be void *__builtin_realloc (size_t, void *);
I went through all other changes from that commit and found that
__builtin_sincos{,f,l} got broken as well, instead of the former
void __builtin_sincos{,f,l} (ftype, ftype *, ftype *);
where ftype is {double,float,long double} it is now incorrectly
void __builtin_sincos{,f,l} (ftype *, ftype *);
The following patch fixes that, plus some formatting issues around
the spots I've changed.
2023-01-11 Jakub Jelinek <jakub@redhat.com>
PR fortran/108349
* f95-lang.cc (gfc_init_builtin_function): Fix up function types
for BUILT_IN_REALLOC and BUILT_IN_SINCOS{F,,L}. Formatting fixes.
Jakub Jelinek [Thu, 5 Jan 2023 10:57:30 +0000 (11:57 +0100)]
openmp: Fix up finish_omp_target_clauses [PR108286]
The comment in the loop says that we shouldn't add a map clause if such
a clause exists already, but the loop was actually using OMP_CLAUSE_DECL
on any clause. Target construct can have various clauses which don't
have OMP_CLAUSE_DECL at all (e.g. nowait, device or if) or clause
where it means something different (e.g. privatization clauses, allocate,
depend).
So, only check OMP_CLAUSE_DECL on OMP_CLAUSE_MAP clauses.
2023-01-05 Jakub Jelinek <jakub@redhat.com>
PR c++/108286
* semantics.cc (finish_omp_target_clauses): Ignore clauses other than
OMP_CLAUSE_MAP.
Jakub Jelinek [Wed, 4 Jan 2023 17:42:31 +0000 (18:42 +0100)]
c++: Error recovery in merge_default_template_args [PR108206]
We ICE on the following testcase during error recovery, both new_parm
and old_parm are error_mark_node, the ICE is on
error ("redefinition of default argument for %q+#D", new_parm);
inform (DECL_SOURCE_LOCATION (old_parm),
"original definition appeared here");
where we don't print anything useful for new_parm and ICE trying to
access DECL_SOURCE_LOCATION of old_parm. I think we shouldn't diagnose
anything when either of the parms is erroneous, GCC 11 before
merge_default_template_args has been added was doing
if (TREE_VEC_ELT (tmpl_parms, i) == error_mark_node
|| TREE_VEC_ELT (parms, i) == error_mark_node)
continue;
tmpl_parm = TREE_VALUE (TREE_VEC_ELT (tmpl_parms, i));
if (error_operand_p (tmpl_parm))
return false;
in redeclare_class_template.
2023-01-04 Jakub Jelinek <jakub@redhat.com>
PR c++/108206
* decl.cc (merge_default_template_args): Return false if either
new_parm or old_parm are erroneous.
Jakub Jelinek [Wed, 4 Jan 2023 09:54:38 +0000 (10:54 +0100)]
generic-match-head: Don't assume GENERIC folding is done only early [PR108237]
We ICE on the following testcase, because a valid V2DImode
!= comparison is folded into an unsupported V2DImode > comparison.
The match.pd pattern which does this looks like:
/* Transform comparisons of the form (X & Y) CMP 0 to X CMP2 Z
where ~Y + 1 == pow2 and Z = ~Y. */
(for cst (VECTOR_CST INTEGER_CST)
(for cmp (eq ne)
icmp (le gt)
(simplify
(cmp (bit_and:c@2 @0 cst@1) integer_zerop)
(with { tree csts = bitmask_inv_cst_vector_p (@1); }
(if (csts && (VECTOR_TYPE_P (TREE_TYPE (@1)) || single_use (@2)))
(with { auto optab = VECTOR_TYPE_P (TREE_TYPE (@1))
? optab_vector : optab_default;
tree utype = unsigned_type_for (TREE_TYPE (@1)); }
(if (target_supports_op_p (utype, icmp, optab)
|| (optimize_vectors_before_lowering_p ()
&& (!target_supports_op_p (type, cmp, optab)
|| !target_supports_op_p (type, BIT_AND_EXPR, optab))))
(if (TYPE_UNSIGNED (TREE_TYPE (@1)))
(icmp @0 { csts; })
(icmp (view_convert:utype @0) { csts; })))))))))
and that optimize_vectors_before_lowering_p () guarded stuff there
already deals with this problem, not trying to fold a supported comparison
into a non-supported one. The reason it doesn't work in this case is that
it isn't GIMPLE folding which does this, but GENERIC folding done during
forwprop4 - forward_propagate_into_comparison -> forward_propagate_into_comparison_1
-> combine_cond_expr_cond -> fold_binary_loc -> generic_simplify
and we simply assumed that GENERIC folding happens only before
gimplification.
The following patch fixes that by checking cfun properties instead of
always returning true in those cases.
2023-01-04 Jakub Jelinek <jakub@redhat.com>
PR middle-end/108237
* generic-match-head.cc: Include tree-pass.h.
(canonicalize_math_p, optimize_vectors_before_lowering_p): Define
to false if cfun and cfun->curr_properties has PROP_gimple_opt_math
resp. PROP_gimple_lvec property set.
Jakub Jelinek [Tue, 3 Jan 2023 11:13:24 +0000 (12:13 +0100)]
expr: Fix up store_expr into SUBREG_PROMOTED_* target [PR108264]
The following testcase ICEs on s390x-linux (e.g. with -march=z13).
The problem is that target is (subreg/s/u:SI (reg/v:DI 66 [ x+-4 ]) 4)
and we call convert_move from temp to the SUBREG_REG of that, expecting
to extend the value properly. That works nicely if temp has some
scalar integer mode (or partial one), but ICEs when temp has V4QImode
on the assertion that from and to modes have the same bitsize.
store_expr generally allows say store from V4QI to SI target because
they have the same size and if temp is a CONST_INT, we already have code
to convert the constant properly, so the following patch just adds handling
of non-scalar integer modes by converting them to the mode of target
first before convert_move extends them.
2023-01-03 Jakub Jelinek <jakub@redhat.com>
PR middle-end/108264
* expr.cc (store_expr): For stores into SUBREG_PROMOTED_* targets
from source which doesn't have scalar integral mode first convert
it to outer_mode.
As reported in the PR, tree-ssa-dom.cc uses real_zerop call to find
if a floating point constant is zero and it shouldn't try to infer
equivalences from comparison against it if signed zeros are honored.
This doesn't work at all for decimal types, because real_zerop always
returns false for them (one can have different representations of decimal
zero beyond -0/+0), and it doesn't work for vector compares either,
as real_zerop checks if all elements are zero, while we need to avoid
infering equivalences from comparison against vector constants which have
at least one zero element in it (if signed zeros are honored).
Furthermore, as mentioned by Joseph, for decimal types many other values
aren't singleton.
So, this patch stops infering anything if element mode is decimal, and
otherwise uses instead of real_zerop a new function, real_maybe_zerop,
which will work even for decimal types and for complex or vector will
return true if any element is or might be zero (so it returns true
for anything but constants for now).
2022-12-23 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/108068
* tree.h (real_maybe_zerop): Declare.
* tree.cc (real_maybe_zerop): Define.
* tree-ssa-dom.cc (record_edge_info): Use it instead of
real_zerop or TREE_CODE (op1) == SSA_NAME || real_zerop. Always set
can_infer_simple_equiv to false for decimal floating point types.
Jakub Jelinek [Thu, 22 Dec 2022 11:52:48 +0000 (12:52 +0100)]
phiopt: Drop SSA_NAME_RANGE_INFO in maybe equal case [PR108166]
The following place in value_replacement is after proving that
x == cst1 ? cst2 : x
phi result is only used in a comparison with constant which doesn't
care if it compares cst1 or cst2 and replaces it with x.
The testcase is miscompiled because we have after the replacement
incorrect range info for the phi result, we would need to
effectively union the phi result range with cst1 (oarg in the code)
because previously that constant might be missing in the range, but
newly it can appear (we've just verified that the single use stmt
of the phi result doesn't care about that value in particular).
The following patch just resets the info, bootstrapped/regtested
on x86_64-linux and i686-linux, ok for trunk?
Aldy/Andrew, how would one instead union the SSA_NAME_RANGE_INFO
with some INTEGER_CST and store it back into SSA_NAME_RANGE_INFO
(including adjusting non-zero bits and the like)?
2022-12-22 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/108166
* tree-ssa-phiopt.cc (value_replacement): For the maybe_equal_p
case turned into equal_p reset SSA_NAME_RANGE_INFO of phi result.
Jakub Jelinek [Thu, 22 Dec 2022 11:44:13 +0000 (12:44 +0100)]
cse: Fix up CSE const_anchor handling [PR108193]
The following testcase ICEs on aarch64, because insert_const_anchor
inserts invalid CONST_INT into the CSE tables - 0x80000000 for SImode.
The second hunk of the patch fixes that, the first one is to avoid
triggering undefined behavior at compile time during compute_const_anchors
computations - performing those additions and subtractions in
HOST_WIDE_INT means it can overflow for certain constants.
2022-12-22 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/108193
* cse.cc (compute_const_anchors): Change n type to
unsigned HOST_WIDE_INT, adjust comparison against it to avoid
warnings. Formatting fix.
(insert_const_anchor): Use gen_int_mode instead of GEN_INT.
Jakub Jelinek [Wed, 21 Dec 2022 08:05:27 +0000 (09:05 +0100)]
openmp: Don't try to destruct DECL_OMP_PRIVATIZED_MEMBER vars [PR108180]
DECL_OMP_PRIVATIZED_MEMBER vars are artificial vars with DECL_VALUE_EXPR
of this->field used just during gimplification and omp lowering/expansion
to privatize individual fields in methods when needed.
As the following testcase shows, when not in templates, they were handled
right, but in templates we actually called cp_finish_decl on them and
that can result in their destruction, which is obviously undesirable,
we should only destruct the privatized copies of them created in omp
lowering.
Jakub Jelinek [Mon, 19 Dec 2022 12:49:52 +0000 (13:49 +0100)]
testsuite: Fix up pr64536.c for LLP64 targets [PR108151]
The test casts a pointer to long, which is ok for ilp32 and lp64
targets but not for llp64 targets. Nothing reads the values later,
it is a link test, so all we care about is that it is the same
cast on s390x-linux where it used to fail before the PR64536 fix,
and that we don't warn about it.
2022-12-19 Jakub Jelinek <jakub@redhat.com>
PR testsuite/108151
* gcc.dg/pr64536.c (bar): Use casts to __INTPTR_TYPE__ rather than
long when casting pointer to integral type.
Jakub Jelinek [Fri, 16 Dec 2022 09:19:22 +0000 (10:19 +0100)]
loop-invariant: Split preheader edge if the preheader bb ends with jump [PR106751]
The RTL loop passes only request simple preheaders, but don't require
fallthru preheaders, while move_invariant_reg apparently assumes the
latter, that it can just append instruction(s) to the end of the preheader
basic block.
The following patch fixes that by splitting the preheader edge if
the preheader bb ends with a JUMP_INSN (asm goto in this case).
Without that we get control flow in the middle of a bb.
2022-12-16 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/106751
* loop-invariant.cc (move_invariant_reg): If preheader bb ends
with a JUMP_INSN, split the preheader edge and emit invariants
into the new preheader basic block.
Jakub Jelinek [Thu, 15 Dec 2022 18:17:45 +0000 (19:17 +0100)]
c++: Ensure !!var is not an lvalue [PR107065]
The TRUTH_NOT_EXPR case in cp_build_unary_op is one of the spots where
we somewhat fold immediately using invert_truthvalue_loc.
I've tried using
return build1_loc (location, TRUTH_NOT_EXPR, boolean_type_node, arg);
in there instead, but unfortunately that regressed
Wlogical-not-parentheses-*.c pr49706.c pr62199.c pr65120.c sequence-pt-1.C
tests, so at least for backporting that doesn't seem to be a way to go.
So, this patch instead wraps it into NON_LVALUE_EXPR if needed (which also
need a tweak for some tests in the pr47906.c test, but nothing major),
with the intent to make it backportable, and later I'll try to do further
steps to avoid folding here prematurely. Most of the problems with
build1 TRUTH_NOT_EXPR are that it doesn't even invert comparisons as most
common case and lots of warning code isn't able to deal with ! around
comparisons; so perhaps one way to do this would be fold by hand only
invertable comparisons and for the rest create TRUTH_NOT_EXPR.
2022-12-15 Jakub Jelinek <jakub@redhat.com>
PR c++/107065
gcc/cp/
* typeck.cc (cp_build_unary_op) <case TRUTH_NOT_EXPR>: If
invert_truthvalue_loc returns obvalue_p, wrap it into NON_LVALUE_EXPR.
* parser.cc (cp_parser_binary_expression): Don't call
warn_logical_not_parentheses if current.lhs is a NON_LVALUE_EXPR
of a decl with boolean type.
gcc/testsuite/
* g++.dg/cpp0x/pr107065.C: New test.
Jakub Jelinek [Thu, 15 Dec 2022 08:26:44 +0000 (09:26 +0100)]
into-ssa: Fix emitting debug stmts after asm goto [PR108095]
The following testcase ICEs, because ccp1 replaced
s.0_1 = &s;
__asm__ goto("" : "=r" MEM[(T *)s.0_1] : : : "lab" lab);
with
__asm__ goto("" : "=r" s : : : "lab" lab);
and because s is no longer addressable, we are rewriting it into
ssa and want
__asm__ goto("" : "=r" s_7 : : : "lab" lab);
plus debug stmt
# DEBUG s => s_7
The code assumes that there is at most one non-EH edge in that
case, but with the addition of outputs to asm goto that is no longer the
case, we can have many outgoing edges.
The patch keeps the checking assertion that there is at most one such
edge for everything but asm goto, but moves the addition of the debug
stmt into the loop, so that it can be added on all edges where it is
possible, not just one of them.
Furthermore, looking at gsi_insert_on_edge_immediate
-> gimple_find_edge_insert_loc, the conditions to insert stmt there
to the destination block are
if (single_pred_p (dest)
&& gimple_seq_empty_p (phi_nodes (dest))
&& dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
(plus there is code to insert it in the previous block but that is
never true when the pred is known to be stmt_ends_bb_p), while
mayube_register_def was just checking
if (ef && single_pred_p (ef->dest)
&& ef->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
so if for whatever reason ef->dest had any PHIs, we'd split the
edge for -g and not for -g0, something we must avoid for -fcompare-debug
stability. So, I've added the no phi_nodes check too.
2022-12-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/108095
* tree-into-ssa.cc (maybe_register_def): Insert debug stmt
on all non-EH edges from asm goto if they have a single
predecessor rather than asserting there is at most one such edge.
Test whether there are no PHI nodes next to the single predecessor
test.
Jakub Jelinek [Sat, 10 Dec 2022 15:50:39 +0000 (16:50 +0100)]
ivopts: Fix IP_END handling for asm goto [PR107997]
The following testcase ICEs, because the latch bb ends with
asm goto which has both fallthrough to the header and one or more labels
in the header too. In that case there is just a single edge out of the
latch block, but still the asm goto is stmt_ends_bb_p statement, yet
ivopts decides to emit an IV bump at the IP_END position and inserts
it into the same bb as the asm goto after it, which then fails verification
(control flow in the middle of bb).
The following patch fixes it by splitting the latch -> header edge in that
case and inserting into the newly created bb, where split_edge ->
redirect_edge_and_branch is able to deal with this case correctly.
2022-12-10 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/107997
* tree-ssa-loop-ivopts.cc: Include cfganal.h.
(create_new_iv) <case IP_END>: If ip_end_pos bb is non-empty and ends
with a stmt which ends bb, instead of adding iv update after it split
the latch edge and insert iterator into the new latch bb.
Jakub Jelinek [Thu, 8 Dec 2022 13:57:22 +0000 (14:57 +0100)]
cfgbuild: Fix DEBUG_INSN handling in find_bb_boundaries [PR106719]
The following testcase FAILs on aarch64-linux. We have some atomic
instruction followed by 2 DEBUG_INSNs (if -g only of course) followed
by NOTE_INSN_EPILOGUE_BEG followed by some USE insn.
Now, split3 pass replaces the atomic instruction with a code sequence
which ends with a conditional jump and the split3 pass calls
find_many_sub_basic_blocks.
For -g0, find_bb_boundaries sees the flow_transfer_insn (the new conditional
jump), then NOTE_INSN_EPILOGUE_BEG which can live in between basic blocks
and then the USE insn, so splits block after the NOTE_INSN_EPILOGUE_BEG
and puts the NOTE in between the blocks.
For -g, if sees a DEBUG_INSN after the flow_transfer_insn, so sets
debug_insn to it, then walks over another DEBUG_INSN, NOTE_INSN_EPILOGUE_BEG
until it finally sees the USE insn, and triggers the:
rtx_insn *prev = PREV_INSN (insn);
/* If the first non-debug inside_basic_block_p insn after a control
flow transfer is not a label, split the block before the debug
insn instead of before the non-debug insn, so that the debug
insns are not lost. */
if (debug_insn && code != CODE_LABEL && code != BARRIER)
prev = PREV_INSN (debug_insn);
code I've added for PR81325. If there are only DEBUG_INSNs, that is
the right thing to do, but if in between debug_insn and insn there are
notes which can stay in between basic blocks or simnilarly JUMP_TABLE_DATA
or their associated CODE_LABELs, it causes -fcompare-debug differences.
The following patch fixes it by clearing debug_insn if JUMP_TABLE_DATA
or associated CODE_LABEL is seen (I'm afraid there is no good answer
what to do with DEBUG_INSNs before those; the code then removes them:
/* Clean up the bb field for the insns between the blocks. */
for (x = NEXT_INSN (flow_transfer_insn);
x != BB_HEAD (fallthru->dest);
x = next)
{
next = NEXT_INSN (x);
/* Debug insns should not be in between basic blocks,
drop them on the floor. */
if (DEBUG_INSN_P (x))
delete_insn (x);
else if (!BARRIER_P (x))
set_block_for_insn (x, NULL);
}
but if there are NOTEs, the patch just reorders the NOTEs and DEBUG_INSNs,
such that the NOTEs come first (so that they stay in between basic blocks
like with -g0) and DEBUG_INSNs after those (so that bb is split before
them, so they will be in the basic block after NOTE_INSN_BASIC_BLOCK).
2022-12-08 Jakub Jelinek <jakub@redhat.com>
PR debug/106719
* cfgbuild.cc (find_bb_boundaries): If there are NOTEs in between
debug_insn (seen after flow_transfer_insn) and insn, move NOTEs
before all the DEBUG_INSNs and split after NOTEs. If there are
other insns like jump table data, clear debug_insn.
Jakub Jelinek [Mon, 28 Nov 2022 09:13:43 +0000 (10:13 +0100)]
i386: Fix up ix86_abi handling [PR106875]
The following testcase fails since my changes to make also
opts_set saved/restored upon function target/optimization changes
(before it has been acting as "has this option be ever explicit
anywhere?").
The problem is that for ix86_abi we depend on the opts_set
value for it in ix86_option_override_internal:
SET_OPTION_IF_UNSET (opts, opts_set, ix86_abi, DEFAULT_ABI);
but as it is a TargetSave, the backend code is required to
save/restore it manually (it does that) and since gcc 11 also
to save/restore the opts_set bit for it (which isn't done).
We don't do that for various other TargetSave which
ix86_function_specific_{save,restore} saves/restores, but as long
as we never test opts_set for it, it doesn't really matter.
One possible fix would be to introduce some new TargetSave into
which ix86_function_specific_{save,restore} would save/restore a bitmask
of the opts_set bits. The following patch uses an easier fix, by
making it a TargetVariable instead the saving/restoring is handled
by the generated code.
The differences in options.h are just slight movements on where
*ix86_abi stuff appears in it, ditto for options.cc, the real
differences are just in options-save.cc, where cl_target_option_save
gets:
+ ptr->x_ix86_abi = opts->x_ix86_abi;
...
+ if (opts_set->x_ix86_abi) mask |= HOST_WIDE_INT_1U << 3;
(plus adjustments of following TargetVariables mask related stuff),
cl_target_option_restore gets:
+ opts->x_ix86_abi = ptr->x_ix86_abi;
...
+ opts_set->x_ix86_abi = static_cast<enum calling_abi>((mask & 1) != 0);
+ mask >>= 1;
plus the movements in other functions too. So, by it being a
TargetVariable, the only thing that changed is that we don't need to
handle it manually in ix86_function_specific_{save,restore} because it
is handled automatically including the opts_set stuff.
2022-11-28 Jakub Jelinek <jakub@redhat.com>
PR target/106875
* config/i386/i386.opt (x_ix86_abi): Remove TargetSave.
(ix86_abi): Replace it with TargetVariable.
* config/i386/i386-options.cc (ix86_function_specific_save,
ix86_function_specific_restore): Don't save and restore x_ix86_abi.
Jakub Jelinek [Thu, 24 Nov 2022 10:29:54 +0000 (11:29 +0100)]
asan: Fix up error recovery for too large frames [PR107317]
asan_emit_stack_protection and functions it calls have various asserts that
verify sanity of the stack protection instrumentation. But, that
verification can easily fail if we've diagnosed a frame offset overflow.
asan_emit_stack_protection just emits some extra code in the prologue,
if we've reported errors, we aren't producing assembly, so it doesn't
really matter if we don't include the protection code, compilation
is going to fail anyway.
2022-11-24 Jakub Jelinek <jakub@redhat.com>
PR middle-end/107317
* asan.cc: Include diagnostic-core.h.
(asan_emit_stack_protection): Return NULL early if seen_error ().
Jakub Jelinek [Wed, 23 Nov 2022 18:09:31 +0000 (19:09 +0100)]
c: Fix compile time hog in c_genericize [PR107127]
The complex multiplications result in deeply nested set of many SAVE_EXPRs,
which takes even on fast machines over 5 minutes to walk.
This patch fixes that by using walk_tree_without_duplicates where it is
instant.
2022-11-23 Andrew Pinski <apinski@marvell.com>
Jakub Jelinek <jakub@redhat.com>
PR c/107127
* c-gimplify.cc (c_genericize): Use walk_tree_without_duplicates
instead of walk_tree for c_genericize_control_r.
Andrew Pinski [Sat, 28 Jan 2023 18:27:08 +0000 (18:27 +0000)]
Fix PR 108582: ICE due to PHI-OPT removing a still in use ssa_name.
This patch adds a check in match_simplify_replacement to make sure the middlebb
does not have any phi-nodes as we don't currently move those.
This was just a thinko from before.
Committed on the GCC 12 branch after a bootstrap/test on x86_64-linux-gnu.
PR tree-optimization/108582
gcc/ChangeLog:
* tree-ssa-phiopt.cc (match_simplify_replacement): Add check
for middlebb to have no phi nodes.
tree-optimization/108522 Use component_ref_field_offset
Instead of using TREE_OPERAND (expr, 2) directly, use
component_ref_field_offset instead, which does scaling for us. The
function also substitutes PLACEHOLDER_EXPRs but it is not relevant for
tree-object-size.
Patrick Palka [Mon, 6 Feb 2023 02:35:33 +0000 (21:35 -0500)]
c++: equivalence of non-dependent calls [PR107461]
After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependence of a CALL_EXPR before treating a FUNCTION_DECL callee as a
dependent name, which leads to us incorrectly accepting the first two
testcases below and rejecting the third:
* In the first testcase, cp_tree_equal incorrectly returns true for
the two non-dependent CALL_EXPRs f(0) and f(0) (whose CALL_EXPR_FN
are different FUNCTION_DECLs) which causes us to treat #2 as a
redeclaration of #1.
* Same issue in the second testcase, for f<int*>() and f<char>().
* In the third testcase, cp_tree_equal incorrectly returns true for
f<int>() and f<void(*)(int)>() which causes us to conflate the two
dependent specializations A<decltype(f<int>()(U()))> and
A<decltype(f<void(*)(int)>()(U()))>.
This patch fixes this by making called_fns_equal treat two callees as
dependent names only if the overall CALL_EXPRs are dependent, via a new
convenience function call_expr_dependent_name that is like dependent_name
but also checks dependence of the overall CALL_EXPR.
PR c++/107461
gcc/cp/ChangeLog:
* cp-tree.h (call_expr_dependent_name): Declare.
* pt.cc (iterative_hash_template_arg) <case CALL_EXPR>: Use
call_expr_dependent_name instead of dependent_name.
* tree.cc (call_expr_dependent_name): Define.
(called_fns_equal): Adjust to take two CALL_EXPRs instead of
CALL_EXPR_FNs thereof. Use call_expr_dependent_name instead
of dependent_name.
(cp_tree_equal) <case CALL_EXPR>: Adjust call to called_fns_equal.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/overload5.C: New test.
* g++.dg/cpp0x/overload5a.C: New test.
* g++.dg/cpp0x/overload6.C: New test.
Mikael Morin [Sun, 29 Jan 2023 20:57:24 +0000 (21:57 +0100)]
fortran: Set name for *LOC default BACK argument [PR108450]
This change fixes an ICE caused by the double resolution of MINLOC,
MAXLOC and FINDLOC expressions which get a default value for the BACK
argument at resolution time. That argument is added without name,
and argument reordering code is not prepared to handle unnamed arguments
coming after named ones, so the second resolution causes a NULL pointer
dereference.
The problem is fixed by explicitly setting the argument name.
PR fortran/108450
gcc/fortran/ChangeLog:
* check.cc (gfc_check_minloc_maxloc): Explicitly set argument name.
(gfc_check_findloc): Ditto.
Harald Anlauf [Wed, 1 Feb 2023 20:01:32 +0000 (21:01 +0100)]
Fortran: error recovery on invalid array section [PR108609]
The testcase for PR108527 uncovered a latent issue with invalid array
sections that resulted in different paths being taken on different
architectures. Detect the invalid array declaration for a clean recovery.
gcc/fortran/ChangeLog:
PR fortran/108609
* expr.cc (find_array_section): Add check to prevent interpreting an
mpz non-integer constant as an integer.
gcc/testsuite/ChangeLog:
PR fortran/108609
* gfortran.dg/pr108527.f90: Adjust test pattern.
Harald Anlauf [Tue, 24 Jan 2023 21:36:25 +0000 (22:36 +0100)]
Fortran: fix ICE in compare_bound_int [PR108527]
gcc/fortran/ChangeLog:
PR fortran/108527
* resolve.cc (compare_bound_int): Expression to compare must be of
type INTEGER.
(compare_bound_mpz_t): Likewise.
(check_dimension): Fix comment on checks applied to array section
and clean up associated logic.
gcc/testsuite/ChangeLog:
PR fortran/108527
* gfortran.dg/pr108527.f90: New test.
Patrick Palka [Fri, 3 Feb 2023 14:41:10 +0000 (09:41 -0500)]
c++: unexpected ADDR_EXPR after overload set pruning [PR107461]
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped
in an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration mismatch error in
the below testcase because the call to min in #1 gets expressed as a
CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call
to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL.
This patch fixes this by stripping the spurious ADDR_EXPR appropriately.
Thus the first call to min now also gets expressed as a CALL_EXPR of
FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f.
PR c++/107461
gcc/cp/ChangeLog:
* semantics.cc (finish_call_expr): Strip ADDR_EXPR from
the selected callee during overload set pruning.
Jonathan Wakely [Tue, 31 Jan 2023 22:28:16 +0000 (22:28 +0000)]
libstdc++: Fix std::random_device for avr
This fixes a build failure that affects avr, but could affect other
targets in theory. The _M_fini function should not try to use ::open or
::fopen if _GLIBCXX_USE_DEV_RANDOM is not defined, because no file can
ever have been opened.
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (random_device::_M_fini): Do not try to
close the file handle if the target doesn't support the
/dev/random and /dev/urandom files.
Jonathan Wakely [Tue, 31 Jan 2023 22:16:31 +0000 (22:16 +0000)]
libstdc++: Fix build failures for avr
The abr-libc <errno.h> does not define EOVERFLOW, which means that
std::errc::value_too_large is not defined, and so <charconv> cannot be
compiled. Define value_too_large for avr with a value that does not
clash with any that is defined in <errno.h>. This is a kluge to fix
bootstrap for avr; it can be removed after PR libstdc++/104883 is
resolved.
The avr-libc <errno.h> fails to meet the C and POSIX requirements that
each error macro has a distinct integral value, and is usable in #if
directives. Add a special case for avr to system_error.cc so that only
the valid errors are recognized. Also disable the errno checks in
std::filesystem::remove_all that assume a meaningful value for errno.
On avr-libc <unistd.h> exists but does not define the POSIX functions
needed by std::filesystem, so _GLIBCXX_HAVE_UNISTD_H is not sufficient
to check for basic POSIX APIs. Check !defined __AVR__ as well as
_GLIBCXX_HAVE_UNISTD_H before using those functions. This is a kluge and
we should really have a specific macro that says the required functions
are available.
libstdc++-v3/ChangeLog:
* config/os/generic/error_constants.h (errc::value_too_large)
[__AVR__]: Define.
* src/c++11/system_error.cc
(system_category::default_error_condition) [__AVR__]: Only match
recognize values equal to EDOM, ERANGE, ENOSYS and EINTR.
* src/c++17/fs_ops.cc (fs::current_path) [__AVR__]: Do not check
for ENOENT etc. in switch.
(fs::remove_all) [__AVR__]: Likewise.
* src/filesystem/ops-common.h [__AVR__]: Do not use POSIX open,
close etc.
Patrick Palka [Sun, 6 Nov 2022 16:30:47 +0000 (11:30 -0500)]
libstdc++: Declare const global variables inline
The changes inside the regex_constants and execution namespaces seem to
be (the only) unimplemented parts of P0607R0 "Inline Variable for the
Standard Library"; the rest of the changes are to implementation details.
Martin Jambor [Wed, 1 Feb 2023 17:58:09 +0000 (18:58 +0100)]
ipa: Release body more carefully when removing nodes (PR 107944)
The code removing function bodies when the last call graph clone of a
node is removed is too aggressive when there are nodes up the
clone_of chain which still need them. Fixed by expanding the check.
gcc/ChangeLog:
2023-01-18 Martin Jambor <mjambor@suse.cz>
PR ipa/107944
* cgraph.cc (cgraph_node::remove): Check whether nodes up the
lcone_of chain also do not need the body.
Marek Polacek [Tue, 31 Jan 2023 19:36:30 +0000 (14:36 -0500)]
c++: ICE with -Wlogical-op [PR107755]
Here we crash in the middle end because warn_logical_operator calls
build_range_check which calls various fold_* functions and those
don't work too well when we're still processing template trees. For
instance here we crash because we're converting a RECORD_TYPE to bool.
At this point VIEW_CONVERT_EXPR<struct Foo>(b) hasn't yet been converted
to Foo::operator bool (&b).
I was excited to fix this with instantiation_dependent_expression_p
which can now be called from c-family/ as well, but the problem isn't
that the expression is dependent. So, p_t_d it is.
PR c++/107755
gcc/cp/ChangeLog:
* call.cc (build_new_op): Don't call warn_logical_operator when
processing a template.
Marek Polacek [Tue, 31 Jan 2023 16:54:03 +0000 (11:54 -0500)]
c++: fix ICE with -Wduplicated-cond [PR107593]
Here we crash because a CAST_EXPR, representing T(), doesn't have
its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
expect that. (o_e_p is called from warn_duplicated_cond_add_or_warn.)
In the past we've adjusted o_e_p to better cope with template codes,
but in this case I think we just want to avoid attempting to warn
about inst-dependent expressions; I don't think I've ever envisioned
-Wduplicated-cond to warn about them. Also destroy the chain when
an inst-dependent expression is encountered to not warn in
Wduplicated-cond4.C.
The ICE started with r12-6022, two-stage name lookup for overloaded
operators, which gave dependent operators a TREE_TYPE (in particular,
DEPENDENT_OPERATOR_TYPE), so we no longer bail out here in o_e_p:
/* Similar, if either does not have a type (like a template id),
they aren't equal. */
if (!TREE_TYPE (arg0) || !TREE_TYPE (arg1))
return false;
PR c++/107593
PR c++/108597
gcc/c-family/ChangeLog:
* c-common.h (instantiation_dependent_expression_p): Declare.
* c-warn.cc (warn_duplicated_cond_add_or_warn): If the condition
is dependent, invalidate the chain.
Andrew MacLeod [Mon, 30 Jan 2023 19:59:30 +0000 (14:59 -0500)]
Correctly detect shifts out of range
get_shift_range was incorrectly communicating that it couldn't calculate
a range when the shift values was always out fo range. Fix this and
alwasy return [0, 0] when the shift value is always out of range.
PR tree-optimization/108306
gcc/
* range-op.cc (operator_lshift::fold_range): Return [0, 0] not
varying for shifts that are always out of void range.
(operator_rshift::fold_range): Return [0, 0] not
varying for shifts that are always out of void range.
Jan Hubicka [Mon, 16 Jan 2023 14:40:45 +0000 (15:40 +0100)]
Disable gather/scatter for zen4
this patch adds more tunes for zen4:
- new tunes for avx512 scater instructions.
In micro benchmarks these seems consistent loss compared to open-coded coe
- disable use of gather for zen4
While these are win for a micro benchmarks (based on TSVC), enabling gather
is a loss for parest. So for now it seems safe to keep it off.
- disable pass to avoid FMA chains for znver4 since fmadd was optimized and does not seem
to cause regressions.
* config/i386/i386.cc (ix86_vectorize_builtin_scatter): Guard scatter
by TARGET_USE_SCATTER.
* config/i386/i386.h (TARGET_USE_SCATTER_2PARTS,
TARGET_USE_SCATTER_4PARTS, TARGET_USE_SCATTER): New macros.
* config/i386/x86-tune.def (TARGET_USE_SCATTER_2PARTS,
TARGET_USE_SCATTER_4PARTS, TARGET_USE_SCATTER): New tunes.
(X86_TUNE_AVOID_256FMA_CHAINS, X86_TUNE_AVOID_512FMA_CHAINS): Disable
for znver4. (X86_TUNE_USE_GATHER): Disable for zen4.
Jan Hubicka [Thu, 22 Dec 2022 09:55:46 +0000 (10:55 +0100)]
Zen4 tuning part 2
Adds tunes needed for zen4 microarchitecture. I added two new knobs.
TARGET_AVX512_SPLIT_REGS which is used to specify that internally 512 vectors
are split to 256 vectors. This affects vectorization costs and reassociation
width. It probably should also affect RTX costs however I doubt it is very useful
since RTL optimizers are usually not judging between 256 and 512 vectors.
I also added X86_TUNE_AVOID_256FMA_CHAINS. Since fma has improved in zen4 this
flag may not be a win except for very specific benchmarks. I am still doing some
more detailed testing here.
Oherwise I disabled gathers on zen4 for 2 parts nad 4 parts. We can open code them
and since the latencies has only increased since zen3 opencoding is better than
actual instrucction. This shows at 4 tsvc benchmarks.
I ended up setting AVX256_OPTIMAL. This is a compromise. There are some tsvc
benchmarks that increase noticeably (up to 250%) however there are also few
regressions. Most of these can be solved by incrasing vec_perm cost in the
vectorizer. However this does not cure about 14% regression on x264 that is
quite important. Here we produce vectorized loops for avx512 that probably
would be faster if the loops in question had high enough iteration count.
We hit this problem with avx256 too: since the loop iterates few times, only
prologues/epilogues are used. Adding another round of prologue/epilogue
code does not make it better.
Finally I enabled avx stores for constnat sized memcpy and memset. I am not
sure why this is an opt-in feature. I think for most hardware this is a win.
gcc/ChangeLog:
2022-12-22 Jan Hubicka <hubicka@ucw.cz>
* config/i386/i386-expand.cc (ix86_expand_set_or_cpymem): Add
TARGET_AVX512_SPLIT_REGS
* config/i386/i386-options.cc (ix86_option_override_internal):
Honor x86_TONE_AVOID_256FMA_CHAINS.
* config/i386/i386.cc (ix86_vec_cost): Honor TARGET_AVX512_SPLIT_REGS.
(ix86_reassociation_width): Likewise.
* config/i386/i386.h (TARGET_AVX512_SPLIT_REGS): New tune.
* config/i386/x86-tune.def (X86_TUNE_USE_GATHER_2PARTS): Disable
for znver4.
(X86_TUNE_USE_GATHER_4PARTS): Likewise.
(X86_TUNE_AVOID_256FMA_CHAINS): Set for znver4.
(X86_TUNE_AVOID_512FMA_CHAINS): New utne; set for znver4.
(X86_TUNE_AVX256_OPTIMAL): Add znver4.
(X86_TUNE_AVX512_SPLIT_REGS): New tune.
(X86_TUNE_AVX256_MOVE_BY_PIECES): Add znver1-3.
(X86_TUNE_AVX256_STORE_BY_PIECES): Add znver1-3.
(X86_TUNE_AVX512_MOVE_BY_PIECES): Add znver4.
(X86_TUNE_AVX512_STORE_BY_PIECES): Add znver4.
Jan Hubicka [Thu, 22 Dec 2022 01:16:24 +0000 (02:16 +0100)]
Update znver4 costs
Update cost of znver4 mostly based on data measued by Agner Fog.
Compared to previous generations x87 became bit slower which is probably not
big deal (and we have minimal benchmarking coverage for it). One interesting
improvement is reducation of FMA cost. I also updated costs of AVX256
loads/stores based on latencies (not throughput which is twice of avx256).
Overall AVX512 vectorization seems to improve noticeably some of TSVC
benchmarks but since internally 512 vectors are split to 256 vectors it is
somewhat risky and does not win in SPEC scores (mostly by regressing benchmarks
with loop that have small trip count like x264 and exchange), so for now I am
going to set AVX256_OPTIMAL tune but I am still playing with it. We improved
since ZNVER1 on choosing vectorization size and also have vectorized
prologues/epilogues so it may be possible to make avx512 small win overall.
2022-12-22 Jan Hubicka <hubicka@ucw.cz>
* config/i386/x86-tune-costs.h (znver4_cost): Upate costs of FP and SSE
moves, division multiplication, gathers, L2 cache size, and more
complex FP instrutions.
Harald Anlauf [Mon, 23 Jan 2023 20:19:03 +0000 (21:19 +0100)]
Fortran: avoid ICE on invalid array subscript triplets [PR108501]
gcc/fortran/ChangeLog:
PR fortran/108501
* interface.cc (get_expr_storage_size): Check array subscript triplets
that we actually have integer values before trying to extract with
mpz_get_si.
gcc/testsuite/ChangeLog:
PR fortran/108501
* gfortran.dg/pr108501.f90: New test.
This patch surrounds the scalar operand of the MVE vcmp patterns with a
vec_duplicate to ensure both operands of the comparision operator have the same
(vector) mode.
Marek Polacek [Wed, 25 Jan 2023 22:19:54 +0000 (17:19 -0500)]
opts: SANITIZE_ADDRESS wrongly cleared [PR108543]
Here we crash on a null fndecl ultimately because we haven't defined
the built-ins described in sanitizer.def. So
builtin_decl_explicit (BUILT_IN_ASAN_POINTER_SUBTRACT);
returns NULL_TREE, causing an ICE later.
DEF_SANITIZER_BUILTIN only actually defines the built-ins when flag_sanitize
has SANITIZE_ADDRESS, or some of the other SANITIZE_*, but it doesn't check
SANITIZE_KERNEL_ADDRESS or SANITIZE_USER_ADDRESS. Unfortunately, with
-fsanitize=address -fno-sanitize=kernel-address
or
-fsanitize=kernel-address -fno-sanitize=address
SANITIZE_ADDRESS ends up being unset from flag_sanitize even though
_USER/_KERNEL are set. That's because -fsanitize=address means
SANITIZE_ADDRESS | SANITIZE_USER_ADDRESS and -fsanitize=kernel-address
is SANITIZE_ADDRESS | SANITIZE_KERNEL_ADDRESS but parse_sanitizer_options
does
flags &= ~sanitizer_opts[i].flag;
so the subsequent -fno- unsets SANITIZE_ADDRESS. Then no sanitizer
built-ins are actually defined.
I'm not sure why SANITIZE_ADDRESS isn't just SANITIZE_USER_ADDRESS |
SANITIZE_KERNEL_ADDRESS, I don't think we need 3 bits.
PR middle-end/108543
gcc/ChangeLog:
* opts.cc (parse_sanitizer_options): Don't always clear SANITIZE_ADDRESS
if it was previously set.
gcc/testsuite/ChangeLog:
* c-c++-common/asan/pointer-subtract-5.c: New test.
* c-c++-common/asan/pointer-subtract-6.c: New test.
* c-c++-common/asan/pointer-subtract-7.c: New test.
* c-c++-common/asan/pointer-subtract-8.c: New test.
Dimitar Dimitrov [Sat, 21 Jan 2023 16:10:59 +0000 (18:10 +0200)]
pru: Fix CLZ expansion for QI and HI modes
The recent gcc.dg/tree-ssa/clz-char.c test case failed for PRU target,
exposing a wrong code generation bug in the PRU backend. The "clz"
pattern did not produce correct output for QI and HI input operand
modes. SI mode is ok.
The "clz" pattern is expanded to an LMBD instruction to get the
left-most bit position having value "1". In turn, to get the correct
"clz" value, that bit position must be subtracted from the MSB bit
position of the input operand. The old behaviour of hard-coding 31
for MSB bit position is wrong.
The LMBD instruction returns 32 if input operand is zero, irrespective
of its register mode. This maps nicely for SI mode, where the "clz"
pattern outputs -1. It also leads to peculiar (but valid!) output
values from the "clz" pattern for QI and HI zero-valued inputs.
The corresponding commit in trunk contains two new test cases, which
have been removed here because they depend on r13-5195-g4798080d4a3530.
Regtested for pru-unknown-elf.
gcc/ChangeLog:
* config/pru/pru.h (CLZ_DEFINED_VALUE_AT_ZERO): Fix value for QI
and HI input modes.
* config/pru/pru.md (clz): Fix generated code for QI and HI
input modes.
Christophe Lyon [Tue, 14 Jun 2022 21:08:33 +0000 (21:08 +0000)]
aarch64: fix warning emission for ABI break since GCC 9.1
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.
We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1. This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.
The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers. This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information). However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.
The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.
We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.
2022-11-28 Christophe Lyon <christophe.lyon@arm.com>
Richard Sandiford <richard.sandiford@arm.com>
* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.
Richard Biener [Mon, 19 Dec 2022 13:55:45 +0000 (14:55 +0100)]
tree-optimization/108164 - undefined overflow with IV vectorization
vect_update_ivs_after_vectorizer can end up emitting a signed
IV update when the loop body performed an unsigned computation.
The following makes sure to perform that update in the type
of the loop update type to avoid undefined behavior on overflow.
PR tree-optimization/108164
* tree-vect-loop-manip.cc (vect_update_ivs_after_vectorizer):
Perform vect_step_op_add update in the appropriate type.
Richard Biener [Mon, 12 Dec 2022 16:52:46 +0000 (17:52 +0100)]
tree-optimization/108076 - if-conversion and forced labels
When doing if-conversion we simply throw away labels without checking
whether they are possibly targets of non-local gotos or have their
address taken. The following rectifies this and refuses to if-convert
such loops.
PR tree-optimization/108076
* tree-if-conv.cc (if_convertible_loop_p_1): Reject blocks
with non-local or forced labels that we later remove
labels from.
`xputenv()` (and `putenv()`) don't copy strings and only store the
pointer in the `environ` global table. As a result `environ` got
corrupted as soon as `jinfo.skipped_makeflags` store got deallocated.
This started causing bootstrap crashes in `execv()` calls:
xgcc: fatal error: cannot execute '/build/build/./prev-gcc/collect2': execv: Bad address
The change restores memory allocation for `xputenv()` argument.
Andreas Krebbel [Mon, 23 Jan 2023 07:56:05 +0000 (08:56 +0100)]
PR 106101: IBM zSystems: Fix strict_low_part problem
This avoids generating illegal (strict_low_part (reg ...)) RTXs. This
required two changes:
1. Do not use gen_lowpart to generate the inner expression of a
STRICT_LOW_PART. gen_lowpart might fold the SUBREG either because
there is already a paradoxical subreg or because it can directly be
applied to the register. A new wrapper function makes sure that we
always end up having an actual SUBREG.
2. Change the movstrict patterns to enforce a SUBREG as inner operand
of the STRICT_LOW_PARTs. The new predicate introduced for the
destination operand requires a SUBREG expression with a
register_operand as inner operand. However, since reload strips away
the majority of the SUBREGs we have to accept single registers as well
once we reach reload.
Bootstrapped and regression tested on IBM zSystems 64 bit.
gcc/ChangeLog:
PR target/106101
* config/s390/predicates.md (subreg_register_operand): New
predicate.
* config/s390/s390-protos.h (s390_gen_lowpart_subreg): New
function prototype.
* config/s390/s390.cc (s390_gen_lowpart_subreg): New function.
(s390_expand_insv): Use s390_gen_lowpart_subreg instead of
gen_lowpart.
* config/s390/s390.md ("*get_tp_64", "*zero_extendhisi2_31")
("*zero_extendqisi2_31", "*zero_extendqihi2_31"): Likewise.
("movstrictqi", "movstricthi", "movstrictsi"): Use the
subreg_register_operand predicate instead of register_operand.
gcc/testsuite/ChangeLog:
PR target/106101
* gcc.c-torture/compile/pr106101.c: New test.
Jonathan Wakely [Thu, 22 Dec 2022 09:56:47 +0000 (09:56 +0000)]
libstdc++: Avoid recursion in __nothrow_wait_cv::wait [PR105730]
The commit r12-5877-g9e18a25331fa25 removed the incorrect
noexcept-specifier from std::condition_variable::wait and gave the new
symbol version @@GLIBCXX_3.4.30. It also redefined the original symbol
std::condition_variable::wait(unique_lock<mutex>&)@GLIBCXX_3.4.11 as an
alias for a new symbol, __gnu_cxx::__nothrow_wait_cv::wait, which still
has the incorrect noexcept guarantee. That __nothrow_wait_cv::wait is
just a wrapper around the real condition_variable::wait which adds
noexcept and so terminates on a __forced_unwind exception.
This doesn't work on uclibc, possibly due to a dynamic linker bug. When
__nothrow_wait_cv::wait calls the condition_variable::wait function it
binds to the alias symbol, which means it just calls itself recursively
until the stack overflows.
This change avoids the possibility of a recursive call by changing the
__nothrow_wait_cv::wait function so that instead of calling
condition_variable::wait it re-implements it. This requires accessing
the private _M_cond member of condition_variable, so we need to use the
trick of instantiating a template with the member-pointer of the private
member.
libstdc++-v3/ChangeLog:
PR libstdc++/105730
* src/c++11/compatibility-condvar.cc (__nothrow_wait_cv::wait):
Access private data member of base class and call its wait
member.
Jonathan Wakely [Thu, 28 Jul 2022 15:15:58 +0000 (16:15 +0100)]
libstdc++: Unblock atomic wait on non-futex platforms [PR106183]
When using a mutex and condition variable, the notifying thread needs to
increment _M_ver while holding the mutex lock, and the waiting thread
needs to re-check after locking the mutex. This avoids a missed
notification as described in the PR.
By moving the increment of _M_ver to the base _M_notify we can make the
use of the mutex local to the use of the condition variable, and
simplify the code a little. We can use a relaxed store because the mutex
already provides sequential consistency. Also we don't need to check
whether __addr == &_M_ver because we know that's always true for
platforms that use a condition variable, and so we also know that we
always need to use notify_all() not notify_one().
Reviewed-by: Thomas Rodgers <trodgers@redhat.com>
libstdc++-v3/ChangeLog:
PR libstdc++/106183
* include/bits/atomic_wait.h (__waiter_pool_base::_M_notify):
Move increment of _M_ver here.
[!_GLIBCXX_HAVE_PLATFORM_WAIT]: Lock mutex around increment.
Use relaxed memory order and always notify all waiters.
(__waiter_base::_M_do_wait) [!_GLIBCXX_HAVE_PLATFORM_WAIT]:
Check value again after locking mutex.
(__waiter_base::_M_notify): Remove increment of _M_ver.
projects / thirdparty / gcc.git / log
