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
On Mon, Jan 22, 2024 at 3:27 PM Hans-Peter Nilsson wrote:
>
> > From: Richard Biener
> > Date: Mon, 22 Jan 2024 08:33:47 +0100
>
> > > - "% function might not be inlinable");
> > > + "% function is not alwa
On Mon, 22 Jan 2024, Jeff Law wrote:
>
>
> On 1/15/24 06:34, Richard Biener wrote:
> > When the x86 backend generates code for cpymem with the rep_8byte
> > strathegy for the 8 byte aligned main rep movq it needs to compute
> > an adjusted pointer to the source afte
When mixing -flto, -ffat-lto-objects and -fdebug-type-section we
fail to reset all type units after early output resulting in an
ICE when attempting to add then duplicate sibling attributes.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
PR debug/112718
*
On Mon, Jan 22, 2024 at 2:24 PM Richard Sandiford
wrote:
>
> Ping for the expr/cfgexpand bits
>
> Richard Sandiford writes:
> > Andrew Pinski writes:
> >> Ccmp is not used if the result of the and/ior is used by both
> >> a GIMPLE_COND and a GIMPLE_ASSIGN. This improves the code generation
> >>
On Mon, 22 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Jan 22, 2024 at 11:56:11AM +0100, Richard Biener wrote:
> > > I guess the || total_bytes * BITS_PER_UNIT > HOST_BITS_PER_DOUBLE_INT
> > > conditions make no sense, all we care is
On Mon, 22 Jan 2024, Jakub Jelinek wrote:
> On Mon, Jan 22, 2024 at 11:27:52AM +0100, Richard Biener wrote:
> > We run into
> >
> > static tree
> > native_interpret_int (tree type, const unsigned char *ptr, int len)
> > {
> > ...
> > i
This refactors the handling of PHIs inbetween the main and the
epilogue loop. Instead of trying to handle the multiple exit
and original single exit case together the following separates
these cases resulting in much easier to understand code.
Bootstrap and regtest running on
On Fri, Jan 19, 2024 at 5:06 PM Georg-Johann Lay wrote:
>
>
>
> Am 18.01.24 um 20:54 schrieb Roger Sayle:
> >
> > This patch tweaks RTL expansion of multi-word shifts and rotates to use
> > PLUS rather than IOR for disjunctive operations. During expansion of
> > these operations, the middle-end
On Fri, Jan 19, 2024 at 9:08 PM Tobias Burnus wrote:
>
> This patch fixes PR111966, i.e. when compiling offloaded code with "-g"
> but without "-march=", mkoffload created a file with e_flags set to
> gfx803/fiji as architecture - while all other files used gfx900, which
> the linker did not
On Fri, Jan 19, 2024 at 5:26 PM Qing Zhao wrote:
>
>
>
> > On Jan 19, 2024, at 4:30 AM, Richard Biener
> > wrote:
> >
> > On Thu, Jan 18, 2024 at 3:46 PM Qing Zhao wrote:
> >>
> >>
> >>
> >>> On Jan 17, 2024, at 1:43 AM, R
On Sun, Jan 21, 2024 at 2:33 PM Hans-Peter Nilsson wrote:
>
> Tested x86_64-linux-gnu. Ok to commit?
>
> Or, does the message need more tweaking?
> (If so, suggestions from native speakers?)
> FWIW, I found no PR for just the message being bad.
>
> -- >8 --
> When you're not regularly exposed to
> Am 20.01.2024 um 10:39 schrieb Jakub Jelinek :
>
> Hi!
>
> The following patch ICEs because fre3 leaves around unfolded
> _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);
Hmm, const_unop should handle this, I suppose either we fail to convert this to
a NOP_EXPR or native encode/interpret do not
> Am 20.01.2024 um 10:36 schrieb Jakub Jelinek :
>
> Hi!
>
> The following patch fixes various issues with large/huge _BitInt used as
> switch
> expressions.
> In particular:
> 1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than
> sizetype precision, varasm uses
The following makes reduction epilogue code generation happy by properly
adding LC PHIs to the exit blocks for multiple exit vectorized loops.
Some refactoring might make the flow easier to follow but I've refrained
from doing that with this patch.
I've kept some fixes in reduction epilogue
Hypothetically, recognizing (x<<4)+(x>>60) as a rotation at the
> tree-level might lead to a code quality regression, if RTL
> expansion doesn't know to lower it back to use PLUS on
> those targets with lea but without rotate.
>
> > From: Richard Biener
> > Sent:
On Thu, Jan 18, 2024 at 8:55 PM Roger Sayle wrote:
>
>
> This patch tweaks RTL expansion of multi-word shifts and rotates to use
> PLUS rather than IOR for disjunctive operations. During expansion of
> these operations, the middle-end creates RTL like (X<>C2)
> where the constants C1 and C2
The new sanity check avoiding creating of DIE refs to self triggers
on the PRs testcase when using -g1 and -ffat-lto-objects as while
early DWARF with -g1 doesn't contain any DIEs for LABEL_DECLs later
cloning will still mark DECLs as in if they would via
dwarf2out_abstract_function calling
The following handles the situation where we lack a loop-closed
PHI for a virtual operand because a loop exit goes to a code
region not having any virtual use (an endless loop). It also
handles the situation of edge redirection re-allocating a PHI node
in the destination block so we have to
On Thu, Jan 18, 2024 at 3:46 PM Qing Zhao wrote:
>
>
>
> > On Jan 17, 2024, at 1:43 AM, Richard Biener
> > wrote:
> >
> > On Wed, Jan 17, 2024 at 7:42 AM Richard Biener
> > wrote:
> >>
> >> On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao wr
ompile { target bitint65535 } } */
> +/* { dg-options "-O2 -w -std=gnu23" } */
> +
> +_BitInt(65532) i;
> +
> +void
> +foo (void)
> +{
> + __asm__ ("" : "+r" (i)); /* { dg-error "impossible constraint" } */
> +}
>
>
2:29:07.586634031
> +0100
> +++ gcc/testsuite/gcc.dg/bitint-73.c 2024-01-18 12:28:42.406986342 +0100
> @@ -0,0 +1,18 @@
> +/* PR tree-optimization/113459 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-std=c23 -O2" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 129
>
dg-options "-std=c23 -O2" } */
> +
> +extern char *a, *b;
> +#if __BITINT_MAXWIDTH__ >= 129
> +_BitInt(129) o;
> +#else
> +_BitInt(63) o;
> +#endif
> +
> +void
> +foo (void)
> +{
> + __builtin_memcpy (a + o, b, 4);
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
Similar to the last one.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-stmts.cc (vectorizable_store): Do not pre-allocate
operands vector.
---
gcc/tree-vect-stmts.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
,
Richard.
> 2024-01-18 Jakub Jelinek
> Richard Biener
>
> * cfgexpand.cc (discover_nonconstant_array_refs_r): Force non-BLKmode
> VAR_DECLs referenced in BLKmode VIEW_CONVERT_EXPRs into memory.
> * expr.cc (expand_expr_real_1) : Do nothing
>
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 18, 2024 at 01:34:53PM +0100, Richard Biener wrote:
> > So - if we simply do
> >
> > /* If the input and output modes are both the same, we are done. */
> > if (mode == GET_MODE (op0) || (mo
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 18, 2024 at 01:16:45PM +0100, Richard Biener wrote:
> > > This doesn't actually do anything, because the base is TREE_ADDRESSABLE.
> > > The var gets both with -O0 and -O2 DECL_RTL like
> > > (mem/c:OI
phi_analyzer leaks all phi_group objects it allocates. The following
fixes this by maintaining a vector of allocated objects and release
them when destroying the phi_analyzer object.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
PR tree-optimization/113475
*
On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> On Thu, Jan 18, 2024 at 08:27:51AM +0100, Richard Biener wrote:
> > On Thu, 18 Jan 2024, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > On aarch64 the backend decides to use non-BLKmode for some arrays
> &g
The following fixes a memory leak in vectorizable_store which happens
because the functions populating gvec_oprnds[i] will call .create ()
on the incoming vector, leaking what we've previously allocated.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
* tree-vect-stmts.cc
The following fixes a memory leak in vect_analyze_loop_form which fails
to free the loop body it gets. It also allows more countable exits,
matching what we can handle later, when we decide which exit to use
as main exit. Finally some no longer applying comments are adjusted.
Bootstrap and
6 100644
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -1939,11 +1939,16 @@ assemble_start_function (tree decl, const char
> *fnname)
>
>/* Tell assembler to move to target machine's alignment for functions. */
>align = floor_log2 (align / BITS_PER_UNIT);
> +
sum += A[i + offset];
> +
> + return sum;
> +}
> +
> +/* Loop can be vectorized by referring "i + offset" is nonwrapping from
> array. */
> +/* { dg-final { scan-tree-dump "vectorized 1 loops" "vect" { target { ! {
> avr-*-* msp430-*-* pru-*-* } } } } } */
>
> 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 Thu, 18 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> From what I can see, this test has been written for a backend fix and
> assumes the loop isn't vectorized (at least, it wasn't when the test was
> added, it contains an early exit), but that is no longer true and because
> of the vectorization
egisters) Optimiz
> Perform a register copy-propagation optimization pass.
>
> ffold-mem-offsets
> -Target Bool Var(flag_fold_mem_offsets) Init(1)
> +Common Var(flag_fold_mem_offsets) Init(1) Optimization
> Fold instructions calculating memory offsets to the memory access
>
The following fixes wrong virtual operands being used for peeled
early breaks where we can have different live ones and for multiple
exits it makes sure to update the correct PHI arguments.
I've introduced SET_PHI_ARG_DEF_ON_EDGE so we can avoid using
a wrong edge to compute the PHI arg index
The vectorizer dependence analysis is confused with invariant loads
when figuring whether the circumstances are so that we preserve
scalar stmt execution order. The following rectifies this.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113431
int");
> mark_addressable (large_huge.m_vars[p]);
> + /* If BITINT_TYPE is BLKmode, make sure the underlying
> + variable is BLKmode as well. */
> + if (TYPE_MODE (TREE_TYPE (s)) == BLKmode
> + && DECL_MODE (large_huge.m_vars[p])
can do this in one vector. */
> /* { dg-final { scan-tree-dump-times "optimized: basic block" 1 "slp2" {
> target amdgcn-*-* } } } */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On Thu, Jan 18, 2024 at 1:58 AM Gaius Mulley wrote:
>
>
> ok for master ?
>
> Bootstrapped on power8 (cfarm135), power9 (cfarm120) and
> x86_64-linux-gnu.
OK.
I wonder what this does to the libm2 ABI?
> ---
>
> This patch corrects commit
> r14-4149-g81d5ca0b9b8431f1bd7a5ec8a2c94f04bb0cf032
ret |= build_access_from_expr (t, asm_stmt, false);
> + }
> + for (i = 0; i < gimple_asm_noutputs (asm_stmt); i++)
> + {
> + t = TREE_VALUE (gimple_asm_output_op (asm_stmt, i));
> + ret |= build_access_from_expr (t, asm_stmt, true);
> + }
> }
> }
> break;
>
--
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, Jan 17, 2024 at 8:39 AM Maxim Kuvyrkov
wrote:
>
> > On Jan 17, 2024, at 10:51, Richard Biener
> > wrote:
> >
> > On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
> >>
> >>
> >>
> >> On 1/15/24 05:56, Maxim Kuvyrk
; > Honza
> > > >
> > > > Richard.
> > > >
> > > > > +}
> > > > > +
> > > > >/* Handle a user-specified function alignment.
> > > > > Note that we still need to align to DECL_ALIGN, as above,
> > > &
if "" { ! run_expensive_tests } { "*" } { "-O0" "-O2" } } */
> +/* { dg-skip-if "" { ! run_expensive_tests } { "-flto" } { "" } } */
> +
> +#if __BITINT_MAXWIDTH__ >= 1024
> +unsigned _BitInt(1024) a = -5wb;
ment?
>
> Well, I do not see much use of the max-skip feature, but it seemed to me
> that perhaps it is better to keep the command line options symmetric.
>
> Actually my first iteration of the patch supported only one value, but
> then I kind of convinced myself that symmetricity is better.
8120
> +0100
> +++ gcc/testsuite/gcc.dg/bitint-72.c 2024-01-16 19:31:06.000328741 +0100
> @@ -0,0 +1,16 @@
> +/* PR middle-end/113410 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-std=c23" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 905
>
scan-tree-dump-times " & " 4 "optimized" } } */
> -/* { dg-final { scan-tree-dump-not "if " "optimized" } } */
> +/* { dg-final { scan-tree-dump-times " \\\*" 4 "optimized" { xfail {
> "aarch64*-*-* alpha*-*-* bfin*-*-* ep
nt } } */
> +/* { dg-options "-std=c23 -O2" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 713
> +struct A { _BitInt(713) b; } g;
> +#else
> +struct A { _BitInt(49) b; } g;
> +#endif
> +int f;
> +
> +void
> +foo (void)
> +{
> + struct A j = g;
> + if (j.b)
&g
/
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-std=c23 -fstrub=internal" } */
> +/* { dg-require-effective-target strub } */
> +
> +#if __BITINT_MAXWIDTH__ >= 146
> +_BitInt(146)
> +#else
> +_BitInt(16)
> +#endif
> +foo (void)
> +{
> + return 0;
> +}
>
> 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, Jan 16, 2024 at 4:00 PM Iain Sandoe wrote:
>
> Tested on x86_64 Darwin, x86_64 Linux.
> OK for trunk? When?
OK now.
> thanks
> Iain
>
> --- 8< ---
>
> Currently, these section names have wrong syntax for Mach-O.
> Although they were added some time ago; recently added tests are
> now
On Tue, Jan 16, 2024 at 3:52 PM Jeff Law wrote:
>
>
>
> On 1/15/24 05:56, Maxim Kuvyrkov wrote:
> > Hi Vladimir,
> > Hi Jeff,
> >
> > Richard and Alexander have reviewed this patch and [I assume] have no
> > further comments. OK to merge?
> I think the question is whether or not we're too late.
On Tue, Jan 16, 2024 at 11:20 PM Greg McGary wrote:
>
> The sign bit of a sign-extending load cannot be known until runtime,
> so don't attempt to simplify it in the combiner.
It feels like this papers over an issue downstream?
> 2024-01-11 Greg McGary
>
> PR rtl-optimization/113010
On Wed, Jan 17, 2024 at 7:42 AM Richard Biener
wrote:
>
> On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao wrote:
> >
> >
> >
> > > On Jan 15, 2024, at 4:31 AM, Richard Biener
> > > wrote:
> > >
> > >> All my questions for u
On Tue, Jan 16, 2024 at 9:26 PM Qing Zhao wrote:
>
>
>
> > On Jan 15, 2024, at 4:31 AM, Richard Biener
> > wrote:
> >
> >> All my questions for unshare_expr relate to a LTO bug that I currently
> >> stuck with
> >> when using .ACCESS_
The following makes reduction epilogue code generation handle missing
LC PHIs for the reductions, in particular also avoid replacing results
on one exit with epilogue result from another one (but not avoiding
generation of dead epilogues yet). The proper fix should be eventually
to create the
The following avoids prologue peeling when doing early exit
vectorization with the IV exit before the early exit. That's because
we it invalidates the invariant that the effective latch of the loop
is empty causing wrong continuation to the main loop. In particular
this is prone to break virtual
On Tue, Jan 16, 2024 at 5:58 AM Xi Ruoyao wrote:
>
> On Tue, 2024-01-16 at 10:57 +0800, chenxiaolong wrote:
> > 在 2024-01-15一的 15:50 +0800，Xi Ruoyao写道：
> > > On Mon, 2024-01-15 at 15:10 +0800, chenxiaolong wrote:
> > > > At 14:42 +0800 on the first day of 2024-01-15, Xi Ruoyao wrote：
> > > > > On
default:
> + return ~0;
> +}
> +}
> +
> +int
> +main ()
> +{
> + {
> +signed char *k[3];
> +int d;
> +for (d = 0; bar (8, 15) - 15 + d < 1; d++)
> + k[baz () + 1] =
> +*k[0] = -*k[0];
> + }
> +}
> --- gcc/tests
On Tue, 16 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> These symbols were exported at an incorrect symbol version,
> the following patch fixes that.
>
> I believe we should also rename the symbols (__nested_func_ptr_*
> or __gcc_nested_func_ptr_* or similar), __builtin_ in the name
> doesn't look
= _27 * { 3, 4, 5, 7 };
> MEM [(int *) + 16B] = vect__9.9_28;
>
>
> We can confirm it here: https://godbolt.org/z/6jGrEoz9s
So same thing, add && { ! vect128 }?
>
>
> juzhe.zh...@rivai.ai
>
> From: Richard Biener
> Date: 2024-01-16 15:43
> To: Juzhe-Zhong
On Tue, 16 Jan 2024, Juzhe-Zhong wrote:
> gcc/testsuite/ChangeLog:
OK
> * gcc.dg/vect/bb-slp-43.c: Add vect128.
>
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-43.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gcc/testsuite/gcc.dg/vect/bb-slp-43.c
>
On Tue, Jan 16, 2024 at 2:13 AM Roger Sayle wrote:
>
>
> This patch resolves PR rtl-optimization/111267 by improving RTL-level
> forward propagation. This x86_64 code quality regression was caused
> (exposed) by my changes to improve how x86's (TImode) argument passing
> is represented at the
_unpack_lo_expr] vect_patt_158.14_199;
> vect_patt_159.15_201 = [vec_unpack_hi_expr] vect_patt_158.14_199;
so xfail { vect_variable_length && { ! vect256 } && { ! vect128 } } then?
>
>
> juzhe.zh...@rivai.ai
>
> From: Richard Biener
> Date: 2024-01-16 15:38
> To:
> target { ! amdgcn-*-* } xfail vect_variable_length } } } */
> +/* { dg-final { scan-tree-dump-times "optimized: basic block" 2 "slp2" {
> target { ! amdgcn-*-* } } } } */
>
> /* amdgcn can do this in one vector. */
> /* { dg-final { scan-tree-dump-times "o
mp; vect_hw_misalign }
> } xfail { vect_variable_length && { ! vect256 } } } } } */
> +/* { dg-final { scan-tree-dump-not "vector operands from scalars" "slp2" {
> target { { vect_int && vect_bool_cmp } && { vect_unpack && vect_hw_misalign }
> } } } } */
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
cc.target/riscv/rvv/autovec/pr112971.c
> new file mode 100644
> index 000..816ebd3c493
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/pr112971.c
> @@ -0,0 +1,18 @@
> +/* { dg-do compile } */
> +/* { dg-options "-march=rv64gcv_zvl256b -mabi=lp64d
The following adjusts find_base_value similar as to what
find_base_term was adjusted for PR113255.
* alias.cc (known_base_value_p): Remove.
(find_base_value): Remove PLUS/MINUS handling
when both operands are not CONST_INT_P.
---
gcc/alias.cc | 62
When the x86 backend generates code for cpymem with the rep_8byte
strathegy for the 8 byte aligned main rep movq it needs to compute
an adjusted pointer to the source after doing a prologue aligning
the destination. It computes that via
src_ptr + (dest_ptr - orig_dest_ptr)
which is perfectly
On Mon, Jan 15, 2024 at 12:27 PM Andrew Carlotti
wrote:
>
> This allows code to determine why a particular function is
> multiversioned. For now, this will primarily be used to preserve
> existing name mangling quirks when subsequent commits change all
> function multiversioning name mangling to
The following avoids splitting an edge before redirecting it. This
allows the loop father of the new block to be correct in the first
place.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113385
* tree-vect-loop-manip.cc
On Sun, Jan 14, 2024 at 4:29 PM Ajit Agarwal wrote:
>
> Hello All:
>
> This patch add the vecload pass to replace adjacent memory accesses lxv with
> lxvp
> instructions. This pass is added before ira pass.
>
> vecload pass removes one of the defined adjacent lxv (load) and replace with
> lxvp.
On Fri, Jan 12, 2024 at 6:30 PM Qing Zhao wrote:
>
> Thanks a lot for the reply.
>
> > On Jan 12, 2024, at 11:28 AM, Richard Biener
> > wrote:
> >
> >
> >
> >> Am 12.01.2024 um 16:55 schrieb Qing Zhao :
> >>
> >> Hi,
> >
On Sun, Jan 14, 2024 at 8:32 PM Roger Sayle wrote:
>
>
> This patch fixes three of the four unexpected failures that I'm seeing
> in the gcc testsuite on x86_64-pc-linux-gnu. The three FAILs are:
> FAIL: gcc.c-torture/execute/fprintf-2.c -O3 -g (test for excess errors)
> FAIL:
{ "" } } */
> +
> +#if __BITINT_MAXWIDTH__ >= 255
> +_BitInt(255)
> +foo (int s)
> +{
> + return -(_BitInt(255)) 3 >> s;
> +}
> +#endif
> +
> +int
> +main ()
> +{
> +#if __BITINT_MAXWIDTH__ >= 255
> + if (foo (51) != -1)
> +__builtin_abort ();
> +#endif
> + return 0;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
; + return __builtin_mul_overflow_p ((__int128) 0x << 64, x,
> (_BitInt(129)) 0);
> +}
> +
> +int
> +bar (_BitInt(63) x)
> +{
> + return __builtin_mul_overflow_p ((__int128) 0x << 64, x,
> (_BitInt(129)) 0);
> +}
> +#endif
> +
> +int
> +main ()
> +{
> +#if __BITINT_MAXWIDTH__ >= 129
> + if (!foo (5167856845))
> +__builtin_abort ();
> + if (!bar (5167856845))
> +__builtin_abort ();
> +#endif
> + return 0;
> +}
>
> 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 13.01.2024 um 10:44 schrieb Jakub Jelinek :
>
> Hi!
>
> As the testcase shows, the INTEGER_CST handling in handle_operand_addr
> (i.e. what is used when passing address of an integer to a bitint library
> routine) wasn't correct. If the minimum precision to represent an
> INTEGER_CST
> Am 12.01.2024 um 16:55 schrieb Qing Zhao :
>
> Hi,
>
> I have some questions on using the utility routine “unshare_expr”:
>
> From my understanding, there should be NO shared nodes in a GENERIC function.
> Otherwise, gimplication might fail.
There is sharing and this is why we unshare
Currently we scale the number of stmts allowed for forward
jump threading to limit those for backwards jump threading
by applying a factor of two to the counted stmts. That doesn't
allow fine-grained adjustments, like by a single stmt as needed
for PR109893. The following changes the factor to
Status
==
The GCC development branch which will become GCC 14 is now
in regression and documentation fixes only mode (Stage 4).
Please concentrate now on fixing regressions from GCC 13
and earlier.
GCC 14.1 will be released when we reach the milestone of
zero P1 regressions (note not all
get_identifier (XSTR (fun, 0));
> + const char *name = targetm.strip_name_encoding (XSTR (fun, 0));
> + get_identifier (name);
> pending_libcall_symbols = gen_rtx_EXPR_LIST (VOIDmode, fun,
> pending_libcall_symbols);
&
__builtin_abort ();
> + if (foo (1) !=
> 0x7ffewb)
> +__builtin_abort ();
> + if (foo (11) !=
> 0x001fffffwb)
>
param=sccvn-max-alias-queries-per-access=0" } */
> +
> +_BitInt(8) a;
> +
> +static inline __attribute__((__always_inline__)) void
> +bar (int, int, int, int, int, int, int, int)
> +{
> +#if __BITINT_MAXWIDTH__ >= 65535
> + _BitInt(65535) b = 0;
> + _BitInt(38
cc/testsuite/gcc.dg/bitint-67.c.jj 2024-01-11 13:54:14.561936065
> +0100
> +++ gcc/testsuite/gcc.dg/bitint-67.c 2024-01-11 13:55:09.474162196 +0100
> @@ -0,0 +1,12 @@
> +/* PR tree-optimization/113316 */
> +/* { dg-do compile { target bitint575 } } */
> +/* { dg-options &q
1 14:40:35.977814727 +0100
> @@ -0,0 +1,14 @@
> +/* PR tree-optimization/113323 */
> +/* { dg-do compile { target bitint575 } } */
> +/* { dg-options "-std=c23 -O2" } */
> +
> +typedef long __attribute__((__vector_size__ (16))) V;
> +V u, v;
> +_BitInt(535) i;
> +
&g
&& tree_int_cst_equal (TYPE_SIZE (rhs_type),
> > -TYPE_SIZE (lhs_type))
> > + && (CEIL (TYPE_PRECISION (lhs_type), limb_prec)
> > + == CEIL (TYPE_PRECISION (rhs_type), limb_prec))
> > && (!m_upwards_2limb
> > || (m_upwards_2limb * limb_prec
> > < TYPE_PRECISION (lhs_type)
> >
> > Jakub
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
LOOP_VINFO_SCALAR_LOOP (loop_vinfo))->dest->count
> - = preheader->count;
> + LOOP_VINFO_SCALAR_IV_EXIT (loop_vinfo)->dest->count = preheader->count;
> }
>
>if (niters_vector == NULL_TREE)
>
>
>
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
On GENERIC tcc_comparison can have int type so restrict the PR113126
fix to vector types.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR middle-end/113344
* match.pd ((double)float CMP (double)float -> float CMP float):
Perform result type check only for
bb_vinfo->slp_instances)
> +{
> + vect_location = instance->location ();
> + vect_bb_slp_mark_live_stmts (bb_vinfo, SLP_INSTANCE_TREE (instance),
> + instance, >cost_vec,
> + scalar_use_map, svisited, visited);
>
On Fri, Jan 12, 2024 at 3:15 AM HAO CHEN GUI wrote:
>
> Hi Richard,
>Thanks so much for your comments.
>
>
> >> patch.diff
> >> diff --git a/gcc/config/rs6000/rs6000-string.cc
> >> b/gcc/config/rs6000/rs6000-string.cc
> >> index 7f777666ba9..4c9b2cbeefc 100644
> >> ---
On Thu, 11 Jan 2024, Arthur Cohen wrote:
> Hi Richard,
>
> On 1/11/24 15:23, Richard Biener wrote:
> > On Thu, 11 Jan 2024, Arthur Cohen wrote:
> >
> >> From: Pierre-Emmanuel Patry
> >>
> >> Fix the missing dependency between the gcc and libgrust
701 - 800 of 25289 matches
Mail list logo
