the first live value. */
> - restart_loop = restart_loop || !main_exit_edge;
> - if (restart_loop
> + if ((all_exits_as_early_p || !main_exit_edge)
> && STMT_VINFO_DEF_TYPE (stmt_info) == vect_induction_def)
> {
> tmp_vec_lhs = vec_lhs0;
>
>
>
>
>
--
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 wipe range info before folding the
COND_EXPRs we insert as part of replacing PHI nodes when combining
blocks in the if-conversion pass.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113796
* tree-if-conv.cc
There has been some confusion in my understanding of how early breaks
work, the following clarifies some comments and undoes one change that
shouldn't have been necessary. It also fixes the dependence test
to avoit TBAA (we're moving stores down across loads).
I'm bootstrapping and testing this
32716283019655932542975wb -
> 1wb) / 2wb * 3wb; /* { dg-warning "integer overflow in expression of type
> '_BitInt\\\(161\\\)' results in" } */
> +_BitInt(160) q = (-730750818665451459101842416358141509827966271487wb - 1wb)
> / 2wb * 3wb;/* { dg-warning "integer overflow in expression of type
> '_BitInt\\\(160\\\)' results in" } */
> +_BitInt(159) r = (-365375409332725729550921208179070754913983135743wb - 1wb)
> / 2wb * 3wb;/* { dg-warning "integer overflow in expression of type
> '_BitInt\\\(159\\\)' results in" } */
> +_BitInt(129) s = (-340282366920938463463374607431768211455wb - 1wb) / 2wb *
> 3wb; /* { dg-warning "integer overflow in expression of type
> '_BitInt\\\(129\\\)' results in" } */
> +_BitInt(128) t = (-170141183460469231731687303715884105727wb - 1wb) / 2wb *
> 3wb; /* { dg-warning "integer overflow in expression of type
> '_BitInt\\\(128\\\)' results in" } */
>
> 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 Tue, 6 Feb 2024, Jakub Jelinek wrote:
> On Mon, Feb 05, 2024 at 03:31:20PM +0100, Richard Biener wrote:
> > On Mon, 5 Feb 2024, Tamar Christina wrote:
> > > > It looks like LOOP_VINFO_EARLY_BRK_STORES is "reverse"? Is that
> > > > why you are doing g
s[1] = "A";
> + return __builtin_strlen (s);
> +}
> +
> +/* { dg-output "ERROR: AddressSanitizer: stack-buffer-overflow on
> address.*(\n|\r\n|\r)" } */
> +/* { dg-output "READ of size.*" } */
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> +#define SEG __seg_fs
> +#else
> +#define SEG
> +#endif
> +
> +void
> +foo (__seg_gs struct T *p)
> +{
> + struct S s;
> + p->b[0] = s;
> +}
> +
> +void
> +bar (__seg_gs struct T *p, _BitInt(710) x, int y, double z)
> +{
> + p->b[0].a = x + 42
, wmult_code, mult_rhs1, mult_rhs2,
> add_rhs);
>update_stmt (gsi_stmt (*gsi));
> --- gcc/testsuite/gcc.c-torture/compile/pr113759.c.jj 2024-02-05
> 10:34:35.017036427 +0100
> +++ gcc/testsuite/gcc.c-torture/compile/pr113759.c2024-02-05
> 10:3
The following avoids accessing out-of-bound vector elements when
native encoding a boolean vector with sub-BITS_PER_UNIT precision
elements. The error was basing the number of elements to extract
on the rounded up total byte size involved and the patch bases
everything on the total number of
On Mon, 5 Feb 2024, Jeff Law wrote:
>
>
> On 2/5/24 01:15, Richard Biener wrote:
>
> >>>
> >>> PR rtl-optimization/113255
> >>> * simplify-rtx.cc (simplify_context::simplify_binary_operation_1):
> >>> Do not re-associate a MIN
695607d0fe9..9aba94bd6ca2061a19487ac4a2735a16d03bcbee
> 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -11800,8 +11800,7 @@ move_early_exit_stmts (loop_vec_info loop_vinfo)
> dump_printf_loc (MSG_NOTE, vect_location, "moving stmt %G",
c uint64_t vals[] = {4294967288ULL, 191ULL,4160749568ULL,
> 4294963263ULL,
> +127ULL,4294950912ULL, 255ULL,
> 4294901760ULL,
> +534781951ULL, 33546240ULL, 4294967292ULL,
> 4294960127ULL,
> +
"single predecessor which is currently not "
> + "supported for early break vectorization.\n",
> + dest_bb->index);
> +
>LOOP_VINFO_EARLY_BRK_DEST_BB (loop_vinfo) = dest_bb;
>
>i
aa36bb5d3c
> 100644
> --- a/gcc/tree-vect-loop.cc
> +++ b/gcc/tree-vect-loop.cc
> @@ -11801,7 +11801,8 @@ move_early_exit_stmts (loop_vec_info loop_vinfo)
>
>gimple_stmt_iterator stmt_gsi = gsi_for_stmt (stmt);
>gsi_move_before (_gsi, _gsi);
> - gsi_p
vals[] = {4294967288, 191,4160749568,
> 4294963263,
> + 127,4294950912, 255,
> 4294901760,
> + 534781951, 33546240, 4294967292,
> 4294960127,
> + 4292872191, 4294967295, 4294443007, 3};
> +
set_inlining_locations looks at a possible macro expansion location
when the location is in a system header but it fails to update its
counter when there's no macro involved. The following fixes that.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
This doesn't fix the observed diagnostic
The following makes sure to use the correct pointer mode when
building pointer types to a non-default address-space.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-data-refs.cc (vect_create_data_ref_ptr): Use
the default mode when building a pointer.
---
The following avoids different avail answers depending on how the
iteration progressed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113707
* tree-ssa-sccvn.cc (rpo_elim::eliminate_avail): After
checking the avail set treat
On Thu, 1 Feb 2024, Andre Vieira (lists) wrote:
>
>
> On 01/02/2024 07:19, Richard Biener wrote:
> > On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
> >
> >
> > The patch didn't come with a testcase so it's really hard to tell
> > what goes wrong now
__BITINT_MAXWIDTH__ >= 129
> +_BitInt(129) a;
> +#else
> +_BitInt(63) a;
> +#endif
> +
> +int b[1], c;
> +
> +int
> +foo (void)
> +{
> + switch (a)
> + case 0:
> + case 2:
> +return 1;
> + return 0;
> +}
> +
> +void
> +bar (int i)
On Fri, 2 Feb 2024, Jeff Law wrote:
>
>
> On 2/1/24 07:20, Richard Biener wrote:
> > The following avoids re-associating
> >
> > (minus:DI (reg/f:DI 119)
> > (minus:DI (reg/f:DI 120)
> > (reg/f:DI 114)))
> >
> &g
> Am 03.02.2024 um 09:46 schrieb Jakub Jelinek :
>
> Hi!
>
> Since bswap has been converted from a method to a function we miscompile
> the following testcase. The problem is the assumption that the passed in
> len argument (number of limbs in the xval array) is the upper bound for the
>
> Am 03.02.2024 um 09:36 schrieb Jakub Jelinek :
>
> Hi!
>
> We are getting a gnuradio PCH ICE
> /usr/include/pybind11/stl.h:447:1: internal compiler error: in gt_pch_save,
> at ggc-common.cc:693
> 0x1304e7d gt_pch_save(_IO_FILE*)
>../../gcc/ggc-common.cc:693
> 0x12a45fb
> Am 01.02.2024 um 22:34 schrieb Tamar Christina :
>
>
>>
>>>
>>> If the above is correct then I think I understand what you're saying and
>>> will update the patch and do some Checks.
>>
>> Yes, I think that's what I wanted to say.
>>
>
> As discussed:
>
> Bootstrapped Regtested on
> Am 02.02.2024 um 10:41 schrieb Jakub Jelinek :
>
> Hi!
>
> Similar problem to calls with uninitialized large/huge _BitInt SSA_NAME
> arguments, var_to_partition will not work for those, but unlike calls
> where we just create a new uninitialized SSA_NAME here we need to change
> the inline
> Am 02.02.2024 um 10:53 schrieb Jakub Jelinek :
>
> Hi!
>
> I thought one needs to cast first to pointer-sized integer before casting to
> pointer, but apparently that is not the case.
> So the following patch arranges for the large/huge _BitInt to
> pointer/reference conversions to use the
> Am 01.02.2024 um 23:46 schrieb Jakub Jelinek :
>
> On Tue, Jan 30, 2024 at 07:33:10AM -, Roger Sayle wrote:
> + wide_int bits = wide_int::from (tree_nonzero_bits (rhs),
>
>
On Thu, 1 Feb 2024, Thomas Schwinge wrote:
> Hi!
>
> On 2024-01-26T10:45:10+0100, Richard Biener wrote:
> > On Fri, 26 Jan 2024, Richard Biener wrote:
> >> On Wed, 24 Jan 2024, Andrew Stubbs wrote:
> >> > [...] is enough to get gfx1100 working for most
The following avoids re-associating
(minus:DI (reg/f:DI 119)
(minus:DI (reg/f:DI 120)
(reg/f:DI 114)))
into
(minus:DI (plus:DI (reg/f:DI 114)
(reg/f:DI 119))
(reg/f:DI 120))
as that possibly confuses the REG_POINTER heuristics of RTL
alias analysis. This happens to
The following avoids re-using a register holding a pointer (and
thus might be REG_POINTER) for the result of a pointer difference
computation. That might confuse heuristics in (broken) RTL alias
analysis which relies on REG_POINTER indicating that we're
dealing with one.
This alone doesn't fix
The following fixes LC SSA preserving with region VN which was broken
when availability checking was enhanced to treat not visited value
numbers as available. The following makes sure to honor availability
data we put in place for LC SSA preserving instead.
Bootstrapped and tested on
On Thu, Feb 1, 2024 at 9:23 AM Jakub Jelinek wrote:
>
> On Wed, Jan 31, 2024 at 01:04:20PM +0100, Jakub Jelinek wrote:
> > On Sun, Jan 28, 2024 at 11:02:33AM +, Iain Sandoe wrote:
> > > * config/aarch64/heap-trampoline.c: Rename
> > > __builtin_nested_func_ptr_created to
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
>
>
> On 31/01/2024 14:35, Richard Biener wrote:
> > On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
> >
> >>
> >>
> >> On 31/01/2024 13:58, Richard Biener wrote:
>
> Am 31.01.2024 um 16:20 schrieb Jakub Jelinek :
>
> On Wed, Jan 31, 2024 at 01:04:22PM +0100, Richard Biener wrote:
>>> Like this, so far just tested on the testcase. Ok for trunk if it passes
>>> bootstrap/regtest on top of Jason's patch?
>>
>> Note
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
>
>
> On 31/01/2024 13:58, Richard Biener wrote:
> > On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
> >
> >>
> >>
> >> On 31/01/2024 12:13, Richard Biener wrote:
> >>> On Wed, 31 Jan
The following fixes a wrong pattern that didn't match the behavior
of the original fold_widened_comparison in that get_unwidened
returned a constant always in the wider type. But here we're
using (int) 4294967295u without the conversion applied. Fixed
by doing as earlier in the pattern -
On Wed, 31 Jan 2024, Richard Biener wrote:
> On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
>
> >
> >
> > On 31/01/2024 12:13, Richard Biener wrote:
> > > On Wed, 31 Jan 2024, Richard Biener wrote:
> > >
> > >> On Tue, 30 Jan 2024, Andr
On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:
>
>
> On 31/01/2024 12:13, Richard Biener wrote:
> > On Wed, 31 Jan 2024, Richard Biener wrote:
> >
> >> On Tue, 30 Jan 2024, Andre Vieira wrote:
> >>
> >>>
> >>> This pa
On Wed, Jan 31, 2024 at 2:53 PM Jason Merrill wrote:
>
> On 1/31/24 03:40, Richard Biener wrote:
> > On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
> >>
> >> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >>
> >> -- >8 -
On Wed, Jan 31, 2024 at 2:39 PM Jonathan Yong <10wa...@gmail.com> wrote:
>
> Ensure sp variable is long enough by using __UINTPTR_TYPE__ for
> rsp.
>
> Attached patch okay? Changes unsigned long to __UINTPTR_TYPE__.
OK.
The following avoids inserting expressions for IPA CP discovered
equivalences into the VN hashtables when we are optimistically
skipping may-defs in the attempt to prove it's redundant.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/111444
*
On Tue, 30 Jan 2024, Andre Vieira wrote:
>
> The current codegen code to support VF's that are multiples of a simdclone
> simdlen rely on BIT_FIELD_REF to create multiple input vectors. This does not
> work for non-constant simdclones, so we should disable using such clones when
> the VF is a
On Wed, 31 Jan 2024, Richard Biener wrote:
> On Tue, 30 Jan 2024, Andre Vieira wrote:
>
> >
> > This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the
> > target can reject a simd_clone based on the vector mode it is using.
> > This
dvanced SIMD
> modes.
> * config/gcn/gcn.cc (gcn_simd_clone_usable): Add unused argument.
> * config/i386/i386.cc (ix86_simd_clone_usable): Likewise.
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
On Wed, Jan 31, 2024 at 12:50 PM Robin Dapp wrote:
>
> Hi,
>
> in PR113607 we see an invalid fold of
>
> _429 = .COND_SHL (mask_patt_205.47_276, vect_cst__262, vect_cst__262, { 0,
> ... });
> vect_prephitmp_129.51_282 = _429;
> vect_iftmp.55_287 = VEC_COND_EXPR vect_prephitmp_129.51_282,
On Wed, Jan 31, 2024 at 12:18 PM Jakub Jelinek wrote:
>
> On Wed, Jan 31, 2024 at 10:07:28AM +0100, Jakub Jelinek wrote:
> > Indeed. But what we could do is try to fold_stmt those .ASAN_MARK calls
> > away earlier (but sure, the asan.cc change would be still required because
> > that would be
The following avoids code hoisting (but also PRE insertion) of
expressions that got value-numbered to another one that are not
a valid replacement (but still compute the same value). This time
because the access path ends in a structure with different size,
meaning we consider a related access as
The following makes sure we're not taking the address of hard
registers when vectorizing appearant gathers or scatters to/from
them.
Bootstrapped and tested on x86_64-unkown-linux-gnu, pushed.
PR tree-optimization/113670
* tree-vect-data-refs.cc (vect_check_gather_scatter):
gt; +++ gcc/testsuite/gcc.target/i386/pr113656.c 2024-01-30 19:37:10.519703443
> +0100
> @@ -0,0 +1,12 @@
> +/* PR rtl-optimization/113656 */
> +/* { dg-do compile } */
> +/* { dg-options "-O3 -frounding-math -funsafe-math-optimizations
> -mavx512fp16 -mavx512vl" }
; +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-g -std=c23" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 639
> +typedef _BitInt(639) B;
> +#else
> +typedef _BitInt(63) B;
> +#endif
> +
> +void
> +foo (B n)
> +{
> + extern void bar (int
int } } */
> +/* { dg-options "-O2 -std=c23" } */
> +
> +int j, k;
> +#if __BITINT_MAXWIDTH__ >= 162
> +struct S { _BitInt(162) n; };
> +void bar (_BitInt(162) x);
> +
> +void
> +foo (struct S s)
> +{
> + bar (s.n * j);
> + (void) (s.n * k);
> +}
On Wed, Jan 31, 2024 at 4:46 AM Vladimir Mezentsev
wrote:
>
> Hi,
>
> I asked in https://sourceware.org/bugzilla/show_bug.cgi?id=31109
> > I prepared a patch for the releases/gcc-13 branch.
> > Richard Biener rejected my patch for
> this branch.
> > Which b
On Wed, Jan 31, 2024 at 4:38 AM Jason Merrill wrote:
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
It's a quite "late" fixup, I suppose you have tried to avoid marking it
during gimplification? I see we do parts of this during BIND_EXPR
processing which is indeed a bit early but possibly
On Wed, Jan 31, 2024 at 12:19 AM Marek Polacek wrote:
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> We plan to deprecate -fconcepts-ts in GCC 15 and remove the flag_concepts_ts
> code. This note is an admonishing reminder to convert the Concepts TS
> code to
On Tue, 30 Jan 2024, Tamar Christina wrote:
> > -Original Message-
> > From: Richard Biener
> > Sent: Tuesday, January 30, 2024 9:51 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: Re: [PAT
The following handles the case of the main exit going to a path without
virtual use and handles it similar to the alternate exit handling.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113659
* tree-vect-loop-manip.cc
On Tue, Jan 30, 2024 at 11:40 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Jan 29, 2024 at 5:00 PM Richard Sandiford
> > wrote:
> >>
> >> Tamar Christina writes:
> >> > Hi All,
> >> >
> >>
On Tue, Jan 30, 2024 at 8:33 AM Roger Sayle wrote:
>
>
> This patch resolves PR113560, a code quality regression from GCC12
> affecting x86_64, by enhancing the middle-end's tree-ssa-math-opts.cc
> to recognize more instances of widening multiplications.
>
> The widening multiplication perception
t control flow statement in the
> latch. Most
> + commonly this is a switch. */
> + if (!last_cond)
> + return opt_result::failure_at (last_stmt,
> + "can't safely apply code motion to dependencies"
> + " to vectorize the early exit, unknown control fow"
> + " in stmt %G", last_stmt);
> + workset.safe_push (gimple_cond_lhs (last_cond));
> + workset.safe_push (gimple_cond_rhs (last_cond));
> +
> + imm_use_iterator imm_iter;
> + use_operand_p use_p;
> + tree lhs;
> + do
> +{
> + tree op = workset.pop ();
> + if (visited.add (op))
> + continue;
> + stmt_vec_info stmt_vinfo = loop_vinfo->lookup_def (op);
> +
> + /* Not defined in loop, don't care. */
> + if (!stmt_vinfo)
> + continue;
> + gimple *stmt = STMT_VINFO_STMT (stmt_vinfo);
> + auto dr_ref = STMT_VINFO_DATA_REF (stmt_vinfo);
> + if (dr_ref)
> + {
> + opt_result res
> + = vect_analyze_early_break_dependences_1 (dr_ref, stmt);
> + if (!res)
> + return res;
> + }
> + else
> + FOR_EACH_IMM_USE_FAST (use_p, imm_iter, op)
> + if ((lhs = gimple_get_lhs (USE_STMT (use_p
> + workset.safe_push (lhs);
> +}
> + while (!workset.is_empty ());
> +
>/* We don't allow outer -> inner loop transitions which should have been
> trapped already during loop form analysis. */
>gcc_assert (dest_bb->loop_father == loop);
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
+int *c;
> +signed char *d;
> +short f;
> +signed char g[3];
> +
> +int *
> +foo (void)
> +{
> + for (int i = 0; i < 3; i++)
> +g[i] = 2;
> + int j[100][100] = { {}, {4} };
> + signed char *k = [1];
> + do
> +{
> + for (;;)
> + {
> + i
2024-01-29 09:48:15.969510457
> +0100
> +++ gcc/testsuite/gcc.dg/pr101195.c 2024-01-29 09:48:08.626614220 +0100
> @@ -0,0 +1,8 @@
> +/* PR middle-end/101195 */
> +/* { dg-do compile } */
> +
> +int
> +foo (void)
> +{
> + return __builtin_eh_return_data_regno (-42);
&g
On Tue, Jan 30, 2024 at 4:35 AM Alexandre Oliva wrote:
>
> On Jan 19, 2024, Alexandre Oliva wrote:
>
> > On Jan 18, 2024, "Kewen.Lin" wrote:
> >> Not sure if I missed something in the testing, could you
> >> kindly double check if those test cases started to fail from r14-6275 on
> >> your
>
On Mon, Jan 29, 2024 at 5:00 PM Richard Sandiford
wrote:
>
> Tamar Christina writes:
> > Hi All,
> >
> > Recently something in the midend had started inverting the branches by
> > inverting
> > the condition and the branches.
> >
> > While this is fine, it makes it hard to actually test. In
> Am 30.01.2024 um 03:31 schrieb Alexandre Oliva :
>
>
> Variant type copies can't have their own alias sets any more, and it's
> not like setting them affected the pointed-to objects anyway.
>
> Regstrapped on x86_64-linux-gnu; also bootstrapped with -fstrub=internal
> enabled by default.
The following implements storing to a non-MEM_P with a variable
offset. We usually avoid this by forcing expansion to memory but
this doesn't work for hard register variables. The solution is
to spill and operate on the stack.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
I realize
On Mon, 29 Jan 2024, Jakub Jelinek wrote:
> On Mon, Jan 29, 2024 at 11:24:58AM +0100, Richard Biener wrote:
> > The following expands .VEC_SET and .VEC_EXTRACT instruction selection
> > to global hard registers, not only automatic variables (possibly)
> > promoted to regis
The following expands .VEC_SET and .VEC_EXTRACT instruction selection
to global hard registers, not only automatic variables (possibly)
promoted to registers. This can avoid some ICEs later and create
better code.
Bootstrapped and tested on x86_64-unknown-linux-gnu.
OK?
Thanks,
Richard.
On Sat, Jan 27, 2024 at 4:44 PM Richard Sandiford
wrote:
>
> This was another PR caused by the way that
> vect_determine_precisions_from_range handle shifts. We tried to
> narrow 32768 >> x to a 16-bit shift based on range information for
> the inputs and outputs, with
04558479 +0100
> @@ -0,0 +1,16 @@
> +/* PR tree-optimization/110603 */
> +
> +typedef __SIZE_TYPE__ size_t;
> +void *memcpy (void *, const void *, size_t);
> +int snprintf (char *restrict, size_t, const char *restrict, ...);
> +extern char a[2];
> +void bar (void);
> +
> +void
> +foo (void)
> +{
> + memcpy (a, "12", sizeof (a));
> + int b = snprintf (0, 0, "%s", a);
> + if (b <= 3)
> +bar ();
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
> Am 27.01.2024 um 09:16 schrieb Jakub Jelinek :
>
> Hi!
>
> We generally allow merging mergeable stmts with some final cast (but not
> further casts or mergeable operations after the cast). As some casts
> are handled conditionally, if (idx < cst) handle_operand (idx); else if
> idx ==
> Am 27.01.2024 um 09:15 schrieb Jakub Jelinek :
>
> Hi!
>
> While the SSA coalescing performed by lower bitint prints some information
> if -fdump-tree-bitintlower-details, it is really hard to read and doesn't
> contain the most important information which one looks for when debugging
>
> Am 27.01.2024 um 09:18 schrieb Jakub Jelinek :
>
> Hi!
>
> The following testcase is miscompiled, because some narrower value
> is sign-extended to wider unsigned _BitInt used as division operand.
> handle_operand_addr for that case returns the narrower value and
> precision
> Am 26.01.2024 um 17:22 schrieb Thomas Schwinge :
>
> Hi!
>
> Great progress that you've made! :-)
>
>> On 2024-01-26T13:32:02+0100, Tobias Burnus wrote:
>> Tobias Burnus wrote:
>>> Am 24.01.24 um 17:01 schrieb Tobias Burnus:
Okay to enable gfx1100 multilib building and to document
On Fri, 26 Jan 2024, Jakub Jelinek wrote:
> On Fri, Jan 26, 2024 at 03:04:11PM +0100, Richard Biener wrote:
> > > > Otherwise it looks reasoanble to me, but let's see what Andrew thinks.
> > >
> > > 'n' before 'a', please. ;-)
> >
> > ?!
>
>
The inliner puts variables for parameters of the inlined functions
in the inline scope in reverse order. The following reverses them
again so that we get consistent ordering between the
DW_TAG_subprogram DW_TAG_formal_parameter and the
DW_TAG_inlined_subroutine DW_TAG_formal_parameter set.
I
On Fri, 26 Jan 2024, Andrew Stubbs wrote:
> On 26/01/2024 12:06, Jakub Jelinek wrote:
> > On Fri, Jan 26, 2024 at 01:00:28PM +0100, Richard Biener wrote:
> >> The following avoids registering unsupported GCN offload devices
> >> when iterating over available one
On Fri, 26 Jan 2024, Tobias Burnus wrote:
> Now with patch ...
>
> Tobias Burnus wrote:
> > Hi all, hi Richard & Andrew,
> >
> > Am 24.01.24 um 17:01 schrieb Tobias Burnus:
> >> This patch obviously depends on Andrew's; he wrote in the previous email of
> >> this thread regarding his patch:
> >>
On Fri, 26 Jan 2024, Tobias Burnus wrote:
> Jakub Jelinek wrote:
> > On Fri, Jan 26, 2024 at 01:00:28PM +0100, Richard Biener wrote:
> >> libgomp/
> >> * plugin/plugin-gcn.c (suitable_hsa_agent_p): Filter out
> >> agents with unsupported
On Fri, Jan 26, 2024 at 9:17 AM Robin Dapp wrote:
>
> Hi,
>
> init_all_optabs initializes > 1 patterns for riscv targets. This
> leads to pathological situations in dataflow analysis (which can occur
> with many adjacent stores).
> To alleviate this this patch makes genopinit split the
The following avoids registering unsupported GCN offload devices
when iterating over available ones. With a Zen4 desktop CPU
you will have an IGPU (unspported) which will otherwise be made
available. This causes testcases like
libgomp.c-c++-common/non-rect-loop-1.c which iterate over all
decives
The following makes the existing architecture support check work
instead of being optimized away (enum vs. -1). This avoids
later asserts when we assume such devices are never actually
used.
Tested as previously, now the error is
libgomp: GCN fatal error: Unknown GCN agent architecture
Runtime
The following avoids selecting an unsupported agent early, avoiding
later asserts when we rely on it being supported.
tested on x86_64-unknown-linux-gnu -> amdhsa-gcn on gfx1060
that's the alternative to the other patch. I do indeed seem to get
the other (unsupported) agent selected somehow
When the agent reports a device ISA we don't support avoid hitting
an assert, instead report the raw integers as error. I'm not sure
whether -1 is special as I didn't figure where that field is
initialized. But I guess since agents are not rejected upfront
when registering them I might be able
On Fri, 26 Jan 2024, Andrew Stubbs wrote:
> On 26/01/2024 09:45, Richard Biener wrote:
> > On Fri, 26 Jan 2024, Richard Biener wrote:
> >
> > === libgomp Summary ===
> >
> > # of expected passes29126
> > # of unexpected
We can end up creating ADDR_EXPRs of non-addressable entities during
for example vectorization. The following plugs this in data-ref
analysis when that would create such invalid ADDR_EXPR as part of
analyzing the ref structure.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
On Fri, 26 Jan 2024, Richard Biener wrote:
> On Wed, 24 Jan 2024, Andrew Stubbs wrote:
>
> > This is enough to get gfx1100 working for most purposes, on top of the
> > patch that Tobias committed a week or so ago; there are still some test
> > failures to investigate,
/gcn/amdgcn_veclib.h
> @@ -230,7 +230,7 @@ do { \
>
> #if defined (__GCN3__) || defined (__GCN5__) \
> || defined (__CDNA1__) || defined (__CDNA2__) \
> -|| defined (__RDNA2__)
> +|| defined (__RDNA2__) || defined (__RDNA3__)
> #define CDNA3_PLUS 0
> #else
>
On Fri, Jan 26, 2024 at 7:23 AM chenxiaolong wrote:
>
> gcc/testsuite/ChangeLog:
OK
> * gcc.dg/signbit-2.c: Added additional "-mlsx" compilation options.
> * gfortran.dg/graphite/vect-pr40979.f90: Dito.
> * gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
> ---
>
On Fri, Jan 26, 2024 at 6:01 AM Andrew Pinski wrote:
>
> The 2 loops in octfapg_universe can and will be vectorized now
> after r14-333-g6d4b59a9356ac4 on targets that support multiplication
> in the long type. But the testcase does not check vect_long_mult for
> that, so this patch corrects that
On Fri, Jan 26, 2024 at 12:04 AM Tobias Burnus wrote:
>
> When targeting AMD GPUs, the LLVM assembler (and linker) are used.
>
> Two days ago LLVM changed the default for the AMDHSA code object
> version (COV) from 4 to 5.
>
> In principle, we do not care which COV is used as long as it works;
>
On Wed, Jan 24, 2024 at 4:50 PM Georg-Johann Lay wrote:
>
>
>
> Am 22.01.24 um 08:45 schrieb Richard Biener:
> > On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
> >>
> >>
> >>
> >> Am 18.01.24 um 20:54 schrieb Roger Sayle:
> >&
dg-skip-if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
> +
> +unsigned _BitInt(1) a;
> +unsigned _BitInt(8) b;
> +
> +void
> +f
On Thu, Jan 25, 2024 at 1:46 AM Andrew Pinski wrote:
>
> This fixes of the vect testcases which uses the gimple FE for LLP64 targets.
> The testcases use directly `unsigned long` for the addition to pointers
> when they should be using `__SIZETYPE__`. This changes to use that instead.
OK
>
We can't support niters with may_be_zero when we end up with a
non-empty latch due to early exit peeling. At least not in
the simplistic way the vectorizer handles this now. Disallow
it again for exits that are not the last one.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
> Am 23.01.2024 um 17:04 schrieb Tamar Christina :
>
> Hi All,
>
> This renamed main_exit_p to last_val_reduc_p to more accurately
> reflect what the value is calculating.
>
> Ok for master if bootstrap passes? Incremental build shows it's fine.
Ok
> Thanks,
> Tamar
>
> gcc/ChangeLog:
>
remember as
> def for the reduction PHI generation. */
>bool double_reduc = false;
> - bool main_exit_p = LOOP_VINFO_IV_EXIT (loop_vinfo) == loop_exit;
> + bool main_exit_p = LOOP_VINFO_IV_EXIT (loop_vinfo) == loop_exit
> + && !LOOP_VINFO_EARLY_BREAKS_V
On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> On Tue, Jan 23, 2024 at 01:03:46PM +0100, Richard Biener wrote:
> > On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> >
> > > On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> > > > The following avoids us
On Tue, 23 Jan 2024, Jakub Jelinek wrote:
> On Tue, Jan 23, 2024 at 12:56:52PM +0100, Richard Biener wrote:
> > The following avoids using exact_log2 on the number of SIMD clone calls
> > to be emitted when vectorizing calls since that can easily be not
> > a power
The following avoids using exact_log2 on the number of SIMD clone calls
to be emitted when vectorizing calls since that can easily be not
a power of two in which case it will return -1. For different simd
clones the number of calls will differ by a multiply with a power of two
only so using
While the bug is persisting that LTO streaming picks up a CONST_DECL
from an attribute argument on a VAR_DECL which with -fdebug-type-section
refers to a DIE in a type unit we can handle this gracefully, at least
with -fno-checking. Do so. The C++ frontend nevetheless should resolve
the
401 - 500 of 25078 matches
Mail list logo
