By logically, Yes, we should not change that but here I would like to put all
enable related code together, will remove this part as it may has no
relationship with this patch.
Pan
From: juzhe.zh...@rivai.ai
Sent: Friday, June 9, 2023 2:31 PM
To: Li, Pan2 ; gcc-patches
Cc: Robin Dapp ; jeffre
OK. But why change the place of these
-;; ISA attributes.
-(define_attr "ext" "base,f,d,vector"
- (const_string "base"))
-
-;; True if the extension is enabled.
-(define_attr "ext_enabled" "no,yes"
- (cond [(eq_attr "ext" "base")
- (const_string "yes")
-
- (and (eq_attr "ext" "f")
- (match
-;; ISA attributes.
-(define_attr "ext" "base,f,d,vector"
- (const_string "base"))
-
-;; True if the extension is enabled.
-(define_attr "ext_enabled" "no,yes"
- (cond [(eq_attr "ext" "base")
- (const_string "yes")
-
- (and (eq_attr "ext" "f")
- (match_test "TARGET_HARD_FLOAT"))
- (const_st
-;; ISA attributes.
-(define_attr "ext" "base,f,d,vector"
- (const_string "base"))
-
-;; True if the extension is enabled.
-(define_attr "ext_enabled" "no,yes"
- (cond [(eq_attr "ext" "base")
- (const_string "yes")
-
- (and (eq_attr "ext" "f")
- (match_test "TARGET_HARD_FLOAT"))
- (const_st
From: Yanzhang Wang
This patch adds support to check function's argument or return is vector type
and throw warning if yes.
There're two exceptions,
- The vector_size attribute.
- The intrinsic functions.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_init_cumulative_args): Se
From: Pan Li
This patch would like to refactor the requirement of both the ZVFH
and ZVFHMIN. By default, the ZVFHMIN will enable FP16 for all the
iterators of RVV. And then the ZVFH will leverage one define attr
the gate for FP16 supported or not.
Please note the ZVFH will cover the ZVFHMIN inst
Hi,
As checking the code, there is a "gcc_assert (SCALAR_INT_MODE_P (mode))"
in "try_const_anchors".
This assert seems correct because the function try_const_anchors cares
about integer values currently, and modes other than SCALAR_INT_MODE_P
are not needed to support.
This patch makes sure SCALA
On Tue, Jun 6, 2023 at 4:23 PM liuhongt wrote:
>
> > I think this is a better patch and will always be correct and still
> > get folded at the gimple level (correctly):
> > diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
> > index d4ff56ee8dd..02bf5ba93a5 100644
> > --- a/gcc/config
On Wed, Jun 7, 2023 at 8:31 AM Hongtao Liu wrote:
>
> On Tue, Jun 6, 2023 at 10:36 PM Uros Bizjak wrote:
> >
> > On Tue, Jun 6, 2023 at 1:42 PM Hongtao Liu wrote:
> > >
> > > On Tue, Jun 6, 2023 at 5:11 PM Uros Bizjak wrote:
> > > >
> > > > On Tue, Jun 6, 2023 at 6:33 AM liuhongt via Gcc-patche
So for the attached testcase, we assumed that zero_one_valued_p would
be the value [0,1] but currently zero_one_valued_p matches also
signed 1 bit integers.
This changes that not to match that and fixes the 2 new testcases at
all optimization levels.
OK? Bootstrapped and tested on x86_64-linux-gnu
On 5/25/23 06:35, Manolis Tsamis wrote:
Implementation of the new RISC-V optimization pass for memory offset
calculations, documentation and testcases.
gcc/ChangeLog:
* config.gcc: Add riscv-fold-mem-offsets.o to extra_objs.
* config/riscv/riscv-passes.def (INSERT_PASS_AFTER)
> Date: Wed, 7 Jun 2023 18:06:15 -0400
> From: Jason Merrill via Gcc-patches
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Now that we support NRV from an inner block, we can also support non-NRV
> returns from other blocks, since once the NRV is out of scope a later return
Hi Maxim,
I managed to nail the bug on the failing test pr100244.C, as I did too
observe a divergence after my patch.
For pr101962.c, it was simply a dg-note I forgot to remove, that made it
fail, since the related warning is no longer relevant. The behavior
otherwise is as expected before and aft
Hi David,
So first real committed patch actually was a misstep. So I'm currently
fixing that.
The issue is that the original idea, to return a boolean and create a
unknown_svalue on OOB access to prevent further "use-of-uninitialized-value"
caused a loss of information on the location of the buffe
On 6/8/23 15:54, Patrick Palka wrote:
On Wed, 7 Jun 2023, Jason Merrill wrote:
On 6/6/23 14:29, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with V=B
If anyone is so inclined, the patches in the following
PR's can be committed and the PR closed. These are
patches for gfortran.
69101 91960 95613 99139 99368 99798
100607 103795 103796 104626 105594 101967
101951 104649 106050 106500 107266 107406
107596
This is an opportunity for lurkers
On Wed, 7 Jun 2023, Jason Merrill wrote:
> On 6/6/23 14:29, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > In the second testcase of PR110122, during regeneration of the generic
> > lambda with V=Bar{}, substi
Range_operator and range_operator_float are 2 different classes, which
was not the original intent. This makes generalized dispatch to the
appropriate function more difficult. The distinction between what is a
float operator and what is an integral operator also blurs when some
methods have mu
This patch introduces a new dispatch mechanism for range_op_handler.
Instead of ad-hoc if then elses based on is_a and is_a,frange
*>, the discriminators in class vrange are used for each operand to
create a triplet, ie (III for "LHS = Irange, op1 = Irange, op2 =
Irange", and IFI for "Irange F
Range_operator had a tree code added last release to facilitate bitmask
operations. This was intended to be a temporary change until we could
figure out something more strategic going forward.
This patch removes the tree_code and replaces it with a virtual routine
to perform the masking. Each
We currently do not have any floating point operators where operand 1 is
a different type than the LHS. When we eventually do there is a bug in
fold_range. If either operand is a known NAN, it returns a NAN of the
type of operand 1 instead of the result type.
This patch sets it to the correct
> Begin forwarded message:
>
> From: Jason Merrill
> Subject: Re: [PATCH][RFC] c++: Accept elaborated-enum-base in system headers
> Date: 8 June 2023 at 19:06:36 BST
> To: Alex Coplan , gcc-patches@gcc.gnu.org
> Cc: Nathan Sidwell , Iain Sandoe
>
> On 6/8/23 07:06, Alex Coplan wrote:
>> Hi,
Hi,
Yes of course, I tested many days ago since regtesting takes several days
on my box, I should have retested !
But I got an account for the compile farm today, so I'm on it immediately,
I also see a divergence in the warnings on my box.
Thanks for the report !
Sincerely sorry,
Benjamin.
On Th
Hi Steve,
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
[...]
Thanks for the explanation. As I likely will not use a POWER-based
system, I only loosely followed the discussion. I don't remember
if ibm double-double is REAL(16) or REAL(17). If ieee 128-bit is
REAL(16), then
On 6/8/23 07:06, Alex Coplan wrote:
Hi,
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.
Upstream LLVM can be made to accept the above construct with
-Wno-error=ela
> On Jun 7, 2023, at 00:50, Ben Boeckel via Gcc-patches
> wrote:
>
> Hi,
>
> This patch series adds initial support for ISO C++'s [P1689R5][], a
> format for describing C++ module requirements and provisions based on
> the source code. This is required because compiling C++ with modules is
> no
The manual is incorrect in saying that the option does not warn
about designated initializers, which it does in C++. Whether the
divergence in behavior is desirable is another thing, but let's
at least make the manual match the reality.
PR c/39589
PR c++/96868
gcc/ChangeLog:
> On Jun 6, 2023, at 15:48, Benjamin Priour via Gcc-patches
> wrote:
>
> From: Benjamin Priour
>
> This patch enchances -Wanalyzer-out-of-bounds that is no longer paired
> with a -Wanalyzer-use-of-uninitialized-value on out-of-bounds-read.
>
> This also fixes PR analyzer/109437.
> Before ther
Le 08/06/2023 à 11:58, Tamar Christina via Gcc-patches a écrit :
Hi,
New version of the patch, I've omitted the explanation again 😊
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Hello,
this is not my area of expertise, but I saw the following:
+ /* [ns..ns
On Thu, Jun 08, 2023 at 12:17:02PM +0200, Thomas Koenig wrote:
> Hi together,
>
> > > On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
> > > > Hi,
> > > >
> > > > > I cannot see if there is proper support for kind=17 in your patch;
> > > > > at least the libgfortran/ieee/ieee_arithmetic.F90 par
Kewen:
On Wed, 2023-06-07 at 17:36 +0800, Kewen.Lin wrote:
> Hi,
>
> on 2023/6/7 03:54, Carl Love wrote:
> > On Mon, 2023-06-05 at 16:45 +0800, Kewen.Lin wrote:
> > > Hi Carl,
> > >
> > > on 2023/5/2 23:52, Carl Love via Gcc-patches wrote:
> > > > GCC maintainers:
> > > >
> > > > The following
Kewen, GCC maintainers:
Version 3, was able to get the overloaded version of scalar_insert_exp
to work and the change to xsxexpqp_f128_ define instruction to
work with the suggestions from Kewen.
Version 2, I have addressed the various comments from Kewen. I had
issues with adding an additiona
> > I'd very much like to see the condops go into GCC as well, but I've been
> > hesitant to move it forward myself. We're still waiting on hardware and
> > it wasn't clear to me that we really had consensus agreement to move the
> > bits forward based on an announcement vs waiting on actual hardw
Committed as passed all riscv.exp rvv.exp tests, thanks Jeff.
Pan
-Original Message-
From: Jeff Law
Sent: Thursday, June 8, 2023 10:01 PM
To: Li, Pan2 ; gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; rdapp@gmail.com; Wang, Yanzhang
; kito.ch...@gmail.com
Subject: Re: [PATCH v2]
On 6/6/23 21:50, Wang, Yanzhang wrote:
Hi Jeff,
Thanks your comments. I have few questions that I don't quite understand.
One of the things that needs to be upstreamed is long jump support within
a function. Essentially once a function reaches 1M in size we have the
real possibility that a
Hi all,
This patch implements RTL constant-folding for the SS_TRUNCATE and US_TRUNCATE
codes.
The semantics are a clamping operation on the argument with the min and max of
the narrow mode,
followed by a truncation. The signedness of the clamp and the min/max extrema
is derived from
the signedn
On Thu 8. Jun 2023 at 16:17, Jeff Law wrote:
>
>
> On 6/8/23 04:22, Kito Cheng wrote:
>
> >
> >
> > Oh, okay I got the awkness point...I am ok with that on gcc land, but I
> > would like binutils support that first, or remove the extension from the
> > mcpu for temporary before binutils support,
C++ requires inline functions to be declared inline and defined in
every translation unit that uses them. frange_nextafter is used in
gimple-range-op.cc but it's only defined as inline in
range-op-float.cc. Drop the extraneous inline specifier.
Other non-static inline functions in range-op-flo
In addition to Andreas's and Richard's comments:
Tamar Christina writes:
> +@item
> +@samp{@{@@} is followed by a layout in parentheses which is @samp{cons:}
> followed by
> +a list of @code{match_operand}/@code{match_scratch} comma operand numbers,
> then a
How about:
a comma-separated lis
On 6/8/23 04:22, Kito Cheng wrote:
Oh, okay I got the awkness point...I am ok with that on gcc land, but I
would like binutils support that first, or remove the extension from the
mcpu for temporary before binutils support, otherwise it just a broken
support for that CPU on trunk gcc.
I
On Thu, Jun 8, 2023 at 9:13 AM Jonathan Wakely wrote:
>
> On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
>
>>
>>
>> On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
>> libstd...@gcc.gnu.org> wrote:
>>
>>> Middle-end folks: any thoughts about how best to make the change
>>> descri
On 6/8/23 01:52, pan2...@intel.com wrote:
From: Pan Li
This patch would like to add new test cases to make sure the
RVV FP16 works well as expected.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/zvfh-intrinsic.c: Add new cases.
* gcc.target/ri
I like JuZhe's proposal too since it's a less invasive way :)
On Thu, Jun 8, 2023 at 9:18 PM Li, Pan2 via Gcc-patches
wrote:
>
> Thanks Juzhe for the idea. It looks work well as we expected, with the
> following try.
>
>
> 1. Allow all FP=16 types for vfadd, then _zvfh and _zvfhmin will be OK
Thanks Juzhe for the idea. It looks work well as we expected, with the
following try.
1. Allow all FP=16 types for vfadd, then _zvfh and _zvfhmin will be OK.
2. Add restriction define_attr as juzhe mentioned, then _zvfh works well,
and _zvfhmin will meet error like unsatisfied insn.
I th
On Fri, 26 May 2023 at 10:58, Jonathan Wakely wrote:
>
>
> On Wed, 24 May 2023 at 19:56, Jason Merrill via Libstdc++ <
> libstd...@gcc.gnu.org> wrote:
>
>> Middle-end folks: any thoughts about how best to make the change
>> described in
>> the last paragraph below?
>>
>> Library folks: any thought
> On Jun 7, 2023, at 6:05 PM, Joseph Myers wrote:
>
> On Wed, 7 Jun 2023, Qing Zhao via Gcc-patches wrote:
>
>> Are you suggesting to use identifier directly as the argument of the
>> attribute?
>> I tried this in the beginning, however, the current parser for the attribute
>> argument can n
On 01/06/2023 05:26, YunQiang Su wrote:
speculation_barrier for MIPS needs sync+jr.hb (r2+),
so we implement __speculation_barrier in libgcc, like arm32 does.
gcc/ChangeLog:
* config/mips/mips-protos.h (mips_emit_speculation_barrier): New
prototype.
* config/mips/mips.
Hi FX,
Am 06.06.23 um 21:29 schrieb FX Coudert via Gcc-patches:
Hi,
This is a repost of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html
which never really got green light, but I stopped pushing because stage 1 was
closing and I was out of time.
I just looke
On Thu, 8 Jun 2023 at 09:58, Maxim Kuvyrkov
wrote:
> Hi Jonathan,
>
> Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu
> on SPEC CPU2017's 641.leela_s benchmark [1].
>
> In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212
> bytes. This seems like a corne
Hi FX,
Having a POWER system isn't enough, it also needs the IBM "advance
toolchain", and (at least with current distros, which default to
ibm long double), you need to dance counterclockwise three
times... I mean you need to invoke configure with some special magic
Thanks for the frank descri
Hi,
This patch fixes the problem that the loop in the tsvc s176 function is
optimized and removed because `iterations/LEN_1D` is 0 (where iterations
is set to 1, LEN_1D is set to 32000 in tsvc.h).
This testcase passed on x86 and AArch64 system.
Best,
Lehua
gcc/testsuite/ChangeLog:
Hi,
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.
Upstream LLVM can be made to accept the above construct with
-Wno-error=elaborated-enum-base.
This macro expansi
On 08/06/2023 11:00, Tamar Christina via Gcc-patches wrote:
Hi All,
This converts some patterns in the AArch64 backend to use the new
compact syntax.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.md (arches): Ad
From: oluade01
This patch adds new RTL and tests for sabd and uabd
PR tree-optimization/109156
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (sabd, uabd):
Change the mode to 3.
* config/aarch64/aarch64-simd.md (aarch64_abd):
Rename to abd3.
*
> It would be good to add a:
>
> /* { dg-final { scan-assembler-not {\tabs\t} } } */
>
> to be the positive tests, to make it more obvious that all separate
> ABS instructions are elided.
Done.
Patch is in the next response.
On 08/06/2023 11:29, Richard Earnshaw (lists) via Gcc-patches wrote:
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
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
On 08/06/2023 11:12, Andreas Schwab wrote:
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
@@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
multi-alternative template:
@end group
@end smallexample
+@node Compact Syntax
+@section Compact Syntax
+@cindex compact sy
New patch to address issue brought up in a different
thread: mptjzwgplp2@arm.com
> > + /* Failed to find a widen operation so we check for a regular
> > MINUS_EXPR. */
> > + if (diff
> > + && gimple_assign_rhs_code (diff) == MINUS_EXPR
> > + && (TYPE_UNSIGNED (abs_type) || TYPE_O
> On Thu 8. Jun 2023 at 09:35, Kito Cheng via Gcc-patches <
> gcc-patches@gcc.gnu.org> wrote:
>
> > > diff --git a/gcc/config/riscv/riscv-cores.def
> > b/gcc/config/riscv/riscv-cores.def
> > > index 7d87ab7ce28..4078439e562 100644
> > > --- a/gcc/config/riscv/riscv-cores.def
> > > +++ b/gcc/config/
> Having a POWER system isn't enough, it also needs the IBM "advance
> toolchain", and (at least with current distros, which default to
> ibm long double), you need to dance counterclockwise three
> times... I mean you need to invoke configure with some special magic
Thanks for the frank descripti
Hi together,
On 6/6/23 21:11, FX Coudert via Gcc-patches wrote:
Hi,
I cannot see if there is proper support for kind=17 in your patch;
at least the libgfortran/ieee/ieee_arithmetic.F90 part does not
seem to have any related code.
Can real(kind=17) ever be an IEEE mode? If so, something seri
On Jun 08 2023, Tamar Christina via Gcc-patches wrote:
> @@ -713,6 +714,183 @@ you can use @samp{*} inside of a @samp{@@}
> multi-alternative template:
> @end group
> @end smallexample
>
> +@node Compact Syntax
> +@section Compact Syntax
> +@cindex compact syntax
> +
> +In cases where the num
Hi All,
This converts some patterns in the AArch64 backend to use the new
compact syntax.
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64.md (arches): Add nosimd.
(*mov_aarch64, *movsi_aarch64, *movdi_aarch6
Hi,
New version of the patch, I've omitted the explanation again 😊
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Thanks,
Tamar
gcc/ChangeLog:
* gensupport.cc (class conlist, add_constraints, add_attributes,
create_missing_attributes, skip_spaces
On Thu 8. Jun 2023 at 09:35, Kito Cheng via Gcc-patches <
gcc-patches@gcc.gnu.org> wrote:
> > diff --git a/gcc/config/riscv/riscv-cores.def
> b/gcc/config/riscv/riscv-cores.def
> > index 7d87ab7ce28..4078439e562 100644
> > --- a/gcc/config/riscv/riscv-cores.def
> > +++ b/gcc/config/riscv/riscv-cor
> On May 25, 2023, at 03:30, Cui, Lili via Gcc-patches
> wrote:
>
> From: Lili Cui
>
> Make some changes in reassoc pass to make it more friendly to fma pass later.
> Using FMA instead of mult + add reduces register pressure and insruction
> retired.
>
> There are mainly two changes
> 1. Put
From: Benjamin Priour
For the record, below is the previous patch I submitted, with the
little formatting issues fixed - multiline docstring no ends on a newline.
It was otherwise validated by David Malcolm, so I already committed it.
This patch enhances -Wanalyzer-out-of-bounds that is no longe
On Thu, Jun 08, 2023 at 10:05:43AM +0100, Jonathan Wakely via Gcc-patches wrote:
> > Looking at assembly, one of the differences I see is that the "after"
> > version has calls to realloc_insert(), while "before" version seems to have
> > them inlined [2].
> >
> > [1]
> > https://git.linaro.org/too
Thanks Gents!
The solution is to gfc_free_expr (p) if the replacement is not made.
I am regtesting a patch for PR107900. I'll include the fix for the
memory leak in the patch for that.
Cheers
Paul
On Thu, 8 Jun 2023 at 09:30, Harald Anlauf wrote:
>
> On 6/8/23 09:46, Mikael Morin wrote:
> >
On Thu, 8 Jun 2023 at 09:58, Maxim Kuvyrkov
wrote:
> Hi Jonathan,
>
> Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu
> on SPEC CPU2017's 641.leela_s benchmark [1].
>
> In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212
> bytes. This seems like a corne
Hi Jonathan,
Interestingly, this increases code-size of -O3 code on aarch64-linux-gnu on
SPEC CPU2017's 641.leela_s benchmark [1].
In particular, FastBoard::get_nearby_enemies() grew from 1444 to 2212 bytes.
This seems like a corner-case; the rest of SPEC CPU2017 is, mostly, neutral to
this p
I have an idea base on what Kito said.
We enable vfadd FP16 for TARGET_ZVFH. But we don't need to add TARGET_VECTOR &&
for each instruction.
We can reference riscv.md:
(define_attr "ext_enabled" "no,yes"
(cond [(eq_attr "ext" "base")
(const_string "yes")
(and (eq_attr "ext" "f")
On 6/8/23 09:46, Mikael Morin wrote:
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but h
Looks doable up to a point, I will have a try and keep you posted.
Pan
-Original Message-
From: Kito Cheng
Sent: Thursday, June 8, 2023 3:58 PM
To: juzhe.zh...@rivai.ai
Cc: Li, Pan2 ; gcc-patches ; Robin
Dapp ; jeffreyalaw ; Wang, Yanzhang
Subject: Re: [PATCH v8] RISC-V: Refactor req
Oh. Good suggestion. It's much better than my solution I think.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2023-06-08 15:58
To: juzhe.zh...@rivai.ai
CC: pan2.li; gcc-patches; Robin Dapp; jeffreyalaw; yanzhang.wang
Subject: Re: [PATCH v8] RISC-V: Refactor requirement of ZVFH and ZVFHMIN.
I am
I am thinking, is it possible to use mode attr to remove the overhead
of checking the mode for other FP modes other than FP16?
e.g.
(define_mode_attr TARGET_FP_FULL_OPERATION_CHECKING [
(VNx1HF "TARGET_ZVFH")
...
(VNx1SF "1")
...
])
"TARGET_VECTOR && riscv_vector::float_mode_supported_p (m
From: Pan Li
This patch would like to add new test cases to make sure the
RVV FP16 works well as expected.
Signed-off-by: Pan Li
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/zvfh-intrinsic.c: Add new cases.
* gcc.target/riscv/rvv/base/zvfh-over-zvfhmin.c: New test.
---
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but his comment was about the case gfc_rep
Bootstrap && Regression PASSed
Ok for trunk ?
juzhe.zh...@rivai.ai
From: juzhe.zhong
Date: 2023-06-08 10:05
To: gcc-patches
CC: richard.sandiford; rguenther; Ju-Zhe Zhong
Subject: [PATCH V5] VECT: Add SELECT_VL support
From: Ju-Zhe Zhong
Co-authored-by: Richard Sandiford
Co-authored-by: Ric
> diff --git a/gcc/config/riscv/riscv-cores.def
> b/gcc/config/riscv/riscv-cores.def
> index 7d87ab7ce28..4078439e562 100644
> --- a/gcc/config/riscv/riscv-cores.def
> +++ b/gcc/config/riscv/riscv-cores.def
> @@ -38,6 +38,7 @@ RISCV_TUNE("sifive-3-series", generic, rocket_tune_info)
> RISCV_TUNE(
81 matches
Mail list logo
