ping^2?
On Wed, 30 Dec 2020 at 11:34, Christophe Lyon
wrote:
>
> ping?
>
> On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
> wrote:
> >
> > This patch enables MVE vshr instructions for auto-vectorization. New
> > MVE patterns are introduced that take a vector o
ping^2?
On Wed, 30 Dec 2020 at 11:34, Christophe Lyon
wrote:
>
> ping?
>
> On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
> wrote:
> >
> > This patch enables MVE vshlq instructions for auto-vectorization.
> >
> > The existing mve_vshlq_n_ is kept, as it
ping^2?
On Wed, 30 Dec 2020 at 11:33, Christophe Lyon
wrote:
>
> ping?
>
> On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
> wrote:
> >
> > This patch adds new movmisalign_mve_load and store patterns for
> > MVE to help vectorization. They are very similar to the
ping?
On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
wrote:
>
> This patch enables MVE vshr instructions for auto-vectorization. New
> MVE patterns are introduced that take a vector of constants as second
> operand, all constants being equal.
>
> The existing mve_vshrq_n_ is
ping?
On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
wrote:
>
> This patch enables MVE vshlq instructions for auto-vectorization.
>
> The existing mve_vshlq_n_ is kept, as it takes a single
> immediate as second operand, and is used by arm_mve.h.
>
> We move the vas
ping?
On Thu, 17 Dec 2020 at 18:48, Christophe Lyon
wrote:
>
> This patch adds new movmisalign_mve_load and store patterns for
> MVE to help vectorization. They are very similar to their Neon
> counterparts, but use different iterators and instructions.
>
> Indeed MVE supports
Le ven. 18 déc. 2020 à 18:03, Patrick Palka a écrit :
> On Fri, 18 Dec 2020, Christophe Lyon wrote:
>
> > On Fri, 18 Dec 2020 at 16:00, Patrick Palka wrote:
> > >
> > > On Fri, 18 Dec 2020, Christophe Lyon wrote:
> > >
> > > > Hi,
> >
On Fri, 18 Dec 2020 at 16:00, Patrick Palka wrote:
>
> On Fri, 18 Dec 2020, Christophe Lyon wrote:
>
> > Hi,
> >
> >
> > On Fri, 18 Dec 2020 at 05:13, Patrick Palka via Gcc-patches
> > wrote:
> > >
> > > On Thu, Dec 17, 2020 at 9:32 AM J
On Fri, 18 Dec 2020 at 17:20, Tamar Christina wrote:
>
> Hi Christoph,
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Friday, December 18, 2020 2:22 PM
> > To: Tamar Christina
> > Cc: gcc Patches ; Richard Earnshaw
> > ; n
On Wed, 16 Dec 2020 at 21:43, Tamar Christina via Gcc-patches
wrote:
>
> Hi All,
>
> This refactors the complex numbers bits of MVE to go through the same unspecs
> as the NEON variant.
>
> This is pre-work to allow code to be shared between NEON and MVE for the
> complex
> vectorization
Hi,
On Fri, 18 Dec 2020 at 05:13, Patrick Palka via Gcc-patches
wrote:
>
> On Thu, Dec 17, 2020 at 9:32 AM Jonathan Wakely wrote:
> >
> > On 19/08/20 17:57 -0400, Patrick Palka via Libstdc++ wrote:
> > >On Wed, 22 Jul 2020, Patrick Palka wrote:
> > >
> > >> On Mon, 20 Jul 2020, Patrick Palka
.
The vashr3 and vlshr3 expanders are moved fron neon.md to
vec-common.md, updated to rely on the normal expansion scheme to
generate shifts by immediate.
2020-12-03 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vshrq_n_s_imm): New entry.
(mve_vshrq_n_u_imm): Likewise
ote: vect_is_simple_use: vectype vector(8) short int
mve-vshl.c:37:117: missed: not vectorized: relevant stmt not supported: _5 =
(int) _4;
mve-vshl.c:37:96: missed: bad operation or unsupported loop bound.
mve-vshl.c:37:96: note: * Analysis failed with vector mode V8HI
2020-12-03 Chris
2020-12-15 Christophe Lyon
PR target/97875
gcc/
* config/arm/arm.h (ARM_HAVE_NEON_V8QI_LDST): New macro.
(ARM_HAVE_NEON_V16QI_LDST, ARM_HAVE_NEON_V4HI_LDST): Likewise.
(ARM_HAVE_NEON_V8HI_LDST, ARM_HAVE_NEON_V2SI_LDST): Likewise
On Wed, 2 Dec 2020 at 04:31, Daniel Engel wrote:
>
> Hi Christophe,
>
> On Thu, Nov 26, 2020, at 1:14 AM, Christophe Lyon wrote:
> > Hi,
> >
> > On Fri, 13 Nov 2020 at 00:03, Daniel Engel wrote:
> > >
> > > Hi,
> > >
> > > Thi
On Fri, 25 Sept 2020 at 16:31, Tamar Christina wrote:
>
> Hi All,
>
> This adds support to the auto-vectorizer to support HFmode vectorization for
> AArch32. This is supported when +fp16 is used. I wonder if I should disable
> the returning of the type if the option isn't enabled.
>
> At the
for VDQW
and VH in neon.md, when WDQWH handles both, and patterns
with VDQ have provision for attributes for FP modes.
Another question is why 2 always sets
neon_abs type when it also handles neon_neq cases.
2020-12-11 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vnegq_f): Use
This patch enables MVE vmvnq instructions for auto-vectorization. MVE
vmvnq insns in mve.md are modified to use 'not' instead of unspec
expression to support one_cmpl2. The one_cmpl2 expander
is added to vec-common.md.
2020-12-11 Christophe Lyon
gcc/
* config/arm
This patch enables MVE vbic instructions for auto-vectorization. MVE
vbicq insns in mve.md are modified to use 'and not' instead of unspec
expression.
2020-12-11 Christophe Lyon
gcc/
* config/arm/iterators.md (supf): Remove VBICQ_S and VBICQ_U.
(VBICQ): Remove
This patch enables MVE veorq instructions for auto-vectorization. MVE
veorq insns in mve.md are modified to use xor instead of unspec
expression to support xor3. The xor3 expander is added to
vec-common.md
2020-12-11 Christophe Lyon
gcc/
* config/arm/iterators.md (supf
On Fri, 11 Dec 2020 at 17:35, Kyrylo Tkachov wrote:
>
>
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 11 December 2020 16:33
> > To: gcc-patches@gcc.gnu.org
> > Subject: [PATCH] ar
The patch restores the unconditional definition of the VDQ iterator,
and changes the conditions of the vand and vorr expanders to use
ARM_HAVE__ARITH.
2020-12-11 Christophe Lyon
gcc/
* config/arm/iterators.md (VDQ): Remove TARGET_HAVE_MVE
conditions.
* config
On Wed, 9 Dec 2020 at 17:47, Richard Sandiford
wrote:
>
> Christophe Lyon via Gcc-patches writes:
> > Hi,
> >
> > I've been working for a while on enabling auto-vectorization for ARM
> > MVE, and I find it a bit awkward to keep things common with Neon as
> >
On Tue, 8 Dec 2020 at 15:00, Kyrylo Tkachov wrote:
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: 08 December 2020 13:59
> > To: Kyrylo Tkachov
> > Cc: gcc-patches@gcc.gnu.org
> > Subject: Re: [PATCH 1/5] arm: Auto-vectorizatio
On Tue, 8 Dec 2020 at 14:19, Kyrylo Tkachov wrote:
>
> Hi Christophe
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 08 December 2020 13:06
> > To: gcc-patches@gcc.gnu.org
> > Subject
Hi,
I've been working for a while on enabling auto-vectorization for ARM
MVE, and I find it a bit awkward to keep things common with Neon as
much as possible.
I've just sent a few patches for logical operators
(vand/vorr/veor/vbic), and I have a few more WIP patches where I
struggle to avoid
This patch enables MVE vorrq instructions for auto-vectorization. MVE
vorrq insns in mve.md are modified to use ior instead of unspec
expression to support ior3. The ior3 expander is added to
vec-common.md
2020-12-03 Christophe Lyon
gcc/
* config/arm/iterators.md (supf
This patch enables MVE vmvnq instructions for auto-vectorization. MVE
vmvnq insns in mve.md are modified to use 'not' instead of unspec
expression to support one_cmpl2. The one_cmpl2 expander
is added to vec-common.md.
2020-12-03 Christophe Lyon
gcc/
* config/arm
This patch enables MVE vbic instructions for auto-vectorization. MVE
vbicq insns in mve.md are modified to use 'and not' instead of unspec
expression.
2020-12-03 Christophe Lyon
gcc/
* config/arm/iterators.md (supf): Remove VBICQ_S and VBICQ_U.
(VBICQ): Remove
This patch enables MVE vandq instructions for auto-vectorization. MVE
vandq insns in mve.md are modified to use 'and' instead of unspec
expression to support and3. The and3 expander is added to
vec-common.md
2020-12-03 Christophe Lyon
gcc/
* config/arm/iterators.md (supf
This patch enables MVE veorq instructions for auto-vectorization. MVE
veorq insns in mve.md are modified to use xor instead of unspec
expression to support xor3. The xor3 expander is added to
vec-common.md
2020-12-04 Christophe Lyon
gcc/
* config/arm/iterators.md (supf
On Thu, 3 Dec 2020 at 13:33, Richard Biener via Gcc-patches
wrote:
>
> On Thu, Dec 3, 2020 at 11:49 AM Eric Botcazou wrote:
> >
> > Hi,
> >
> > this replaces the ICE by a sorry message for the use of reverse scalar
> > storage
> > order with a 128-bit decimal floating-point type on 32-bit
Hi Alexandre,
On Wed, 2 Dec 2020 at 19:23, Jeff Law via Gcc-patches
wrote:
>
>
>
> On 11/10/20 7:35 PM, Alexandre Oliva wrote:
> > This patch introduces maybe_emit_call_builtin___clear_cache for the
> > builtin expander machinery and the trampoline initializers to use to
> > clear the
On Fri, 27 Nov 2020 at 19:46, Matthew Malcomson
wrote:
>
> Hello,
>
> -
>
> This test should ensure that we can compile with hwasan, that such a compiled
> binary runs as expected, *and* that we're running on a kernel which implements
> the capability to ignore the top bytes of pointers in
On Mon, 30 Nov 2020 at 15:58, Jonathan Wakely wrote:
>
> On 27/11/20 21:17 +0100, Christophe Lyon via Libstdc++ wrote:
> >On Fri, 27 Nov 2020 at 17:13, Jonathan Wakely via Gcc-patches
> > wrote:
> >>
> >> The default for the GCC testsuite is 300, i.
On Fri, 27 Nov 2020 at 16:29, Christophe Lyon
wrote:
>
> On Fri, 27 Nov 2020 at 15:13, Andre Vieira (lists)
> wrote:
> >
> > Hi Christophe,
> >
> > On 26/11/2020 15:31, Christophe Lyon wrote:
> > > Hi Andre,
> > >
> > > Thanks for
On Fri, 27 Nov 2020 at 17:13, Jonathan Wakely via Gcc-patches
wrote:
>
> The default for the GCC testsuite is 300, i.e. 5 minutes, which is the
> same as the DejaGnu default.
>
> Libstdc++ overrides this to 600, i.e. 10 minutes.
>
> This seems ridiculously long. If any test takes that long on
On Fri, 27 Nov 2020 at 15:13, Andre Vieira (lists)
wrote:
>
> Hi Christophe,
>
> On 26/11/2020 15:31, Christophe Lyon wrote:
> > Hi Andre,
> >
> > Thanks for the quick feedback.
> >
> > On Wed, 25 Nov 2020 at 18:17, Andre Simoes Dias Vieira
> &
On Fri, 27 Nov 2020 at 02:03, Stam Markianos-Wright
wrote:
>
> On 26/11/2020 09:01, Christophe Lyon wrote:
> > On Wed, 25 Nov 2020 at 14:24, Stam Markianos-Wright via Gcc-patches
> > wrote:
> >>
> >> Hi all,
> >&g
Hi Andre,
Thanks for the quick feedback.
On Wed, 25 Nov 2020 at 18:17, Andre Simoes Dias Vieira
wrote:
>
> Hi Christophe,
>
> Thanks for these! See some inline comments.
>
> On 25/11/2020 13:54, Christophe Lyon via Gcc-patches wrote:
> > This patch enables MVE van
Hi,
On Fri, 13 Nov 2020 at 00:03, Daniel Engel wrote:
>
> Hi,
>
> This patch adds an efficient assembly-language implementation of IEEE-754
> compliant floating point routines for Cortex M0 EABI (v6m, thumb-1). This is
> the libgcc portion of a larger library originally described in 2018:
>
>
On Wed, 25 Nov 2020 at 14:24, Stam Markianos-Wright via Gcc-patches
wrote:
>
> Hi all,
>
> A while back I submitted GCC10 commit:
>
> 44f77a6dea2f312ee1743f3dde465c1b8453ee13
>
> for PR91816.
>
> Turns out I was an idiot and forgot to include the test in the actual
> git commit, even my entire
This patch enables MVE vmvnq instructions for auto-vectorization. MVE
vmvnq insns in mve.md are modified to use 'not' instead of unspec
expression to support one_cmpl2. The one_cmpl2 expander
is added to vec-common.md.
2020-11-12 Christophe Lyon
gcc/
* config/arm
.
2020-11-20 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vshrq_n_s_imm): New entry.
(mve_vshrq_n_u_imm): Likewise.
* config/arm/neon.md (vashr3, vlshr3): Move to ...
* config/arm/vec-common.md: ... here.
gcc/testsuite/
* gcc.target/arm/simd
.
The vashl3 expander is added to vec-common.md.
2020-11-12 Christophe Lyon
gcc/
* config/arm/mve.md (mve_vshlq_n__imm): New entry.
* config/arm/neon.md (vashl3): Rename into vashl3_neon.
* config/arm/vec-common.md (vasl3): New expander.
gcc/testsuite
This patch enables MVE veorq instructions for auto-vectorization. MVE
veorq insns in mve.md are modified to use xor instead of unspec
expression to support xor3. The xor3 expander is added to
vec-common.md
2020-11-12 Christophe Lyon
gcc/
* config/arm/iterators.md (supf
This patch enables MVE vorrq instructions for auto-vectorization. MVE
vorrq insns in mve.md are modified to use ior instead of unspec
expression to support ior3. The ior3 expander is added to
vec-common.md
2020-11-13 Christophe Lyon
gcc/
* config/arm/iterators.md (supf
This patch enables MVE vandq instructions for auto-vectorization. MVE
vandq insns in mve.md are modified to use 'and' instead of unspec
expression to support and3. The and3 expander is added to
vec-common.md
2020-11-12 Christophe Lyon
gcc/
* gcc/config/arm/iterators.md (supf
On Tue, 24 Nov 2020 at 19:43, Ulrich Weigand via Gcc-patches
wrote:
>
> On Fri, Nov 20, 2020 at 09:33:48PM -0700, Jeff Law wrote:
> > > * doc/invoke.texi (-ffast-math): Remove mention of
> > > -fno-signaling-nans.
> > > Clarify conditions when __FAST_MATH__ preprocessor macro is defined.
On Thu, 12 Nov 2020 at 06:56, Jason Merrill via Gcc-patches
wrote:
>
> If DECL_INITIAL isn't set, we can't emit anything about the body of the
> function, so add the declaration attribute.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> gcc/ChangeLog:
>
> PR debug/97060
> *
Hi,
On Thu, 19 Nov 2020 at 07:34, Uecker, Martin
wrote:
>
>
>
> Here is another version of the patch. The
> only difference is the additional the check
> using 'tree_ssa_useless_type_conversion'.
>
>
> Best,
> Martin
>
>
>
>
> C: Drop qualifiers during lvalue conversion. PR97702
>
>
Some tests force -mcpu=cortex-mXX but do not add -mthumb, causing
errors if GCC is not configured to default to Thumb code
(--with-mode=thumb):
cc1: error: target CPU does not support ARM mode
This patch adds -mthumb where relevant.
2020-11-23 Christophe Lyon
gcc/testsuite
On Tue, 17 Nov 2020 at 16:41, Richard Earnshaw (lists) via Gcc-patches
wrote:
>
> On 17/11/2020 15:18, Bernd Edlinger wrote:
> > On 11/17/20 1:44 PM, Richard Earnshaw (lists) wrote:
> >> On 03/11/2020 15:08, Bernd Edlinger wrote:
> >>> Hi,
> >>>
> >>> this fixes a problem with a missing symbol
Hi,
On Mon, 9 Nov 2020 at 15:43, Aldy Hernandez via Gcc-patches
wrote:
>
> [This is actually part of a larger patch that actually changes
> behavior, but I thought I'd commit the non-invasive cleanups first
> which will simplify the upcoming work.]
>
> irange::set was doing more work than it
Hi,
On Fri, 23 Oct 2020 at 10:02, Dennis Zhang via Gcc-patches
wrote:
>
> Hi Kyrylo,
>
> >
> > From: Kyrylo Tkachov
> > Sent: Thursday, October 22, 2020 9:40 AM
> > To: Dennis Zhang; gcc-patches@gcc.gnu.org
> > Cc: nd; Richard Earnshaw; Ramana
Hi,
On Thu, 5 Nov 2020 at 17:12, David Candler via Gcc-patches
wrote:
>
> Hi Richard,
>
> Thanks for the feedback.
>
> Richard Sandiford writes:
> > > diff --git a/gcc/config/aarch64/aarch64-builtins.c
> > > b/gcc/config/aarch64/aarch64-builtins.c
> > > index 4f33dd936c7..f93f4e29c89 100644
>
On Sat, 7 Nov 2020 at 00:59, Jeff Law wrote:
>
>
> On 9/18/20 6:33 AM, Christophe Lyon wrote:
> > On Thu, 17 Sep 2020 at 23:33, Jeff Law wrote:
> >>
> >> On 9/14/20 3:29 AM, Christophe Lyon via Gcc-patches wrote:
> >>> Initializing orig_err
On Fri, 6 Nov 2020 at 15:06, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> > On Thu, 5 Nov 2020 at 15:30, Andrea Corallo wrote:
> >>
> >> Christophe Lyon writes:
> >>
> >> > On Thu, 5 Nov 2020 at 12:11, Andrea Corallo
Hi,
On Tue, 27 Oct 2020 at 11:22, Jan Hubicka wrote:
>
> Hi,
> this patch makes C++ new and delete operators to be handled as
> malloc/free for fnspec.
>
> I still do not understand why free is ".co " and not ".cO ".
> I do not think we need to invalidate memory referenced to by blockbeing
>
On Thu, 5 Nov 2020 at 12:55, Christophe Lyon wrote:
>
> On Thu, 5 Nov 2020 at 10:36, Kyrylo Tkachov wrote:
> >
> > H, Christophe,
> >
> > > -Original Message-
> > > From: Gcc-patches On Behalf Of
> > > Christophe Lyon via Gcc-patc
On Wed, 4 Nov 2020 at 10:59, Richard Biener wrote:
>
> On Wed, 4 Nov 2020, Jakub Jelinek wrote:
>
> > Hi!
> >
> > The following patch generalizes the x ? 1 : 0 -> (int) x optimization
> > to handle also left shifts by constant.
> >
> > During x86_64-linux and i686-linux bootstraps + regtests it
On Fri, 6 Nov 2020 at 12:33, Tamar Christina wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Friday, November 6, 2020 10:27 AM
> > To: Tamar Christina
> > Cc: Richard Biener ; nd ; gcc-
> > patc...@gcc.gnu.org; o...@u
On Fri, 6 Nov 2020 at 11:18, Tamar Christina wrote:
>
>
>
> > -Original Message-
> > From: Christophe Lyon
> > Sent: Friday, November 6, 2020 8:42 AM
> > To: Tamar Christina
> > Cc: Richard Biener ; nd ; gcc-
> > patc...@gcc.gnu.org; o...@u
On Thu, 5 Nov 2020 at 11:21, Tamar Christina via Gcc-patches
wrote:
>
> > -Original Message-
> > From: rguent...@c653.arch.suse.de On
> > Behalf Of Richard Biener
> > Sent: Thursday, November 5, 2020 10:17 AM
> > To: Tamar Christina
> > Cc: gcc-patches@gcc.gnu.org; nd ; o...@ucw.cz
> >
On Thu, 5 Nov 2020 at 15:30, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> > On Thu, 5 Nov 2020 at 12:11, Andrea Corallo wrote:
> >>
> >> Christophe Lyon writes:
> >>
> >> [...]
> >>
> >> >> I think you
On Tue, 3 Nov 2020 at 12:17, Dennis Zhang via Gcc-patches
wrote:
>
> Hi Richard,
>
> On 10/30/20 2:07 PM, Richard Sandiford wrote:
> > Dennis Zhang writes:
> >> diff --git a/gcc/config/aarch64/aarch64-simd-builtins.def
> >> b/gcc/config/aarch64/aarch64-simd-builtins.def
> >> index
On Thu, 5 Nov 2020 at 12:11, Andrea Corallo wrote:
>
> Christophe Lyon writes:
>
> [...]
>
> >> I think you need to add -mfloat-abi=hard to the dg-additional-options
> >> otherwise vld1_lane_bf16_1.c
> >> fails on targets with a soft float-abi def
On Thu, 5 Nov 2020 at 10:36, Kyrylo Tkachov wrote:
>
> H, Christophe,
>
> > -Original Message-
> > From: Gcc-patches On Behalf Of
> > Christophe Lyon via Gcc-patches
> > Sent: 15 October 2020 18:23
> > To: gcc-patches@gcc.gnu.org
> > Subject
On Mon, 2 Nov 2020 at 23:01, Vladimir Makarov wrote:
>
>
> On 2020-11-02 4:30 p.m., Vladimir Makarov via Gcc-patches wrote:
> >
> > On 2020-11-02 3:12 p.m., Christophe Lyon wrote:
> >>
> >> Hi,
> >>
> >> This patch causes ICEs on arm (e
ping?
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556299.html
On Fri, 23 Oct 2020 at 19:20, Christophe Lyon
wrote:
>
> ping?
>
> On Fri, 16 Oct 2020 at 10:41, Christophe Lyon
> wrote:
> >
> > On Thu, 15 Oct 2020 at 20:10, Andrea Corallo wrote
On Wed, 4 Nov 2020 at 14:29, Christophe Lyon wrote:
>
> On Tue, 3 Nov 2020 at 11:27, Kyrylo Tkachov via Gcc-patches
> wrote:
> >
> > Hi Andrea,
> >
> > > -Original Message-
> > > From: Andrea Corallo
> > > Sent: 26 October 2020 15
On Tue, 3 Nov 2020 at 11:27, Kyrylo Tkachov via Gcc-patches
wrote:
>
> Hi Andrea,
>
> > -Original Message-
> > From: Andrea Corallo
> > Sent: 26 October 2020 15:59
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov ; Richard Earnshaw
> > ; nd
> > Subject: [PATCH 1/x] arm: Add
On Tue, 3 Nov 2020 at 07:39, Kewen.Lin via Gcc-patches
wrote:
>
> Hi Richard,
>
> Thanks again for your review!
>
> on 2020/11/2 下午6:23, Richard Sandiford wrote:
> > "Kewen.Lin" writes:
> >> diff --git a/gcc/function.c b/gcc/function.c
> >> index 2c8fa217f1f..3e92ee9c665 100644
> >> ---
On Wed, 4 Nov 2020 at 11:54, Tobias Burnus wrote:
>
> Three of the testcases fail on PowerPC:
> gcc.target/i386/zero-scratch-regs-{9,10,11}.c
>powerpc64le-linux-gnu/default/gcc.d/zero-scratch-regs-10.c:77:1: sorry,
> unimplemented: '-fzero-call-used_regs' not supported on this target
>
>
Hi,
Add -mfloat-abi=soft and skip the tests if -mfloat-abi=hard is
supplied.
This avoids failures when testing with overridden flags such as
mthumb/-mcpu=cortex-m4/-mfloat-abi=hard
Pushed as obvious.
2020-11-04 Christophe Lyon
gcc/testsuite/
* gcc.target/arm/pure-code
On Mon, 2 Nov 2020 at 19:43, Thomas Rodgers via Gcc-patches
wrote:
>
>
> Testsed x86_64-pc-linux-gnu, committed to master.
>
Hi,
I can see the new tests failing on bare-metal targets using newlib
(arm-eabi, aarch64-elf):
27_io/basic_syncbuf/1.cc (test for excess errors)
On Fri, 30 Oct 2020 at 20:11, Vladimir Makarov via Gcc-patches
wrote:
>
> The following patch implements taking insn scratch requirements into
> account in global RA (IRA). Before the patch IRA simply ignored insn
> scratches. Only LRA took the scratches into account and assigned hard
>
Hi,
On Fri, 30 Oct 2020 at 13:49, Richard Earnshaw
wrote:
>
> On 29/10/2020 19:18, Richard Earnshaw via Gcc-patches wrote:
> > On 28/10/2020 18:10, Christophe Lyon via Gcc-patches wrote:
> >> On Wed, 28 Oct 2020 at 18:44, Richard Earnshaw
> >> wrote:
> >&
On Tue, 27 Oct 2020 at 17:22, Richard Earnshaw
wrote:
>
> On 28/09/2020 10:09, Christophe Lyon via Gcc-patches wrote:
> > With -mpure-code on v6m (thumb-1), we can use small offsets with
> > upper/lower relocations to avoid the extra addition of the
> > offset.
&g
On Wed, 28 Oct 2020 at 18:44, Richard Earnshaw
wrote:
>
> On 27/10/2020 15:42, Richard Earnshaw via Gcc-patches wrote:
> > On 26/10/2020 10:52, Christophe Lyon via Gcc-patches wrote:
> >> On Thu, 22 Oct 2020 at 17:22, Richard Earnshaw
> >> wrote:
> >>>
On Wed, 28 Oct 2020 at 11:27, Christophe Lyon
wrote:
>
> On Tue, 27 Oct 2020 at 13:18, Richard Biener wrote:
> >
> > This makes SLP discovery detect backedges by seeding the bst_map with
> > the node to be analyzed so it can be picked up from recursive calls.
&
On Tue, 27 Oct 2020 at 13:18, Richard Biener wrote:
>
> This makes SLP discovery detect backedges by seeding the bst_map with
> the node to be analyzed so it can be picked up from recursive calls.
> This removes the need to discover backedges in a separate walk.
>
> This enables SLP build to
Hi,
On Mon, 26 Oct 2020 at 13:44, Richard Sandiford via Gcc-patches
wrote:
>
> Tamar Christina writes:
> > Hi Richard,
> >
> > The 10/26/2020 11:29, Richard Sandiford wrote:
> >> Tamar Christina writes:
> >> >/* We can't do anything smart if the amount to copy is not constant.
> >> > */
Hi,
On Mon, 26 Oct 2020 at 22:51, Andrew MacLeod via Gcc-patches
wrote:
>
> In the core of gori_compute::logical_combine we are suppose to combine
> the calculated true and false ranges on each side of the operation.
>
> when encountering
>
> [0,0] = c_3 | c_4
>
> we know we only need to
On Thu, 22 Oct 2020 at 17:22, Richard Earnshaw
wrote:
>
> On 22/10/2020 09:45, Christophe Lyon via Gcc-patches wrote:
> > On Wed, 21 Oct 2020 at 19:36, Richard Earnshaw
> > wrote:
> >>
> >> On 21/10/2020 17:11, Christophe Lyon via Gcc-patches wrote:
> &g
ping?
On Fri, 16 Oct 2020 at 10:41, Christophe Lyon
wrote:
>
> On Thu, 15 Oct 2020 at 20:10, Andrea Corallo wrote:
> >
> > Hi Christophe,
> >
> > I've spotted two very minors.
> >
> > Christophe Lyon via Gcc-patches writes:
> >
> >
ping?
On Tue, 6 Oct 2020 at 10:30, Christophe Lyon wrote:
>
> ping?
>
> On Mon, 28 Sep 2020 at 11:09, Christophe Lyon
> wrote:
> >
> > With -mpure-code on v6m (thumb-1), to avoid a useless indirection when
> > building the address of a symbol, we want to consid
ping?
On Tue, 6 Oct 2020 at 10:30, Christophe Lyon wrote:
>
> ping?
>
> On Mon, 28 Sep 2020 at 11:09, Christophe Lyon
> wrote:
> >
> > With -mpure-code on v6m (thumb-1), we can use small offsets with
> > upper/lower relocations to avoid the extra addition of t
On Wed, 21 Oct 2020 at 19:36, Richard Earnshaw
wrote:
>
> On 21/10/2020 17:11, Christophe Lyon via Gcc-patches wrote:
> > On Wed, 21 Oct 2020 at 18:07, Richard Earnshaw
> > wrote:
> >>
> >> On 21/10/2020 16:49, Christophe Lyon via Gcc-patches wrote:
> &g
On Wed, 21 Oct 2020 at 18:07, Richard Earnshaw
wrote:
>
> On 21/10/2020 16:49, Christophe Lyon via Gcc-patches wrote:
> > On Tue, 20 Oct 2020 at 13:25, Richard Earnshaw
> > wrote:
> >>
> >> On 20/10/2020 12:22, Richard Earnshaw wrote:
> >>> On 1
On Tue, 20 Oct 2020 at 13:25, Richard Earnshaw
wrote:
>
> On 20/10/2020 12:22, Richard Earnshaw wrote:
> > On 19/10/2020 17:32, Christophe Lyon via Gcc-patches wrote:
> >> On Mon, 19 Oct 2020 at 16:39, Richard Earnshaw
> >> wrote:
> >>>
> >>>
On Mon, 19 Oct 2020 at 16:39, Richard Earnshaw
wrote:
>
> On 12/10/2020 08:59, Christophe Lyon via Gcc-patches wrote:
> > On Thu, 8 Oct 2020 at 11:58, Richard Earnshaw
> > wrote:
> >>
> >> On 08/10/2020 10:07, Christophe Lyon via Gcc-patches wrote:
> &
On Thu, 15 Oct 2020 at 20:10, Andrea Corallo wrote:
>
> Hi Christophe,
>
> I've spotted two very minors.
>
> Christophe Lyon via Gcc-patches writes:
>
> [...]
>
> > +/* For vceqq_p64, we rely on vceq_p64 for each of the two elements. */
> > +_
On Thu, 15 Oct 2020 at 20:10, Andrea Corallo wrote:
>
> Hi Christophe,
>
> I've spotted two very minors.
>
> Christophe Lyon via Gcc-patches writes:
>
> [...]
>
> > +/* For vceqq_p64, we rely on vceq_p64 for each of the two elements. */
> > +_
) testcases make sure that the poly64x2_t
variants have results with one element of all zeroes (false) and the
other element with all bits set to one (true).
2020-10-15 Christophe Lyon
gcc/
* config/arm/arm_neon.h (vceqz_p64, vceqq_p64, vceqzq_p64): New.
gcc/testsuite
On Tue, 13 Oct 2020 at 15:51, Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Wed, 23 Sep 2020 at 20:33, Richard Sandiford
> > wrote:
> >>
> >> These tests were inspired by the corresponding aarch64 ones that I just
> >> committed. The
On Mon, 12 Oct 2020 at 18:43, Segher Boessenkool
wrote:
>
> On Mon, Oct 12, 2020 at 03:26:38PM +0200, Christophe Lyon wrote:
> > That's why I kept the reporting part manual on my side: once you know
> > which commit introduced a failure/regression (either via bisect, or by
On Tue, 29 Sep 2020 at 00:02, Martin Sebor via Gcc-patches
wrote:
>
> On 9/25/20 11:17 PM, Jason Merrill wrote:
> > On 9/22/20 4:05 PM, Martin Sebor wrote:
> >> The rebased and retested patches are attached.
> >>
> >> On 9/21/20 3:17 PM, Martin Sebor wrote:
> >>> Ping:
> >>>
On Mon, 5 Oct 2020 at 17:19, Segher Boessenkool
wrote:
>
> On Sun, Oct 04, 2020 at 09:51:23AM -0700, H.J. Lu wrote:
> > On Sat, Oct 3, 2020 at 5:57 PM Segher Boessenkool
> > wrote:
> > > On Sat, Oct 03, 2020 at 12:21:04PM -0700, sunil.k.pandey via Gcc-patches
> > > wrote:
> > > > On
Hi,
On Thu, 8 Oct 2020 at 16:22, Christophe Lyon wrote:
>
> On Thu, 8 Oct 2020 at 16:08, Dennis Zhang wrote:
> >
> > Hi Christophe,
> >
> > On 08/10/2020 14:14, Christophe Lyon wrote:
> > > Hi,
> > >
> > >
> > > On T
801 - 900 of 2855 matches
Mail list logo
