On Thu, Nov 30, 2023 at 5:13 AM Alexandre Oliva wrote:
>
> On Nov 29, 2023, Richard Biener wrote:
>
> >> Because _#(D)[n_#] is good gimple, but &(*byref_arg_#(D))[n_#] isn't.
>
> > 'arg_#(D)' looks like a SSA name, and no, taking the address doesn't work,
>
On Thu, Nov 30, 2023 at 6:04 AM Alexandre Oliva wrote:
>
> On Nov 29, 2023, Richard Biener wrote:
>
> > On Wed, Nov 29, 2023 at 9:53 AM Alexandre Oliva wrote:
>
> >> Because _#(D)[n_#] is good gimple, but &(*byref_arg_#(D))[n_#] isn't.
>
> > 'arg_#(D
On Thu, 30 Nov 2023, Alexandre Oliva wrote:
> On Nov 29, 2023, Hans-Peter Nilsson wrote:
>
> >> XPASS: gcc.dg/tree-ssa/scev-3.c scan-tree-dump-times ivopts "" 1
> >> XPASS: gcc.dg/tree-ssa/scev-4.c scan-tree-dump-times ivopts "" 1
> >> XPASS: gcc.dg/tree-ssa/scev-5.c scan-tree-dump-times ivopts
ar stmt.%G", stmt);
> > +"not vectorized: irregular stmt: %G",
> > stmt);
> > }
> >
> >tree vectype;
> > @@ -14490,6 +14528,14 @@ vect_get_vector_types_for_stmt (vec_info
> > *vinfo, stmt_vec_info stmt_inf
rizable_lc_phi (as_a (vinfo),
> > stmt_info, NULL, node)
> > || vectorizable_recurr (as_a (vinfo),
> > - stmt_info, NULL, node, cost_vec));
> > + stmt_info, NULL, node, cost_vec)
> > + || vectorizable_early_exit (vinfo, stmt_info, NULL, NULL, node,
> > + cost_vec));
> >else
> > {
> >if (bb_vinfo)
> > @@ -12951,7 +13147,10 @@ vect_analyze_stmt (vec_info *vinfo,
> > NULL, NULL, node, cost_vec)
> > || vectorizable_comparison (vinfo, stmt_info, NULL, NULL, node,
> > cost_vec)
> > - || vectorizable_phi (vinfo, stmt_info, NULL, node, cost_vec));
> > + || vectorizable_phi (vinfo, stmt_info, NULL, node, cost_vec)
> > + || vectorizable_early_exit (vinfo, stmt_info, NULL, NULL, node,
> > + cost_vec));
> > +
> > }
> >
> >if (node)
> > @@ -13110,6 +13309,12 @@ vect_transform_stmt (vec_info *vinfo,
> >gcc_assert (done);
> >break;
> >
> > +case loop_exit_ctrl_vec_info_type:
> > + done = vectorizable_early_exit (vinfo, stmt_info, gsi, _stmt,
> > + slp_node, NULL);
> > + gcc_assert (done);
> > + break;
> > +
> > default:
> >if (!STMT_VINFO_LIVE_P (stmt_info))
> > {
> > @@ -13511,7 +13716,7 @@ vect_is_simple_use (tree operand, vec_info
> > *vinfo, enum vect_def_type *dt,
> > case vect_first_order_recurrence:
> > dump_printf (MSG_NOTE, "first order recurrence\n");
> > break;
> > - case vect_early_exit_def:
> > + case vect_early_exit_def:
> > dump_printf (MSG_NOTE, "early exit\n");
> > break;
> > case vect_unknown_def_type:
> >
> >
> >
> >
> > --
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
{
> + if (dump_enabled_p ())
> + dump_printf_loc (MSG_NOTE, vect_location,
> +"vec_stmt_relevant_p: induction forced for "
> +"early break.\n");
> + *live_p = true;
> +
> +}
> +
>if (*live_p && *relevant == vect_unused_in_scope
>&& !is_simple_and_all_uses_invariant (stmt_info, loop_vinfo))
> {
> @@ -1774,7 +1788,7 @@ compare_step_with_zero (vec_info *vinfo, stmt_vec_info
> stmt_info)
> /* If the target supports a permute mask that reverses the elements in
> a vector of type VECTYPE, return that mask, otherwise return null. */
>
> -static tree
> +tree
> perm_mask_for_reverse (tree vectype)
> {
>poly_uint64 nunits = TYPE_VECTOR_SUBPARTS (vectype);
> @@ -12720,20 +12734,27 @@ can_vectorize_live_stmts (vec_info *vinfo,
> stmt_vec_info stmt_info,
> bool vec_stmt_p,
> stmt_vector_for_cost *cost_vec)
> {
> + loop_vec_info loop_vinfo = dyn_cast (vinfo);
>if (slp_node)
> {
>stmt_vec_info slp_stmt_info;
>unsigned int i;
>FOR_EACH_VEC_ELT (SLP_TREE_SCALAR_STMTS (slp_node), i, slp_stmt_info)
> {
> - if (STMT_VINFO_LIVE_P (slp_stmt_info)
> + if ((STMT_VINFO_LIVE_P (slp_stmt_info)
> +|| (loop_vinfo
> +&& LOOP_VINFO_EARLY_BREAKS (loop_vinfo)
> +&& STMT_VINFO_DEF_TYPE (slp_stmt_info)
> + == vect_induction_def))
> && !vectorizable_live_operation (vinfo, slp_stmt_info, slp_node,
> slp_node_instance, i,
> vec_stmt_p, cost_vec))
> return false;
> }
> }
> - else if (STMT_VINFO_LIVE_P (stmt_info)
> + else if ((STMT_VINFO_LIVE_P (stmt_info)
> + || (LOOP_VINFO_EARLY_BREAKS (loop_vinfo)
> + && STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def))
> && !vectorizable_live_operation (vinfo, stmt_info,
> slp_node, slp_node_instance, -1,
> vec_stmt_p, cost_vec))
> diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
> index
> de60da31e2a3030a7fbc302d3f676af9683fd019..fd4b0a787e6128b43c5ca2b0612f55845e6b3cef
> 100644
> --- a/gcc/tree-vectorizer.h
> +++ b/gcc/tree-vectorizer.h
> @@ -2248,6 +2248,7 @@ extern bool vect_is_simple_use (vec_info *,
> stmt_vec_info, slp_tree,
> enum vect_def_type *,
> tree *, stmt_vec_info * = NULL);
> extern bool vect_maybe_update_slp_op_vectype (slp_tree, tree);
> +extern tree perm_mask_for_reverse (tree);
> extern bool supportable_widening_operation (vec_info*, code_helper,
> stmt_vec_info, tree, tree,
> code_helper*, code_helper*,
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Wed, Nov 29, 2023 at 9:53 AM Alexandre Oliva wrote:
>
> On Nov 23, 2023, Richard Biener wrote:
>
> > Conceptually it shouldn't be much different from what IPA-SRA does
> > which is cloning a function but with different arguments, the function
> > signature transfor
On Tue, Nov 28, 2023 at 7:56 PM Andrew Pinski wrote:
>
> On Tue, Nov 28, 2023 at 7:38 AM wrote:
> >
> > From: Ezra Sitorus
> >
> > Add the transform rule (T)(~A) -> ~(T)(A) for view_convert. The simplified
> > result could be a single assembly instruction when chained with other
> >
On Tue, Nov 28, 2023 at 7:08 AM Andrew Pinski wrote:
>
> On Mon, Nov 27, 2023 at 10:04 PM Feng Wang
> wrote:
> >
> > On 2023-11-28 11:06 Andrew Pinski wrote:
> > >On Mon, Nov 27, 2023 at 6:56 PM Feng Wang
> > >wrote:
> > >>
> > >> The link of PATCH v1:
> > >>
On Wed, Nov 29, 2023 at 10:35 AM Uros Bizjak wrote:
>
> The compiler, configured with --enable-checking=yes,rtl,extra ICEs with:
>
> internal compiler error: RTL check: expected elt 0 type 'e' or 'u',
> have 'E' (rtx unspec) in try_combine, at combine.cc:3237
>
> This is
>
> 3236 /*
; }
>wi_unpack (b_dividend, dividend.get_val (), dividend.get_len (),
>dividend_blocks_needed, dividend_prec, UNSIGNED);
> @@ -1969,7 +1975,7 @@ wi::divmod_internal (HOST_WIDE_INT *quot
>if (b_quotient == b_quotient_buf)
> memset (b_quotient_buf, 0, sizeof (
> Am 29.11.2023 um 09:29 schrieb Jakub Jelinek :
>
> Hi!
>
> We ICE on the following testcase when wi::multiple_of_p is called on
> widest_int 1 and -128 with UNSIGNED. I still need to work on the
> actual wide-int.cc issue, the latest patch attached to the PR regressed
> bitint-{38,39}.c,
On Tue, Nov 28, 2023 at 8:54 AM liuhongt wrote:
>
> 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,
On Tue, 28 Nov 2023, Jeff Law wrote:
>
>
> On 11/28/23 00:50, Richard Biener wrote:
>
> >
> > There's no way to distinguish a partial vs. non-partial MEM on RTL and
> > while without the bogus MEM_ATTR the alias oracle pieces that
> > miscompiled the origi
gimple_stmt_iterator exit_gsi = gsi_after_labels (exit_bb);
> - if (stmts)
> - gsi_insert_seq_before (_gsi, stmts, GSI_SAME_STMT);
> + gimple_stmt_iterator exit_gsi;
> + tree new_tree
> + = vectorizable_live_operation_1 (loop_vinfo, stmt_info,
> + LOOP_VINFO_IV_EXIT (loop_vinfo),
> + vectype, ncopies, slp_node, bitsize,
> + bitstart, vec_lhs, lhs_type,
> + _gsi);
>
>/* Remove existing phis that copy from lhs and create copies
>from new_tree. */
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> Am 28.11.2023 um 18:38 schrieb Jan Hubicka :
>
>
>>
>>
>>
>>>> Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
>>>
>>>
>>>>
>>>>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>>>>>
> Am 28.11.2023 um 17:59 schrieb Jan Hubicka :
>
>
>>
>>> On Tue, 28 Nov 2023, Martin Jambor wrote:
>>>
>>> On Tue, Nov 28 2023, Richard Biener wrote:
>>>> On Mon, 27 Nov 2023, Martin Jambor wrote:
>>>>
>>>>
On Tue, 28 Nov 2023, Martin Jambor wrote:
> On Tue, Nov 28 2023, Richard Biener wrote:
> > On Mon, 27 Nov 2023, Martin Jambor wrote:
> >
> >> Hi,
> >>
> >> The enhancement to address PR 109849 contained an importsnt thinko,
> >> and that
On Tue, Nov 28, 2023 at 5:44 AM Andrew Pinski wrote:
>
> This fixes the incorrect assumption that was done in r14-3721-ge6bcf839894783,
> that being able to doing the negative after the conversion would be a valid
> thing
> but really it is not valid for boolean types.
>
> OK? Bootstrapped and
On Tue, Nov 28, 2023 at 2:24 PM Rainer Orth
wrote:
>
> The gcc.dg/scantest-lto.c test FAILs on Solaris/SPARC with the native as:
>
> FAIL: gcc.dg/scantest-lto.c scan-assembler-not ascii
> FAIL: gcc.dg/scantest-lto.c scan-assembler-times ascii 0
>
> It requires double-quoting the section name
The GIMPLE frontend, when bypassing gimplification, doesn't set
DECL_SEEN_IN_BIND_EXPR_P given there are no such things in GIMPLE.
But it probably should set the flag anyway to avoid later ICEs
when regimplifying.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR
The following fixes a stray TYPE_ALIAS_SET in a type variant built
by build_opaque_vector_type which is diagnosed by type checking
enabled with -flto.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/112732
* tree.cc (build_opaque_vector_type): Reset
On Tue, 28 Nov 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 28 Nov 2023, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > On Mon, 27 Nov 2023, Jeff Law wrote:
> >> >
> >> >>
> >> >
On Tue, 28 Nov 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Mon, 27 Nov 2023, Jeff Law wrote:
> >
> >>
> >>
> >> On 11/27/23 05:39, Robin Dapp wrote:
> >> >> The easiest way to avoid running into the alias analysi
On Tue, 28 Nov 2023, Jiufu Guo wrote:
>
> Hi,
>
> Thanks so much for your helpful review!
>
> Richard Biener writes:
>
> > On Fri, Oct 27, 2023 at 3:51?AM Jiufu Guo wrote:
> >>
> >> Hi,
> >>
> >> Compare with previous versi
On Tue, 28 Nov 2023, Joseph Myers wrote:
> On Sun, 26 Nov 2023, Martin Uecker wrote:
>
> > My understand is that it is used for aliasing analysis and also
> > checking of conversions. TYPE_CANONICAL must be consistent with
> > the idea the middle-end has about type conversions. But as long
> >
et_supports_op_p (type, code, optab_vector))
> + return false;
> + }
> +
> /* Fold in dependencies and cost of the condition. */
> FOR_EACH_SSA_TREE_OPERAND (val, cond, iter, SSA_OP_USE)
> {
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> Am 28.11.2023 um 09:58 schrieb Jakub Jelinek :
>
> On Tue, Nov 28, 2023 at 09:43:52AM +0100, Jakub Jelinek wrote:
>>> On Tue, Nov 28, 2023 at 03:56:47PM +0800, juzhe.zh...@rivai.ai wrote:
>>> Hi, there is a regression in RISC-V caused by this patch:
>>>
>>> FAIL: gcc.dg/vect/pr111754.c
> Am 28.11.2023 um 09:36 schrieb Jakub Jelinek :
>
> Hi!
>
> When looking around, I've noticed we have a similar simplification
> for parity (with ^ rather than +). Note, unlike the popcount one,
> this one doesn't check for INTEGRAL_TYPE_P (type) (which rules out
> vector simplification),
> Am 28.11.2023 um 09:30 schrieb Jakub Jelinek :
>
> Hi!
>
> Since my PR112566 r14-5557 changes the following testcase ICEs, because
> .POPCOUNT (x) + .POPCOUNT (y) has a simplification attempted even when
> x and y have incompatible types (different precisions).
> Note, with _BitInt it can
On Mon, 27 Nov 2023, Richard Sandiford wrote:
> Catching up on backlog, so this might already be resolved, but:
>
> Richard Biener writes:
> > On Tue, 7 Nov 2023, Tamar Christina wrote:
> >
> >> > -Original Message-
> >> > From: Richard Bie
DIRECTLY);
> + }
> + else
> + can_be_returned = false;
> + ret |= build_access_from_call_arg (gimple_call_arg (call,
> + i),
> +
On Mon, 27 Nov 2023, Jeff Law wrote:
>
>
> On 11/27/23 05:39, Robin Dapp wrote:
> >> The easiest way to avoid running into the alias analysis problem is
> >> to scrap the MEM_EXPR when we expand the internal functions for
> >> partial loads/stores. That avoids the disambiguation we run into
>
The following separates the escape solution for return stmts not
only during points-to solving but also for later querying. This
requires adjusting the points-to-global tests to include escapes
through returns. Technically the patch replaces the existing
post-processing which computes the
ld_vector_from_val
> for all eligible vectors.
>
> Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu.
> OK to install?
OK.
Thanks for picking up.
Richard.
> Richard
>
>
> 2023-11-27 Richard Biener
> Richard Sandiford
On Fri, Nov 24, 2023 at 5:53 PM Andrew MacLeod wrote:
>
> This problem here is that IPA is calling something like operator_minus
> with 2 operands, one with precision 32 (int) and one with precision 64
> (pointer). There are various ways this can happen as mentioned in the PR.
>
> Regardless of
We lack a match.pd pattern recognizing ptr + o ==/!= ptr + o'.
The following extends handling we have for integral types to
pointers.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/112706
* match.pd (ptr + o ==/!=/- ptr + o'): New patterns.
On Mon, Nov 27, 2023 at 9:11 AM FX Coudert wrote:
>
> Hi,
>
> I’d like to ping that patch from Iain Sandoe. It would clear up a number of
> failures in the darwin testsuite.
OK.
> Thanks,
> FX
>
>
>
> > --- 8< ---
> >
> > Earlier assembler support for complex fp16 on x86_64 Darin is broken.
piler does not consider aliasing to occur in those cases (even though
> > in fact there is aliasing).
> >
> > If that's the intent of this test, it definitely needs commenting. The
> > test would also need to (be a gnu23-* test and) use appropriate attributes
>
On Sat, Nov 25, 2023 at 12:26 PM Sebastian Huber
wrote:
>
> contrib/ChangeLog
Did you verify an in-tree build with these works and the testsuite
is clean?
> * download_prerequisites: Update to gmp-6.3.0, mpfr-4.2.1,
> mpc-1.3.1, isl-0.26, and gettext-0.22.4.
> *
> + a usage later on after peeling which is needed for the alternate exit.
> */
> + if (LOOP_VINFO_EARLY_BREAKS (loop_vinfo)
> + && STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def)
> +{
> + if (dump_enabled_p ())
> + dump_printf_loc (MSG_NOTE, vec
#define LOOP_VINFO_EARLY_BREAKS_VECT_PEELED(L) \
> + (single_pred ((L)->loop->latch) != (L)->vec_loop_iv_exit->src)
> #define LOOP_VINFO_EARLY_BRK_CONFLICT_STMTS(L) (L)->early_break_conflict
> #define LOOP_VINFO_EARLY_BRK_DEST_BB(L)(L)->early_break_dest_bb
>
est are dealt with via bb_before_epilog
> + adjustments. */
> + e->dest->count = e->count ();
> +
>/* Scalar version loop may be preferred. In this case, add guard
>and skip to epilog. Note this only happens when the number of
>iterations of loop is unknown at compile time, otherwise this
> diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
> index
> b5e27d1c46d9cb3dfe5b44f1b49c9e4204572ff1..39aa4d1250efe308acccf484d370f8adfd1ba843
> 100644
> --- a/gcc/tree-vectorizer.h
> +++ b/gcc/tree-vectorizer.h
> @@ -1821,7 +1821,7 @@ is_loop_header_bb_p (basic_block bb)
> {
>if (bb == (bb->loop_father)->header)
> return true;
> - gcc_checking_assert (EDGE_COUNT (bb->preds) == 1);
> +
>return false;
> }
>
> @@ -2212,7 +2212,8 @@ extern bool slpeel_can_duplicate_loop_p (const class
> loop *, const_edge,
>const_edge);
> class loop *slpeel_tree_duplicate_loop_to_edge_cfg (class loop *, edge,
> class loop *, edge,
> - edge, edge *, bool = true);
> + edge, edge *, bool = true,
> + vec * = NULL);
> class loop *vect_loop_versioning (loop_vec_info, gimple *);
> extern class loop *vect_do_peeling (loop_vec_info, tree, tree,
> tree *, tree *, tree *, int, bool, bool,
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
The following makes sure to allocate enough space for vectype_op
in vectorizable_reduction.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/112677
* tree-vect-loop.cc (vectorizable_reduction): Use alloca
to allocate vectype_op.
---
On Fri, 24 Nov 2023, Martin Jambor wrote:
> Hello,
>
> On Thu, Nov 23 2023, Jonathan Wakely wrote:
> > On Thu, 23 Nov 2023 at 15:34, Jan Hubicka wrote:
> >>
>
> [...]
>
> >>
> >> I also wonder, if default operator new and malloc can be handled as not
> >> reading/modifying anything visible to
On Fri, 24 Nov 2023, Jakub Jelinek wrote:
> On Fri, Nov 24, 2023 at 10:20:01AM +0100, Richard Biener wrote:
> > > + /* Similarly, e.g. with -frounding-math casts from _BitInt
> > > INTEGER_CSTs
> > > + to floating point types need to be re
260525
> +0100
> +++ gcc/testsuite/gcc.dg/pr112673.c 2023-11-23 18:31:31.863765381 +0100
> @@ -0,0 +1,10 @@
> +/* PR tree-optimization/112673 */
> +/* { dg-do compile { target bitint575 } } */
> +/* { dg-options "-O3" } */
> +/* { dg-additional-options "-mavx2&
(TREE_TYPE (t));
> if (this_kind > kind)
> kind = this_kind;
> }
> --- gcc/testsuite/gcc.dg/bitint-42.c.jj 2023-11-23 16:50:52.392502318
> +0100
> +++ gcc/testsuite/gcc.dg/bitint-42.c 2023-11-23 16:42:08.559881704 +0100
> @@ -0,0
On Fri, Nov 24, 2023 at 6:33 AM Xi Ruoyao wrote:
>
> With -fno-fp-int-builtin-inexact, trunc is not allowed to raise
> FE_INEXACT and it should produce an integral result (if the input is not
> NaN or Inf). Thus FE_INEXACT should not be raised.
>
> But (int)x may raise FE_INEXACT when x is a
On Thu, Nov 23, 2023 at 7:14 PM Alexander Monakov wrote:
>
> Our system.h and configure.ac try to accommodate valgrind-3.1, but it is
> more than 15 years old at this point. As Valgrind-based checking is a
> developer-oriented feature, drop the compatibility stuff and streamline
> the detection.
On Thu, Nov 23, 2023 at 7:14 PM Alexander Monakov wrote:
>
> When top-level configure has either --enable-checking=valgrind or
> --enable-valgrind-annotations, we want to activate a couple of workarounds
> in libcpp. They do not use anything from the Valgrind API, so just
> delete all detection.
The following tries to reduce the number of cases we use an unsigned
type for the addition when we know the original signed increment was
OK which is when the total unsigned increment computed fits the signed
type as well.
This fixes the observed testsuite fallout.
Bootstrapped and tested on
> Am 23.11.2023 um 16:17 schrieb Jose E. Marchesi :
>
> [Changes from V1:
> - Use always_inline only in BPF target.]
>
> The function __hardcfr_check_fail in hardcfr.c is internal and static
> inline. It receives many arguments, which require more than five
> registers to be passed in
On Thu, Nov 23, 2023 at 2:56 PM Jakub Jelinek wrote:
>
> On Thu, Nov 23, 2023 at 01:10:02PM +0100, Richard Biener wrote:
> > Looks a bit better. As for constructing a gsi_end_p () iterator for a
> > basic-block
> > I'd simply add a new gsi_end_{bb,seq} ({basic_block,gi
On Thu, Nov 23, 2023 at 2:47 PM Sebastian Huber
wrote:
>
> gcc/ChangeLog:
> PR tree-optimization/112678
>
> * tree-profile.cc (tree_profiling): Do not use atomic operations
> for -fprofile-update=single.
> ---
> gcc/tree-profile.cc | 8 +---
> 1 file changed, 5
On Wed, Nov 22, 2023 at 3:39 PM Jose E. Marchesi
wrote:
>
> The function __hardcfr_check_fail in hardcfr.c is internal and static
> inline. It receives many arguments, which require more than five
> registers to be passed in bpf-none-unknown targets. BPF is limited to
> that number of registers
On Fri, Oct 27, 2023 at 3:51 AM Jiufu Guo wrote:
>
> Hi,
>
> Compare with previous version:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632399.html
> This verion supports TI/VEC mode of the access.
>
> There are a few PRs (meta-bug PR101926) on various targets.
> The root causes of
On Thu, Nov 23, 2023 at 12:55 PM Jakub Jelinek wrote:
>
> On Thu, Nov 23, 2023 at 11:56:33AM +0100, Jakub Jelinek wrote:
> > Now, regarding m_init_gsi, I think I'll need to play around, maybe
> > I should have in the end insert after and update behavior rather than
> > insert after, and that
On Thu, Nov 23, 2023 at 11:56 AM Alexandre Oliva wrote:
>
> Hello, Richi,
>
> Thanks for the extensive review!
>
> On Nov 22, 2023, Richard Biener wrote:
>
> > On Mon, Nov 20, 2023 at 1:40 PM Alexandre Oliva wrote:
> >>
> >
On Thu, Nov 23, 2023 at 11:05 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the following testcase shows, we ICE when trying to emit ADDR_EXPR of
> a bitint variable which doesn't have mode width.
> The problem is in the EXTEND_BITINT stuff which makes sure we treat the
> padding bits on memory reads
On Thu, Nov 23, 2023 at 10:43 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the following testcase shows, there are some bugs in the
> -fnon-call-exceptions bit-field load lowering. In particular, there
> is a case where we want to emit a load early in the initialization
> (before m_init_gsi) and
On Thu, Nov 23, 2023 at 4:02 AM Kewen.Lin wrote:
>
> on 2023/11/22 18:25, Richard Biener wrote:
> > On Wed, Nov 22, 2023 at 10:31 AM Kewen.Lin wrote:
> >>
> >> on 2023/11/17 20:55, Alexander Monakov wrote:
> >>>
> >>> On Fri, 17 Nov 20
On Wed, 22 Nov 2023, Jakub Jelinek wrote:
> On Wed, Nov 22, 2023 at 01:21:12PM +0100, Jakub Jelinek wrote:
> > So, pedantically perhaps just assuming TRY_CATCH_EXPR where second argument
> > is not STATEMENT_LIST to be the CATCH_EXPR/EH_FILTER_EXPR case could work
> > for C++, but there are other
On Thu, 23 Nov 2023, Jakub Jelinek wrote:
> On Thu, Nov 23, 2023 at 08:00:49AM +0000, Richard Biener wrote:
> > The following amends the cpymem documentation to mention that exact
> > overlap needs to be handled gracefully, also noting that the target
> > runtime is expect
The following amends the cpymem documentation to mention that exact
overlap needs to be handled gracefully, also noting that the target
runtime is expected to behave the same way.
OK?
Thanks,
Richard.
PR middle-end/32667
* md.texi (cpymem): Document that exact overlap of source
When performing final value replacement chrec_apply that's used to
compute the overall effect of niters to a CHREC doesn't consider that
the overall increment of { -2147483648, +, 2 } doesn't fit in
a signed integer when the loop iterates until the value of the IV
of 20. The following fixes this
On Mon, Nov 20, 2023 at 1:40 PM Alexandre Oliva wrote:
>
> On Oct 26, 2023, Alexandre Oliva wrote:
>
> >> This is a refreshed and improved version of the version posted back in
> >> June. https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621936.html
>
> > Ping?
On Mon, Nov 20, 2023 at 1:54 PM Alexandre Oliva wrote:
>
> On Sep 20, 2023, Alexandre Oliva wrote:
>
> > This patch introduces an attribute to add extra asm names (aliases)
> > for a decl when its definition is output.
>
> Ping?
>
3-11-21 19:22:47.437439283
> +0100
> +++ gcc/testsuite/g++.dg/eh/pr112619.C2023-11-21 19:22:24.887754376
> +0100
> @@ -0,0 +1,15 @@
> +// PR c++/112619
> +// { dg-do compile }
> +
> +struct S { S (); ~S (); };
> +
> +S
> +foo (int a, int b)
> +{
> + if (a || b)
> +{
> + S s;
> + return s;
> +}
> + return S ();
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Wed, Nov 22, 2023 at 10:31 AM Kewen.Lin wrote:
>
> on 2023/11/17 20:55, Alexander Monakov wrote:
> >
> > On Fri, 17 Nov 2023, Kewen.Lin wrote:
> >>> I don't think you can run cleanup_cfg after sched_init. I would suggest
> >>> to put it early in schedule_insns.
> >>
> >> Thanks for the
On Wed, Nov 22, 2023 at 3:30 AM Li, Pan2 wrote:
>
> Hi Richard S,
>
> Thanks a lot for reviewing and comments. May I know is there any concern or
> further comments for landing this patch to GCC-14?
It looks like Jeff approved the patch?
Richard.
> Pan
>
> -Original Message-
> From:
On Wed, Nov 22, 2023 at 3:04 AM Hans-Peter Nilsson wrote:
>
> I added that xfail in February for { ilp32 && c++98_only } and it
> looks like it's moved on to lp64 now. :-/ Noted by Rainer
> Orth, see the PR.
>
> Tested cris-elf and x86_64-pc-linux-gnu w/wo. -m32.
> Ok to commit?
OK
> -- >8 --
EE, _oprnds1, NULL_TREE,
> - op.ops[2], _oprnds2, NULL_TREE);
> + reduc_index == 1 ? NULL_TREE : op.ops[1],
> + _oprnds1, NULL_TREE,
> + reduc_index == 2 ? NULL_TREE : op.ops[2],
> + _oprnds2, NULL_TREE);
> }
>
>/* For single def-use cycles get one copy of the vectorized reduction
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
For vec_pack_trunc patterns there can be an ambiguity for the
source mode for BFmode vs HFmode. The vectorizer checks
the insns operand mode for this, the following makes forwprop
do the same. That of course doesn't help if the target supports
both conversions.
Bootstrapped and tested on
The following moves the check whether the maximum vectorization
factor determined by data dependence analysis is in conflict with
the chosen vectorization factor to after the point where we applied
both the SLP and the unrolling adjustment to the vectorization
factor. We check the latter before
On Thu, Nov 9, 2023 at 6:53 PM Di Zhao OS wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, October 31, 2023 9:48 PM
> > To: Di Zhao OS
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH v4]
On Tue, Nov 21, 2023 at 10:38 AM Richard Earnshaw
wrote:
>
>
>
> On 20/11/2023 21:49, Tamar Christina wrote:
> >> -Original Message-
> >> From: Richard Earnshaw
> >> Sent: Monday, November 20, 2023 12:53 PM
> >> To: Tamar Christina ; gcc-patches@gcc.gnu.org
> >> Cc: nd ; Richard Earnshaw
On Tue, Nov 21, 2023 at 9:56 AM Alexander Monakov wrote:
>
>
> On Tue, 21 Nov 2023, Richard Biener wrote:
>
> > and this, too, btw. - the DSE actually happens, the latter transform not.
> > We specifically "opt out" of doing that for QOI to not make undefined
>
On Tue, Nov 21, 2023 at 9:30 AM Ajit Agarwal wrote:
>
> Hello All:
>
> This patch marked LOOP_DATA->live as the livein at the loop header basic
> block. This is because Livein at each basic block is live in at the loop
> header.
The current code does the same, you now have fewer regs live. In
; } */
>__builtin_ctzg (0U, true);
> - __builtin_ctzg (0U, E0); /* { dg-error "does not have 'int' type" "" {
> target c++ } } */
> + __builtin_ctzg (0U, E0); /* { dg-error "does not have 'int' type" "" {
> target { c++ &&
SIZEOF_LONG_LONG__ * __CHAR_BIT__ - 1 || b != 2)
> +__builtin_abort ();
> + if (foo () != __SIZEOF_LONG_LONG__ * __CHAR_BIT__ - 2 || b != 3)
> +__builtin_abort ();
> + b = 0;
> + if (bar () != __SIZEOF_LONG_LONG__ * __CHAR_BIT__ || b != 1)
> +__builtin_abort ();
&g
On Tue, Nov 21, 2023 at 8:59 AM Alexander Monakov wrote:
>
>
> On Tue, 21 Nov 2023, Alexander Monakov wrote:
>
> > I am concerned that if GCC ever learns to leave out the following access
> > to 'this->foo', leaving tmp uninitialized, we will end up with:
> >
> > this->foo = 42;
>
> Sorry,
The error message improved, adjust arm specific testcases.
Pushed.
* gcc.target/arm/bfloat16_vector_typecheck_1.c: Adjust.
* gcc.target/arm/bfloat16_vector_typecheck_2.c: Likewise.
* gcc.target/aarch64/bfloat16_vector_typecheck_1.c: Likewise.
*
There's a missed index adjustment for the SLP vector number when
computing the index/data vectors for emulated gather/scatter with SLP.
The following fixes this.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/111970
* tree-vect-stmts.cc
> Am 20.11.2023 um 19:02 schrieb Martin Jambor :
>
> Hi Richi,
>
>> On Wed, Sep 20 2023, Richard Biener wrote:
>> The following turns MAX_NUM_CHAINS and MAX_CHAIN_LEN to params which
>> allows to experiment with raising them. For the testcase in PR111489
>&g
On Mon, Nov 20, 2023 at 3:34 PM Sebastian Huber
wrote:
>
> This fixes issues like this:
>
> gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c: In function
> 'main':
> gcc/testsuite/gcc.dg/no_profile_instrument_function-attr-1.c:19:1: error:
> incorrect sharing of tree nodes
>
The following avoids ICEing when trying to convert a vector to
a scalar float.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/112622
* convert.cc (convert_to_real_1): Use element_precision
where a vector type might appear. Provide specific
The following fixes an omission in dependence testing for loop
distribution. When the overall dependence distance is not zero but
the dependence direction in the innermost common loop is = there is
a conflict between the partitions and we have to merge them.
Bootstrapped and tested on
We have to make sure to remove unused .MASK_CALL internal function
calls after vectorization.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/112618
* tree-vect-loop.cc (vect_transform_loop_stmt): For not
relevant and unused .MASK_CALL
On Mon, 20 Nov 2023, Alexandre Oliva wrote:
> On Oct 20, 2023, Alexandre Oliva wrote:
>
> > Here's a refreshed and retested version of the patch for hardened
> > booleans in C. It is unchanged aside from some conflict resolution,
> > compared with the previous version posted back in June.
> >
On Mon, Nov 20, 2023 at 1:51 PM Alexandre Oliva wrote:
>
> On Sep 23, 2023, Alexandre Oliva wrote:
>
> > On Sep 21, 2023, Alexandre Oliva wrote:
> >> On Sep 15, 2023, Alexandre Oliva wrote:
> >>> On Jun 22, 2023, Alexandre Oliva wrote:
> On Jun 2, 2023, Alexandre Oliva wrote:
> >
On Mon, Nov 20, 2023 at 2:42 PM Maxim Kuvyrkov
wrote:
>
> > On Nov 20, 2023, at 17:09, Richard Biener
> > wrote:
> >
> > On Mon, Nov 20, 2023 at 1:08 PM Maxim Kuvyrkov
> > wrote:
> >>
> >> This patch avoids sched-deps.cc:find_inc() creating ex
On Mon, Nov 20, 2023 at 1:08 PM Maxim Kuvyrkov
wrote:
>
> This patch avoids sched-deps.cc:find_inc() creating exponential number
> of dependencies, which become memory and compilation time hogs.
> Consider example (simplified from PR96388) ...
> ===
> sp=sp-4 // sp_insnA
> mem_insnA1[sp+A1]
> ...
On Mon, Nov 20, 2023 at 11:16 AM Maciej W. Rozycki wrote:
>
> On Sun, 19 Nov 2023, Kito Cheng wrote:
>
> > ok
>
> Thank you for your review, but I think I need a general maintainer's ack
> for this one.
OK.
> Maciej
On Mon, Nov 20, 2023 at 9:56 AM Michael Meissner wrote:
>
> On Mon, Nov 20, 2023 at 08:24:35AM +0100, Richard Biener wrote:
> > I wouldn't expose the "fake" larger modes to the vectorizer but rather
> > adjust m_suggested_unroll_factor (which you already do to some ex
On Mon, 20 Nov 2023, Jakub Jelinek wrote:
> On Mon, Nov 20, 2023 at 08:37:55AM +0000, Richard Biener wrote:
> > > I'm not sure about that, it would be nice for them to be usable there,
> >
> > Btw, I think that {( .. )} should be made usable in sizeof () and
> &g
On Mon, 20 Nov 2023, Jakub Jelinek wrote:
> On Mon, Nov 20, 2023 at 07:54:54AM +0000, Richard Biener wrote:
> > On Fri, 17 Nov 2023, Jakub Jelinek wrote:
> > > Per the earlier discussions on this PR, the following patch folds
> > > popcount (x) == 1 (and != 1)
On Mon, 20 Nov 2023, Jakub Jelinek wrote:
> On Mon, Nov 20, 2023 at 09:18:57AM +0100, Florian Weimer wrote:
> > * Richard Biener:
> >
> > > Ugh. First of all I don't like that the exception is applied during
> > > folding. As for the problem of multi evaluati
Status
==
The GCC development branch which will become GCC 14 is in
general bugfixing mode (Stage 3) now. There is still time
to get larger changes in that were posted before the end
of Stage 1 but this is more aimed at fixing important bugs
that are not regressions and maybe flesh out
On Fri, Nov 17, 2023 at 8:20 PM Robin Dapp wrote:
>
> > No, you shouldn't place _7 != 0 inside the .COND_ADD but instead
> > have an extra pattern stmt producing that so
> >
> > patt_8 = _7 != 0;
> > patt_9 = .COND_ADD (patt_8, ...);
> >
> > that's probably still not enough, but I always quickly
1301 - 1400 of 25516 matches
Mail list logo