[AArch64 folks CC'd fyi as this is common between both backends.]
Hi,
The design in the backend used to be that advanced simd types are
generally added to is_neon_type in the backend. It appears that
neon_fcmla and neon_fcadd aren't added in as neon_type instructions.
Applying this to the tree
On Fri, Nov 18, 2022 at 4:59 PM Kyrylo Tkachov via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Andrea Corallo
> > Sent: Thursday, November 17, 2022 4:38 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov ; Richard Earnshaw
> > ; Stam Markianos-Wright >
On Fri, Nov 18, 2022 at 9:33 AM Srinath Parvathaneni
wrote:
>
> Hi,
>
> > -Original Message-
> > From: Ramana Radhakrishnan
> > Sent: Thursday, November 17, 2022 8:27 PM
> > To: Srinath Parvathaneni
> > Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw
> > ; Kyrylo Tkachov
> > Subject: Re:
On Mon, Oct 24, 2022 at 9:55 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> until most other machine attributes, this one does not work in Ada because,
> while it applies to pointer-to-function types, it is explicitly marked as
> requiring declarations in the implementation.
>
> Now, in Ada,
On Thu, Nov 17, 2022 at 5:30 PM Richard Sandiford via Gcc-patches
wrote:
>
> Wilco Dijkstra writes:
> > Hi Richard,
> >
> >> Can you go into more detail about:
> >>
> >>Use :option:`-mdirect-extern-access` either in shared libraries or in
> >>executables, but not in both. Protected
On Thu, Nov 10, 2022 at 10:38 AM Srinath Parvathaneni via Gcc-patches
wrote:
>
> Hi,
>
> This patch adds support for Arm frame unwinding instruction "0xb5" [1]. When
> an exception is taken and "0xb5" instruction is encounter during runtime
> stack-unwinding, we use effective vsp as modifier in
gt; On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
> > > >
> > > >
> > > > On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote:
> > > >> PR92999 is a case where the VFP calling convention does not allocate
> > > >> enough
>
> OK with the comment typos fixed.
>
> > > > gcc/ChangeLog:
> > > >
> > > > 2018-11-11 Tamar Christina
> > > >
> > > > * config/aarch64/aarch64-simd.md (aarch64_fcadd,
> > > > fcadd3, aarch64_fcmla,
> > > > fcmla4): New.
> > > > * config/aarch64/aarch64.h
On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
wrote:
>
> On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
> wrote:
> >
> >
> >
> > On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
> > >
> > >
> > > On 08/11/2022 18:20
On Thu, Nov 10, 2022 at 10:24 AM Srinath Parvathaneni via Gcc-patches
wrote:
>
> Hi,
>
> This patch adds the -mcpu support for the Arm Cortex-X1C CPU.
>
> Regression tested on arm-none-eabi and bootstrapped on
> arm-none-linux-gnueabihf.
>
> Ok for GCC master?
Ok
Ramana
>
> Regards,
> Srinath.
On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
wrote:
>
>
>
> On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
> >
> >
> > On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote:
> >> PR92999 is a case where the VFP calling conv
PR92999 is a case where the VFP calling convention does not allocate
enough FP registers for a homogenous aggregate containing FP16 values.
I believe this is the complete fix but would appreciate another set of
eyes on this.
Could I get a hand with a regression test run on an armhf environment
Update affiliation as I'm moving on from Arm. More from me in a month or so.
Pushed to trunk
regards
Ramana
commit 4e5f373406ed5da42c4a7c4b7f650d92195f2984
Author: Ramana Radhakrishnan
Date: Fri Nov 4 09:30:00 2022 +
Update affiliation
diff --git a/htdocs/steering.html
As $subject. Pushed to trunk.
Regards,
Ramana
diff --git a/MAINTAINERS b/MAINTAINERS
index e4e7349a6d9..55c5ef95806 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -60,7 +60,7 @@ arc port Joern Rennecke
arc port Claudiu Zissulescu
arm port
Hi Lance,
Thanks for your contribution - looks like your first one to GCC ?
The patch looks good to me, though it should probably go through a
full test suite run on arm-linux-gnueabihf and get a ChangeLog - see
here for more https://gcc.gnu.org/contribute.html#patches.
This is probably small
Thanks Ard and Qing.
I have been busy with other things in the last few weeks and I don’t work on
GCC as part of my day job : however I’ll try to find some time to review this
patch set in the coming days.
Sorry about the delay.
Regards,
Ramana
From: Ard Biesheuvel
Date: Tuesday, 9 November
Hi There,
I think for AArch32 mapping it back to armv8-a sounds sufficient. Unless we
have string or math routines in newlib that make use of any ACLE guards that
are beyond armv8-a …
Ramana
From: Richard Earnshaw
Date: Tuesday, 16 November 2021 at 11:48
To: Christophe Lyon , Przemyslaw
This is OK
Ramana
On 22/09/2021, 09:45, "Przemyslaw Wirkus" wrote:
Patch is adding Cortex-R52+ as 'cortex-r52plus' command line
flag for -mcpu option.
See: https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r52-plus
OK for master?
gcc/ChangeLog:
2021-09-22
On Thu, Oct 8, 2020 at 10:22 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The arm target hook for divmod wasn't prepared to handle constants passed to
> the function.
>
> Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
>
> 2020-10-08 Jakub Jelinek
>
>
On Thu, Sep 3, 2020 at 6:13 PM Kees Cook via Gcc-patches
wrote:
>
> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote:
> > On average, all the options starting with “used_…” (i.e, only the
> > registers that are used in the routine will be zeroed) have very low
> > runtime overheads,
On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote:
> >
> > Hi Kito,
> >
> > > I just found the mail thread about div mod with -fnon-call-exceptions,
> > > I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS
On Mon, Aug 24, 2020 at 4:35 PM Christophe Lyon
wrote:
>
> On Mon, 24 Aug 2020 at 11:09, Christophe Lyon
> wrote:
> >
> > On Sat, 22 Aug 2020 at 00:44, Ramana Radhakrishnan
> > wrote:
> > >
> > > On Wed, Aug 19, 2020 at 10:32 AM Christophe Lyon via Gcc-patches
> > > wrote:
> > > >
> > > >
On Fri, Aug 21, 2020 at 2:28 PM Joe Ramsay wrote:
>
> From: Joe Ramsay
>
> Hi,
>
> Previously, the machine description patterns for vst1q accepted a generic
> memory
> operand for the destination, which could lead to an unrecognised builtin when
> expanding vst1q* intrinsics. This change fixes
On Wed, Aug 19, 2020 at 10:32 AM Christophe Lyon via Gcc-patches
wrote:
>
> armv8-m.base (cortex-m23) has the movt instruction, so we need to
> disable the define_split to generate a constant in this case,
> otherwise we get incorrect insn constraints as described in PR94538.
>
> We also need to
On Mon, Aug 17, 2020 at 7:42 PM Dennis Zhang wrote:
>
>
> Hi all,
>
> This patch enables MVE vsub instructions for auto-vectorization.
> It adds RTL templates for MVE vsub instructions using 'minus' instead of
> unspec expression to make the instructions recognizable for vectorization.
> MVE
On Thu, Aug 20, 2020 at 3:31 PM Joe Ramsay wrote:
>
> Hi Ramana,
>
> Thanks for the review.
>
> On 18/08/2020, 18:37, "Ramana Radhakrishnan"
> wrote:
>
> On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote:
> >
> > From: Joe Ramsay
> >
> > Hi,
> >
> > Previously, the
On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote:
>
> From: Joe Ramsay
>
> Hi,
>
> Previously, the machine description patterns for vst1q accepted a generic
> memory
> operand for the destination, which could lead to an unrecognised builtin when
> expanding vst1q* intrinsics. This change fixes
On Mon, Apr 27, 2020 at 2:22 PM Andre Vieira (lists)
wrote:
>
> Hi,
>
> The code change that caused this regression was not meant to affect neon
> code-gen, however I missed the REG fall through. This patch makes sure
> we only get the left-hand of the PLUS if it is indeed a PLUS expr.
>
> I
On Fri, May 15, 2020 at 12:31 PM Srinath Parvathaneni
wrote:
>
> Armv8.1-M Mainline Security Extensions related changes in GCC-10.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
>
On Fri, May 15, 2020 at 7:36 AM Christophe Lyon
wrote:
>
> On Thu, 14 May 2020 at 17:58, Ramana Radhakrishnan
> wrote:
> >
> > > static bool reg_needs_saving_p (unsigned reg)
> > > {
> > >unsigned long func_type = arm_current_func_type ();
> >
> > Ah ok , you needed it here.
>
> Yes sorry.
> static bool reg_needs_saving_p (unsigned reg)
> {
>unsigned long func_type = arm_current_func_type ();
Ah ok , you needed it here.
Ramana
On Thu, May 14, 2020 at 3:58 PM Christophe Lyon via Gcc-patches
wrote:
>
> The same code pattern occurs in several functions, so it seems cleaner
> to move it into a dedicated function.
>
> 2020-05-14 Christophe Lyon
>
> gcc/
> * config/arm/arm.c (reg_needs_saving_p): New
On Thu, May 14, 2020 at 3:57 PM Christophe Lyon via Gcc-patches
wrote:
>
> While running the tests with -march=armv5t -mthumb, I came across this
> error message which I think could be clearer.
>
> 2020-05-14 Christophe Lyon
>
> gcc/
> * config/arm/arm.c
On Wed, Apr 29, 2020 at 4:19 PM Christophe Lyon via Gcc-patches
wrote:
>
> Remove two duplicate entries in isr_attribute_args ("abort" and
> "ABORT").
>
> 2020-04-29 Christophe Lyon
>
> PR target/57002
> gcc/
> * config/arm/arm.c (isr_attribute_args): Remove duplicate
On Wed, Apr 29, 2020 at 11:30 AM Richard Sandiford
wrote:
>
> Essentially the same fix as for x86.
>
> Tested on arm-linux-gnueabihf and armeb-eabi. Bordering on the obvious
> I guess, but OK to install?
>
> Richard
>
Ok.
Ramana
>
> 2020-04-29 Richard Sandiford
>
> gcc/
> *
On Wed, Apr 22, 2020 at 8:25 PM Joel Jones wrote:
>
> Yes, Bellsoft's contribution is to be covered under the Marvell copyright
>
> assignment, as this is a work for hire.
Thanks !
Ramana
>
>
>
> Joel
>
>
>
> >Yes, Bellsoft's contribution is to be covered under the Marvell copyright
>
>
On Wed, Apr 22, 2020 at 5:38 AM Joel Jones via Gcc-patches
wrote:
>
> I just joined the gcc-patches list, so I hope the mail software can parse
> this out with an "In-Reply-To" header.
>
> I work for Marvell, and Anton's work is approved for submittal. I wrote the
> first version of the .md
37 matches
Mail list logo
