This test should pass no matter how we adjust cost model.
Remove -fno-vect-cost-model.
Committed.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/fold-min-poly.c: Remove
-fno-vect-cost-model
---
gcc/testsuite/gcc.target/riscv/rvv/autovec/fold-min-poly.c | 2 +-
1 file
Bootstrapped and tested on x86_64-linux with no regressions.
I'm still getting used to things so let me know if the change log
entries are excessive, thanks.From 9dc168e7bcbbd7d515fa28cb9cae28ec113fae0f Mon Sep 17 00:00:00 2001
From: Waffl3x
Date: Thu, 11 Jan 2024 14:32:46 -0700
Subject: [PATCH]
ok.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-12 11:24
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v5] RISC-V: Rewrite some instructions using ASM
ok.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-12 11:23
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v6] RISC-V: Fix register overlap issue for some
ok
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-12 11:22
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v6] RISC-V: Handle differences between XTheadvector
OK.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-12 11:21
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v5] RISC-V: Adds the prefix "th." for the
This patch needs kito review. I can't approve that.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-12 11:20
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; kito.cheng; Jun Sha (Joshua); Jin Ma; Xianmiao
Qu
Am Do., 11. Jan. 2024 um 21:23 Uhr schrieb Jonathan Wakely :
>
> Tested x86_64-linux. Does this look better now?
Yes, thank you.
- Daniel
Hi,
On P9 "setb" is used to set the result of block compare. So it works
with m32 and mpowerpc64. On P8, carry bit is used. So it can't work
with m32 and mpowerpc64. This patch enables block compare expand for
m32 and mpowerpc64 on P9.
Bootstrapped and tested on x86 and powerpc64-linux BE and
Add a depth parameter to limit recursion of vec_slp_has_scalar_use.
Feng
---
.../gcc.target/aarch64/bb-slp-pr113091.c | 22 ++
gcc/tree-vect-slp.cc | 207 ++
2 files changed, 190 insertions(+), 39 deletions(-)
create mode 100644
On Wed, 10 Jan 2024, liuhongt wrote:
> To override -fcf-protection, -fcf-protection=none needs to be added
> and then with -fcf-protection=xxx.
I'm afraid I am struggling with the English of this, but need more time to
untangle and suggest an alternative.
For the time being I pushed the
On Linux/x86_64,
b5476e4c881b0d2bfbbfb84ee38d791123acf8e1 is the first bad commit
commit b5476e4c881b0d2bfbbfb84ee38d791123acf8e1
Author: Julian Brown
Date: Mon Nov 15 02:23:49 2021 -0800
OpenMP: lvalue parsing for map/to/from clauses (C)
caused
FAIL: gcc.dg/gomp/bad-array-section-c-3.c
Exception handling on nios2-linux-gnu with -fpic has been broken since
revision 790854ea7670f11c14d431c102a49181d2915965, "Use _dl_find_object
in _Unwind_Find_FDE". For whatever reason, this doesn't work on nios2.
Nios2 uses the GOT address as the base for DW_EH_PE_datarel
relocations in PIC;
On Thu, 2024-01-04 17:28:02 +0100, Georg-Johann Lay wrote:
> This fixes the avr-specific attributes io, io_low and address,
> that are all basically the same except that io and io_low imply
> assertions on allowed addressing modes.
> --- a/gcc/config/avr/avr.cc
> +++ b/gcc/config/avr/avr.cc
There are some xtheadvector instructions that differ from RVV1.0
apart from simply adding "th." prefix. For example, RVV1.0
load/store instructions will have SEW while xtheadvector not;
RVV1.0 will have "o" for indexed-ordered store instructions while
xtheadvecotr not; xtheadvector and RVV1.0 have
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 add an attribute "spec_restriction" to
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.
(class th_extract): Define new builtin bases.
This patch is to handle the differences in instruction generation
between Vector and XTheadVector. In this version, we only support
partial xtheadvector instructions that leverage directly from current
RVV1.0 with simple adding "th." prefix. For different name xtheadvector
instructions but share
This patch adds th. prefix to all XTheadVector instructions by
implementing new assembly output functions. We only check the
prefix is 'v', so that no extra attribute is needed.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_asm_output_opcode):
Add new function to add
This patch is to introduce basic XTheadVector support
(march string parsing and a test for __riscv_xtheadvector)
according to https://github.com/T-head-Semi/thead-extension-spec/
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse): Add new vendor
On Thu, Jan 11, 2024 at 12:06 AM H.J. Lu wrote:
>
> 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
On Fri, Jan 12, 2024 at 10:55 AM Jiang, Haochen wrote:
>
> > -Original Message-
> > From: Richard Biener
> > Sent: Thursday, January 11, 2024 4:19 PM
> > To: Liu, Hongtao
> > Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> > ubiz...@gmail.com; bur...@net-b.de; san...@codesourcery.com
>
This patch series presents gcc implementation of the XTheadVector
extension [1].
[1] https://github.com/T-head-Semi/thead-extension-spec/
For some vector patterns that cannot be avoided, we use
"!TARGET_XTHEADVECTOR" to disable them in order not to
generate instructions that xtheadvector does
Hi Alexandre,
on 2024/1/11 17:05, Alexandre Oliva wrote:
> On Jan 7, 2024, "Kewen.Lin" wrote:
>
>> As PR113100 shows, the unbiasing introduced by r14-6737 can
>> cause the scrubbing to overrun and screw some critical data
>> on stack like saved toc base consequently cause segfault on
>> Power.
Committed, thanks Juzhe.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, January 12, 2024 10:54 AM
To: Li, Pan2 ; gcc-patches
Cc: Li, Pan2 ; Wang, Yanzhang ;
kito.cheng
Subject: Re: [PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]
OK
> -Original Message-
> From: Richard Biener
> Sent: Thursday, January 11, 2024 4:19 PM
> To: Liu, Hongtao
> Cc: Jiang, Haochen ; gcc-patches@gcc.gnu.org;
> ubiz...@gmail.com; bur...@net-b.de; san...@codesourcery.com
> Subject: Re: [PATCH] i386: Add AVX10.1 related macros
>
> On Thu, Jan
OK
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2024-01-12 10:52
To: gcc-patches
CC: juzhe.zhong; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v1] RISC-V: Update the comments of riscv_v_ext_mode_p [NFC]
From: Pan Li
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_v_ext_mode_p): Update
From: Pan Li
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_v_ext_mode_p): Update the
comments of predicate func riscv_v_ext_mode_p.
Signed-off-by: Pan Li
---
gcc/config/riscv/riscv.cc | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
> -Original Message-
> From: Jiang, Haochen
> Sent: Friday, January 12, 2024 10:26 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] i386: Remove redundant move in vnni pattern
>
> Hi all,
>
> This patch removes all redundant set in vnni
Committed, thanks.
From: juzhe.zh...@rivai.ai
Date: 2024-01-12 09:38
To: wangfeng; gcc-patches
CC: kito.cheng; jeffreyalaw; wangfeng
Subject: Re: [PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t
Good catch. LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-12 09:35
To:
Hi all,
This patch removes all redundant set in vnni patterns.
Ok for trunk?
Thx,
Haochen
gcc/ChangeLog:
* config/i386/sse.md (sdot_prod): Remove redundant SET.
(usdot_prod): Ditto.
(sdot_prod): Ditto.
(udot_prod): Ditto.
---
gcc/config/i386/sse.md | 4
1
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
>> --- a/gcc/config/rs6000/rs6000-string.cc
>> +++ b/gcc/config/rs6000/rs6000-string.cc
>> @@ -140,7
1.Delete "dg-do run".
When binutils do not support vectorization, an error occurs during
the assembly phase that does not recognize vector instructions.
2.Added "-mlsx" option for vectorization on LoongArch.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/gen-vect-2.c: Remove the program's
gcc/testsuite/ChangeLog:
* gcc.dg/pr104992.c: Added additional "-mlsx" compilation options.
* gcc.dg/signbit-2.c: Dito.
* gcc.dg/tree-ssa/scev-16.c: Dito.
* gfortran.dg/graphite/vect-pr40979.f90: Dito.
* gfortran.dg/vect/fast-math-mgrid-resid.f: Dito.
---
Pushed to r14-7160 and r14-7161.
在 2024/1/11 下午7:36, Li Wei 写道:
We found that the current combine optimization pass in gcc cannot handle
the following redundant sign extension situations:
(insn 77 76 78 5 (set (reg:SI 143)
(plus:SI (subreg/s/u:SI (reg/v:DI 104 [ len ]) 0)
I found an issue bootstrapping GCC with -mcmodel=extreme in BOOT_CFLAGS:
we need a target hook to tell the generic code
UNSPEC_LA_PCREL_64_PART{1,2} are just a wrapper around symbols, or we'll
see millions lines of messages like
../../gcc/gcc/tree.h:4171:1: note: non-delegitimized UNSPEC
Good catch. LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-12 09:35
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH] RISC-V: Modify ABI-name length of vfloat16m8_t
The length of vfloat16m8_t ABI-name should be 17.
gcc/ChangeLog:
*
The length of vfloat16m8_t ABI-name should be 17.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.def (vfloat16m8_t):Modify ABI-name
length of vfloat16m8_t
---
gcc/config/riscv/riscv-vector-builtins.def | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, 11 Jan 2024, Jason Merrill wrote:
> Now in patch form!
It appears quite clear to me.
(At first I thought we need to escape the '&' in "[&] (tree arg)" as
"", but checking with validator.w3.org apparently not so in this
specific context.)
Gerald
Hi!
On 2024-01-11T15:22:07+0100, Arthur Cohen wrote:
> Sorry about this - two simple changes to Makefile.def we had missed
> during our first libgrust/ patchset
I don't think those were "missed" but rather "intentionally omitted"?
I'll have to have a more detailed look.
(..., and almost no
Hi.
This patch fixes the bug 113343.
I'm wondering if there's a better solution than using mpfr.
The only other solution I found is real_from_string, but that seems
overkill to convert the number to a string.
I could not find a better way to create a real value from a host
double.
If there's no
Verify that if-conversion succeeded through noce_try_store_flag_mask, as
per PR rtl-optimization/105314, tightening the test case and making it
explicit.
gcc/testsuite/
* gcc.target/riscv/pr105314.c: Scan the RTL "ce1" pass too.
---
gcc/testsuite/gcc.target/riscv/pr105314.c |
The optimization levels pr105314.c is iterated over are needlessly
overridden with "-O2", limiting the coverage of the test case to that
level, perhaps with additional options the original optimization level
has been supplied with. We could prevent the extra iterations other
than "-O2" from
Hi,
Here's a pair of further pr105314.c changes I came up with in the course
of recent RISC-V if-conversion work. It's not entirely clear to me what
our policy is for Stages 3 and 4 when it comes to testsuite cleanups or
improvements, but I think it's worth sharing these updates anyway.
OK
This fixes a regression introduced by the LWG 3809 change, so is needed
on trunk and gcc-13 and gcc-12.
Tested x86_64-linux and aarch64-linux.
-- >8 --
I implemented the resolution of LWG 3809 in r13-4364-ga64775a0edd469 but
more recently it was noted that the change causes possible truncation
On Thu, 11 Jan 2024 at 16:12, Patrick Palka wrote:
>
> On Thu, 11 Jan 2024, Jonathan Wakely wrote:
>
> > On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
> > >
> > > This avoids redundant moves when
On Thu, 2024-01-11 at 22:40 +0100, Guillaume Gomez wrote:
> Hi David,
>
> > The above looks correct, but the patch adds the entrypoint
> > descriptions
> > to topics/types.rst, which seems like the wrong place. The
> > function-
> > related ones should be in topics/functions.rst in the
On Fri, 12 Jan 2024 at 00:16, Jonathan Wakely wrote:
>
> I'd like to commit this to trunk for GCC 14. Please take a look.
Without looking at it in excruciating detail, it's pretty much along
the lines of what I have always envisioned
to be a powerful combination of concepts and if-constexpr. My
I'd like to commit this to trunk for GCC 14. Please take a look.
-- >8 --
This is the last part of PR libstdc++/108822 implementing P2255R2, which
makes it ill-formed to create a std::tuple that would bind a reference
to a temporary.
The dangling checks are implemented as deleted constructors
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
As discussed, our handling of corresponding object parameters needed to
handle the using-declaration case better. And I took the opportunity to
share code between the add_method and cand_parms_match uses.
This patch specifically doesn't
On Thu, Jan 11, 2024 at 04:33:10PM -0500, Jason Merrill wrote:
> Now in patch form!
>
> Any further comments?
It looks good to me, but it doesn't say if we want to put a space
after } and before () if we're invoking the lambda (I suppose we
want that space). As in
... = [&] (tree arg) { ...
Hi David,
> The above looks correct, but the patch adds the entrypoint descriptions
> to topics/types.rst, which seems like the wrong place. The function-
> related ones should be in topics/functions.rst in the "Functions"
> section and the lvalue/variable one in topics/expression.rst after the
Now in patch form!
Any further comments?
---
htdocs/codingconventions.html | 60 +++
1 file changed, 60 insertions(+)
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index f5a356a8..2bbf6670 100644
--- a/htdocs/codingconventions.html
And a follow-up to fix the obvious typo in the first word.
Pushed to trunk and gcc-13.
-- >8 --
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Fix spelling.
* doc/html/manual/api.html: Regenerate.
---
libstdc++-v3/doc/html/manual/api.html | 6 --
> 1. This patch set scalar_to_vec cost as 2 instead 1 since scalar move
>instruction is slightly more costly than normal rvv instructions (e.g.
> vadd.vv).
We can go with 2 or 3 (if needed) for now but should later
really incorporate reg-move costs in this IMHO. Just like e.g.
static const
Hello,
You are absolutely right, we can't throw all side-effects away.
Example:
```c++
auto __attribute__ ((noinline)) bar()
{
volatile int* b = (int *)0xff;
*b = 10;
volatile auto n = nullptr;
return n; // Problem (1)
}
int* foo_2()
{
volatile
Tested x86_64-linux. Does this look better now?
It also fixes PR113320 that got reported.
-- >8 --
I seem to have implemented this feature based on the P2918R0 revision,
not the final P2918R2 one that was approved for C++26. This commit fixes
it.
The runtime-format-string type should not have
Pushed to trunk. I'll backport to gcc-13 too.
-- >8 --
The API Evolution section of the manual should mention when the
libstdc++exp.a library was added.
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Document addition of
libstdc++exp.a.
* doc/html/*:
On Wed, 10 Jan 2024 at 23:31, Jonathan Wakely wrote:
>
> On Wed, 10 Jan 2024 at 21:28, Michael Levine (BLOOMBERG/ 120 PARK)
> wrote:
> >
> > From a67cfd07ce27a62f764b381268502acb68b6bad9 Mon Sep 17 00:00:00 2001
> > From: Michael Levine
> > Date: Wed, 10 Jan 2024 15:48:46 -0500
> > Subject:
This WIP patch adds preliminary and very lightly-tested support for
the "begin declare variant" and "end declare variant" directives of
OpenMP 5.1. I am posting it now for logistical reasons, rather than
because I believe it is immediately ready for review.
Some notes follow on the
On Linux/x86_64,
897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737 is the first bad commit
commit 897b95a12b7fe549ec2cb8ef3a3f0e4fbabf9737
Author: Richard Biener
Date: Thu Jan 11 12:02:43 2024 +0100
tree-optimization/113126 - vector extension compare optimization
caused
FAIL: gcc.dg/pr15784-1.c
Here's an updated patch to include the change from this PATCH:
https://gcc.gnu.org/pipermail/jit/2023q4/001763.html
On Thu, 2023-11-09 at 18:04 -0500, David Malcolm wrote:
> On Thu, 2023-11-09 at 17:27 -0500, Antoni Boucher wrote:
> > Hi.
> > This patch adds support for getting the CPU features
On Thu, 2024-01-11 at 01:00 +0100, Guillaume Gomez wrote:
> Hi David.
>
> Thanks for the review!
>
> > > +.. function:: void\
> > > + gcc_jit_lvalue_add_string_attribute
> > > (gcc_jit_lvalue *variable,
> > > + enum
> > >
On Thu, Jan 11, 2024 at 4:36 PM Kito Cheng wrote:
>
> LGTM
>
> On Thu, Jan 11, 2024 at 7:23 PM Jin Ma wrote:
> >
> > Due to the premature split optimizations for XTheadFMemIdx, GPR
> > is allocated when reload allocates registers, resulting in the
> > following insn.
LGTM.
This was most likely
Printing the raw symbol is useful in inline asm (e.g. in C++ to get the
mangled name). Similar constraints are available in other targets (e.g.
"S" for aarch64/riscv, "Cs" for m68k).
There isn't a good way for x86 yet, e.g. "i" doesn't work for
PIC/-mcmodel=large. This patch adds "Ws". Here
Tested x86_64-linux and aarch64-linux, with TBB 2020.3 only.
Reviews requested.
-- >8 --
This is a step towards implementing the C++23 change P2408R5, "Ranges
iterators as inputs to non-Ranges algorithms". C++20 random access
iterators which do not meet the C==17RandomAccessIterator
On Wed, 10 Jan 2024 at 18:28, François Dumont wrote:
>
> 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
I was finding it frustrating when returning from a function in GDB and
the return value was shown as $1 = { }, so this makes it
print std::true_type or std::false_type.
There are some contexts where the output isn't ideal, e.g. a type
derived from std::true_type will now show something like:
$2
On Tue, 9 Jan 2024 at 22:00, Jonathan Wakely wrote:
>
> Does anybody see any problem with making this change, so that we avoid
> the problem described in the PR?
Pushed to trunk. We should backport this too.
>
> -- >8 --
>
> As described in PR libstdc++/113258 there are old versions of tcmalloc
On Tue, Jan 09, 2024 at 04:35:22PM -0600, Peter Bergner wrote:
> ...and this is really ugly and hard to read/understand. Can't we use
> register variables to make it simpler? Something like the following
> which tests having both FPR and Altivec reg numbers assigned?
>
> ...
> void
> test
This is version 2 of the patch. The only difference is I made the test case
simpler to read.
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
On Thu, 11 Jan 2024, Jonathan Wakely wrote:
> On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > This avoids redundant moves when composing and partially applying range
> > adaptor objects.
> >
> > Note
On Thu, 11 Jan 2024 at 16:04, Marcus Hähnel wrote:
>
> Forwarding since I forgot to add gcc-patches in the original mail.
> Sorry for the noise.
And I forgot about this one, so thanks for the ping. I'll push it.
>
> -- >8 --
>
> Commit f4130a3eb545ab1aaf3ecb44f3d06b43e3751e04 changed the type
Forwarding since I forgot to add gcc-patches in the original mail.
Sorry for the noise.
-- >8 --
Commit f4130a3eb545ab1aaf3ecb44f3d06b43e3751e04 changed the type of
__expected_handler in libsupc++/unwind-cxx.h to be a
std::terminate_handler to avoid a deprecated warning. However, the
definition
Hi Richard,
As you've recommended, this issue has now been filed in bugzilla
as PR other/113336. As explained in the new PR, libatomic's testsuite
used to pass on armv6 (raspberry pi) in previous GCC releases, but
the code was incorrect/non-synchronous; this was reported as
PR target/107567 and
Tested x86_64-pc-linux-gnu, applying to trunk.
-- 8< --
These two lines have been getting XPASS since the test was added.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/explicit-obj-diagnostics7.C: Remove xfail.
---
gcc/testsuite/g++.dg/cpp23/explicit-obj-diagnostics7.C | 4 ++--
1 file
LGTM
On Thu, Jan 11, 2024 at 7:23 PM Jin Ma wrote:
>
> Due to the premature split optimizations for XTheadFMemIdx, GPR
> is allocated when reload allocates registers, resulting in the
> following insn.
>
> (insn 66 21 64 5 (set (reg:DF 14 a4 [orig:136 ] [136])
> (mem:DF (plus:SI
This adds a new @subsubsection "AVR Internal Options" in
"AVR Options".
"Internal" options are options that are not supposed to be
set by the user, but are solely required to ship information
from device-specs to the compiler proper.
(Without device-specs, non of these options would be needed
On Thu, 11 Jan 2024 at 00:26, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
OK. Nice to see explicit object functions landing in the library so soon!
>
> -- >8 --
>
> This simplifies the operator() of the _Pipe and _Partial range adaptor
> closure objects
On Wed, 10 Jan 2024 at 21:40, Patrick Palka wrote:
>
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> This avoids redundant moves when composing and partially applying range
> adaptor objects.
>
> Note that the new constraints on _Partial's constructor templates are
On 1/11/24 14:58, Richard Biener wrote:
> The following adds guards avoiding code generation to
> expand_perm_as_a_vlbr_vstbr_candidate when d.testing_p.
>
> Built and tested on the testcase in the PR.
>
> OK to push as obvious? Otherwise please pick up, test and push.
Ok to commit now. Thanks
On 11/01/2024 14:43, Szabolcs Nagy wrote:
> The 12/07/2023 13:13, Richard Earnshaw wrote:
>> On 03/11/2023 15:36, Szabolcs Nagy wrote:
>>> * config/aarch64/aarch64.cc (aarch_handle_no_branch_protection): Copy.
>>> (aarch_handle_standard_branch_protection): Copy.
>>>
The 12/07/2023 13:13, Richard Earnshaw wrote:
> On 03/11/2023 15:36, Szabolcs Nagy wrote:
> > * config/aarch64/aarch64.cc (aarch_handle_no_branch_protection): Copy.
> > (aarch_handle_standard_branch_protection): Copy.
> > (aarch_handle_pac_ret_protection): Copy.
> >
This patch series presents the comprehensive implementation of the MEM
extension for CORE-V.
Tested with riscv-gnu-toolchain on binutils, ld, gas and gcc testsuites to
ensure its correctness and compatibility with the existing codebase.
However, your input, reviews, and suggestions are invaluable
XCVmem adds more loads and stores. To prevent non-XCVmem loads and
stores from generating illegal XCVmem specific operands, constraint
'm' was redefined. 'm' does not accept POST_MODIFY or reg + reg
addresses.
Spec:
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.
> >>
> >> ChangeLog:
> >>
> >> *
The branch-protection types are target specific, not the same on arm
and aarch64. This currently affects pac-ret+b-key, but there will be
a new type on aarch64 that is not relevant for arm.
After the move, change aarch_ identifiers to aarch64_ or arm_ as
appropriate.
Refactor
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112918
The patch was successfully bootstrapped and tested on x86_64, aarch64,
ppc64le
commit 902a5931a1fbb04c65b48ca8b0f3827f6ff3b43e
Author: Vladimir N. Makarov
Date: Thu Jan 11 08:46:26 2024 -0500
[PR112918][LRA]:
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.
ChangeLog:
* Makefile.def: Add a dependency to libgrust for all-gcc.
* Makefile.in: Regenerate
On Thu, 11 Jan 2024, Arthur Cohen wrote:
> From: Pierre-Emmanuel Patry
>
> Fix the missing dependency between the gcc and libgrust.
>
> ChangeLog:
>
> * Makefile.def: Add a dependency to libgrust for all-gcc.
> * Makefile.in: Regenerate the file.
>
> Signed-off-by:
From: Pierre-Emmanuel Patry
Fix the missing dependency between the gcc and libgrust.
ChangeLog:
* Makefile.def: Add a dependency to libgrust for all-gcc.
* Makefile.in: Regenerate the file.
Signed-off-by: Pierre-Emmanuel Patry
---
Makefile.def | 1 +
Makefile.in | 10
From: Pierre-Emmanuel Patry
The bootstrap was failing due to a missing target which was not
available during the bootstrap.
ChangeLog:
* Makefile.def: Add libgrust target to bootstrap.
* Makefile.in: Regenerate.
Signed-off-by: Pierre-Emmanuel Patry
---
Makefile.def | 2 +-
Hi everyone,
Sorry about this - two simple changes to Makefile.def we had missed
during our first libgrust/ patchset, plus the associated regen of
Makefile.in in each commit.
Let me know if I should squash them together. I'll follow them up
with our entire patchset.
Best,
Arthur
On Thu, 11 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> This removes -save-temps from the tests I've introduced to fix the LTO
> mismatches.
>
> Bootstrapped Regtested on aarch64-none-linux-gnu, x86_64-pc-linux-gnu
> and no issue
>
> Ok for master?
OK.
Richard.
> Thanks,
> Tamar
>
>
On Thu, 11 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> Instead of searching for where to move stores to, they should always be in
> exit belonging to the latch. We can only ever delay stores and even if we
> pick a different exit than the latch one as the main one, effects still
> happen in
The following makes sure the resulting boolean type is the same
when eliding a float extension.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/113126
* match.pd ((double)float CMP (double)float -> float CMP float):
Make sure the boolean
Vectorization of bit-precision inductions isn't implemented but we
don't check this, instead we ICE during transform.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
PR tree-optimization/112505
* tree-vect-loop.cc (vectorizable_induction): Reject
Is the patch with !TARGET_XTHEADVECTOR for sext/zext
patterns removed OK to commit?
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642657.html
--
发件人：juzhe.zh...@rivai.ai
发送时间：2024年1月11日(星期四) 18:56
收件人："cooper.joshua";
The following adds guards avoiding code generation to
expand_perm_as_a_vlbr_vstbr_candidate when d.testing_p.
Built and tested on the testcase in the PR.
OK to push as obvious? Otherwise please pick up, test and push.
Thanks,
Richard.
PR target/112280
* config/s390/s390.cc
On Wed, 13 Sept 2023 at 21:50, Jonathan Wakely wrote:
>
> On Wed, 13 Sept 2023 at 21:47, François Dumont wrote:
> >
> > It's working and what's I've committed.
>
> Nice, thanks!
>
>
> >
> > Thanks
> >
> > On 12/09/2023 19:04, Jonathan Wakely wrote:
> > > On Tue, 12 Sept 2023 at 17:47, Jonathan
1 - 100 of 197 matches
Mail list logo
