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
) == 12, "");
>static_assert (__builtin_classify_type (__typeof__ (u)) == 13, "");
>static_assert (__builtin_classify_type (__typeof__ (a)) == 14, "");
> + static_assert (__builtin_classify_type (__typeof__ (vi)) == 19, "");
> + static_assert (__builtin_cl
1, OPTAB_DIRECT);
> + if (argm1 == NULL_RTX)
> +goto fail;
> + rtx argxorargm1 = expand_simple_binop (mode, XOR, op0, argm1, NULL_RTX,
> + 1, OPTAB_DIRECT);
> + if (argxorargm1 == NULL_RTX)
> +goto fail;
> + rtx cmp = emit_store_flag (NULL_RTX, GTU, argxorargm1, argm1, mode, 1, 1);
> + if (cmp == NULL_RTX)
> +goto fail;
> + rtx_insn *cmp_insns = get_insns ();
> + end_sequence ();
> + unsigned popcount_cost = (seq_cost (popcount_insns, speed_p)
> + + seq_cost (popcount_cmp_insns, speed_p));
> + unsigned cmp_cost = seq_cost (cmp_insns, speed_p);
> + if (popcount_cost < cmp_cost)
> +emit_insn (popcount_insns);
> + else
> +{
> + emit_insn (cmp_insns);
> + plhs = expand_normal (lhs);
> + if (GET_MODE (cmp) != GET_MODE (plhs))
> + cmp = convert_to_mode (GET_MODE (plhs), cmp, 1);
> + emit_move_insn (plhs, cmp);
> +}
> +}
>
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
100
> @@ -0,0 +1,29 @@
> +/* PR tree-optimization/90693 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -mno-abm -mno-popcnt -fdump-tree-optimized" } */
> +/* { dg-final { scan-tree-dump-not "POPCOUNT \\\(" "optimized" } } */
> +/* { dg-final {
On Mon, 20 Nov 2023, Richard Biener wrote:
> On Sat, 18 Nov 2023, Jakub Jelinek wrote:
>
> > Hi!
> >
> > In https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html
> > Florian Weimer raised concern that the type-generic stdbit.h macros
> > cu
On Sat, Nov 18, 2023 at 8:38 PM Jakub Jelinek wrote:
>
> Hi!
>
> Another obstackle mentioned in the
> https://sourceware.org/pipermail/libc-alpha/2023-November/152819.html
> thread is that half of the stdc_{leading,trailing}_{zeros,ones},
> stdc_first_{leading,trailing}_{zero,one} and
iltin_ctzg ((unsigned _BitInt(156)) 0, 0ULL) != 156
>|| __builtin_clrsbg ((_BitInt(156)) 0) != 156 - 1
>|| __builtin_ffsg ((_BitInt(156)) 0) != 0
>|| __builtin_parityg ((unsigned _BitInt(156)) 0) != 0
> @@ -159,8 +161,10 @@ main ()
>|| popcount156 (-1) != 156
>|| __bu
On Sun, 19 Nov 2023, Jeff Law wrote:
>
>
> On 11/19/23 00:30, Alexandre Oliva wrote:
> >
> > I've recently patched scev-3.c and scev-5.c because it only passed by
> > accident on ia32. It also fails on some (but not all) arm-eabi
> > variants. It seems hard to characterize the conditions in
On Mon, Nov 20, 2023 at 5:19 AM Michael Meissner wrote:
>
> This is simiilar to the patches on November 10th.
>
> * https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636077.html
> * https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636078.html
> *
((unsigned
> _BitInt(512)) x); }
> +int bar (unsigned _BitInt(256) x) { return __builtin_popcountg ((unsigned
> _BitInt(512)) x); }
> +int baz (unsigned _BitInt(256) x) { return __builtin_parityg ((unsigned
> _BitInt(512)) x); }
> +int qux (_BitInt(256) x) { return __builtin_
The offending commit r14-5444-g5ea2965b499f9e was reverted. The
following adds a testcase.
Pushed.
PR tree-optimization/112585
* gcc.dg/torture/pr112585.c: New testcase.
---
gcc/testsuite/gcc.dg/torture/pr112585.c | 18 ++
1 file changed, 18 insertions(+)
ot;-march=skylake-avx512" { target i?86-*-*
> x86_64-*-* } }
> +// { dg-additional-options "-march=armv9-a" { target aarch64*-*-* } }
> +
> +struct t
> +{
> + long coef[1];
> + t(const unsigned long ) : coef{(long)a} {};
> + t(const t );
> +};
> +exter
se
> + gcc_unreachable ();
> +
> + scc.release ();
> +}
> +
> + cleanup_after_all_replaces_done (need_eh_cleanup, need_ab_cleanup,
> +stmts_to_fixup);
> +
> + /* Remove data structs for cleanup after stmt modification. */
> + BITMAP_FREE (need_eh_cleanup);
> + BITMAP_FREE (need_ab_cleanup);
> + stmts_to_fixup.release ();
> +}
> +
> +/* Called when pass execution starts. */
> +
> +static void
> +init_sccopy (void)
> +{
> + /* Clear statement flags. */
> + basic_block bb;
> + FOR_EACH_BB_FN (bb, cfun)
> +{
> + gimple_stmt_iterator gsi;
> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
> + {
> + gimple* stmt = gsi_stmt (gsi);
> + clear_stmt_dead (stmt);
> + tarjan_clear_using (stmt);
> + }
> +
> + gphi_iterator pi;
> + for (pi = gsi_start_phis (bb); !gsi_end_p (pi); gsi_next ())
> + {
> + gimple *stmt = pi.phi ();
> + clear_stmt_dead (stmt);
> + tarjan_clear_using (stmt);
> + }
> +}
> +}
> +
> +/* Called before pass execution ends. */
> +
> +static void
> +finalize_sccopy (void)
> +{
> + basic_block bb;
> +
> + /* Remove all propagated statements. */
> + FOR_EACH_BB_FN (bb, cfun)
> +{
> + gimple_stmt_iterator gsi;
> + for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi);)
You generally should remove stmts back-to-front to make
debug stmt generation work. To not re-invent the wheel
it might be simplest to use simple_dce_from_worklist with
the dead stmts defs as seeds (just remove set/is_stmt_dead
and track dead SSA defs in a bitmap).
> + {
> + gimple *stmt = gsi_stmt (gsi);
> + if (is_stmt_dead (stmt))
> + gsi_remove (, true);
> + else
> + gsi_next ();
this also fails to release the SSA def in the stmt.
release_defs (stmt);
would do that (or simple_dce_from_worklist).
> + }
> +
> + gphi_iterator pi;
> + for (pi = gsi_start_phis (bb); !gsi_end_p (pi);)
> + {
> + gphi *stmt = pi.phi ();
> +
> + if (is_stmt_dead (stmt))
> + remove_phi_node (, true);
> + else
> + gsi_next ();
> + }
> +}
> +
> + /* More cleanup. */
> + FOR_EACH_BB_FN (bb, cfun)
> +gimple_purge_dead_eh_edges (bb);
You only removed copies, I'm sure this should neve do anything?
As a general comment I wonder if we can simplify most of the
pass by starting SSA based SCC discovery from a copy stmt and
whether we can reduce the number of vec<>s that are allocated
and possibly re-allocated many times?
Thanks,
Richard.
> +}
> +
> +namespace {
> +
> +const pass_data pass_data_sccopy =
> +{
> + GIMPLE_PASS, /* type */
> + "sccopy", /* name */
> + OPTGROUP_NONE, /* optinfo_flags */
> + TV_NONE, /* tv_id */
> + ( PROP_cfg | PROP_ssa ), /* properties_required */
> + 0, /* properties_provided */
> + 0, /* properties_destroyed */
> + 0, /* todo_flags_start */
> + TODO_update_ssa | TODO_cleanup_cfg, /* todo_flags_finish */
> +};
> +
> +class pass_sccopy : public gimple_opt_pass
> +{
> +public:
> + pass_sccopy (gcc::context *ctxt)
> +: gimple_opt_pass (pass_data_sccopy, ctxt)
> + {}
> +
> + /* opt_pass methods: */
> + virtual bool gate (function *) { return true; }
> + virtual unsigned int execute (function *);
> + opt_pass * clone () final override { return new pass_sccopy (m_ctxt); }
> +}; // class pass_sccopy
> +
> +unsigned
> +pass_sccopy::execute (function *)
> +{
> + init_sccopy ();
> + sccopy_propagate ();
> + finalize_sccopy ();
> + return 0;
> +}
> +
> +} // anon namespace
> +
> +gimple_opt_pass *
> +make_pass_sccopy (gcc::context *ctxt)
> +{
> + return new pass_sccopy (ctxt);
> +}
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
> > > > > > > > > > > +use
> > > > > > > > > > > > niters
> > > > > > > > > > > > > > > > > + since if you exit from the
> > > > > > > > > > > > > > > > > main exit
> > > > > > > > > > > > > > > > > +you've
> > > > > &g
On Fri, Nov 17, 2023 at 10:04 AM Kewen.Lin wrote:
>
> on 2023/11/15 17:43, Alexander Monakov wrote:
> >
> > On Wed, 15 Nov 2023, Kewen.Lin wrote:
> >
> And I suppose it would be OK to do that. Empty BBs are usually removed
> by
> CFG cleanup so the situation should only happen in
On Fri, Nov 17, 2023 at 9:46 AM Arsen Arsenović wrote:
>
>
> David Edelsohn writes:
>
> > On Thu, Nov 16, 2023 at 5:52 PM Arsen Arsenović wrote:
> >
> > [snip]
> >> Sure, but my patch does insert --disable-shared:
> >>
> >> --8<---cut here---start->8---
> >>
On Fri, Nov 17, 2023 at 9:45 AM Robin Dapp wrote:
>
> > But note you can explicitly specify a vector type as well, there's an
> > overload for it, so we can fix the "invariant" case with the following
> > (OK if you can test this on relevant targets)
> >
> > diff --git a/gcc/tree-vect-loop.cc
On Fri, Nov 17, 2023 at 12:13 AM Arsen Arsenović wrote:
>
>
> Bruno Haible writes:
>
> > Hi David,
> >
> >> the default, distributed libintl library will not allow GCC to be built
> >> with NLS enabled.
> >
> > The problem is this configure test from gettext.m4
> >
> > checking for GNU gettext
On Fri, Nov 17, 2023 at 1:12 AM liuhongt wrote:
>
> x86 backend support reduc_{and,ior,xor>_scal_m for vector integer
> modes.
>
> Ok for trunk?
OK
> gcc/testsuite/ChangeLog:
>
> * lib/target-supports.exp (vect_logical_reduc): Add i?86-*-*
> and x86_64-*-*.
> ---
>
On Thu, Nov 16, 2023 at 11:30 PM Robin Dapp wrote:
>
> > For the fortran testcase we don't even run into this but hit an
> > internal def and assert on
> >
> > gcc_assert (STMT_VINFO_VEC_STMTS (def_stmt_info).length () ==
> > ncopies);
> >
> > I think this shows missing handling of .COND_*
On Thu, 16 Nov 2023, Jason Merrill wrote:
> On 10/30/23 08:57, Richard Biener wrote:
> > We have a support case that shows GCC 7 sometimes creates
> > DW_TAG_label refering to itself via a DW_AT_abstract_origin
> > when using LTO. This for example triggers the sanity check
&
as_a (stmt);
> + gimple_stmt_iterator call_gsi = gsi;
> +
> /* Operands must be processed before the lhs. */
> - for (i = 0; i < gimple_call_num_args (stmt); i++)
> + for (i = 0; i < gimple_call_num_args (call); i++)
> {
> - t = gimple_call_arg_ptr (stmt, i);
> - modified |= sra_modify_expr (t, , false);
> + int flags = gimple_call_arg_flags (call, i);
> + t = gimple_call_arg_ptr (call, i);
> + modified |= sra_modify_call_arg (t, _gsi, ,
> flags);
> }
> -
> - if (gimple_call_lhs (stmt))
> + if (gimple_call_chain (call))
> + {
> + t = gimple_call_chain_ptr (call);
> + int flags = gimple_call_static_chain_flags (call);
> + modified |= sra_modify_call_arg (t, _gsi, ,
> +flags);
> + }
> + if (gimple_call_lhs (call))
> {
> - t = gimple_call_lhs_ptr (stmt);
> - modified |= sra_modify_expr (t, , true);
> + t = gimple_call_lhs_ptr (call);
> + modified |= sra_modify_expr (t, true, _gsi, );
> }
> }
> break;
>
> case GIMPLE_ASM:
> {
> + gimple_stmt_iterator stmt_gsi = gsi;
> gasm *asm_stmt = as_a (stmt);
> for (i = 0; i < gimple_asm_ninputs (asm_stmt); i++)
> {
> t = _VALUE (gimple_asm_input_op (asm_stmt, i));
> - modified |= sra_modify_expr (t, , false);
> + modified |= sra_modify_expr (t, false, _gsi, );
> }
> for (i = 0; i < gimple_asm_noutputs (asm_stmt); i++)
> {
> t = _VALUE (gimple_asm_output_op (asm_stmt, i));
> - modified |= sra_modify_expr (t, , true);
> + modified |= sra_modify_expr (t, true, _gsi, );
> }
> }
> break;
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Am 16.11.2023 um 17:00 schrieb David Edelsohn :Bruno,I have been able to tweak the environment and build gettext and libintl. With the updated libintl and environment, GCC reliably does not use NLS.The issue is that libintl utilizes pthreads. AIX does not provide no-op pthread stubs in libc.
On Thu, 16 Nov 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, November 16, 2023 1:36 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH 7/
gt; > > > > > > loop_vinfo,
> > > > > > > > > > >/* Don't bother call vect_peel_nonlinear_iv_init.
> > > > > > > > > > > */
> > > > > > > > > > >else if (induction_ty
On Thu, 16 Nov 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, November 16, 2023 11:28 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH 7/
On Thu, 16 Nov 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, November 16, 2023 10:40 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH 7/
On Wed, 15 Nov 2023, Tamar Christina wrote:
>
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, November 15, 2023 1:42 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > S
On Tue, Nov 7, 2023 at 10:53 AM Richard Biener wrote:
>
> On Mon, 6 Nov 2023, Tamar Christina wrote:
>
> > Hi All,
> >
> > This adds new test to check for all the early break functionality.
> > It includes a number of codegen and runtime tests checking th
On Wed, 15 Nov 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, November 15, 2023 1:23 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH 7/
On Mon, Oct 30, 2023 at 1:10 PM Ajit Agarwal wrote:
>
> Hello Richard:
>
> Currently, code sinking will sink code at the use points with loop having same
> nesting depth. The following patch improves code sinking by placing the sunk
> code in immediate dominator with same loop nest depth.
>
>
00.
> This will fixes the error prone code as you have mentioned.
>
> This will add the register pressure and profile data both in better way.
>
> Please let me know if this is okay to submit.
>
> I will send the patch accordingly.
Please send an updated patch.
Richard.
> Tha
= f;
> + a[6] = g;
> + a[7] = h;
> +}
> +
> +void
> +baz (void)
> +{
> + int i = a[8];
> + int j = a[9];
> + int k = a[10];
> + int l = a[11];
> + int e = __builtin_clz (i);
> + int f = j ? __builtin_clz (j) : __SIZEOF_INT__ * __CHAR_BIT__;
> + int g =
On Thu, 16 Nov 2023, Dimitar Dimitrov wrote:
> On Wed, Nov 15, 2023 at 12:11:50PM +0000, Richard Biener wrote:
> > The following avoids hoisting of invariants from conditionally
> > executed parts of an if-converted loop. That now makes a difference
> > since we perform b
at change.
Richard.
> return dump_user_location_t ();
>
> - if (loops_state_satisfies_p (LOOPS_HAVE_RECORDED_EXITS))
> + if (loops_state_satisfies_p (LOOPS_HAVE_RECORDED_EXITS)
> + && loop->latch != EXIT_BLOCK_PTR_FOR_FN (cfun))
> {
>/* We only c
t; + vectorization since SELECT_VL is the GIMPLE IR that calculates the
> + number of elements to be process for each iteration.
> +
> + After loop vectorization analysis, Clear LOOP_VINFO_USING_SELECT_VL_P
> + if it is not partial vectorized loop. */
> + if (!LOOP_VINFO_USING_PARTIAL_VECTORS_P (loop_vinfo))
> +LOOP_VINFO_USING_SELECT_VL_P (loop_vinfo) = false;
> +
>return opt_result::success ();
> }
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
c tree
> +tree
> perm_mask_for_reverse (tree vectype)
> {
>poly_uint64 nunits = TYPE_VECTOR_SUBPARTS (vectype);
> diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
> index
> b9a71a0b5f5407417e8366b0df132df20c7f60aa..f261fc74b8795b4516b17155441d25baaf8c22ae
> 100644
On Wed, 15 Nov 2023, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Wednesday, November 15, 2023 1:01 PM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: RE: [PATCH 7/
On Wed, 15 Nov 2023, Tamar Christina wrote:
> Patch updated to latest trunk:
>
> Hi All,
>
> This changes the PHI node updates to support early breaks.
> It has to support both the case where the loop's exit matches the normal loop
> exit and one where the early exit is "inverted", i.e. it's an
901 - 1000 of 25078 matches
Mail list logo