Hi Jeff:
Could you take a look for this? RISC-V part is ok to me.
Thanks :)
Feng Wang 於 2023年9月12日 週二 17:18 寫道：
> New patch add some comments and update docs for this new usage.
> ---
> Accoring to Kito's advice, using "MASK(name) Var(other_flag_name)"
> to generate MASK and TARGET MACRO autom
Committed to trunk, thanks Feng :)
On Sat, Sep 30, 2023 at 3:34 AM Jeff Law wrote:
>
>
>
> On 9/12/23 03:18, Feng Wang wrote:
> > New patch add some comments and update docs for this new usage.
> > ---
> > Accoring to Kito's advice, using "MASK(name) Var(other_flag_name)"
> > to generate MASK and
Hi Gerald:
Thanks for reporting this issue, I just realized multidimensional
arrays are gawk extensions, could you try the attached patch to see if
it can resolve the issue?
On Mon, Oct 2, 2023 at 4:56 AM Gerald Pfeifer wrote:
>
> On Sun, 1 Oct 2023, Kito Cheng wrote:
> > Commit
Multidimensional arrary is gawk extension, and we accidentally
introduced that in recent commit[1].
[1]
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e4a4b8e983bac865eb435b11798e38d633b98942
gcc/ChangeLog:
* opt-read.awk: Drop multidimensional arrays.
* opth-gen.awk: Ditto.
---
> > On Tue, Sep 26, 2023 at 10:59 AM Patrick O'Neill
> > wrote:
> >> stdint.h can be replaced with stdint-gcc.h to resolve some missing
> >> system headers in non-multilib installations.
> >>
> >> Tested using glibc rv32gcv and rv64gcv on r14-4258-gc9837443075.
> >>
> >> gcc/ChangeLog:
> >>
> >>
Just one nit and one more comment for doc:
Could you add some doc something like that? mostly I grab from other
target, so you can just included in the patch.
diff --git a/gcc/doc/install.texi b/gcc/doc/install.texi
index 31f2234640f..39396668da2 100644
--- a/gcc/doc/install.texi
+++ b/gcc/doc/in
riscv_legitimize_poly_move was expected to ensure the poly value is at most 32
times smaller than the minimal VLEN (32 being derived from '4096 / 128').
This assumption held when our mode modeling was not so precisely defined.
However, now that we have modeled the mode size according to the correct
Proposed fix, and verified with "mawk" and "gawk -P" (gawk with posix
mode) on my linux also some other report it work on freebsd, just wait
review :)
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631785.html
On Tue, Oct 3, 2023 at 2:07 AM Jeff Law wrote:
>
>
>
> On 10/2/23 12:03, David
We TARGET__P marcro to test a Mask and InverseMask with user
specified target_variable, however we may want to test with specific
gcc_options variable rather than target_variable.
Like RISC-V has defined lots of Mask with TargetVariable, which is not
easy to use, because that means we need to know
From: Kito Cheng
Reply-To:
Subject: [PATCH v1 0/4] RISC-V target attribute
In-Reply-To:
This patch set implement target attribute for RISC-V target, which is similar
to other target like x86 or ARM, let user able to set some local setting per
function without changing global settings.
We
Allow those funciton apply from a local gcc_options rather than the
global options.
Preparatory for target attribute, sperate this change for eaiser reivew
since it's a NFC.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_convert_vector_bits): Get setting
from argument rather than
The target attribute which proposed in [1], target attribute allow user
to specify a local setting per-function basis.
The syntax of target attribute is `__attribute__((target("")))`.
and the syntax of `` describes below:
```
ATTR-STRING := ATTR-STRING ';' ATTR
| ATTR
ATTR:=
riscv_subset_list only accept a full arch string before, but we need to
parse single extension when supporting target attribute, also we may set
a riscv_subset_list directly rather than re-parsing the ISA string
again.
gcc/ChangeLog:
* config/riscv/riscv-subset.h (riscv_subset_list::parse
Ooop, I screwed up when writing my cover letter of the target
attribute patch set...
On Tue, Oct 3, 2023 at 5:10 PM Kito Cheng wrote:
>
> From: Kito Cheng
>
> Reply-To:
>
> Subject: [PATCH v1 0/4] RISC-V target attribute
>
> In-Reply-To:
>
> This patch set impleme
钟居哲 於 2023年10月4日 週三，20:20寫道：
>
> I think the "max poly value" is the LMUL 1 mode coeffs[1]
>
> See int vlenb = BYTES_PER_RISCV_VECTOR.coeffs[1];
>
> So I think bump max_power to exact_log2 (64); is not enough.
> since we adjust the LMUL 1 mode size according to TARGET_MIN_VLEN.
>
> I suspect the te
committed to trunk, got approval from Jeff in another mail thread:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/631873.html :)
On Mon, Oct 2, 2023 at 4:03 PM Kito Cheng wrote:
>
> Multidimensional arrary is gawk extension, and we accidentally
> introduced that in recent
LGTM, will commit if nobody commit that tomorrow :p
Christoph Müllner 於 2023年10月4日 週三，23:04寫道：
> On Wed, Oct 4, 2023 at 9:49 AM Xianmiao Qu
> wrote:
> >
> > From: quxm
> >
> > When generating CFI directives for the store-pair instruction,
> > if we add two parallel REG_FRAME_RELATED_EXPR expr_l
Hi Robin:
Your suggested code seems work fine, let me run more test and send v2, I
guess I just don’t know how to explain why it work in comment :p
Robin Dapp 於 2023年10月5日 週四，03:57寫道：
> >> I think the "max poly value" is the LMUL 1 mode coeffs[1]
> >>
> >> See int vlenb = BYTES_PER_RISCV_VECTOR.
LGTM
Patrick O'Neill 於 2023年10月6日 週五 07:46 寫道：
> stdint.h can be replaced with stdint-gcc.h to resolve some missing
> system headers in non-multilib installations.
>
> Tested using glibc rv32gcv and rv64gcv on r14-4381-g7eb5ce7f58e.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv
LGTM
於 2023年10月6日 週五 10:39 寫道：
> From: Pan Li
>
> Some comment is out of date, this patch would like to fix it.
>
> gcc/ChangeLog:
>
> * config/riscv/autovec.md: Update comments.
>
> Signed-off-by: Pan Li
> ---
> gcc/config/riscv/autovec.md | 6 +-
> 1 file changed, 5 insertions(+
> Doesn't this need to be updated to avoid multi-dimensional arrays in awk
> and rebased?
Oh, yeah, I should update that, it's post before that issue reported,
let me send v2 sn :P
I guess you may also want to clean up those bodies for "check-function-bodies"?
On Mon, Oct 9, 2023 at 3:47 PM Christoph Muellner
wrote:
>
> From: Christoph Müllner
>
> Fixes: c1bc7513b1d7 ("RISC-V: const: hide mvconst splitter from IRA")
>
> A recent change broke the xtheadcondmov-indirect test
LGTM
On Mon, Oct 9, 2023 at 4:23 PM Juzhe-Zhong wrote:
>
> For RVV, we have VLS modes enable according to TARGET_MIN_VLEN
> from M1 to M8.
>
> For example, when TARGET_MIN_VLEN = 128 bits, we enable
> 128/256/512/1024 bits VLS modes.
>
> This patch fixes following FAIL:
> FAIL: gcc.dg/vect/bb-slp
This patch set implement target attribute for RISC-V target, which is similar
to other target like x86 or ARM, let user able to set some local setting per
function without changing global settings.
We support arch, tune and cpu first, and we will support other target attribute
later, this versi
We TARGET__P marcro to test a Mask and InverseMask with user
specified target_variable, however we may want to test with specific
gcc_options variable rather than target_variable.
Like RISC-V has defined lots of Mask with TargetVariable, which is not
easy to use, because that means we need to know
Allow those funciton apply from a local gcc_options rather than the
global options.
Preparatory for target attribute, sperate this change for eaiser reivew
since it's a NFC.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_convert_vector_bits): Get setting
from argument rather than
The target attribute which proposed in [1], target attribute allow user
to specify a local setting per-function basis.
The syntax of target attribute is `__attribute__((target("")))`.
and the syntax of `` describes below:
```
ATTR-STRING := ATTR-STRING ';' ATTR
| ATTR
ATTR:=
riscv_subset_list only accept a full arch string before, but we need to
parse single extension when supporting target attribute, also we may set
a riscv_subset_list directly rather than re-parsing the ISA string
again.
gcc/ChangeLog:
* config/riscv/riscv-subset.h (riscv_subset_list::parse
Just repeat what I said on the mailing list again :P it's LGTM, just
need to rebase to deal with riscv.opt related changes :)
On Sat, Sep 30, 2023 at 8:02 PM Mary Bennett wrote:
>
> Thank you for reviewing this patch.
>
> v1->v2:
> * Add XCValu RTL.
> * Change assembly mnemonics from mixed c
Thanks, committed with fixup for those two comments :)
On Tue, Oct 10, 2023 at 7:01 AM Jeff Law wrote:
>
>
>
> On 10/9/23 22:13, Kito Cheng wrote:
> > riscv_subset_list only accept a full arch string before, but we need to
> > parse single extension when supporting targe
Thanks, committed, and just did one more check with x86 again, it
works as well, hope no more awk portable issue this time :P
On Tue, Oct 10, 2023 at 6:51 AM Jeff Law wrote:
>
>
>
> On 10/9/23 22:13, Kito Cheng wrote:
> > We TARGET__P marcro to test a Mask and InverseMask with
Thanks, committed :)
On Tue, Oct 10, 2023 at 6:51 AM Jeff Law wrote:
>
>
>
> On 10/9/23 22:13, Kito Cheng wrote:
> > Allow those funciton apply from a local gcc_options rather than the
> > global options.
> >
> > Preparatory for target attribute, sperate thi
> Assuming you're agreeable to adjusting the code to avoid alloca, we'll
> do a quick turnaround on the v3 -- I'll just audit the return paths to
> make sure we don't leak and we'll be good to go.
Thanks for point out that, let me figure out which is the best way to
fix that, using xstrdup + free
PTS (opts);
>
>
>
> --
> juzhe.zh...@rivai.ai
>
>
> *From:* Kito Cheng
> *Date:* 2023-10-12 05:20
> *To:* Jeff Law
> *CC:* Kito Cheng ; gcc-patches
> ; palmer ; rdapp
> ; juzhe.zhong
> *Subject:* Re: [PATCH v2 1/4] options: Define TARGET__P and
> TARGET__OPTS_P m
riscv-autovec-lmul=m8
> -march=rv64gcv_zvl4096b --param=riscv-autovec-lmul=dynamic
>
> I will do that in stage 3. I hope this patch can be landed before I do that.
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2023-10-05 22:00
gcc/ChangeLog:
* config/riscv/riscv-opts.h (TARGET_MIN_VLEN_OPTS): New.
---
gcc/config/riscv/riscv-opts.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/config/riscv/riscv-opts.h b/gcc/config/riscv/riscv-opts.h
index e7c6b75c5ea..31ee42dea6b 100644
--- a/gcc/config/riscv/ri
Fixed, sorry for disturbing trunk
On Wed, Oct 11, 2023 at 3:50 PM Kito Cheng wrote:
>
> Oh, my bad seem like that was in later patch, let me fix now
>
> 钟居哲 於 2023年10月11日 週三 15:49 寫道：
>>
>> ../../../../gcc/gcc/config/riscv/riscv.cc:8142:18: error:
>> ‘TARGET_MIN_
Take a quick look and maybe fix it like that, but I am not sure the
layout is what they want.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index eb665188caf..1692e43de10 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -21714,7 +21714,7 @@ vector intrinsic specification, whi
Did I miss something? the title says support but it seems only testcase??
On Wed, Oct 11, 2023 at 8:38 PM Li, Pan2 wrote:
>
> Committed, thanks Juzhe.
>
>
>
> Pan
>
>
>
> From: juzhe.zh...@rivai.ai
> Sent: Thursday, October 12, 2023 11:34 AM
> To: Li, Pan2 ; gcc-patches
> Cc: Li, Pan2 ; Wang, Y
ion from the situation like search from the git logs,
> I choose option 2 here and add some description in
> as well.
>
> Finally, is there any best practices for this case? Thank again for
> comments.
>
> Pan
>
> -Original Message-
> From: Kito Cheng
>
Yeah, will send v2 today
Jeff Law 於 2023年10月12日 週四 09:15 寫道：
>
>
> On 10/11/23 17:17, Kito Cheng wrote:
> > Yeah, I'll take you suggestion and go ahead, Robin's suggestion is
> > great but it's just a little too magic :P
> So there'll be a V2 of this
Sorry for the late comment after Jeff say ok, but I guess we may
consider add "-fno-schedule-insns -fno-schedule-insns2" to avoid
disturbing from schedule like some of our test case in
gcc/testsuite/gcc.target/riscv/rvv?
On Thu, Oct 12, 2023 at 9:12 AM Jeff Law wrote:
>
>
>
> On 10/12/23 07:06, C
but anyway, I don't have a strong opinion for either way, just go
ahead no matter which one you choose.
On Thu, Oct 12, 2023 at 11:28 AM Kito Cheng wrote:
>
> Sorry for the late comment after Jeff say ok, but I guess we may
> consider add "-fno-schedule-insns -fno-schedu
riscv_legitimize_poly_move was expected to ensure the poly value is at most 32
times smaller than the minimal VLEN (32 being derived from '4096 / 128').
This assumption held when our mode modeling was not so precisely defined.
However, now that we have modeled the mode size according to the correct
Committed with few changelog tweak :P
On Thu, Oct 12, 2023 at 3:37 PM 钟居哲 wrote:
>
> LGTM
>
>
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2023-10-13 02:40
> To: gcc-patches; kito.cheng; palmer; jeffreyalaw; rdapp; juzhe.zh
LGTM
Juzhe-Zhong 於 2023年10月12日 週四 22:45 寫道：
> Like ARM SVE and GCN, add RVV.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/vect/bb-slp-pr69907.c: Add RVV.
>
> ---
> gcc/testsuite/gcc.dg/vect/bb-slp-pr69907.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/te
> When looking around, I stumbled upon commit
> d0bbecb1c41 "RISC-V: Add riscv_vector.h wrapper in testsuite to
> prevent pull in stdint.h from C library"
>work
> Which seems like a step in a right direction, but how does one ensure
> that the wrapper riscv_vector.h (containing stdint-gcc.h) i
Hi Jim:
Does it possible just combine those pattern into simple_return
pattern, and then check the function type and output correct return
instruction in riscv_output_return?
On Tue, Jul 3, 2018 at 8:22 AM Jim Wilson wrote:
>
> This fixes a problem found by someone trying to use the new RISC-V in
Hi Jim:
It's no problem with current approach, I just think it can simplify
the .md file.
Thanks :)
On Tue, Jul 3, 2018 at 11:22 AM Jim Wilson wrote:
>
> On Mon, Jul 2, 2018 at 8:04 PM, Kito Cheng wrote:
> > Does it possible just combine those pattern into simple_return
>
Hi all:
This patch implemented TARGET_MERGE_DECL_ATTRIBUTES hook to check the
interrupter is all compatible, tested with rv32ima and rv64ima elf
toolchain.
gcc/ChangeLog
2018-07-06 Kito Cheng
* config/riscv/riscv.c (enum riscv_privilege_levels): Add UNKNOWN_MODE
ping.
On Fri, Jul 6, 2018 at 4:38 PM Kito Cheng wrote:
>
> Hi all:
>
> This patch implemented TARGET_MERGE_DECL_ATTRIBUTES hook to check the
> interrupter is all compatible, tested with rv32ima and rv64ima elf
> toolchain.
>
> gcc/ChangeLog
> 2018-07-06 Kito Cheng
This patch set implement _Float16 both for softfloat and hardfloat (zfh/zfhmin),
_Float16 has introduced into RISC-V psABI[1] since Jul 2021 and zfh/zfhmin
extension has ratified since 2022[2].
[1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/172
[2]
https://github.com/riscv/riscv-is
RISC-V decide use _Float16 as primary IEEE half precision type, and this
already become part of psABI, this patch has added folloing support for
_Float16:
- Soft-float support for _Float16.
- Make sure _Float16 available on C++ mode.
- Name mangling for _Float16 on C++ mode.
gcc/ChangeLog
Zfh and Zfhmin are extensions for IEEE half precision, both are ratified
in Jan. 2022[1]:
- Zfh has full set of operation like F or D for single or double precision.
- Zfhmin has only provide minimal support for half precision operation,
like conversion, load, store and move instructions.
[1]
Hi Joseph:
On Wed, Jul 27, 2022 at 5:42 AM Joseph Myers wrote:
>
> On Thu, 7 Jul 2022, Kito Cheng wrote:
>
> > +/* Implement TARGET_MANGLE_TYPE. */
> > +
> > +static const char *
> > +riscv_mangle_type (const_tree type)
> > +{
> > + /* Half-pr
This patch is updating all soft-fp from glibc, most changes are
copyright years update, removing "Contributed by" lines and update URL for
license, and changes other than those update are adding conversion
function between IEEE half and 32-bit/64-bit integer, those functions are
required by RISC-V
This patch set implements Zfh and Zfhmin, adds soft-float for _Float16, and
enables _Float16 type in C++ mode.
Zfh and Zfhmin are extensions for IEEE half precision, both are ratified in
Jan. 2022[1]
v2 Changes:
Fix mangling for C++ mode to fit the RISC-V psABI spec.
[1]
https://github.com/r
RISC-V decide use _Float16 as primary IEEE half precision type, and this
already become part of psABI, this patch has added folloing support for
_Float16:
- Soft-float support for _Float16.
- Make sure _Float16 available on C++ mode.
- Name mangling for _Float16 on C++ mode.
gcc/ChangeLog
Zfh and Zfhmin are extensions for IEEE half precision, both are ratified
in Jan. 2022[1]:
- Zfh has full set of operation like F or D for single or double precision.
- Zfhmin has only provide minimal support for half precision operation,
like conversion, load, store and move instructions.
[1]
> 1. Remove "m_" prefix as they are not private members.
Actually it's not only for private members[1], but I think it's not
mandatory, anyway it's not objection, and I am OK with that, just
share the doc
[1] "When structs and/or classes have member functions, prefer to name
data members with a l
Few minor comments:
On Mon, Oct 23, 2023 at 5:04 PM Juzhe-Zhong wrote:
>
> ICE:
>
> during RTL pass: vsetvl
> : In function 'riscv_lms_f32':
> :240:1: internal compiler error: in merge, at
> config/riscv/riscv-vsetvl.cc:1997
> 240 | }
>
> In general compatible_p (avl_equal_p) has:
>
> if (
LGTM
Juzhe-Zhong 於 2023年10月23日 週一 17:41 寫道：
> ICE:
>
> during RTL pass: vsetvl
> : In function 'riscv_lms_f32':
> :240:1: internal compiler error: in merge, at
> config/riscv/riscv-vsetvl.cc:1997
> 240 | }
>
> In general compatible_p (avl_equal_p) has:
>
> if (next.has_vl () && next.vl_use
Ok for gcc 13 but just wait one more week to make sure everything is fine
as gcc convention :)
Li Xu 於 2023年10月24日 週二，15:49寫道：
> Committed to trunk. Thanks juzhe.
>
>
> --
>
>
>
> Li Xu
>
>
>
> >Ok for trunk (You can commit it to the trunk now).
>
>
>
> >
>
>
>
> >For GCC-13, I'd lik
> +using namespace rtl_ssa;
> +using namespace riscv_vector;
> +
> +/* The AVL propagation instructions and corresponding preferred AVL.
> + It will be updated during the analysis. */
> +static hash_map *avlprops;
Maybe put into member data of pass_avlprop?
> +
> +const pass_data pass_data_avl
LGTM, but plz mention it's NFC in the title, no v2 needed :)
On Wed, Oct 25, 2023 at 5:03 PM Juzhe-Zhong wrote:
>
> Address kito's comments of AVL propagation patch.
>
> Export the functions that are not only used by VSETVL PASS but also AVL
> propagation PASS.
>
> No functionality change.
> gcc
LGTM, Thanks, it's really awesome - the implementation is simpler than
I expected, it's another great improvement for RISC-V GCC!
Just make sure Patrick gives a green light on the testing before
committing the patch :)
On Wed, Oct 25, 2023 at 8:05 PM Juzhe-Zhong wrote:
>
> This patch addresse
Could you put it into riscv-string.cc rather than riscv-v.cc? I would
like to put those builtin function expander together if possible,
riscv-string.cc might little bit confuse, but it's all included in
string.h
On Fri, Oct 27, 2023 at 3:40 PM juzhe.zh...@rivai.ai
wrote:
>
> LGTM. Thanks.
>
> ___
> Unless Kito feels otherwise I would suggest keeping a distinct API
> interface for each case.
Yeah, I think they should have a distinct API.
> Overall it looks pretty good. Does Andestech have a copyright
> assignment in place? Or are you contributing under the DCO rule?
Kuan-Lin Chen is Andestech folk, and Andestech have signed copyright
assignment for most GNU toolchain components I believe :)
> https://gcc.gnu.org/dco.html
>
> J
Could you add a testcase? other than that LGTM.
On Mon, Nov 6, 2023 at 8:27 PM Juzhe-Zhong wrote:
>
> An ICE was discovered in recent rounding autovec support:
>
> config/riscv/riscv-v.cc:4314
>65 | }
> | ^
> 0x1fa5223 riscv_vector::validate_change_or_fail(rtx_def*, rtx_def**,
> rtx_def
___
> juzhe.zh...@rivai.ai
>
>
> From: Kito Cheng
> Date: 2023-11-06 20:38
> To: Juzhe-Zhong
> CC: gcc-patches; kito.cheng; jeffreyalaw; rdapp.gcc
> Subject: Re: [PATCH] RISC-V: Early expand DImode vec_duplicate in RV32 system
> Could you add a t
> Oh, you're right! I should have checked the master branch first... and
> I was even wondering why it wasn't marked as such. Should perhaps
> cherry pick this for gcc-13-with-riscv-opts?
gcc-13-with-riscv-opts mostly maintained by Ventana folks, so maybe
ask Jeff if you want to cherry pick into
> ([gnu.org #1673033] Xing GUO), but I haven’t got response so far. Not sure if
> this patch can be accepted as a small bugfix patch. If not, I’m happy to
> wait until FSF prove it.
>
> Best Regards,
> Xing
>
> On Jan 22, 2021, at 2:26 PM, Kito Cheng wrote:
>
>
- Check `TO` mode is not BLMmode before call store_expr, calling store_expr
with BLKmode will cause ICE.
- Verified with riscv64, x86_64 and aarch64, no introduce new regression.
Note: Those logic was introduced by 3e60ddeb8220ed388819bb3f14e8caa9309fd3c2,
so I cc Jakub for reivew.
gc
> > - Check `TO` mode is not BLMmode before call store_expr, calling store_expr
> >with BLKmode will cause ICE.
>
> How do you end up with a SUBREG_PROMOTED* of something that has bitsize of 0
> (GET_MODE_BITSIZE of BLKmode is 0, right)?
to_rtx is already having a mode other than BLKmode in t
- Check `from` mode is not BLMmode before call store_expr, calling store_expr
with BLKmode will cause ICE.
- Verified with riscv64, x86_64 and aarch64, no introduce new regression.
Note: Those logic was introduced by 3e60ddeb8220ed388819bb3f14e8caa9309fd3c2,
so I cc Jakub for reivew.
Hi Jakub:
Thanks for your review, committed with testcase movement.
On Tue, Feb 2, 2021 at 4:41 PM Jakub Jelinek wrote:
>
> On Tue, Feb 02, 2021 at 03:21:24PM +0800, Kito Cheng wrote:
> > - Check `from` mode is not BLMmode before call store_expr, calling
> > store_expr
&
- Multi-lib only check the default argument is appeared in the multilib
flag list, but we didn't check the case that the flag is required but
default argument didn't provide.
- For example riscv*-rtems has a multilib set:
rv32imafd/ilp32d;@march=rv32imafd@mabi=ilp32d
And when we
Hi
Does it update config.sub and config.guess, I know it's already
stage 4, but the config.* stuff update should be harmless things,
and we need this for RISC-V big-endian support, which is already
supported in binutils 2.36.
This imports from:
sha1 6faca61810d335c7837f320733fe8e15a1431fc2
Chan
.
2021-03-05 Sinan Lin
Kito Cheng
gcc/ChangeLog:
* config/riscv/riscv.c (riscv_block_move_straight): Change type
to unsigned HOST_WIDE_INT for parameter and local variable with
HOST_WIDE_INT type.
(riscv_adjust_block_mem): Ditto
Committed to trunk.
On Wed, Jul 21, 2021 at 4:45 PM Kito Cheng wrote:
>
> --with-multilib-generator was only support for different ISA/ABI
> combination, however code model is effect the code gen a lots it
> should able to handled in multilib mechanism.
>
> Adding `--cmodel=`
In g:70cdb21e579191fe9f0f1d45e328908e59c0179e, DECL/global variable has handled
misaligned stores, but it didn't handle PARALLEL values, and I refer the
other part of this function, I found the PARALLEL need handled by
emit_group_* functions, so I add a check, and using emit_group_store if
storing
- According the conclusion in RISC-V C API document, we decide to deprecat
the __riscv_cmodel_pic marco
- __riscv_cmodel_pic is deprecated and will removed in next GCC
release.
[1] https://github.com/riscv/riscv-c-api-doc/pull/11
---
gcc/config/riscv/riscv-c.c| 7 ---
ping.
On Fri, Sep 25, 2020 at 2:33 PM Richard Biener wrote:
> On Fri, 25 Sep 2020, Kito Cheng wrote:
>
> > In g:70cdb21e579191fe9f0f1d45e328908e59c0179e, DECL/global variable has
> handled
> > misaligned stores, but it didn't handle PARALLEL values, and I refer
- Disable kasan if target is unsupported and -fasan-shadow-offset= is not
given, no matter `--param asan-stack=1` is given or not.
- Moving KASAN option checking testcase to gcc.dg, those testcase could be
useful for all other target which not support asan.
- Verifed on riscv and x86.
g
Hi Jim, Palmer and Andrew:
I think this patch is kind of major change for GCC RISC-V port, so I cc all
RISC-V gcc maintainer to make sure this change is fine with you guys.
- Motivation of this patch:
1. Sync behavior between clang/llvm.
2. Preparation for -mcpu option support, -mcpu will
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_tunes): New.
(riscv_get_valid_option_values): New.
(TARGET_GET_VALID_OPTION_VALUES): New.
* config/riscv/riscv-cores.def (RISCV_TUNE): New, define options
for tune here.
(RISCV_CORE): Fix co
From: Monk Chiang
Currnetly setting of -falign-functions=N will be ignored if the function
is optimized for size or marked as cold function.
However function alignment requirement is needed even optimized for
size in some situations, RISC-V target is an example, RISC-V kernel implement
patchable
gcc/ChangeLog:
* config/riscv/riscv-c.cc: Add newline to the end of file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pragma-1.c: Add newline to the end of file.
* gcc.target/riscv/rvv/base/pragma-2.c: Ditto.
* gcc.target/riscv/rvv/base/pragma-3.c: Ditto.
The -march option check isn't precise enough, -march=rv*v* also mach any
zve extensions.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/user-1.c: Add dg-options and drop
dg-skip-if.
Reported-by: Christoph Müllner
Tested-by: Christoph Müllner
Reviewed-by: Ju-Zhe Zhong
---
For RISC-V linux/glibc toolchain will got header file not found when including
stdint.h if multilib is not enabled, it because some header file will
try to include gnu/stubs-.h from the system, however it only
generated when multilib enabled.
In order to prevent that, we introduce a wrapper for ri
See also:
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Update flag name and mask name.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Define
misc macro for vector extensio
Hi Palmer:
I guess the problem is binutils isn't included and it's too close to the
GCC release, and binutils will report errors if it has any unsupported
extensions.
Most distro will use GCC 12 + binutils 2.38 or GCC 11 + binutils 2.38, so
either combination doesn't work for march string with zt
Currently we are sync that manually, but I guess we should re-implement
arch-canonicalize in C++, so that we could reuse the stuffs from
riscv-common.cc.
gcc/ChangeLog:
* config/riscv/arch-canonicalize: Add TODO item.
(IMPLIED_EXT): Sync.
(arch_canonicalize): Checking unti
We migrate the default ISA spec version from 2.2 to 20191213, but those scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.
gcc/ChangeLog:
PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
mu
RISC-V glibc intend to removed its own `sigcontext.h`[1] and use the linux
kernel's one, however the struct layout is slightly different between those two
version, fortunately they have identical layout, so we just need a
magical way to detect which one we are used.
libgcc/ChangeLog:
* co
Extension version might be different among different ISA spec version,
add explicitly isa-spec version to prevent that might fail when build
GCC with different default ISA version.
gcc/testsuite/ChangeLog
* gcc.target/riscv/attribute-19.c: Add -misa-spec=2.2
---
gcc/testsuite/gcc.target/
I-ext 2.0 already included zicsr and zifencei, skip that prevent
confusing binutils.
gcc/ChangeLog
* common/config/riscv/riscv-common.cc (riscv_subset_list::to_string):
Skip zicsr and zifencei if I-ext is 2.0.
---
gcc/common/config/riscv/riscv-common.cc | 14 --
1 fil
Add -misa-spec to OPTION_DEFAULT_SPECS to make sure -misa-spec will
always pass that into assembler, that prevent GCC and binutils using
different way to interpret the ISA string.
gcc/ChangeLog:
PR target/104219
* config.gcc (riscv*-*-*): Normalize the with_isa_spec value.
- binutils will complain version info is not found if default ISA spec
is 2.2 for binutils.
Error: cannot find default versions of the ISA extension `zifencei'
gcc/ChangeLog:
* configure.ac: Fix detection for zifencei support.
* configure: Regenerate.
---
gcc/configure| 2
1 - 100 of 1640 matches
Mail list logo
