> -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
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?
> >
> >
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
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
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:
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
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.
--
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
> 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
> 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
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.
*
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
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
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
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
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
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.
>
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.
*
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
> -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
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
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
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
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
发件人：
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
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
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
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
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
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
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;
> 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 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);
> > -
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:
*
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
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, /*
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
>
>
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:
> > > > >
> > > > >
> >
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
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
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
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
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
>
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
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
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
LGTM.
Regards
Robin
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 */
>
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-
> >
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
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
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?
>> 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
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
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
>
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.
---
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
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 } */
> > +/* {
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.
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
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
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
---
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:
*
> -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.
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
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,
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
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
> 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:
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
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 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
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]))
> > > ?
> >
> >
> 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
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.
> >
> >
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.
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
>> 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?
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
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
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, 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:
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:
>> (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
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
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
This patch implements built-in trait for std::is_floating_point.
gcc/cp/ChangeLog:
* cp-trait.def: Define __is_floating_point.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_FLOATING_POINT.
* semantics.cc (trait_expr_value): Likewise.
Julian Brown wrote:
This patch adds support for parsing general lvalues ("locator list item
types") for OpenMP "map", "to" and "from" clauses to the C front-end,
similar to the previously-posted patch for C++. Such syntax is permitted
for OpenMP 5.0 and above. It was previously posted for
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
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
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:
> >
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.
>
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
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
This patch optimizes the compilation performance of std::is_integral
by dispatching to the new __is_integral built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_integral): Use __is_integral
built-in trait.
(is_integral_v): Likewise.
Signed-off-by: Ken
This patch optimizes the compilation performance of std::is_fundamental
by dispatching to the new __is_arithmetic built-in trait.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_fundamental_v): Use
__is_arithmetic built-in trait.
(is_fundamental): Likewise. Optimize
This is a v3 which addresses shortcomings of the v2 patch. v2 was
posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642448.html
The main issue in v2 is that we were using the final (transformed)
patterns in combine_reg_notes instead of the initial patterns (thanks
Richard S for
On Wed, 10 Jan 2024 at 19:43, Ken Matsui wrote:
>
> This patch optimizes the compilation performance of
> std::is_floating_point by dispatching to the new
> __is_floating_point built-in trait.
OK for trunk (if the new built-in is approved).
>
> libstdc++-v3/ChangeLog:
>
> *
1 - 100 of 177 matches
Mail list logo
