Alan,
Thanks for your info. Just notice your patch. I will wait for your
patch being reviewed.
On 3/2/2021 上午 10:32, Alan Modra wrote:
On Fri, Jan 29, 2021 at 11:11:23AM +0800, HAO CHEN GUI via Gcc-patches wrote:
This patch tries to optimize PowerPC 64 bit constant generation when the
Hi,
This patch merges the previously approved one[1] and its relied patch
made by Segher here[2], it's to make unsigned int vector init go with
rldimi to merge two integers instead of shift and ior.
Segher's patch in [2] is required to make the test case pass,
otherwise the costing for new pseudo
> > Could you extract the endian related LINK_SPEC change to
> > ENDIAN_LINK_SPEC to riscv.h, so that we can prevent
> > duplicate this several times.
>
> You mean a define which expands to
>
> "-melf" XLEN_SPEC DEFAULT_ENDIAN_SPEC "riscv"
Yeah, but I'd like to include following 2 lines too:
%{
On Fri, Jan 29, 2021 at 11:11:23AM +0800, HAO CHEN GUI via Gcc-patches wrote:
> This patch tries to optimize PowerPC 64 bit constant generation when the
> constant can be transformed from a 32 bit or 16 bit constant by rotating,
> shifting and mask AND.
All and more of what you are doing here f
On 2/2/21 2:29 PM, David Malcolm wrote:
On Tue, 2021-02-02 at 12:57 -0700, Martin Sebor via Gcc-patches wrote:
The strlen pass initializes its pointer_query member object with
a cache consisting of a couple of vec's. Because vec doesn't
implement RAII its memory must be explicitly released to a
Hi,
With the following patch:
[qinzhao@localhost gcc]$ git diff tree-ssa-structalias.c
diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index cf653be..bd18841 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -4851,6 +4851,30 @@ find_func_aliases_for_
On 2/2/21 2:21 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> The following testcase has ice-on-invalid, it can't be reloaded, but we
> shouldn't ICE the compiler because the user typed non-sense.
>
> In current_insn_transform we have:
> if (process_alt_operands (reused_alternative_num))
>
On 2/2/21 2:29 AM, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, RTL ifcvt can throw random RTL (whatever it found in
> some insns) at expand_binop or expand_unop and expects it to do something
> (and then will check if it created valid insns and punts if not).
> These functions in the e
I merged trunk revision 8e4a738d2540ab6aff77506d368bf4e3fa6963bd to
the gccgo branch.
Ian
On 2021-01-28 5:40 a.m., Ilya Leoshkevich via Gcc-patches wrote:
Hello,
I would like to ping the following patch:
lra: clear lra_insn_recog_data after simplifying a mem subreg
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563428.html
Sorry, I missed your original email. The patch i
I saw the gcc.gnu.org at the end of the address and did not realize
the link was not part gnu.org.
The gcc.gnu.org link is:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564239.html
with the attachment at
https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210125/b5a7df3b/attachment-
Changes in this version from Version 6:
Updated copyrights for following three files to -2021.
gcc/c-family/c-cppbuiltin.c
Moved code for setting LIBGCC modename to FUNC_EXT section.
Added code to set modename for any additional modes such as
FLT128 or FLT64X
Here we crash with a noexcept-specifier in a nested template class,
because my handling of such deferred-parse noexcept-specifiers was
gronked when we need to instantiate a DEFERRED_PARSE before it was
actually parsed at the end of the outermost class.
In
struct S {
template struct B {
Hi,
On Mon, Feb 01, 2021 at 11:24:42PM -0500, Michael Meissner wrote:
> In PR target/98519, the assembler does not like asm memory references that are
> prefixed. We can't automatically change the instruction to prefixed form with
> a 'p' like we do for normal RTL insns, since this is assembly co
On Tue, 2021-02-02 at 12:57 -0700, Martin Sebor via Gcc-patches wrote:
> The strlen pass initializes its pointer_query member object with
> a cache consisting of a couple of vec's. Because vec doesn't
> implement RAII its memory must be explicitly released to avoid
> memory leaks. The attached pa
This patch to the gotools Makefile runs "go test
embed/internal/embedtest" using the newly built go tool, to test that
file embedding works. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainline.
Ian
* Makefile.am (check-embed): New target.
(check): Depend on check-emb
The strlen pass initializes its pointer_query member object with
a cache consisting of a couple of vec's. Because vec doesn't
implement RAII its memory must be explicitly released to avoid
memory leaks. The attached patch adds a dtor to
the strlen_dom_walker to do that.
Tested on x86_64-linux a
Pushed to master.
gcc/testsuite/ChangeLog:
PR target/97510
* gcc.target/i386/pr97510.c: New test.
---
gcc/testsuite/gcc.target/i386/pr97510.c | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 gcc/testsuite/gcc.target/i386/pr97510.c
diff --git a/gcc/t
On Tue, Feb 02, 2021 at 11:39:30AM -0700, Jeff Law wrote:
> > This patch adds some ctz simplifications (e.g. ctz (x) >= 3 can be done by
> > testing if the low 3 bits are zero, etc.).
> >
> > In addition, I've noticed that in the CLZ case, the
> > #ifdef CLZ_DEFINED_VALUE_AT_ZERO don't really work
On 1/16/21 11:19 AM, Jakub Jelinek via Gcc-patches wrote:
> Hi!
>
> This patch adds some ctz simplifications (e.g. ctz (x) >= 3 can be done by
> testing if the low 3 bits are zero, etc.).
>
> In addition, I've noticed that in the CLZ case, the
> #ifdef CLZ_DEFINED_VALUE_AT_ZERO don't really work
On 1/16/21 11:13 AM, Jakub Jelinek wrote:
> Hi!
>
> The following patch tests both x / y * y and x - x % y expansion for the
> former GIMPLE code and chooses the cheaper of those sequences.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2021-01-16 Jakub Jelinek
>
Hi All,
Previously the SLP pattern matcher was using STMT_VINFO_SLP_VECT_ONLY as a way
to dissolve the SLP only patterns during SLP cancellation. However it seems
like the semantics for STMT_VINFO_SLP_VECT_ONLY are slightly different than what
I expected.
Namely that the non-SLP path can still u
This fixes various vec<> memory leaks as discovered compiling 521.wrf_r.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
2021-02-02 Richard Biener
* gimple-loop-interchange.cc (prepare_data_references):
Release vectors.
* gimple-loop-jam.c (tree_loop_unrol
> -Original Message-
> From: Andre Vieira (lists)
> Sent: 02 February 2021 17:27
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov ; ja...@redhat.com
> Subject: Re: [PATCH] arm: Fix up neon_vector_mem_operand [PR97528]
>
> Hi,
>
> This is a gcc-9 backport of the PR97528 fix that has b
Changes in this version from Version 6:
Updated copyrights for following three files to -2021.
gcc/c-family/c-cppbuiltin.c
Moved code for setting LIBGCC modename to FUNC_EXT section.
Added code to set modename for any additional modes such as
FLT128 or FLT64X
On Tue, 2 Feb 2021, Richard Sandiford wrote:
> Richard Biener writes:
> > On January 30, 2021 11:52:20 AM GMT+01:00, Jakub Jelinek
> > wrote:
> >>On Sat, Jan 30, 2021 at 11:47:24AM +0100, Richard Biener wrote:
> >>> OK, so I'd prefer we simply unset the flag after processing deferred
> >>rescan
Hi,
This is a gcc-9 backport of the PR97528 fix that has been applied to
trunk and gcc-10.
Bootstraped on arm-linux-gnueabihf and regression tested.
OK for gcc-9 branch?
2021-02-02 Andre Vieira
Backport from mainline
2020-11-20 Jakub Jelinek
PR target/97528
* config/ar
Hi Thomas,
On 02.02.21 15:54, Thomas Koenig wrote:
So, while your patch is OK, I think a simple removal of the test
is also OK.
Take your pick :-)
I think I will do a combination: If 'identical' is true, I think I
cannot remove it. If it is false, it can be identical or nonoverlapping
– which
On Jan 28, 2021, Richard Biener wrote:
> That would allow turning back the memset into the original loop (but
> with optimal IVs, etc.).
Is this sort of what you had in mind?
I haven't tested the inline expansion of memset much yet; and that of
memcpy, not at all; this really is mainly to check
Richard Biener writes:
> On January 30, 2021 11:52:20 AM GMT+01:00, Jakub Jelinek
> wrote:
>>On Sat, Jan 30, 2021 at 11:47:24AM +0100, Richard Biener wrote:
>>> OK, so I'd prefer we simply unset the flag after processing deferred
>>rescan. I clearly misread the function to do that.
>>
>>This wo
My patch for 96199 had us re-substitute the parameter types of a constructor
in order to rewrite mentions of members into dependent references. We need
to do that for member functions, too.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
PR c++/98929
PR c++/9619
(added fortran@ at it is about Fortran)
I note that some lines in the testcase are commented (polymorphic
arrays), but I note further that Patch 3/4 enables them.
On 02.02.21 14:28, Julian Brown wrote:
Derived-type members that are themselves derived types are not always
represented as pointers
Richard Biener writes:
> On Tue, Feb 2, 2021 at 4:03 PM Richard Sandiford
> wrote:
>>
>> Richard Biener writes:
>> > On Mon, Feb 1, 2021 at 6:54 PM Joel Hutton wrote:
>> >>
>> >> Hi Richard(s),
>> >>
>> >> I'm just looking to see if I'm going about this the right way, based on
>> >> the discus
Hi,
first, I have attached a new example – it works if I move bar/hello up,
but if 'foo' comes first, it fails. I think it is valid.
(ifort 19 also compiles it.)
Sorry for trying hard to find examples where it does not
work – but I have simply the feeling that resolving things
during parsing can
Hi all,
Another very simple move from inline asm to builtins.
Only two intrinsics this time.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.
Pushing to trunk.
Thanks,
Kyrill
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (ursqrte): Define builtin.
Hi all,
Another transition from inline asm to builtin.
Only 3 intrinsics converted this time but they use the "+w" constraint in their
inline asm
so are more likely to generate redundant moves so benefit more from
reimplementation.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_b
> On Feb 2, 2021, at 1:43 AM, Richard Biener wrote:
>
> On Mon, 1 Feb 2021, Qing Zhao wrote:
>
>> Hi, Richard,
>>
>> I have adjusted SRA phase to split calls to DEFERRED_INIT per you suggestion.
>>
>> And now the routine “bump_map” in 511.povray is like following:
>> ...
>>
>> # DEBUG BEGI
On Tue, Feb 2, 2021 at 4:03 PM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Feb 1, 2021 at 6:54 PM Joel Hutton wrote:
> >>
> >> Hi Richard(s),
> >>
> >> I'm just looking to see if I'm going about this the right way, based on
> >> the discussion we had on IRC. I've managed to
Hi Tobias,
ifort (IFORT) 2021.1 Beta 20201112 is happy with the testcase in the patch.
In foo.f90, if I remove
call var(i) ! { dg-bogus "VARIABLE attribute of 'var' conflicts with
PROCEDURE attribute" }
gfortran correctly complains
23 | associate (var => bar())
|
Richard Biener writes:
> On Mon, Feb 1, 2021 at 6:54 PM Joel Hutton wrote:
>>
>> Hi Richard(s),
>>
>> I'm just looking to see if I'm going about this the right way, based on the
>> discussion we had on IRC. I've managed to hack something together, I've
>> attached a (very) WIP patch which gives
On 27/01/21 21:42 +0100, Matthias Kretz wrote:
From: Matthias Kretz
In many failure cases it is helpful to inspect the instructions leading
up to the test failure. After this change the location is easier to find
and the branch after failure is easier to find.
libstdc++-v3/ChangeLog:
*
Am 02.02.21 um 12:46 schrieb Tobias Burnus:
Hi all,
the attached patch now handles -fcoarray=single and access to the local
image like no coarray access, using the same check a before.
Actually, I think we could remove the if (..coarray..) check completely:
For 'single', it is like no coarrays;
On 2/2/21 1:19 AM, Ed Smith-Rowland wrote:
On 2/2/21 12:12 AM, Jason Merrill wrote:
On 2/1/21 9:15 PM, Ed Smith-Rowland wrote:
On 2/1/21 2:23 PM, Jakub Jelinek wrote:
On Mon, Feb 01, 2021 at 01:46:13PM -0500, Ed Smith-Rowland wrote:
@@ -0,0 +1,8 @@
+// { dg-do compile { target c++23 } }
+
+#i
o apply the patch but, sorry, how do I proceed?
Where in the gcc tree to apply the patch file?
Should I use git apply or diff? e.g. it does not work with
$ pwd
/home/bigpack/gcc-paq/sources/gcc-11.0-20210202
$ git apply dep-caf.diff
error: patch failed: gcc/fortran/dependency.c:30
error: g
On Tue, Feb 2, 2021 at 2:56 PM Jakub Jelinek wrote:
>
> On Tue, Feb 02, 2021 at 02:23:55PM +0100, Richard Biener wrote:
> > Btw, I just can find V1DI mentioned in mmx.md but I can't find
> > rotate or shift patterns that would match?
>
> The backend has several V1?Imode shifts, but optab only for
Hi Paul,
On 02.02.21 13:20, Paul Richard Thomas via Gcc-patches wrote:
This is more or less 'obvious' and does not require any further explanation.
Well, I am not sure whether calling resolve is premature or not. In any
case, it still fails for the attached testcase. (Related but separate
issu
On Tue, Feb 02, 2021 at 02:23:55PM +0100, Richard Biener wrote:
> Btw, I just can find V1DI mentioned in mmx.md but I can't find
> rotate or shift patterns that would match?
The backend has several V1?Imode shifts, but optab only for those V1DImode
ones:
grep '[la]sh[lr]v1[qhsdtox]' tmp-mddump.md
On Mon, Feb 1, 2021 at 6:54 PM Joel Hutton wrote:
>
> Hi Richard(s),
>
> I'm just looking to see if I'm going about this the right way, based on the
> discussion we had on IRC. I've managed to hack something together, I've
> attached a (very) WIP patch which gives the correct codegen for the tes
This patch fixes lowering of derived-type mappings which select elements
of arrays of derived types, and similar. These would previously lead
to ICEs.
With this change, update directives and enter/exit data directives can
pass through constructs that are no longer recognized by the gimplifier,
hen
OpenACC 3.0 ("2.14.4. Update Directive") states:
Noncontiguous subarrays may appear. It is implementation-specific
whether noncontiguous regions are updated by using one transfer for
each contiguous subregion, or whether the non-contiguous data is
packed, transferred once, and unpacked, or
Elsewhere in the Fortran front-end, the class_pointer attribute is
used for BT_CLASS entities instead of the pointer attribute. This patch
follows suit for OpenACC. I couldn't actually come up with a test case
where this makes a difference (i.e., where "class_pointer" and "pointer"
have different v
Derived-type members that are themselves derived types are not always
represented as pointers, so it is not always correct to dereference
them. The attached test case fails during gimplification without this
patch.
Tested with offloading to AMD GCN. OK for mainline?
Thanks,
Julian
2020-02-02 J
This patch series fixes support for mixing arbitrary derived type
accesses and array element accesses in OpenACC directives, and fixes a
bug in derived-type lowering.
Somewhat relatedly, it also allows strided accesses in update directives.
Further commentary alongside each patch. Some of the tes
On Tue, 2 Feb 2021, Jakub Jelinek wrote:
> On Tue, Feb 02, 2021 at 11:06:33AM +0100, Richard Biener wrote:
> > So I fear this only covers parts of the paths simplifications can
> > end up used. Now one question is whether we want to allow
> > "invalid" intermediate transforms if a final match mak
On Tue, Feb 02, 2021 at 11:06:33AM +0100, Richard Biener wrote:
> So I fear this only covers parts of the paths simplifications can
> end up used. Now one question is whether we want to allow
> "invalid" intermediate transforms if a final match makes it
> "valid" again. If not then doing the veri
This is more or less 'obvious' and does not require any further explanation.
Regtests with FC33/x86_64 - OK for master (and )?
Paul
Fortran: Fix calls to associate name typebound subroutines [PR98897].
2021-02-02 Paul Thomas
gcc/fortran
PR fortran/98897
* match.c (gfc_match_call): Inclu
Hi all,
This patch updates the flags for the bfloat16 builtins.
The bfdot ones aren't affected by the FPCR/FPSR so can be AUTO_FP
whereas the bfmlal ones follow the normal floating-point instructions and get
FP.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill
Hi all,
We already have a STORE flag that we use for builtins. This patch introduces a
LOAD set
that uses AUTO_FP and FLAG_READ_MEMORY. This allows for more aggressive
optimisation of the load
intrinsics.
Turns out we have a great many testcases that do:
float16x4x2_t
f_vld2_lane_f16 (float16_t
Hi all,
This patch relaxes the flags for some builtins to AUTO_FP. These builtins do
permutes
and similar, so they shouldn't get the FP flags when operating on
floating-point modes
as they don't care about FPCR/FPSR and exceptions.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to t
Hi all,
This patch relaxes various floating-point builtins to use the FP flags to
signify they
made use the FPCR or raise exceptions.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill
gcc/ChangeLog:
* config/aarch64/aarch64-simd-builtins.def (fcmla_lan
Hi all,
This patch relaxes the flags for most integer builtins to NONE as they don't
read/write memory
and don't care about the FPCR/FPSR or exceptions so we should be more
aggressive with them.
This leads to fallout in a testcase where the result of an intrinsic was unused
and it is now
DCE'd
Hi all,
the attached patch now handles -fcoarray=single and access to the local
image like no coarray access, using the same check a before.
Actually, I think we could remove the if (..coarray..) check completely:
For 'single', it is like no coarrays; for 'lib' both AA[remote] =... and
"AA = ...
On Linux/x86_64,
6e0a231a4aa2407bb7167daf98a37795a67364d8 is the first bad commit
commit 6e0a231a4aa2407bb7167daf98a37795a67364d8
Author: Jason Merrill
Date: Wed Jan 27 17:15:39 2021 -0500
c++: alias in qualified-id in template arg [PR98570]
caused
FAIL: g++.dg/modules/xtreme-header-1_a.
On 01/02/21 16:08 +, Jonathan Wakely wrote:
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2011.xml: Update std::call_once
status.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise. Update
std::from_chars
On Tue, 2 Feb 2021, Przemyslaw Wirkus wrote:
> > On 2021-01-18 7:50 a.m., Richard Biener wrote:
> > > On Mon, 18 Jan 2021, Przemyslaw Wirkus wrote:
> > >
> > >> Hi all,
> > >>
> > >> Can we backport PR97969 patch to GCC 10 and (maybe) GCC 9 ?:
> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97
On Tue, 2 Feb 2021, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because after the veclower pass which is the
> last point which lowers unsupported vector operations to supported ones
> (or scalars) match.pd simplifies a supported vector operation into
> unsupported one (vec << 1 >
> On 2021-01-18 7:50 a.m., Richard Biener wrote:
> > On Mon, 18 Jan 2021, Przemyslaw Wirkus wrote:
> >
> >> Hi all,
> >>
> >> Can we backport PR97969 patch to GCC 10 and (maybe) GCC 9 ?:
> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97969
> >>
> >> IMHO bug is severe and could land in GCC 10 an
Jakub Jelinek via Gcc-patches writes:
> On Tue, Feb 02, 2021 at 09:38:09AM +, Richard Sandiford wrote:
>> > +default:
>> > + if (!VECTOR_MODE_P (mode))
>> > + return true;
>> > + op = optab_for_tree_code (code, type, optab_default);
>> > + if (op == unknown_optab
>> > +
On Tue, Feb 02, 2021 at 09:38:09AM +, Richard Sandiford wrote:
> > +/* In PROP_gimple_lvec mode, perform extra checking if RES_OP and return
> > + true if RES_OP is not appropriate - would require vector operations that
> > + would need to be lowered before expansion. */
> > +
> > +bool
>
Jakub Jelinek via Gcc-patches writes:
> Hi!
>
> The following testcase ICEs, because after the veclower pass which is the
> last point which lowers unsupported vector operations to supported ones
> (or scalars) match.pd simplifies a supported vector operation into
> unsupported one (vec << 1 >> 1
Hi!
As the testcase shows, RTL ifcvt can throw random RTL (whatever it found in
some insns) at expand_binop or expand_unop and expects it to do something
(and then will check if it created valid insns and punts if not).
These functions in the end if the operands don't match try to
copy_to_mode_reg
Hi!
The following testcase has ice-on-invalid, it can't be reloaded, but we
shouldn't ICE the compiler because the user typed non-sense.
In current_insn_transform we have:
if (process_alt_operands (reused_alternative_num))
alt_p = true;
if (check_only_p)
return ! alt_p || best_lose
On Tue, 2 Feb 2021, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, the reduction code isn't able to cope with type
> promotions/demotions in the reduction computation, so if we recognize an
> over-widening pattern that has vect_reduction_def type, we most likely make
> it non-vectorizable
Hi!
The following testcase ICEs, because after the veclower pass which is the
last point which lowers unsupported vector operations to supported ones
(or scalars) match.pd simplifies a supported vector operation into
unsupported one (vec << 1 >> 1 into vec & { ~1, ... }).
Guarding each match.pd pa
Hi!
As discussed in the PR, the reduction code isn't able to cope with type
promotions/demotions in the reduction computation, so if we recognize an
over-widening pattern that has vect_reduction_def type, we most likely make
it non-vectorizable.
Fixed thusly, bootstrapped/regtested on x86_64-linu
Hi!
This testcase has been fixed by
r11-5904-g4cf70c20cb10acd6fb1016611d05540728176b60
so I'm checking it in so that we can close the PR.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk as
obvious.
2021-02-02 Jakub Jelinek
PR tree-optimization/97960
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
> >with BLKmode will
On Tue, Feb 02, 2021 at 08:51:07AM +0100, Richard Biener wrote:
> > Shouldn't we gather statistics from larger codebase first and perhaps
> > compare against tree-ssa-dse statistics? I mean, in many functions there
> > are no DSE opportunities at all.
>
> Of course. Some DSE will definitely be r
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
>with BLKmode will cause ICE.
>
> - Verified with riscv64, x86_64 and aarch64, no introduce new regression.
>
> Note: Those logic was introduced by 3e6
> -Original Message-
> From: Christophe Lyon
> Sent: 02 February 2021 07:19
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] arm: Auto-vectorization for MVE: vorn
>
> On Mon, 1 Feb 2021 at 10:08, Kyrylo Tkachov
> wrote:
> >
> >
> >
> > > -Original Message-
80 matches
Mail list logo
