>> Yeah sure, we need to be able to run tests only for specific targets.
>> Why does {riscv_vector} && {rv64} not work?
I am not sure. These testcases were added by kito long time ago.
Frankly, I am not familiar with GCC test framework.
I think the highest priority is to fix the "real" compiler bu
> I am not sure. These testcases were added by kito long time ago.
> Frankly, I am not familiar with GCC test framework.
Ok, I'm going to have a look. Need to verify the zvfh things anyway.
Regards
Robin
Sure, working on the V2 as well as the RV32 testing, will reply the bugfix
PATCH once ready.
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, June 14, 2023 3:01 PM
To: Robin Dapp ; Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ;
Wang, Yanzhang ; kito.cheng
Subject: Re: Re: [PATCH v1] R
On Tue, 13 Jun 2023 at 12:38, Tejas Belagod via Gcc-patches
wrote:
>
>
>
> From: Richard Sandiford
> Date: Monday, June 12, 2023 at 2:15 PM
> To: Tejas Belagod
> Cc: gcc-patches@gcc.gnu.org , Tejas Belagod
>
> Subject: Re: [PATCH v2] [PR96339] Optimise svlast[ab]
> Tejas Belagod writes:
> > F
Hi,
this patch adds the missing (u)int8_t types to the binop tests.
I suggest in the future we have the testsuite pass -march=rv32gcv
as well as -march=rv64gcv as options to each test case instead of
essentially duplicate the files as we do now.
Regards
Robin
gcc/testsuite/ChangeLog:
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-06-14 15:16
To: gcc-patches; palmer; Kito Cheng; juzhe.zh...@rivai.ai; jeffreyalaw
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Add (u)int8_t to binop tests.
Hi,
this patch adds the missing (u)int8_t types to the binop tests.
I suggest in the f
From: Pan Li
This patch would like to fix one bug exported by RV32 test case
multiple_rgroup_run-2.c. The mask should be restricted by elen in
vector, and the condition between the vmv.s.x and the vmv.v.x should
take inner_bits_size rather than constants.
After this patch, below failures on RV32
Thanks Juzhe for reviewing, update the PATCH v2 as below.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621645.html
Pan
From: juzhe.zh...@rivai.ai
Sent: Wednesday, June 14, 2023 9:07 AM
To: Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffreyalaw ; Li,
Pan2 ; Wang, Yanzhang ; kito.cheng
Su
On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
wrote:
>
> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
> never longer (yet sometimes shorter) than the corresponding VSHUFPS /
> VPSHUFD, due to the immediate operand of the shuffle insns balancing the
> need for
+ /* We restrict the limit to the elen of RVV. For example:
+ -march=zve32*, the ELEN is 32.
+ -march=zve64*, the ELEN is 64.
+ The related vmv.v.x/vmv.s.x is restricted to ELEN as above, we cannot
+ take care of case like below when ELEN=32
+ vsetvil e64,m1
+ vmv.v.x/vmv.s
In order to avoid interrupt functions to change the FCSR, it needs to be saved
and restored at the beginning and end of the function.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_compute_frame_info): Allocate frame for
FCSR.
(riscv_for_each_saved_reg): Save and restore FCSR in i
On Wed, 14 Jun 2023, Jiufu Guo wrote:
>
> Hi,
>
> Segher Boessenkool writes:
>
> > Hi!
> >
> > As I said in a reply to the original patch: not okay. Sorry.
>
> Thanks a lot for your comments!
> I'm also thinking about other solutions:
> 1. "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])"
>
Hi!
On 2023-06-13T20:44:39+0200, Tobias Burnus wrote:
> I intent to commit this tomorrow, unless there are comments.
I'm sorry I'm late. ;-P
> It does as it says (see commit log): It initializes default-device-var
> to the value using the algorithm described in OpenMP 5.2, which
> depends on w
Now committed - with additional changes: two GCC 13 features on the
implementation-status list were missed in a previous update. Current
version:
→ https://gcc.gnu.org/projects/gomp/
→ https://gcc.gnu.org/gcc-14/changes.html (as first entry)
Tobias
On 13.06.23 20:45, Tobias Burnus wrote:
Firs
On Wed, Jun 14, 2023 at 1:59 PM Jan Beulich via Gcc-patches
wrote:
>
> There's no reason to constrain this to AVX512VL, as the wider operation
> is not usable for more narrow operands only when the possible memory
But this may require more resources (on AMD znver4 processor a zmm
instruction will
On Tue, Jun 13, 2023 at 10:07 AM Kewen Lin via Gcc-patches
wrote:
>
> This patch adjusts the cost handling on
> VMAT_CONTIGUOUS_PERMUTE in function vectorizable_load. We
> don't call function vect_model_load_cost for it any more.
>
> As the affected test case gcc.target/i386/pr70021.c shows,
> th
Hi Pan,
> This patch would like to fix one bug exported by RV32 test case
> multiple_rgroup_run-2.c. The mask should be restricted by elen in
> vector, and the condition between the vmv.s.x and the vmv.v.x should
> take inner_bits_size rather than constants.
exported -> exposed.
How about someth
On Tue, Jun 13, 2023 at 6:03 PM Roger Sayle wrote:
>
>
> This patch is the next instalment in a set of backend patches around
> improvements to ptest/vptest. A previous patch optimized the sequence
> t=pand(x,y); ptestz(t,t) into the equivalent ptestz(x,y), using the
> property that ZF is set to
Thanks Robin, that looks like much better than the v2, let me update it to
PATCH v3.
Pan
-Original Message-
From: Robin Dapp
Sent: Wednesday, June 14, 2023 4:27 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; juzhe.zh...@rivai.ai; jeffreya...@gmail.com; Wang,
Yanzha
Hi Tobias!
On 2023-06-12T18:44:23+0200, Tobias Burnus wrote:
> Cleanup follow up to
>r14-1579-g4ede915d5dde93 "openmp: Add support for the 'present' modifier"
> committed 6 days ago.
>
> Namely:
> * Replace for the program → libgomp ABI
> GOMP_MAP_PRESENT_[ALLOC,TO,FROM,TOFROM]
>by the p
From: Pan Li
When constructing a vector mask from individual elements we wrongly
assumed that we can broadcast BITS_PER_WORD (i.e. XLEN). The maximum is
actually the vector element length (i.e. ELEN). This patch fixes this.
After this patch, below failures on RV32 will be fixed.
FAIL: gcc.tar
LGTM
juzhe.zh...@rivai.ai
From: pan2.li
Date: 2023-06-14 17:00
To: gcc-patches
CC: juzhe.zhong; rdapp.gcc; jeffreyalaw; pan2.li; yanzhang.wang; kito.cheng
Subject: [PATCH v3] RISC-V: Bugfix for vec_init repeating auto vectorization in
RV32
From: Pan Li
When constructing a vector mask from
On 14.06.2023 09:41, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 1:58 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> ... in vec_dupv4sf / *vec_dupv4si. The respective broadcast insns are
>> never longer (yet sometimes shorter) than the corresponding VSHUFPS /
>> VPSHUFD, due to the immediate opera
Richard Biener writes:
> AFAIU this special instruction is only supposed to prevent
> code motion (of stack memory accesses?) across this instruction?
> I'd say a
>
> (may_clobber (mem:BLK (reg:DI 1 1)))
>
> might be more to the point? I've used "may_clobber" which doesn't
> exist since I'm not
This patch removes a remnant of mudflap.
gcc/ChangeLog:
* config/moxie/uclinux.h (MFWRAP_SPEC): Remove
--
With the best regards
Jivan Hakobyan
diff --git a/gcc/config/moxie/uclinux.h b/gcc/config/moxie/uclinux.h
index f7bb62e56c7..a7d371047c4 100644
--- a/gcc/config/moxie/uclinux.h
+++
On Wed, 2023-06-14 at 09:55 +0800, Jiufu Guo wrote:
> Hi,
>
> Xi Ruoyao writes:
>
> > On Tue, 2023-06-13 at 20:23 +0800, Jiufu Guo via Gcc-patches wrote:
> >
> > > Compare with previous version, this addes ChangeLog and removes
> > > const_anchor parts.
> > > https://gcc.gnu.org/pipermail/gcc-p
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > AFAIU this special instruction is only supposed to prevent
> > code motion (of stack memory accesses?) across this instruction?
> > I'd say a
> >
> > (may_clobber (mem:BLK (reg:DI 1 1)))
> >
> > might be more to the poin
Hi,
Richard Biener writes:
> On Wed, 14 Jun 2023, Jiufu Guo wrote:
>
>>
>> Hi,
>>
>> Segher Boessenkool writes:
>>
>> > Hi!
>> >
>> > As I said in a reply to the original patch: not okay. Sorry.
>>
>> Thanks a lot for your comments!
>> I'm also thinking about other solutions:
>> 1. "set
Hi,
Richard Sandiford writes:
> Richard Biener writes:
>> AFAIU this special instruction is only supposed to prevent
>> code motion (of stack memory accesses?) across this instruction?
>> I'd say a
>>
>> (may_clobber (mem:BLK (reg:DI 1 1)))
>>
>> might be more to the point? I've used "may_
On 14.06.2023 10:10, Hongtao Liu wrote:
> On Wed, Jun 14, 2023 at 1:59 PM Jan Beulich via Gcc-patches
> wrote:
>>
>> There's no reason to constrain this to AVX512VL, as the wider operation
>> is not usable for more narrow operands only when the possible memory
> But this may require more resources
On 14.06.23 10:09, Thomas Schwinge wrote:
This reminds me of the (unresolved)https://gcc.gnu.org/PR81886
"Means to determine at runtime foffload targets specified at compile time".
I think there is the problem that we also support offloading in
libraries. Thus, if you compile the main program w
Richard Biener writes:
> On Wed, 14 Jun 2023, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > AFAIU this special instruction is only supposed to prevent
>> > code motion (of stack memory accesses?) across this instruction?
>> > I'd say a
>> >
>> > (may_clobber (mem:BLK (reg:DI 1 1)))
Currently vect_determine_partial_vectors_and_peeling will decide
to apply fully masking to the main loop despite
--param vect-partial-vector-usage=1 when the currently analyzed
vector mode results in a vectorization factor that's bigger
than the number of scalar iterations. That's undesirable fo
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Wed, 14 Jun 2023, Richard Sandiford wrote:
> >
> >> Richard Biener writes:
> >> > AFAIU this special instruction is only supposed to prevent
> >> > code motion (of stack memory accesses?) across this instruction?
> >>
Hi!
On 2023-06-13T13:11:38+0200, Tobias Burnus wrote:
> On 13.06.23 12:42, Thomas Schwinge wrote:
>> On 2023-06-05T14:18:48+0200, I wrote:
>>> OK to push the attached
>>> "Add 'libgomp.{,oacc-}fortran/fortran-torture_execute_math.f90'"?
>>
>> Subject: [PATCH] Add
>> 'libgomp.{,oacc-}fortran/for
On 14.06.23 10:42, Thomas Schwinge wrote:
Couldn't/shouldn't we now get rid of this 'GOMP_MAP_FLAG_PRESENT'...
...
#define GOMP_MAP_PRESENT_P(X) \
- (((X) & GOMP_MAP_FLAG_PRESENT) == GOMP_MAP_FLAG_PRESENT)
+ (((X) & GOMP_MAP_FLAG_PRESENT) == GOMP_MAP_FLAG_PRESENT \
+ || (X) == GOMP_MAP_FO
Richard Biener writes:
> On Wed, 14 Jun 2023, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Wed, 14 Jun 2023, Richard Sandiford wrote:
>> >
>> >> Richard Biener writes:
>> >> > AFAIU this special instruction is only supposed to prevent
>> >> > code motion (of stack memory accesses
On 13.06.23 12:44, Thomas Schwinge wrote:
On 2023-06-05T14:25:18+0200, I wrote:
OK to push the attached
"driver: Forward '-lgfortran', '-lm' to offloading compilation"?
(We didn't have a PR open for that, or did we?)
(It was approved by Joseph and pushed by Thomas as r14-1807-g4bcb46b3ade179 )
Use default argument when callback function is not required to merge
rtx_equal_p and hash_rtx functions with their callback variants.
gcc/ChangeLog:
* cse.cc (hash_rtx_cb): Rename to hash_rtx.
(hash_rtx): Remove.
* early-remat.cc (remat_candidate_hasher::equal): Update
to call rtx
Comments on the wording and/or the content?
I did notice that we missed to document three OMP_* environment
variables, hence, I added them.
(For OMP_ALLOCATOR, I expect an update once the 5.1 extensions have been
implemented.)
(Some cross references could be added if we had/once we have documen
Hi,
This patch fix the PR 110119.
The reason for this bug is that in the case where the vector register is set
to a fixed length (with `--param=riscv-autovec-preference=fixed-vlmax` option),
TARGET_PASS_BY_REFERENCE thinks that variables of type vint32m1 can be passed
through two scalar register
Hi!
Any objections to pushing the attached
"libgomp testsuite: Don't handle 'lang_link_flags'"?
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank
Add PR target/pr110119
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-06-14 18:34
To: gcc-patches; juzhe.zhong
Subject: [PATCH] RISC-V: Fix PR 110119
Hi,
This patch fix the PR 110119.
The reason for this bug is that in the case where the vector register is set
to a fixed length (with `-
Hi!
On 2023-06-14T11:42:22+0200, Tobias Burnus wrote:
> On 14.06.23 10:09, Thomas Schwinge wrote:
>> Let me know if I should also adjust the new 'target { ! offload_device }'
>> diagnostic "[...] MANDATORY but only the host device is available" to
>> include a comma before 'but', for consistency
Hi,
The reason for this bug is that in the case where the vector register is set
to a fixed length (with `--param=riscv-autovec-preference=fixed-vlmax` option),
TARGET_PASS_BY_REFERENCE thinks that variables of type vint32m1 can be passed
through two scalar registers, but when GCC calls FUNCTION_V
Thanks for fixing this.
This patch let RVV type (both vector and tuple) return in memory by default
when there is no vector ABI support.
It makes sens to me.
CC more RISC-V folks to comments.
Thanks.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-06-14 19:03
To: gcc-patches; juzhe.zhong
S
Resubmitted a new, more standardized patch(bellow is the new patch link),
thanks.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621683.html
Oluwatamilore Adebayo writes:
> From: oluade01
>
> This adds a recognition pattern for the non-widening
> absolute difference (ABD).
>
> gcc/ChangeLog:
>
> * doc/md.texi (sabd, uabd): Document them.
> * internal-fn.def (ABD): Use new optab.
> * optabs.def (sabd_optab, uabd_optab
On Tue, Jun 13, 2023 at 01:29:04PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > + else if (addc_subc)
> > > + {
> > > + if (!integer_zerop (arg2))
> > > + ;
> > > + /* x = y + 0 + 0; x = y - 0 - 0; */
> > > + else if (integer_zerop (arg1))
> > > + result
Oh. I see.
Change if (riscv_v_ext_mode_p (arg.mode) || riscv_v_ext_tuple_mode_p
(arg.mode))
into
if (riscv_v_ext_mode_p (arg.mode))
since riscv_v_ext_mode_p (arg.mode) includes riscv_v_ext_vector_mode_p
(arg.mode) and riscv_v_ext_tuple_mode_p (arg.mode)
no need has riscv_v_ext_tuple_mode_p
Also
p110119-1.c
change name of test into
pr110119-1.c
juzhe.zh...@rivai.ai
发件人： juzhe.zh...@rivai.ai
发送时间： 2023-06-14 19:17
收件人： 丁乐华; gcc-patches
抄送： jeffreyalaw; Robin Dapp; palmer
主题： Re: [PATCH] RISC-V: Ensure vector args and return use function stack to
pass [PR110119]
Oh. I see.
Change
Fix all comment from Juzhe, thanks. Below is the new patch. Please use the
attachment if there is a problem with the format of the patch below.
PR 110119
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_get_arg_info): Return NULL_RTX for
vector mode
(riscv_pass_by_refer
\ No newline at end of file
Add newline for each test.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-06-14 19:33
To: 钟居哲; gcc-patches
CC: Jeff Law; Robin Dapp; palmer
Subject: Re: [PATCH] RISC-V: Ensure vector args and return use function stack
to pass [PR110119]
Fix all comment from Juzhe
Hi,
> Thanks for fixing this.
>
> This patch let RVV type (both vector and tuple) return in memory by
> default when there is no vector ABI support. It makes sens to me.
>
> CC more RISC-V folks to comments.
so this is intended to fix the PR as well as unblock while we continue
with the prelimi
* Paul Eggert:
> I don't see how you could implement __has_include_next()
> for arbitrary non-GCC compilers, which is what we'd need for glibc
> users.
This is not a requirement for glibc in general. For example,
only works with compilers to which it has been ported.
Thanks,
Florian
The function is only meaningful for LOOP_VINFO_MASKS processing so
inline it into the single use.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
* tree-vect-loop.cc (vect_get_max_nscalars_per_iter): Inline
into ...
(vect_verify_full_masking): ... this.
---
gcc/t
This adds a loop_vinfo argument for future use, making the next
patch smaller.
* tree-vectorizer.h (vect_get_loop_mask): Add loop_vec_info
argument.
* tree-vect-loop.cc (vect_get_loop_mask): Likewise.
(vectorize_fold_left_reduction): Adjust.
(vect_transform_
> so this is intended to fix the PR as well as unblock while we continue
> with the preliminary ABI separately?
Yes, and I will send the new prerelease vector calling convention later.
Best,
Lehua
This implemens fully masked vectorization or a masked epilog for
AVX512 style masks which single themselves out by representing
each lane with a single bit and by using integer modes for the mask
(both is much like GCN).
AVX512 is also special in that it doesn't have any instruction
to compute the
The V2 patch address comments from Juzhe, thanks.
Hi,
The reason for this bug is that in the case where the vector register is set
to a fixed length (with `--param=riscv-autovec-preference=fixed-vlmax` option),
TARGET_PASS_BY_REFERENCE thinks that variables of type vint32m1 can be passed
through
> \ No newline at end of file
> Add newline for each test.
Address this comment, below is the V2 patch link.
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621698.html
Best,
Lehua
LGTM now. Thanks for fixing it.
Good to see a Fix patch of the ICE before Vector ABI patch.
Let's wait for more comments.
Lehua Ding takes care of Vector ABI implementation and hopefully will send it
soon.
Thanks.
juzhe.zh...@rivai.ai
From: Lehua Ding
Date: 2023-06-14 19:56
To: gcc-patches
LGTM now. Thanks for fixing it.
Good to see a Fix patch of the ICE before Vector ABI patch.
Let's wait for more comments.
Lehua Ding takes care of Vector ABI implementation and hopefully will send it
soon.
It seems the email of Jeff is wrong. CC Jeff .for you.
Thanks.
juzhe.zh...@rivai.
LGTM now. Thanks for fixing it.
Good to see a Fix patch of the ICE before Vector ABI patch.
Let's wait for more comments.
Lehua Ding takes care of Vector ABI implementation and hopefully will send it
soon.
It seems the email of Jeff is wrong. CC Jeff .for you.
Oh. I see Robin's email is al
> Oh. I see Robin's email is also wrong. CC Robin too for you
It still arrived via the mailing list ;)
> Good to see a Fix patch of the ICE before Vector ABI patch.
> Let's wait for more comments.
LGTM, this way I don't even need to rewrite my tests.
Regards
Robin
This patch fixes the link to README.Portability in "GCC Coding Conventions"
page
--
With the best regards
Jivan Hakobyan
diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index 9b6d243d..f5a356a8 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.h
PING
On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
>
> This patch converts the ipa_jump_func code to use the type agnostic
> ipa_vr suitable for GC instead of value_range which is integer specific.
>
> I've disabled the range cacheing to simplify the patch for review, but
> it is handled
PING
On Mon, May 22, 2023 at 8:56 PM Aldy Hernandez wrote:
>
> Minor cleanups to get rid of value_range in IPA. There's only one left,
> but it's in the switch code which is integer specific.
>
> OK?
>
> gcc/ChangeLog:
>
> * ipa-cp.cc (decide_whether_version_node): Adjust comment.
>
PING
On Sat, Jun 10, 2023 at 10:30 PM Aldy Hernandez wrote:
>
>
>
> On 5/29/23 16:51, Martin Jambor wrote:
> > Hi,
> >
> > On Mon, May 22 2023, Aldy Hernandez via Gcc-patches wrote:
> >> Implement hashing for ipa_vr. When all is said and done, all these
> >> patches incurr a 7.64% slowdown for i
Nit for test.
+/* { dg-options "-march=rv64gczve32x
+--param=riscv-autovec-preference=fixed-vlmax" } */
To
+/* { dg-options "-march=rv64gc_zve32x
--param=riscv-autovec-preference=fixed-vlmax" } */
Pan
-Original Message-
From: Gcc-patches On Behalf
Of juzhe.zh...@rivai.ai
Sent: Wedn
On Wed, 14 Jun 2023, Jakub Jelinek wrote:
> On Tue, Jun 13, 2023 at 01:29:04PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > > > + else if (addc_subc)
> > > > + {
> > > > + if (!integer_zerop (arg2))
> > > > + ;
> > > > + /* x = y + 0 + 0;
On Tue, 13 Jun 2023, Jakub Jelinek wrote:
> On Tue, Jun 13, 2023 at 08:40:36AM +, Richard Biener wrote:
> > I suspect re-association can wreck things even more here. I have
> > to say the matching code is very hard to follow, not sure if
> > splitting out a function matching
> >
> >_22 =
> Nit for test.
> +/* { dg-options "-march=rv64gczve32x
> +--param=riscv-autovec-preference=fixed-vlmax" } */
> To
> +/* { dg-options "-march=rv64gc_zve32x
--param=riscv-autovec-preference=fixed-vlmax" } */
Fixed in the V2 patch
(https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621698.html), t
Richard Biener via Gcc-patches writes:
> Currently vect_determine_partial_vectors_and_peeling will decide
> to apply fully masking to the main loop despite
> --param vect-partial-vector-usage=1 when the currently analyzed
> vector mode results in a vectorization factor that's bigger
> than the num
Richard Biener via Gcc-patches writes:
> The function is only meaningful for LOOP_VINFO_MASKS processing so
> inline it into the single use.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
>
> * tree-vect-loop.cc (vect_get_max_nscalars_per_iter): Inline
> into ...
>
Hi,
This is a v2 patch addressing feedback for:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621050.html
macOS SDK headers using the CF_ENUM macro can expand to invalid C++ code
of the form:
typedef enum T : BaseType T;
i.e. an elaborated-type-specifier with an additional enum-base.
Upst
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > Currently vect_determine_partial_vectors_and_peeling will decide
> > to apply fully masking to the main loop despite
> > --param vect-partial-vector-usage=1 when the currently analyzed
> > vector mode resul
On Wed, 14 Jun 2023, Richard Sandiford wrote:
> Richard Biener via Gcc-patches writes:
> > The function is only meaningful for LOOP_VINFO_MASKS processing so
> > inline it into the single use.
> >
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, OK?
> >
> > * tree-vect-loop.cc (vect_g
On Wed, Jun 14, 2023 at 12:25:46PM +, Richard Biener wrote:
> I think that's still very much desirable so this followup looks OK.
> Maybe you can re-base it as prerequesite though?
Rebased then (of course with the UADDC/USUBC handling removed from this
first patch, will be added in the second
On Wed, 14 Jun 2023, Jakub Jelinek wrote:
> On Wed, Jun 14, 2023 at 12:25:46PM +, Richard Biener wrote:
> > I think that's still very much desirable so this followup looks OK.
> > Maybe you can re-base it as prerequesite though?
>
> Rebased then (of course with the UADDC/USUBC handling remove
Hi!
On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
> At this point two pages of code without a comment - can you introduce
> some vertical spacing and comments as to what is matched now? The
> split out functions help somewhat but the code is far from obvious :/
>
> Maybe I'm co
In discussion of this issue CWG decided that the change of behavior on
well-formed code like overload-conv-4.C is undesirable. In further
discussion of possible resolutions, we discovered that we can avoid that
change while still getting the desired behavior on overload-conv-3.C by
making this a t
On Sat, 10 Jun 2023 at 23:04, Jonny Grant wrote:
>
> libstdc++-v3/ChangeLog:
>
> * doc/xml/manual/extensions.xml: Remove demangle exception
> description and include.
Thanks, pushed to trunk.
>
> ---
> libstdc++-v3/doc/xml/manual/extensions.xml | 6 ++
> 1 file changed, 2 insertions
Hi,
this introduces new checks for run tests. Currently we have
riscv_vector as well as rv32 and rv64 which all check if GCC (with the
current configuration) can build (not execute) the respective tests.
Many tests specify e.g. a different -march for vector, though. So the
check fails even thou
On 14/06/2023 12:54, Richard Biener via Gcc-patches wrote:
This implemens fully masked vectorization or a masked epilog for
AVX512 style masks which single themselves out by representing
each lane with a single bit and by using integer modes for the mask
(both is much like GCN).
AVX512 is also s
> Am 14.06.2023 um 16:00 schrieb Jakub Jelinek :
>
> Hi!
>
>> On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
>> At this point two pages of code without a comment - can you introduce
>> some vertical spacing and comments as to what is matched now? The
>> split out functions h
> Am 14.06.2023 um 16:27 schrieb Andrew Stubbs :
>
> On 14/06/2023 12:54, Richard Biener via Gcc-patches wrote:
>> This implemens fully masked vectorization or a masked epilog for
>> AVX512 style masks which single themselves out by representing
>> each lane with a single bit and by using inte
On Wed, Jun 14, 2023 at 4:00 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
> > At this point two pages of code without a comment - can you introduce
> > some vertical spacing and comments as to what is matched now? The
> > split out functions
On Wed, Jun 14, 2023 at 4:00 PM Jakub Jelinek wrote:
>
> Hi!
>
> On Wed, Jun 14, 2023 at 12:35:42PM +, Richard Biener wrote:
> > At this point two pages of code without a comment - can you introduce
> > some vertical spacing and comments as to what is matched now? The
> > split out functions
On Tue, 13 Jun 2023, Paul Eggert wrote:
> > There is always the possibility to have the header co-owned by both
> > the compiler and C library, limits.h style.
> > Just
> > #if __has_include_next()
> > # include_next
> > #endif
>
> I don't see how you could implement __has_include_next() for
> a
On Wed, Jun 14, 2023 at 04:34:27PM +0200, Uros Bizjak wrote:
> LGTM for the x86 part. I did my best, but those peephole2 patterns are
> real PITA to be reviewed thoroughly.
>
> Maybe split out peephole2 pack to a separate patch, followed by a
> testcase patch. This way, bisection would be able to
Hi Juzhe,
the general method seems sane and useful (it's not very complicated).
I was just distracted by
> Selector = { 0, 17, 2, 19, 4, 21, 6, 23, 8, 9, 10, 27, 12, 29, 14, 31 }, the
> common expression:
> { 0, nunits + 1, 1, nunits + 2, 2, nunits + 3, ... }
>
> For this selector, we can use
On Wed, Jun 14, 2023 at 4:56 PM Jakub Jelinek wrote:
>
> On Wed, Jun 14, 2023 at 04:34:27PM +0200, Uros Bizjak wrote:
> > LGTM for the x86 part. I did my best, but those peephole2 patterns are
> > real PITA to be reviewed thoroughly.
> >
> > Maybe split out peephole2 pack to a separate patch, foll
Hi!
On Wed, Jun 14, 2023 at 05:18:15PM +0800, Xi Ruoyao wrote:
> The generic issue here is to fix (not "papering over") the signed
> overflow, we need to perform the addition in a target machine mode. We
> may always use Pmode (IIRC const_anchor was introduced for optimizing
> some constant addre
Hi!
On Wed, Jun 14, 2023 at 12:06:29PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> I'm also thinking about other solutions:
> 1. "set (mem/c:BLK (reg/f:DI 1 1) (const_int 0 [0])"
> This is the existing pattern. It may be read as an action
> to clean an unknown-size memory block.
On Wed, Jun 14, 2023 at 04:45:48PM +0200, Uros Bizjak wrote:
> +;; Helper peephole2 for the addcarry and subborrow
> +;; peephole2s, to optimize away nop which resulted from uaddc/usubc
> +;; expansion optimization.
> +(define_peephole2
> + [(set (match_operand:SWI48 0 "general_reg_operand")
> +
From: oluade01
This adds a recognition pattern for the non-widening
absolute difference (ABD).
gcc/ChangeLog:
* doc/md.texi (sabd, uabd): Document them.
* internal-fn.def (ABD): Use new optab.
* optabs.def (sabd_optab, uabd_optab): New optabs,
* tree-vect-pattern
Hi,
this implements the floating-point autovec expanders for binary
operations: vfadd, vfsub, vfdiv, vfmul, vfmax, vfmin and adds
tests.
The existing tests are amended and split up into non-_Float16
and _Float16 flavors as we cannot rely on the zvfh extension
being present.
As long as we do not
Hi,
this patch adds floating-point autovec expanders for vfneg, vfabs as well as
vfsqrt and the accompanying tests. vfrsqrt7 will be added at a later time.
Similary to the binop tests, there are flavors for zvfh now. Prerequisites
as before.
Regards
Robin
gcc/ChangeLog:
* config/ris
Hi!
On Wed, Jun 14, 2023 at 07:59:04AM +, Richard Biener wrote:
> On Wed, 14 Jun 2023, Jiufu Guo wrote:
> > 3. "set (mem/c:DI (reg/f:DI 1 1) unspec:DI (const_int 0 [0])
> > UNSPEC_TIE".
> >This avoids using BLK on unspec, but using DI.
>
> That gives the MEM a size which means we can inte
1 - 100 of 176 matches
Mail list logo
