> -Original Message-
> From: Jiang, Haochen
> Sent: Wednesday, January 10, 2024 3:35 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com; burnus@net-
> b.de; san...@codesourcery.com
> Subject: [PATCH] i386: Add AVX10.1 related macros
>
> Hi all,
>
> This patch aims
On Tue, Jan 9, 2024 at 3:09 PM Hongyu Wang wrote:
>
> Hi,
>
> For APX, the inline asm behavior was not mentioned in any document
> before. Add description for it.
>
> Ok for trunk?
>
> gcc/ChangeLog:
>
> * config/i386/i386.opt: Adjust document.
> * doc/invoke.texi: Add description
Thanks, this is the patch I'm going to check-in
Hongtao Liu 于2024年1月10日周三 16:02写道:
>
> On Tue, Jan 9, 2024 at 3:09 PM Hongyu Wang wrote:
> >
> > Hi,
> >
> > For APX, the inline asm behavior was not mentioned in any document
> > before. Add description for it.
> >
> > Ok for trunk?
> >
> > gcc/Ch
On 1/9/24 19:37, Radek Barton wrote:
Hello.
I forgot to add the target maintainers to the CC. My apologies for that.
Furthermore, I am adding also relevant changes in `libgcc/config/aarch64/lse.S`
file to the patch. Originally we wanted to submit those changes separately but
after the feedbac
On Tue, Jan 09, 2024 at 04:35:22PM -0600, Peter Bergner wrote:
> On 1/5/24 4:18 PM, Michael Meissner wrote:
> > @@ -14504,13 +14504,17 @@ print_operand (FILE *file, rtx x, int code)
> > print_operand (file, x, 0);
> >return;
> >
> > +case 'S':
> > case 'x':
> > - /* X is
> On 10 Jan 2024, at 08:49, Jonathan Yong <10wa...@gmail.com> wrote:
>
> On 1/9/24 19:37, Radek Barton wrote:
>> Hello.
>> I forgot to add the target maintainers to the CC. My apologies for that.
>> Furthermore, I am adding also relevant changes in
>> `libgcc/config/aarch64/lse.S` file to the
Hi Mike,
on 2024/1/6 06:18, Michael Meissner wrote:
> In looking at support for load vector pair and store vector pair for the
> PowerPC in GCC, I noticed that we were missing a print_operand output modifier
> if you are dealing with vector pairs to print the 2nd register in the vector
> pair.
>
> On 10 Jan 2024, at 09:02, Iain Sandoe wrote:
>> On 10 Jan 2024, at 08:49, Jonathan Yong <10wa...@gmail.com> wrote:
>>
>> On 1/9/24 19:37, Radek Barton wrote:
>>> Hello.
>>> I forgot to add the target maintainers to the CC. My apologies for that.
>>> Furthermore, I am adding also relevant ch
On Fri, Jan 05, 2024 at 12:23:26PM +, Julian Brown wrote:
> * g++.dg/gomp/bad-array-section-10.C: New test.
This test FAILs in C++23/C++26 modes, just try
make check-g++ GXX_TESTSUITE_STDS=98,11,14,17,20,23,26
RUNTESTFLAGS=gomp.exp=bad-array-section-10.C
While in C++20 comma in ar
ping
> -Original Message-
> From: Tamar Christina
> Sent: Friday, January 5, 2024 1:31 PM
> To: Xi Ruoyao ; Palmer Dabbelt
> Cc: gcc-patches@gcc.gnu.org; nd ; rguent...@suse.de; Jeff Law
>
> Subject: RE: [PATCH]middle-end: Don't apply copysign optimization if target
> does
> not implem
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(BASE): Define new builtin bases.
* con
This patch only involves the generation of xtheadvector
special load/store instructions and vext instructions.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class th_loadstore_width): Define new builtin bases.
(BASE): Define new builtin bases.
* con
Hi Jakub,
> When flock program doesn't exist, libgomp configure attempts to
> offer a fallback version using a perl script, but we weren't using
> absolute filename to that, so it apparently failed to work correctly.
>
> The following patch arranges for it to get the absolute filename.
>
> Tested
On Tue, Jan 9, 2024 at 9:18 PM Eric Botcazou wrote:
>
> Hi,
>
> this is not really a regression but the patch was written last week and is
> quite straightforward, so hopefully can nevertheless be OK. It implements the
> support of DW_AT_endianity for enumeration types because they are scalar and
Hi!
As changed in other parts of the compiler, using
build_nonstandard_integer_type is not appropriate for arbitrary precisions,
especially if the precision comes from a BITINT_TYPE or something based on
that, build_nonstandard_integer_type relies on some integral mode being
supported that can sup
On Wed, Jan 10, 2024 at 3:35 AM Haochen Jiang wrote:
>
> Hi Richard,
>
> It seems that I send out a not updated patch. This patch should what
> I want to send.
OK
> Thx,
> Haochen
>
> gcc/ChangeLog:
>
> * doc/invoke.texi: Add -mevex512.
> ---
> gcc/doc/invoke.texi | 7 ++-
> 1 file
On Wed, Jan 10, 2024 at 9:01 AM Liu, Hongtao wrote:
>
>
>
> > -Original Message-
> > From: Jiang, Haochen
> > Sent: Wednesday, January 10, 2024 3:35 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Liu, Hongtao ; ubiz...@gmail.com; burnus@net-
> > b.de; san...@codesourcery.com
> > Subject: [PAT
And revise th_loadstore_width, append the name according TYPE_UNSIGNED and
GET_MODE_BITSIZE (GET_MODE_INNER (TYPE_MODE
(instance.op_info->args[i].get_tree_type (instance.type.index
What do you mean by it? I'm a bit confused.
Changing i8_v_scalar_const_ptr_ops into all_v_scalar_const_ptr_ops
On Wed, 10 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> As changed in other parts of the compiler, using
> build_nonstandard_integer_type is not appropriate for arbitrary precisions,
> especially if the precision comes from a BITINT_TYPE or something based on
> that, build_nonstandard_integer_type re
This patch is preparing patch for the following cost model tweak.
Since we don't have vector cost model in default tune info (rocket),
we set the cost model default as generic cost model by default.
The reason we want to switch to generic vector cost model is the default
cost model generates infe
Originally we've used `!__MINGW64__` but changed it to `__ELF__` upon feedback
received. Should I change it back to `!__MINGW64__`? Or introduce '__COFF__'
and then use `!__COFF__`? What would be the minimal acceptable change? we are
currently probably not able to provide that generic solution a
On Wed, Jan 10, 2024 at 10:51:32AM +0100, Richard Biener wrote:
> > @@ -2742,8 +2743,11 @@ analyze_access_subtree (struct access *r
> > tree rt = root->type;
> > gcc_assert ((root->offset % BITS_PER_UNIT) == 0
> > && (root->size % BITS_PER_UNIT) == 0);
> > - root->
> -Original Message-
> From: Chung-Ju Wu
> Sent: Wednesday, January 10, 2024 7:07 AM
> To: Gerald Pfeifer ; gcc-patches patc...@gcc.gnu.org>
> Cc: Kyrylo Tkachov ; Richard Earnshaw
> ; Sudakshina Das ;
> jason...@anshingtek.com.tw
> Subject: [PATCH][wwwdoc] gcc-14: Add arm cortex-m52 cp
The key difference between vlb/vlh/vlw is not output type too.
Their difference is the range of datatype, not one specific type.
We have dived into the xtheadvector special intrinsics and are
sure about that.
--
发件人:juzhe.zh...@
Can you see the images that I sent to you in the last email?
If not, maybe you can refer to the last chapter in the thead spec.
--
发件人:joshua
发送时间:2024年1月10日(星期三) 19:06
收件人:"juzhe.zh...@rivai.ai";
"gcc-patches"
抄 送:Jim Wilson;
So vlb has not only sew = 8 ?
But why do you add intrinsics as follows ?
+DEF_RVV_FUNCTION (th_vlb, th_loadstore_width, full_preds,
i8_v_scalar_const_ptr_ops)
Why it is not :
DEF_RVV_FUNCTION (th_vlb, th_loadstore_width, full_preds,
all_v_scalar_const_ptr_ops)
?
juzhe.zh...@rivai.ai
发件人:
vlb can accept sew=8/16/32/64.
vlh can accept sew=16/32/64;
vlw can accept sew=32/64.
vint8m1_t __riscv_th_vlb_v_i8m1 (const int8_t *a, size_t vl);
vint8m2_t __riscv_th_vlb_v_i8m2 (const int8_t *a, size_t vl);
vint8m4_t __riscv_th_vlb_v_i8m4 (const int8_t *a, size_t vl);
vint8m8_t __riscv_th_vlb_v
On Wed, Jan 10, 2024 at 10:32:56AM +0100, Rainer Orth wrote:
> > When flock program doesn't exist, libgomp configure attempts to
> > offer a fallback version using a perl script, but we weren't using
> > absolute filename to that, so it apparently failed to work correctly.
> >
> > The following pat
On Tue, 2 Jan 2024 23:21:21 +0800
Chung-Lin Tang wrote:
> To Julian, there is a patch to the middle-end neutering, a hack
> actually, that detects SSA_NAMEs used in reduction array MEM_REFs,
> and avoids single->parallel copying (by moving those definitions
> before BUILT_IN_GOACC_SINGLE_COPY_STA
On 05/01/2024 01:43, Lipeng Zhu wrote:
This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
not defined in dec_waiting_unlocked function. As io.h does
not include async.h, the WRLOCK and RWUNLOCK macros are
undefined.
libgfortran/ChangeLog:
* io/io.h (dec_waiting_unlocked): Use
> Can you elaborate on the DIE order constraint and why it was chosen? That
> is,
>
> + /* The DIE with DW_AT_endianity is placed right after the naked DIE.
> */ + if (reverse)
> + {
> + gcc_assert (type_die);
> ...
>
> and
>
> + /* The DIE with DW_AT_endianity is
On Wed, Jan 10, 2024 at 12:53 PM Eric Botcazou wrote:
>
> > Can you elaborate on the DIE order constraint and why it was chosen? That
> > is,
> >
> > + /* The DIE with DW_AT_endianity is placed right after the naked DIE.
> > */ + if (reverse)
> > + {
> > + gcc_assert (type
On Sat, Dec 23, 2023 at 7:35 PM Andrew Pinski wrote:
>
> Like r14-2293-g11350734240dba and r14-2289-gb083203f053f16,
> reassociation can combine across a few bb and one of the usage
> can be an uninitializated variable and if going from an conditional
> usage to an unconditional usage can cause wr
On Tue, Jan 9, 2024 at 11:48 AM liuhongt wrote:
>
> > I wonder if you can amend the existing patterns instead by iterating
> > over cond/vec_cond. There are quite some (look for uses of
> > minmax_from_comparison) that could be adapted to vectors.
> >
> > The ones matching the simple form you mat
Pushed to r14-7096.
在 2024/1/10 下午3:24, chenxiaolong 写道:
After the code is committed in r14-6948, GCC regression testing on some
architectures will produce the following error:
"error executing dg-final: unknown effective target keyword `loongarch*-*-*'"
gcc/testsuite/ChangeLog:
* lib
Pushed to r14-7097.
在 2024/1/10 下午3:25, chenxiaolong 写道:
The function of this test is to check that the compiler supports vectorization
using SLP and vec_{load/store/*}_lanes. However, vec_{load/store/*}_lanes are
not supported on LoongArch, such as the corresponding "st4/ld4" directives on
aarc
Hi Jakub,
>> FLOCK is also substituted into testsuite/libgomp-site-extra.exp.in,
>> which gets included into site.exp. That one has
>>
>> ## Begin content included from file libgomp-site-extra.exp. Do not modify.
>> ##
>> set FLOCK {$(abs_top_srcdir)/testsuite/flock}
>>
>> So expect tries to
This is a v2 which addresses feedback from v1, posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642313.html
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Thanks,
Alex
-- >8 --
In r14-6604-gd7ee988c491cde43d04fe25f2b3dbad9d85ded45 we changed the CFI notes
attached
On Fri, 5 Jan 2024, Tamar Christina wrote:
> > On Fri, 2024-01-05 at 11:02 +, Tamar Christina wrote:
> > > Ok, so something like:
> > >
> > > > > ([istarget loongarch*-*-*] &&
> > > > > ([check_effective_target_loongarch_sx] ||
> > > > > [check_effective_target_hard_float]))
> > > ?
> >
> > W
> Date: Tue, 9 Jan 2024 21:02:44 +0100
> Cc: i...@google.com, gcc-patches@gcc.gnu.org, g...@gcc.gnu.org
> From: Björn Schäpers
>
> Am 07.01.2024 um 18:03 schrieb Eli Zaretskii:
> > In that case, you an call either GetModuleHandeExA or
> > GetModuleHandeExW, the difference is minor.
>
> Here an u
Just a note that, following discussion on IRC, I'll pull this for
GCC 14 and resubmit for GCC 15.
There was also pushback on IRC about making the pass opt-in.
Enabling it for x86_64 would mean fixing RPAD to use a representation
that is more robust against recombination, but as you can imagine, it
This patch fixes several tests introduced by the commit
r14-7033-g1413af02d62182 for 32-bit targets.
I will commit as obvious.
2024-01-10 Julian Brown
gcc/testsuite/
* g++.dg/gomp/array-section-1.C: Fix scan output for 32-bit target.
* g++.dg/gomp/array-section-2.C: Likewise.
This patch adjusts diagnostic output for C++23 and above for the test
case mentioned in the commit title.
I will apply shortly as obvious.
2024-01-10 Julian Brown
gcc/testsuite/
* g++.dg/gomp/bad-array-section-10.C: Adjust diagnostics for C++23 and
up.
---
gcc/testsuite/g++.d
On Wed, 10 Jan 2024 10:14:41 +0100
Jakub Jelinek wrote:
> On Fri, Jan 05, 2024 at 12:23:26PM +, Julian Brown wrote:
> > * g++.dg/gomp/bad-array-section-10.C: New test.
>
> This test FAILs in C++23/C++26 modes, just try
> make check-g++ GXX_TESTSUITE_STDS=98,11,14,17,20,23,26
>
Hi Joshua,
> For th.vmadc/th.vmsbc as well as narrowing arithmetic instructions
> and floating-point compare instructions, an illegal instruction
> exception will be raised if the destination vector register overlaps
> a source vector register group.
>
> To handle this issue, we use "group_overla
On Wed, 10 Jan 2024, Richard Sandiford wrote:
> Just a note that, following discussion on IRC, I'll pull this for
> GCC 14 and resubmit for GCC 15.
>
> There was also pushback on IRC about making the pass opt-in.
> Enabling it for x86_64 would mean fixing RPAD to use a representation
> that is mo
No functional change intended.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-7104-g7daa935c7997f3.
gcc/ChangeLog:
* pretty-print.cc (selftest::test_pp_format): Add selftest
coverage for numbered args.
Signed-off-by: David Malcolm
---
gcc/
Given e.g. this missppelled option (omitting the trailing 's'):
$ LANG=C ./xgcc -B. -fno-inline-small-function
xgcc: error: unrecognized command-line option '-fno-inline-small-function'; did
you mean '-fno-inline-small-functions'?
we weren't providing a documentation URL for the suggestion.
The
TL;DR: for the case when the user misspells a command-line option
and we suggest one, with this patch we now provide a documentation URL
for the suggestion.
In r14-5118-gc5db4d8ba5f3de I added a mechanism to automatically add
URLs to quoted strings in diagnostics, and in r14-6920-g9e49746da303b8
t
>> For the other insns, I wonder if we could get away with not really
>>disabling the newly added early-clobber alternatives for RVV but
>>just disparaging ("?") them? That way we could re-use "full" for
>>the thv-disabled alternatives and "none" for the newly added ones.
>>("none" will still be m
Hi All,
Should control enter the switch from one of the cases other than
the IVDEP one then the variable remains uninitialized.
This fixes it by initializing it to false.
Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
and no issues
Committed as obvious.
Thanks,
Tamar
gc
Hi Juzhe,
> The reason we want to switch to generic vector cost model is the default
> cost model generates inferior codegen for various benchmarks.
>
> For example, PR113247, we have performance bug that we end up having over 70%
> performance drop of SHA256. Currently, no matter how we adapt c
>> So is the idea here to just revert the values to the defaults for now
>> and change them again soon? And not to keep this as another default
>> and add others?
My idea is to revert default for now. Then we can refine the cost gradually.
>> I'm a bit confused here :) How does this help? Can'
Hi All,
The vectorizer needs to know during early break vectorization whether the edge
that will be taken if the condition is true stays or leaves the loop.
This is because the code assumes that if you take the true branch you exit the
loop. If you don't exit the loop it has to generate a differ
When if-conversion was changed to use .COND_ADD/SUB for conditional
reduction it was forgotten to update reduction path handling to
canonicalize .COND_SUB to .COND_ADD for vectorizable_reduction
similar to what we do for MINUS_EXPR. The following adds this
and testcases exercising this at runtime
On Wed, 10 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> The vectorizer needs to know during early break vectorization whether the edge
> that will be taken if the condition is true stays or leaves the loop.
>
> This is because the code assumes that if you take the true branch you exit the
> lo
On Thu, 2023-11-16 at 17:28 -0500, Antoni Boucher wrote:
> Hi.
> This patch fixes a segfault that happens when compiling librsvg (more
> specifically its dependency aho-corasick) with rustc_codegen_gcc (bug
> 112575).
> I was not able to create a reproducer for this bug: I'm assuming I
> might need
The optimization to expand uniform boolean vectors by sign-extension
works only for dense masks but it failed to check that.
Bootstrap and regtest running on x86_64-unknown-linux-gnu, I've
checked aarch64 RTL expansion for the testcase. Will push tomorrow.
Richard.
PR middle-end/112740
On Wed, 2024-01-10 at 09:30 -0500, David Malcolm wrote:
> On Thu, 2023-11-16 at 17:28 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch fixes a segfault that happens when compiling librsvg
> > (more
> > specifically its dependency aho-corasick) with rustc_codegen_gcc
> > (bug
> > 112575).
> > I w
I need to add these costs for segment load/stores:
/* Generic costs for VLA vector operations. */
static const scalable_vector_cost generic_vla_vector_cost = {
{
1, /* int_stmt_cost */
1, /* fp_stmt_cost */
1, /* gather_load_cost */
1, /* scatter_store_cost */
1, /* vec_
Hi!
Thanks for fixing it, just testsuite nits.
On Wed, Jan 10, 2024 at 03:22:53PM +0100, Richard Biener wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/vect/vect-early-break_100-pr113287.c
> > @@ -0,0 +1,35 @@
> > +/* { dg-add-options vect_early_break } */
> > +/* { dg-require-effective-t
> -Original Message-
> From: Jakub Jelinek
> Sent: Wednesday, January 10, 2024 2:42 PM
> To: Tamar Christina ; Richard Biener
>
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: correctly identify the edge taken when
> condition
> is true. [PR113
As discussed on IRC, this makes the aarch64 ldp/stp pass off by default. This
should stabilize the trunk and give some time to address the P1 regressions.
Sorry for the breakage.
Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
Alex
gcc/ChangeLog:
* config/aarch64/aarch64.op
Alex Coplan writes:
> As discussed on IRC, this makes the aarch64 ldp/stp pass off by default. This
> should stabilize the trunk and give some time to address the P1 regressions.
>
> Sorry for the breakage.
>
> Bootstrapped/regtested on aarch64-linux-gnu, OK for trunk?
>
> Alex
>
> gcc/ChangeLog:
On Mon, 2023-12-11 at 09:06 -0700, Jeff Law wrote:
>
>
> On 11/20/23 16:54, David Malcolm wrote:
> > On Mon, 2023-11-20 at 16:38 -0700, Jeff Law wrote:
> > >
> > >
> > > On 11/20/23 15:46, David Malcolm wrote:
> > > > On Fri, 2023-11-17 at 14:09 -0700, Jeff Law wrote:
> > > > >
> > > > >
> >
On Wed, Jan 10, 2024 at 02:45:41PM +, Tamar Christina wrote:
> > -Original Message-
> > From: Jakub Jelinek
> > Sent: Wednesday, January 10, 2024 2:42 PM
> > To: Tamar Christina ; Richard Biener
> >
> > Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> > Subject: Re: [PATCH]mi
LGTM.
Regards
Robin
On Wed, Jan 10, 2024 at 02:47:29PM +, Richard Sandiford wrote:
> Alex Coplan writes:
> > As discussed on IRC, this makes the aarch64 ldp/stp pass off by default.
> > This
> > should stabilize the trunk and give some time to address the P1 regressions.
> >
> > Sorry for the breakage.
> >
> >
On 1/10/24 15:40, 钟居哲 wrote:
> I need to add these costs for segment load/stores:
>
> /* Generic costs for VLA vector operations. */
> static const scalable_vector_cost generic_vla_vector_cost = {
> {
> 1,/* int_stmt_cost */
> 1,/* fp_stmt_cost */
> 1,/* gather_load_cost */
>
Current generic cost model makes dynamic-lmul2-7.c generate inferior codegen.
I found if I tweak the cost a little bit then dynamic-lmul2-7.c codegen can be
recovered.
However, it makes other tests failed
It's complicated story
So, I'd rather set it as default cost and switch to it.
Then
On Mon, 2023-12-11 at 19:20 -0500, Antoni Boucher wrote:
> I'm not sure how to do this. I tried the following commands, but this
> fails even on master:
>
> ../../gcc/configure --enable-host-shared --enable-
> languages=c,jit,c++,fortran,objc,lto --enable-checking=release --
> disable-werror --pre
On 08/01/2024 17:21, Matthieu Longo wrote:
Hi,
Arm GCC backend does not define __ARM_FEATURE_BF16 when +bf16 is
specified (via -march option, or target pragma) whereas it is supposed
to be tested before including arm_bf16.h (as specified in ACLE document:
https://arm-software.github.io/acl
On Wed, 2024-01-10 at 10:19 -0500, David Malcolm wrote:
> On Mon, 2023-12-11 at 19:20 -0500, Antoni Boucher wrote:
> > I'm not sure how to do this. I tried the following commands, but
> > this
> > fails even on master:
> >
> > ../../gcc/configure --enable-host-shared --enable-
> > languages=c,jit,
On 08/01/2024 16:07, Roger Sayle wrote:
Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently
has a large number of FAILs in libatomic (regressions since last time I
attempted this). The failure mode is related to IFUNC handling with the
file tas_8_2_.o containing an unre
> Current generic cost model makes dynamic-lmul2-7.c generate inferior codegen.
>
> I found if I tweak the cost a little bit then dynamic-lmul2-7.c codegen can
> be recovered.
> However, it makes other tests failed
> It's complicated story
Ok, makes sense. So the plan seems to be:
(1)
This patch is preparing patch for the following cost model tweak.
Since we don't have vector cost model in default tune info (rocket),
we set the cost model default as generic cost model by default.
The reason we want to switch to generic vector cost model is the default
cost model generates infe
>> (1) Fall back to the generic cost model if the tune model didn't
>> (specify one, i.e. make sure we always use the generic cost
>> ( model rather than the default one.
>> ((2) Change this generic (fallback) cost model so we don't have
>> (regressions on the current trunk, as it's now always used
LGTM.
Regards
Robin
GCC tends to optimistically create CONST of globals with an immediate offset.
However it is almost always better to CSE addresses of globals and add immediate
offsets separately (the offset could be merged later in single-use cases).
Splitting CONST expressions with an index in aarch64_legitimize_
Hi Edwin,
> This patch copies the vector reservations from generic-ooo.md and
> inserts them into generic.md and sifive.md. Creates new vector crypto related
> insn reservations.
In principle, the changes look good to me but I wonder if we could
split off the vector parts from generic-ooo into th
On Tue, Jan 9, 2024 at 6:02 PM liuhongt wrote:
>
> After r14-2692-g1c6231c05bdcca, the option is defined as EnumSet and
> -fcf-protection=branch won't unset any others bits since they're in
> different groups. So to override -fcf-protection, an explicit
> -fcf-protection=none needs to be added and
Hi!
This test was already fixed by r14-6051 aka PR112770 fix.
Tested on x86_64-linux, committed to trunk as obvious.
2024-01-10 Jakub Jelinek
PR tree-optimization/112734
* gcc.dg/bitint-64.c: New test.
--- gcc/testsuite/gcc.dg/bitint-64.c.jj 2024-01-10 17:17:08.438466886 +01
On 1/10/24 06:35, Richard Biener wrote:
I think x86 maintainers could opt to disable the pass - so it would
be opt-out. It's reasonable to expect them to fix the backend given
there's nothing really wrong with the new pass, it just does
something that wasn't done before at that point?
That's
On Tue, 9 Jan 2024, Jeff Law wrote:
> > Depending on how you look at it you may qualify this as a bug fix (for
> > the commit referred; it's surely rare enough a case I missed in original
> > testing) or a missed optimisation. Either way it's a narrow-scoped very
> > small change, almost an obv
On 1/10/24 06:01, Richard Sandiford wrote:
So to get an idea for expectations: would it be a requirement that a
GCC 15 submission is enabled unconditionally and all known issues in
the ports fixed?
I don't think we need to fix those latent port issues as a hard
requirement. I try to balance
Add terminating `/' character missing from one of the test harness
command clauses in pr105314.c. This causes no issue with compilation
owing to another comment immediately following, but would cause a:
pr105314.c:3:1: warning: "/*" within comment [-Wcomment]
message if warnings were enabled.
On 1/9/24 19:04, Mike Frysinger wrote:
Nothing uses this, so delete it to avoid confusion.
config/ChangeLog:
* acinclude.m4 (CYG_AC_PATH_LIBERTY): Delete.
OK
jeff
Hi All,
This changes the tests I committed for PR113287 to also
run on targets that don't support bitint.
Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
and no issues and tests run on both.
Ok for master?
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR tree-optimization/113287
On Wed, Jan 10, 2024 at 04:55:00PM +, Tamar Christina wrote:
> PR tree-optimization/113287
> * gcc.dg/vect/vect-early-break_100-pr113287.c: Support non-bitint.
This part is ok.
> --- a/gcc/testsuite/gcc.dg/vect/vect-early-break_99-pr113287.c
> +++ b/gcc/testsuite/gcc.dg/vect/vect-
Congratulations on landing this impressive work in GCC 14!
On Sun, 7 Jan 2024, waffl3x wrote:
> Bootstrapped and tested on x86_64-linux with no regressions.
>
> I'm considering this finished, I have CWG2586 working but I have not
> included it in this version of the patch. I was not happy with t
On Tue, Jan 9, 2024 at 6:59 PM Jeff Law wrote:
>
>
>
> On 11/17/23 00:33, Jin Ma wrote:
> > The XTheadInt ISA extension provides acceleration interruption
> > instructions as defined in T-Head-specific:
> > * th.ipush
> > * th.ipop
> >
> > Ref:
> > https://github.com/T-head-Semi/thead-extension-sp
Wilco Dijkstra writes:
> GCC tends to optimistically create CONST of globals with an immediate offset.
> However it is almost always better to CSE addresses of globals and add
> immediate
> offsets separately (the offset could be merged later in single-use cases).
> Splitting CONST expressions wi
> But I'm afraid I have no idea how is this supposed to work on
> non-bitint targets or where __BITINT_MAXWIDTH__ is smaller than 9020.
> There is no loop at all there, so what should be vectorized?
>
Yeah It was giving an unresolved and I didn't notice in diff.
> I'd say introduce
> # Return 1
Wilco Dijkstra writes:
> Hi Richard,
>
>>> +#define MAX_SET_SIZE(speed) (speed ? 256 : 96)
>>
>> Since this isn't (AFAIK) a standard macro, there doesn't seem to be
>> any need to put it in the header file. It could just go at the head
>> of aarch64.cc instead.
>
> Sure, I've moved it in v4.
>
>>
Hi Robin,
On 1/10/2024 8:00 AM, Robin Dapp wrote:
Hi Edwin,
This patch copies the vector reservations from generic-ooo.md and
inserts them into generic.md and sifive.md. Creates new vector crypto related
insn reservations.
In principle, the changes look good to me but I wonder if we could
spl
libstdc++: [_GLIBCXX_DEBUG] Fix assignment of value-initialized iterator
[PR112477]
Now that _M_Detach do not reset iterator _M_version value we need to
reset it when
the iterator is attached to a new sequence. Even if this sequencer is
null like when
assigning a value-initialized iterator. In
Am Mo., 8. Jan. 2024 um 03:25 Uhr schrieb Jonathan Wakely :
>
> Tested x86_64-linux and aarch64-linux. Pushed to trunk.
>
> -- >8 --
>
> This adds std::runtime_format for C++26. These new overloaded functions
> enhance the std::format API so that it isn't necessary to use the less
> ergonomic std::
On Wed, Jan 10, 2024 at 06:07:16PM +, Tamar Christina wrote:
> This changes the tests I committed for PR113287 to also
> run on targets that don't support bitint.
>
> Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu and no issues and
> tests run on both.
>
> Ok for master?
Yes, thank
Hi,
This patch is still work in progress, but posting to show failure with
bitint-7 test where handle_stmt called from lower_mergeable_stmt ICE's
because the idx (3) is out of range for the __BitInt(135) with a
limb_prec of 64.
I hacked gcc locally to work around this issue and still have on
> Since all the pipelines should be tuned to their cost model, they
> would be different anyway. If it would be simpler for now, I could
> separate the files out.
> I think I'm getting a bit confused. Is there a reason why we would
> want to exchange scheduler descriptions like the example you
> pr
1 - 100 of 177 matches
Mail list logo