On 2024/01/08 22:32 UTC+8, Kyrylo Tkachov wrote:
-Original Message-
From: Chung-Ju Wu
Sent: Monday, January 8, 2024 6:17 AM
To: gcc-patches ; Kyrylo Tkachov
; Richard Earnshaw
Cc: jason...@anshingtek.com.tw
Subject: [PATCH 2/2] arm: Add cortex-m52 doc
Hi,
This is the patch to add
On 2024/01/08 22:31 UTC+8, Kyrylo Tkachov wrote:
Hi jasonwucj,
-Original Message-
From: Chung-Ju Wu
Sent: Monday, January 8, 2024 6:16 AM
To: gcc-patches ; Kyrylo Tkachov
; Richard Earnshaw
Cc: jason...@anshingtek.com.tw
Subject: [PATCH 1/2] arm: Add cortex-m52 core
Hi,
Recently,
The test case pr30957-1.c first comes from this commit about 19 years ago which
expect the -1.0 for testing.
https://github.com/gcc-mirror/gcc/commit/290358f770d21d9204ea621f839ee8fba606a275
Then the below commit changes from -1.0 to +1.0 for this test file only,
because of the instantiates cop
Hi,
This patch adds missing description for inline asm behavior and related
compiler switch for APX.
Ok for gcc-wwwdocs?
---
htdocs/gcc-14/changes.html | 6 ++
1 file changed, 6 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index e3a68998..73a90d30 1006
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 for
-mapx-inline-asm-use-gpr32.
---
gcc/config/i386/i386.opt |
Hi all,
In invoke.texi, -mevex512 is missing. This patch adds that.
Ok for trunk?
Thx,
Haochen
gcc/ChangeLog:
* doc/invoke.texi: Add -mevex512.
---
gcc/doc/invoke.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 6
Pushed to r14-7022.
在 2024/1/5 下午3:38, Jiahao Xu 写道:
This patch implenments more vec_init optabs that can handle two LSX vectors
producing a LASX
vector by concatenating them. When an lsx vector is concatenated with an LSX
const_vector of
zeroes, the vec_concatz pattern can be used effectively
It has been updated.
[PATCH v5] RISC-V: Handle differences between XTheadvector and Vector (gnu.org)
--
发件人：钟居哲
发送时间：2024年1月9日(星期二) 07:08
收件人："cooper.joshua";
"gcc-patches"
抄 送："jim.wilson.gcc"; palmer;
andrew; "philipp.tomsich"
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 sa
We have supported segment load/store intrinsics.
Committed as it is obvious.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-functions.def (vleff): Move
comments.
(vundefined): Ditto.
---
gcc/config/riscv/riscv-vector-builtins-functions.def | 4 ++--
1 file changed, 2 inse
For the vsetvl issue, we have discussed last week.
Maybe riscv_asm_output function cannot return
instructions like riscv_output_move.
The briefest approach may be to add some logic in
the vsetvl patterns. Only 3 patterns need to be modified
and that will not be too invasive.
--
We have supported segment load/store intrinsics.
Committed as it is obvious.
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-functions.def (vleff): Move
comments to real place.
(vcreate): Ditto.
---
gcc/config/riscv/riscv-vector-builtins-functions.def | 4 +---
1 file chan
Committed, thanks Juzhe.
发件人： 钟居哲
发送时间： 2024-01-09 07:02
收件人： wangfeng; gcc-patches
抄送： kito.cheng; Jeff Law; wangfeng
主题： Re: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function.
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffrey
Committed, thanks Juzhe.
发件人： 钟居哲
发送时间： 2024-01-09 07:02
收件人： wangfeng; gcc-patches
抄送： kito.cheng; Jeff Law; wangfeng
主题： Re: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases.
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffrey
Yes. It does sufficient. Send a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642216.html
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2024-01-09 00:45
To: 钟居哲; gcc-patches
CC: rdapp.gcc; kito.cheng; kito.cheng; Jeff Law
Subject: Re: [PATCH] RISC-V: Teach liveness computation
As Robin suggested, remove gimple_uid check which is sufficient for our need.
Tested on both RV32/RV64 no regression, ok for trunk ?
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc (loop_invariant_op_p): Fix loop
invariant check.
---
gcc/config/riscv/riscv-vector-costs.cc | 2 +-
Thanks Richard B for comments.
> We don't really expect targets to do this. The small testcase above
> is somewhat ill-formed with -fno-signed-zeros. Note there's no
> -0.0 in pr30957-1.c so why does that one fail for you? Does
> the -fvariable-expansion-in-unroller code maybe not trigger for
>
> -Original Message-
> From: Jiang, Haochen
> Sent: Monday, January 8, 2024 4:41 PM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com
> Subject: [PATCH] i386: Fix recent testcase fail
>
> After commit 01f4251b8775c832a92d55e2df57c9ac72eaceef, early break
> vectorizat
Can I please ping this one again? It's 3 lines or so to fix the PR. Thanks!
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638692.html
On Tue, Dec 19, 2023 at 6:20 PM Lewis Hyatt wrote:
>
> Hello-
>
> May I please ping this one? Thanks...
> https://gcc.gnu.org/pipermail/gcc-patches/2023-
From: trcrsired
In the case of x86_64-w64-mingw32 gcc with multilibs, a conflict arises as both
64-bit and 32-bit DLLs attempt to copy into the bin/ directory. This
discrepancy results in coverage issues.
This commit aligns the Canadian build process for gcc targeting Windows with
cross build
This patch looks ok from myside.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2024-01-03 14:08
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 v4] RISC-V: Adds the pre
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v8 2/2] RISC-V: Add crypto vector api-testing cases.
Patch v8: Resubmit after fix the rtl-checking issue. Passed all the riscv
regression test.
LGTM.
juzhe.zh...@rivai.ai
From: Feng Wang
Date: 2024-01-08 17:12
To: gcc-patches
CC: kito.cheng; jeffreyalaw; juzhe.zhong; Feng Wang
Subject: [PATCH v7 1/2] RISC-V: Add crypto vector builtin function.
Patch v7:Resubmit after fix trl-checking issue. Passed all the riscv regression
test.
Patch
On Mon, 8 Jan 2024 at 01:19, Jonathan Wakely wrote:
>
> I decided to push this now, not wait for the morning.
>
> This is mostly the same as V2, but adds to the contrib/unicode/README as
> suggested by Lewis, and avoids a trailing whitespace character in the
> generated header.
>
> Tested x86_64-l
On 1/8/24 04:21, Iain Sandoe wrote:
On 6 Jan 2024, at 22:30, Nathan Sidwell wrote:
Richard Smith & I discussed whether we should use the module interface's
capability of giving vague linkage entities a strong location. I didn't want to go
messing with that, 'cos it was changing yet more stuff
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
xfail dg-final "Sunk statements: 5" on hppa*64*-*-*
2024-01-08 John David Anglin
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ssa-sink-18.c: xfail dg-final "Sunk statements: 5"
on hppa*64*-*-*.
diff --git a/gcc/test
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
Skip gfortran.dg/dec_math.f90 on hppa
hppa*-*-hpux* doesn't have any long double trig functions.
2024-01-08 John David Anglin
gcc/testsuite/ChangeLog:
* gfortran.dg/dec_math.f90: Skip on hppa*-*-hpux*.
diff --git a/gcc/t
On Linux/x86_64,
b3cc5a1efead520bc977b4ba51f1328d01b3e516 is the first bad commit
commit b3cc5a1efead520bc977b4ba51f1328d01b3e516
Author: Richard Biener
Date: Fri Dec 15 10:32:29 2023 +0100
tree-optimization/113026 - avoid vector epilog in more cases
caused
FAIL: gcc.c-torture/execute/95
On Mon, 8 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> In C you can have loops without a condition, the original version of the patch
> was rejecting the use of #pragma GCC novector, however during review it was
> changed to not due this with the reason that we didn't want to give a compile
> e
Hi Paul,
your patch looks already very impressive!
Regarding the patch as is, I am still trying to grok it, even with your
explanations at hand...
While the testcase works as advertised, I noticed that it exhibits a
runtime memleak that occurs for (likely) each case where the associate
target i
On 1/8/24 12:11, Richard Sandiford wrote:
Thanks. That led me to the following, which seems a bit more plausible
than my first attempt. I'll test it on aarch64-linux-gnu and
x86_64-linux-gnu. Does it look OK?
It looks reasonable to me. I'm going to send another failure (ICE in
finalize_
Tested on hppa64-hp-hpux11.11. Committed to trunk.
Dave
---
hppa: Fix bind_c_coms.f90 and bind_c_vars.f90 tests on hppa
Commit 6271dd98 changed the default from -fcommon to -fno-common.
This silently changed the alignment of uninitialized BSS data on
hppa where the alignment of common data must
On Mon, Jan 8, 2024 at 5:57 PM Andrew Pinski wrote:
>
> On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote:
> >
> > Instead of converting XOR or PLUS of two values, ANDed with two constants
> > that
> > have no bits in common, to IOR expression, convert IOR or XOR of said two
> > ANDed values to P
Hi!
On 2024-01-08T15:30:06+0100, Tobias Burnus wrote:
> Andrew Stubbs wrote:
>> I know there will be things that need fixing for
>> both experimental architectures.
>
> Indeed. [...]
..., like, making it even build? ;-P
>> P.S. Apologies, but I think my commits today conflict a little; you
>>
Jeff Law writes:
> On 1/8/24 09:59, Richard Sandiford wrote:
>> This is a bit of a hopeful stab, but is the problem that recog_data still
>> had the previous contents of insn 3674, and so extract_insn_cached wrongly
>> thought that it doesn't need to do anything? If so, does something like:
>>
>
diff --git a/htdocs/steering.html b/htdocs/steering.html
index 95d6a4a8..6039a503 100644
--- a/htdocs/steering.html
+++ b/htdocs/steering.html
@@ -36,7 +36,7 @@ place to reach them is the gcc mailing
list.
Jason Merrill (Red Hat)
David Miller (Red Hat)
Toon Moene (Koninklijk Nederlands Meteorol
* MAINTAINERS: Update my email address.
diff --git a/MAINTAINERS b/MAINTAINERS
index fe5d95ae970..882694cc47d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -34,7 +34,7 @@ Jeff Law
Michael Meissner
Jason Merrill
The attached patch does a tiny updated to the OpenMP features (AMD GCN
now also has an optimized memcpy_rect not only nvptx), but the main
change is some shifting around to make it more consistent and better
readable.
I intend to commit this relatively soon; like always, comments and
suggesti
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/13/12?
-- >8 --
The get_target_expr call added in r12-7069-g119cea98f66476 causes us
for the below testcase to call build_vec_delete in a template context,
which builds a templated destructor call and checks expr_noexc
Thanks! Committed.
David Faust writes:
> Hi Cupertino,
>
> On 1/8/24 02:55, Cupertino Miranda wrote:
>> Hi everyone,
>>
>> This patch adds a comment to the BTF strings regarding their position
>> within the section. This is useful for assembly inspection purposes.
>>
>> Regards,
>> Cupertino
>>
Thanks! Committed.
David Faust writes:
> Hi Cupetino,
>
> On 1/8/24 03:05, Cupertino Miranda wrote:
>> Hi everyone,
>>
>> This patch address the problem reported in:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
>>
>> Looking forward to your review.
>
> LGTM, thanks. Please apply.
>
>>
On Thu, 21 Dec 2023 17:05:18 +0100
Tobias Burnus wrote:
> I think it makes sense to split this patch into two parts:
>
> * The libgomp/plugin/plugin-gcn.c – which is independent and would
> already used by omp_memcpy_rect.
I will commit this version in a moment. I needed to add the
DLSYM_OPT_FN
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/acle/main/acle.html#arm_bf16h).
gcc/ChangeLog:
Hi Cupetino,
On 1/8/24 03:05, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch address the problem reported in:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
>
> Looking forward to your review.
LGTM, thanks. Please apply.
>
> Cheers,
> Cupertino
>
>
> This patch fix a problem
On 1/8/24 09:59, Richard Sandiford wrote:
This is a bit of a hopeful stab, but is the problem that recog_data still
had the previous contents of insn 3674, and so extract_insn_cached wrongly
thought that it doesn't need to do anything? If so, does something like:
diff --git a/gcc/recog.cc
Hi Cupertino,
On 1/8/24 02:55, Cupertino Miranda wrote:
> Hi everyone,
>
> This patch adds a comment to the BTF strings regarding their position
> within the section. This is useful for assembly inspection purposes.
>
> Regards,
> Cupertino
>
> When using -dA, this function was only printing as
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
> On Sat, Jan 06, 2024 at 05:32:37PM -0500, Nathan Sidwell wrote:
> > I;m not sure about this, there was clearly a reason I did it the way it is,
> > but perhaps that reasoning became obsolete -- something about an existing
> > declaration and reading in
On 1/8/24 09:57, Andrew Pinski wrote:
On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote:
Instead of converting XOR or PLUS of two values, ANDed with two constants that
have no bits in common, to IOR expression, convert IOR or XOR of said two
ANDed values to PLUS expression.
I think this on
Jeff Law writes:
> On 1/8/24 04:52, Richard Sandiford wrote:
>> Jeff Law writes:
>>> The other issue that's been in the back of my mind is costing. But I
>>> think the model here is combine without regards to cost.
>>
>> No, it does take costing into account. For size, it's the usual
>> "sum u
On Mon, 8 Jan 2024 at 16:25, Hans-Peter Nilsson wrote:
>
> (Sorry, never a bringer of good news...)
Regarding this bit ... even if you're reporting something I've broken,
I like to see it as an incremental step towards better portability, so
it's always good news ;-)
On Mon, Jan 8, 2024 at 6:44 AM Uros Bizjak wrote:
>
> Instead of converting XOR or PLUS of two values, ANDed with two constants that
> have no bits in common, to IOR expression, convert IOR or XOR of said two
> ANDed values to PLUS expression.
I think this only helps targets which have leal like
On Mon, 8 Jan 2024 at 16:28, Hans-Peter Nilsson wrote:
>
> > From: Hans-Peter Nilsson
> > Date: Mon, 8 Jan 2024 17:24:35 +0100
>
> > For some reason, this (r14-6990-g74a0dab18292be) breaks a
> > build of (newlib targets) at least cris-elf and arm-eabi:
>
> ...aaand, just now fixed in r14-7007-geb8
> > + if (is_gimple_min_invariant (op))
> > + return true;
> > + if (SSA_NAME_IS_DEFAULT_DEF (op)
> > + || !flow_bb_inside_loop_p (loop, gimple_bb (SSA_NAME_DEF_STMT
> (op
> > + return true;
> > + return gimple_uid (SSA_NAME_DEF_STMT (op)) & 1;
> > +}
Hi Richard,
>> Benchmarking showed that LSE and LSE2 RMW atomics have similar performance
>> once
>> the atomic is acquire, release or both. Given there is already a significant
>> overhead due
>> to the function call, PLT indirection and argument setup, it doesn't make
>> sense to add
>> extra
> From: Hans-Peter Nilsson
> Date: Mon, 8 Jan 2024 17:24:35 +0100
> For some reason, this (r14-6990-g74a0dab18292be) breaks a
> build of (newlib targets) at least cris-elf and arm-eabi:
...aaand, just now fixed in r14-7007-geb846114ed7c49.
(Thanks!)
brgds, H-P
(Sorry, never a bringer of good news...)
> From: Jonathan Wakely
> Date: Mon, 8 Jan 2024 01:15:50 +
> Tested x86_64-linux and aarch64-linux. Pushed to trunk.
>
> -- >8 --
>
> This change ensures that char and wchar_t arguments are formatted
> consistently when using integer presentation t
On 1/8/24 04:52, Richard Sandiford wrote:
Jeff Law writes:
The other issue that's been in the back of my mind is costing. But I
think the model here is combine without regards to cost.
No, it does take costing into account. For size, it's the usual
"sum up the before and after insn costs
Tested x86_64-linux, pushed to trunk.
-- >8 --
The name __null_sentinel is defined as a macro by newlib, so we can't
use it as an identifier. That variable is not actually used by
libstdc++, it was added because P2728R6 proposes std::uc::null_sentinel.
Since we don't need it and it breaks bootstr
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 unresolved reference to the function
libat_test_a
Jeff Law writes:
>>> +
>>> +/* Initialization of the ext-dce pass. Primarily this means
>>> + setting up the various bitmaps we utilize. */
>>> +
>>> +static void
>>> +ext_dce_init (void)
>>> +{
>>> +
>>
>> Nit: excess blank line.
> Various nits have been fixed. I think those are all mine.
Victor Do Nascimento writes:
> On 1/5/24 11:10, Richard Sandiford wrote:
>> Victor Do Nascimento writes:
>>> The introduction of further architectural-feature dependent ifuncs
>>> for AArch64 makes hard-coding ifunc `_i' suffixes to functions
>>> cumbersome to work with. It is awkward to remembe
On Mon, 8 Jan 2024, Nathaniel Shead wrote:
> On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
> > On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The TYPE_DECL_SUPPRESS_DEBUG and
Instead of converting XOR or PLUS of two values, ANDed with two constants that
have no bits in common, to IOR expression, convert IOR or XOR of said two
ANDed values to PLUS expression.
If we consider the following testcase:
--cut here--
unsigned int foo (unsigned int a, unsigned int b)
{
unsig
Wilco Dijkstra writes:
> Hi,
>
>>> Is there no benefit to using SWPPL for RELEASE here? Similarly for the
>>> others.
>>
>> We started off implementing all possible memory orderings available.
>> Wilco saw value in merging less restricted orderings into more
>> restricted ones - mainly to reduce
> -Original Message-
> From: Chung-Ju Wu
> Sent: Monday, January 8, 2024 6:17 AM
> To: gcc-patches ; Kyrylo Tkachov
> ; Richard Earnshaw
> Cc: jason...@anshingtek.com.tw
> Subject: [PATCH 2/2] arm: Add cortex-m52 doc
>
> Hi,
>
> This is the patch to add cortex-m52 in the Arm-related o
Hi jasonwucj,
> -Original Message-
> From: Chung-Ju Wu
> Sent: Monday, January 8, 2024 6:16 AM
> To: gcc-patches ; Kyrylo Tkachov
> ; Richard Earnshaw
> Cc: jason...@anshingtek.com.tw
> Subject: [PATCH 1/2] arm: Add cortex-m52 core
>
> Hi,
>
> Recently, Arm announced the Cortex-M52, de
Hi Andrew,
Andrew Stubbs wrote:
OK for mainline ?
This looks fine to me. I know there will be things that need fixing for
both experimental architectures.
Indeed. I tried to be a bit more verbose also to avoid too high
expectations by occasional gcc-patches@ readers.
P.S. Apologies, b
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 12:48 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: check if target can do extract first for
> early breaks
> [PR113199]
>
> On Tue, 2 Jan 2
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 12:38 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: maintain LCSSA form when peeled vector
> iterations have virtual operands
>
> On Fri, 29
On Mon, Jan 8, 2024 at 10:56 AM Richard Biener wrote:
>
> It was noticed that -mmovbe doesn't use movbe for __builtin_bswap{32,64}
> when not optimizing. The follownig adjusts the documentation to
> say it will be used for optimizing and applies to all byte swaps,
> not just those carried out via
---
gcc/doc/invoke.texi | 16
1 file changed, 16 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 68d1f364ac0..81ee7ac758a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -30037,6 +30037,22 @@ Generate code for given RISC-V ISA (e.g.@:
@sa
We has relaxed -march string, it no longer require canonical order, so
we need update some of those testcase.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-23.c: Update test.
* gcc.target/riscv/arch-27.c: Ditto.
* gcc.target/riscv/arch-28.c: Ditto.
* gcc.target/
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_std_ext): Remove.
(riscv_subset_list::parse_multiletter_ext): Remove.
* config/riscv/riscv-subset.h
(riscv_subset_list::parse_std_ext): Remove.
(riscv_subset_list::parse_m
-march was require canonical order before, however it's not easy for
most user when we have so many extension, so this patch is relax the
constraint, -march accept the ISA string in any order, it only has few
requirement:
1. Must start with rv[32|64][e|i|g].
2. Multi-letter and single letter exten
Minor refactor, preparation for further change.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc
(riscv_subset_list::parse_base_ext): New.
(riscv_subset_list::parse): Extract part of logic into
riscv_subset_list::parse_base_ext.
* config/riscv/riscv-sub
Do you know how to build a ISA string with following extension?
- g
- c
- zba
- zbs
- svnapot
- zve64d
- zvl128b
Don't trial and error with your gcc and don't read RISC-V ISA spec! OK, I
believe it's impossible for most people, even I work for RISC-V so many years,
I remember most of the rule
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 12:07 PM
> To: Tamar Christina
> Cc: gcc-patches@gcc.gnu.org; nd ; j...@ventanamicro.com
> Subject: Re: [PATCH]middle-end: rejects loops with nonlinear inductions and
> early
> breaks [PR113163]
>
> On Fri, 29 D
> -Original Message-
> From: Richard Biener
> Sent: Monday, January 8, 2024 11:29 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Tamar Christina
> Subject: [PATCH] tree-optimization/113026 - avoid vector epilog in more cases
>
> The following avoids creating a niter peeling epilog more consisten
On Mon, Dec 11, 2023 at 03:13:03PM +, Richard Ball wrote:
> ACLE has added intrinsics to bridge between SVE and Neon.
>
> The NEON_SVE Bridge adds intrinsics that allow conversions between NEON and
> SVE vectors.
>
> This patch adds support to GCC for the following 3 intrinsics:
> svset_neonq
Spec:
github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
Contributors:
Mary Bennett
Nandni Jamnadas
Pietra Ferreira
Charlie Keaney
Jessica Mills
Craig Blackmore
Simon Cook
Jeremy Bennett
Helene Chelin
gcc/ChangeLog:
* common/config/
Thank you for reviewing my patches and merging XCVelw.
This patch series presents the comprehensive implementation of the BI
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.
Howeve
Hi,
>> Is there no benefit to using SWPPL for RELEASE here? Similarly for the
>> others.
>
> We started off implementing all possible memory orderings available.
> Wilco saw value in merging less restricted orderings into more
> restricted ones - mainly to reduce codesize in less frequently use
On Thu, 4 Jan 2024, Jan Hubicka wrote:
> Hi,
> this patch adds new option -falign-all-functions which works like
> -falign-functions, but applies to all functions including those in cold
> regions. As discussed in the PR log, this is needed for atomically
> patching function entries in the kernel
Hi All,
In C you can have loops without a condition, the original version of the patch
was rejecting the use of #pragma GCC novector, however during review it was
changed to not due this with the reason that we didn't want to give a compile
error with such cases.
However because annotations seem
On Thu, 4 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The PHI argument expansion of INTEGER_CSTs where bitint_min_cst_precision
> returns significantly smaller precision than the PHI result precision is
> optimized by loading the much smaller constant (if any) from memory and
> then either setting t
On Thu, 4 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> _BitInt lowering for .{ADD,SUB,MUL}_OVERFLOW calls which have both
> REALPART_EXPR and IMAGPART_EXPR used and have a cast from the IMAGPART_EXPR
> to a boolean or normal integral type lowers them at the point of
> the REALPART_EXPR statement (whi
On Tue, 2 Jan 2024, Tamar Christina wrote:
> Hi All,
>
> I was generating the vector reverse mask without checking if the target
> actually supported such an operation.
>
> It also seems like more targets implement VEC_EXTRACT than permute on mask
> registers.
>
> So this adds a check for IFN_V
On Fri, 29 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> This patch fixes several interconnected issues.
>
> 1. When picking an exit we wanted to check for niter_desc.may_be_zero not
> true.
>i.e. we want to pick an exit which we know will iterate at least once.
>However niter_desc.may
On 1/5/24 11:10, Richard Sandiford wrote:
Victor Do Nascimento writes:
The introduction of further architectural-feature dependent ifuncs
for AArch64 makes hard-coding ifunc `_i' suffixes to functions
cumbersome to work with. It is awkward to remember which ifunc maps
onto which arch featur
On Fri, 29 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> Only trying to update certain dominators doesn't seem to work very well
> because as the loop gets versioned, peeled, or skip_vector then we end up with
> very complicated control flow. This means that the final merge blocks for the
> loo
On Fri, 29 Dec 2023, Tamar Christina wrote:
> Hi All,
>
> We can't support nonlinear inductions other than neg when vectorizing
> early breaks and iteration count is known.
>
> For early break we currently require a peeled epilog but in these cases
> we can't compute the remaining values.
>
> B
On Mon, Jan 8, 2024 at 10:58 AM Nathaniel Shead
wrote:
>
> On Thu, Jan 04, 2024 at 03:39:15PM -0500, Patrick Palka wrote:
> > On Sun, 3 Dec 2023, Nathaniel Shead wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
> > >
> > > -- >8 --
> > >
> > > The TYPE_DECL_SUPPRES
Jeff Law writes:
> The other issue that's been in the back of my mind is costing. But I
> think the model here is combine without regards to cost.
No, it does take costing into account. For size, it's the usual
"sum up the before and after insn costs and see which one is lower".
For speed, the
On Mon, Jan 8, 2024 at 3:35 AM Kewen.Lin wrote:
>
> Hi,
>
> 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.
>
> By checking PR112917, IMHO we should keep
On 2024-01-08 10:20, Eric Botcazou wrote:
pr88077 fails on SPARC since char HeaderStr[1] in pr88077_1.c and
long HeaderStr in pr88077_0.c differs in alignment.
warning: alignment 4 of normal symbol `HeaderStr' in c_lto_pr88077_0.o is
smaller than 8 used by the common definition in c_lto_pr88077_
On Sat, 6 Jan 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs during regimplificatgion since the addition of
> (convert (eqne zero_one_valued_p@0 INTEGER_CST@1))
> simplification. That simplification is novel in the sense that in
> gimplify_expr it can turn an expression (compar
The following avoids creating a niter peeling epilog more consistently,
matching what peeling later uses for the skip_vector condition, in
particular when versioning is required which then also ensures the
vector loop is entered unless the epilog is vectorized. This should
ideally match LOOP_VINFO
Hi everyone,
This patch adds a comment to the BTF strings regarding their position
within the section. This is useful for assembly inspection purposes.
Regards,
Cupertino
When using -dA, this function was only printing as comment btf_string or
btf_aux_string.
This patch changes the comment to al
Hi everyone,
This patch address the problem reported in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
Looking forward to your review.
Cheers,
Cupertino
This patch fix a problem with kernel_helper attribute BTF information,
which incorrectly generates BTF_KIND_FUNC entry.
This BTF entry
On Tue, Jan 2, 2024 at 2:37 PM wrote:
>
> From: Pan Li
>
> According to the sematics of no-signed-zeros option, the backend
> like RISC-V should treat the minus zero -0.0f as plus zero 0.0f.
>
> Consider below example with option -fno-signed-zeros.
>
> void
> test (float *a)
> {
> *a = -0.0;
>
1 - 100 of 119 matches
Mail list logo
