On Sat, Dec 16, 2023 at 6:18 AM Andrew Carlotti wrote:
>
> This adds initial support for function multiversioning on aarch64 using
> the target_version and target_clones attributes. This loosely follows
> the Beta specification in the ACLE [1], although with some differences
> that still need to
> On 5 Oct 2023, at 14:04, Victor Do Nascimento
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> On 10/5/23 12:42, Richard Earnshaw wrote:
>>
>>
>> On 03/10/2023 16:18, Victor Do Nascimento wrote:
>>> This patch adds the `aarch64-sys-regs.def' file to GCC,
+ linaro-toolchain as I don't understand the CI issues on patchwork.
On Wed, Sep 27, 2023 at 8:40 PM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> > Hope this helps.
>
> Yes definitely!
>
> >> Passes regress/bootstrap, OK for commit?
> >
> > Target ? armhf ? --with-arch , -with-fpu , -with-float
On Wed, Sep 27, 2023 at 1:51 AM Tamar Christina wrote:
>
> Hi All,
>
> Following the Neoverse N/V and Cortex-A optimization guides SIMD 0 immediates
> should be created with a movi of 0.
>
> At the moment we generate an `fmov .., xzr` which is slower and requires a
> GP -> FP transfer.
>
>
n_logic , simd, 4] mov\t%0., %1.
> + [?r , w ; multiple , * , 8] #
> + [?w , r ; multiple , * , 8] #
> + [?r , r ; multiple , * , 8] #
> + [w , Dn; neon_move , simd, 4] <<
> aarch64_output_simd_mov_immediate (ope
Reviewed-by: Ramana Radhakrishnan
A very initial review here . I think it largely looks ok based on the
description but I've spotted a few obvious nits and things that come
to mind on reviewing this. I've not done a very deep review but hope
it helps you move forward. I'm happy to work with you
Hi Wilco,
Thanks for your email.
On Tue, Sep 26, 2023 at 12:07 AM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> >> __sync_val_compare_and_swap may be used on 128-bit types and either calls
> >> the
> >> outline atomic code or uses an inline loop. On AArch64 LDXP is only
> >> atomic if
> >> the
think we went with LDXP in this form.
Has something changed from then ?
Reviewed-by : Ramana Radhakrishnan
regards
Ramana
>
> Passes regress/bootstrap, OK for commit?
>
> gcc/ChangeLog/
> PR target/111404
> * config/aarch64/aarch64.cc (aarch64_split_compare_and_swa
On Wed, Jul 19, 2023 at 5:44 PM Andrew Carlotti via Gcc-patches
wrote:
>
> Updated patch to fix the fp16 intrinsic pragmas, and pushed to master.
> OK to backport to GCC 13?
>
>
> Many intrinsics currently depend on both an architecture version and a
> feature, despite the corresponding
ig/arm but its possibly ok given the usage
statistics.
Reviewed-by: Ramana Radhakrishnan.
regards
Ramana
>
> --
> Evandro Menezes
>
>
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-
On Fri, Jan 27, 2023 at 2:44 PM Andrea Corallo via Gcc-patches
wrote:
>
> gcc/
>
> * config/arm/arm.cc (arm_valid_target_attribute_rec): Add ARM function
> attribute 'branch-protection' and parse its options.
> * doc/extend.texi: Document ARM Function attribute
>
Ping x 2
Ramana
On Thu, 17 Nov 2022, 20:15 Ramana Radhakrishnan,
wrote:
> On Fri, Nov 11, 2022 at 9:50 PM Ramana Radhakrishnan
> wrote:
> >
> > On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
> > wrote:
> > >
> > > On Thu, Nov 10, 202
later this week after having built armhf and
a bootstrap and test run on aarch64-linux-gnu.
Thanks,
Ramana
commit 7dd15fae0ac1455f5818a1fc0078e35d85e1e250
Author: Ramana Radhakrishnan
Date: Wed Nov 16 10:32:04 2022 +
[Patch Arm] Add neon_fcadd and neon_fcmla to is_neon_type
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 Earnsha
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
On Fri, Nov 11, 2022 at 9:50 PM Ramana Radhakrishnan
wrote:
>
> On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
> wrote:
> >
> > On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
> > wrote:
> > >
> > >
> > >
> > &
>
> 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
while I fix my environment ?
gcc/ChangeLog:
PR target/92999
* config/arm/arm.c (aapcs_vfp_allocate_return_reg): Adjust to handle
aggregates with elements smaller than SFmode.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr92999.c: New test.
Thanks,
Ramana
Signed-off-by: Ramana Radhakrishnan
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 b/htdocs
Nick Clifton
arm port Richard Earnshaw
-arm port Ramana Radhakrishnan
+arm port Ramana Radhakrishnan
arm port Kyrylo Tkachov
avr port Denis Chertykov
bfin port Jie
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
2021 at 22:03
To: Qing Zhao
Cc: Ramana Radhakrishnan ,
linux-harden...@vger.kernel.org , kees Cook
, Keith Packard ,
thomas.preudho...@celest.fr ,
adhemerval.zane...@linaro.org , Richard
Sandiford , gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v4 1/1] [ARM] Add support for TLS register based
Wirkus
Cc: Ramana Radhakrishnan ,
gcc-patches@gcc.gnu.org , Richard Earnshaw
Subject: Re: [PATCH][GCC] arm: add armv9-a architecture to -march
You can't make an omelette without breaking eggs, as they say. New
architectures need new assemblers.
However, I wonder if there's anything in v9
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
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 Ramsa
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 ();
> &g
> 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
On Fri, Feb 7, 2020 at 8:19 AM Jakub Jelinek wrote:
>
> Hi!
>
> As the following testcase shows, unwind.h on ARM can't be (starting with GCC
> 10) compiled with -std=c* modes, only -std=gnu* modes.
> The problem is it uses asm keyword, which isn't a keyword in those modes
> (system headers vs.
On Tue, Nov 26, 2019 at 3:18 PM Wilco Dijkstra wrote:
>
> Hi,
>
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks. Since the impact is relatively small with -O2 and mainly
On Mon, Nov 25, 2019 at 9:43 PM Andrew Dean wrote:
>
> > > >>> I get errors like this:
> > > >>>
> > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > > >>> 'rdimon.specs': No such file or directory
> > > >>>
> > > >>> I can see that the rdimon.specs flag is added based on
On Mon, Nov 25, 2019 at 8:40 PM Adhemerval Zanella
wrote:
>
>
>
> On 25/11/2019 17:28, Andrew Dean via gcc wrote:
> >>> This completes successfully. However, when I then try to run the gcc
> >>> tests like
> >> so:
> >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> >>>
On Fri, Oct 18, 2019 at 8:49 PM Richard Earnshaw
wrote:
>
>
> This series of patches rewrites all the DImode arithmetic patterns for
> the Arm backend when compiling for Arm or Thumb2 to split the
> operations during expand (the thumb1 code is unchanged and cannot
> benefit from early splitting
>
> Patch bootstrapped and regression tested on arm-none-linux-gnueabihf,
> however, on my native Aarch32 setup the test times out when run as part
> of a big "make check-gcc" regression, but not when run individually.
>
> 2019-10-11 Stamatis Markianos-Wright
>
> * config/arm/arm.md:
On Fri, Oct 11, 2019 at 10:42 PM Wilco Dijkstra wrote:
>
> Hi,
>
> > the defaults for v7-a are still to use the
> > Cortex-A8 scheduler
>
> I missed that part, but that's a serious bug btw - Cortex-A8 is 15 years old
> now so
> way beyond obsolete. Even Cortex-A53 is ancient now, but it has an
On Fri, Oct 11, 2019 at 6:19 PM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> > Can you see what happens with the Cortex-A8 or Cortex-A9 schedulers to
> > spread the range across some v7-a CPUs as well ? While they aren't that
> > popular today I
> > would suggest you look at them because the
On Fri, Oct 11, 2019 at 3:52 PM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> > My only question would be whether it's more suitable to use
> > optimize_function_for_size_p(cfun) instead as IIRC that gives us a
> > chance with lto rather than the global optimize_size.
>
> Yes that is even better and
On Fri, Oct 11, 2019 at 5:17 PM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> >On Mon, Sep 9, 2019 at 6:03 PM Wilco Dijkstra wrote:
> >>
> >> Currently arm_legitimize_address doesn't handle Thumb-2 at all, resulting
> >> in
> >> inefficient code. Since Thumb-2 supports similar address offsets use
On Tue, Oct 8, 2019 at 4:21 PM Andre Vieira (lists)
wrote:
>
> Hi,
>
> This patch implements the TARGET_HOOK_SANITIZE_CLONE_ATTRIBUTES for the
> arm backend to remove the 'cmse_nonsecure_entry' attribute from cmse.
>
> Bootstrapped the series on x86_64 and built arm-none-eabi, running the
> cmse
On Thu, Oct 10, 2019 at 7:06 PM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > ping
> >
> > Contrary to all documentation, SLOW_BYTE_ACCESS simply means accessing
> > bitfields by their declared type, which results in better codegeneration on
> > practically
> > any target.
>
> The
On Mon, Sep 9, 2019 at 6:05 PM Wilco Dijkstra wrote:
>
> Setting HONOR_REG_ALLOC_ORDER improves codesize with -Os, however it generates
> slower and larger code with -O2 and higher. So only set it when optimizing
> for
> size. On Cortex-A57 this improves SPECINT2006 by 0.15% and SPECFP2006 by
On Mon, Sep 9, 2019 at 6:03 PM Wilco Dijkstra wrote:
>
> Currently arm_legitimize_address doesn't handle Thumb-2 at all, resulting in
> inefficient code. Since Thumb-2 supports similar address offsets use the Arm
> legitimization code for Thumb-2 to get significant codesize and performance
>
On Tue, Jul 30, 2019 at 4:16 PM Wilco Dijkstra wrote:
>
> Hi all,
>
> >On 30/07/2019 10:31, Ramana Radhakrishnan wrote:
> >> On 30/07/2019 10:08, Christophe Lyon wrote:
>
> >>> Hi Wilco,
> >>>
> >>> Do you know which benchmarks
Hi,
I'm pleased to announce that the GCC steering committee has appointed
Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers.
Please join me in congratulating them both on their additional roles
in the community. Kyrill / Richard, please update your listings in the
MAINTAINERS file.
On Mon, Sep 16, 2019 at 2:40 PM Christophe Lyon
wrote:
>
> [Re-sending in plain text-mode, sorry for the duplicates]
>
> Hi,
>
> In PR91749, we have ICEs because -mflip-thumb switches to Thumb-1 (the
> default target cpu does not support Thumb-2).
>
> Although we already filter this in
On Fri, Sep 13, 2019 at 5:31 PM Sandra Loosemore
wrote:
>
> In some bare-metal environments, the tests for fp16 runtime support fail
> in a way that causes a timeout rather than immediate failure. (E.g.,
> the runtime might provide a do-nothing exception handler that just sits
> in a tight loop
On 30/07/2019 10:08, Christophe Lyon wrote:
On Mon, 29 Jul 2019 at 18:49, Wilco Dijkstra wrote:
Currently the Arm backend selects the alternative sched pressure algorithm.
The issue is that this doesn't take register pressure into account, and so
it causes significant additional spilling on
On 22/07/2019 17:16, Wilco Dijkstra wrote:
Like the logical operations, expand all shifts early rather than only
sometimes. The Neon shift expansions are never emitted (not even with
-fneon-for-64bits), so they are not useful. So all the late expansions
and Neon shift patterns can be removed,
On Wed, Jul 10, 2019 at 11:07 AM Richard Sandiford
wrote:
>
> Christophe Lyon writes:
> > On Mon, 8 Jul 2019 at 11:04, Richard Sandiford
> > wrote:
> >>
> >> Christophe Lyon writes:
> >> > Hi,
> >> >
> >> > This patch fixes PR 91060 where the lane ordering was no longer the
> >> > right one
On Tue, Jul 2, 2019 at 1:38 PM Paul E. McKenney wrote:
>
> Once a user-created non-dependent pointer is assigned to, it is OK to
> break the dependency.
Ok, that's good.
>
> Or am I missing the point here?
I was just trying to make sure we were on the same page. I wonder if
marking this
>>
>> It's worth figuring out what passes are doing this - however the worry
>> I have is that every pass now needs to be handling this case with
>> respect to pointer attributes. Is there some place that you are
>> storing said information and what is the transitive nature of
>> assignments with
On Tue, Jul 2, 2019 at 1:29 AM Akshat Garg wrote:
>
> On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote:
>>
>> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan
>> wrote:
>>>
>> [CCing gcc mailing list]
>>
>> So, shall I start looki
On Thu, May 23, 2019 at 3:12 PM Richard Earnshaw (lists)
wrote:
>
> On 23/05/2019 15:03, Richard Earnshaw (lists) wrote:
> > On 20/05/2019 20:24, Jeff Law wrote:
> >> On 4/9/19 10:36 AM, Richard Earnshaw (lists) wrote:
> >>> On 09/04/2019 16:04, Jeff Law wrote:
> On 4/8/19 9:17 AM,
On Mon, May 20, 2019 at 7:57 AM Christophe Lyon
wrote:
>
> Hi,
>
> After Martin's commit r271338, we now emit quotes around reserved
> names, and some tests started to fail on aarch64 and arm.
>
> This should fix them, OK?
Looks obvious to me.
R
>
> Christophe
On Thu, May 16, 2019 at 5:41 PM Maxim Kuvyrkov
wrote:
>
> > On May 16, 2019, at 7:22 PM, Jeff Law wrote:
> >
> > On 5/15/19 5:19 AM, Richard Biener wrote:
> >>
> >> For the official converted repo do we really want all (old)
> >> development branches to be in the
> >> main git repo? I suppose
On Tue, Apr 30, 2019 at 12:38 PM Jakub Jelinek wrote:
>
> On Tue, Apr 30, 2019 at 10:50:46AM +0100, Richard Earnshaw (lists) wrote:
> > > * config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Define
> > > __ARM_FEATURE_ATOMICS
> > >
> > > atomics.txt
> > >
> > > diff --git
On Mon, Apr 29, 2019 at 8:44 AM Jaydeep Chauhan
wrote:
>
> Hi All,
>
> The attached patch (89057.patch) fixes the subjected issue.
> Please let me know your thoughts on the patch.
Thanks for your patch.
Before getting started with reviewing the patch , the first question
is whether you have a
ue that the system compiler could be some earlier GCC 9.0.1 snapshot
> which doesn't support general-regs-only.
I don't grok enough ada to approve this and will leave that part to
Eric or others.
Ramana
>
> 2019-04-22 Ramana Radhakrishnan
> Bernd Edlinger
>
On 12/04/2019 15:12, Jakub Jelinek wrote:
Hi!
Just something I've noticed while looking at Ramana's patch.
As can be seen on the testcase, on arm we accept arbitrary garbage
after arm or thumb prefixes, is that really desirable?
While for fpu= or arch= we reject garbage after it and so do for
This keeps coming up repeatedly and the ACLE has finally added
__ARM_FEATURE_ATOMICS for the LSE feature in GCC. This is now part of
the latest ACLE release
(https://developer.arm.com/docs/101028/latest/5-feature-test-macros)
I know it's late for GCC-9 but this is a simple macro which need
On 04/03/2019 09:04, Jakub Jelinek wrote:
> On Fri, Mar 01, 2019 at 03:41:33PM +, Wilco Dijkstra wrote:
>> > and regtest revealed two code size
>> > regressions because of that. Is -1 vs. 1 the only case of immediate
>> > valid for both "I" and "L" constraints where the former is longer than
Nope, just do it after testing it and adjust with Christophes follow up
R
On Mon, 11 Mar 2019, 10:36 Andre Vieira (lists), <
andre.simoesdiasvie...@arm.com> wrote:
> Hi,
>
> Any objections to me backporting this to GCC 8 and 7?
>
> Cheers,
> Andre
>
> On 08/03/2019 17:30, Andre Vieira (lists)
Ok.
Ramana
On Mon, 11 Mar 2019, 20:24 Christophe Lyon,
wrote:
> On Mon, 11 Mar 2019 at 12:34, Richard Biener wrote:
> >
> > On Mon, 11 Mar 2019, Andre Vieira (lists) wrote:
> >
> > > Hi,
> > >
> > > Any objections to me backporting this to GCC 8 and 7?
> >
> > No, go ahead (after proper
On 05/03/2019 12:33, Wilco Dijkstra wrote:
ping
From: Wilco Dijkstra
Sent: 13 February 2019 12:23
To: Ramana Radhakrishnan
Cc: GCC Patches; nd; Olivier Hainque
Subject: Re: [PATCH][ARM] Fix PR89222
Hi Ramana,
ARMv5te bootstrap OK, regression tests pass. OK for commit?
Interesting
On Fri, Feb 15, 2019 at 1:16 PM Jakub Jelinek wrote:
>
> On Fri, Feb 15, 2019 at 02:12:27PM +0100, Richard Biener wrote:
> > On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel
> > wrote:
> > >I never could understand, why field reordering was removed from GCC?
> >
> > The implementation simply
On Mon, Feb 11, 2019 at 4:48 PM Olivier Hainque wrote:
>
> Hi Wilco,
>
> > On 8 Feb 2019, at 22:35, Wilco Dijkstra wrote:
>
> > So I think we need to push much harder on getting rid of obsolete stuff and
> > avoid people encountering these nasty issues.
>
> Numbers I just received indicate that
On Mon, Feb 11, 2019 at 5:35 PM Wilco Dijkstra wrote:
>
> The GCC optimizer can generate symbols with non-zero offset from simple
> if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
> with offsets fail if it changes bit zero and the relocation forces bit zero
> to true.
On 08/02/2019 16:19, Olivier Hainque wrote:
> Hi Wilco,
>
>> On 8 Feb 2019, at 15:49, Wilco Dijkstra wrote:
>>
>> Hi Olivier,
>>
>>> Below is a description of a very annoying bug we are witnessing
>>> on ARM.
>> ...
>>> compiled with -Og -mapcs
>>
>> Do you know -mapcs has been deprecated for
istina
> Cc: gcc-patches@gcc.gnu.org; nd; James Greenhalgh; Richard Earnshaw;
> Marcus Shawcroft; Ramana Radhakrishnan; ni...@redhat.com; Kyrylo Tkachov
> Subject: Re: [PATCH][wwwdocs][Arm][AArch64] Update changes with new
> features and flags.
>
> On Wed, 23 Jan 2019, Ta
On Wed, Jan 23, 2019 at 1:54 PM Jason Merrill wrote:
>
> Since in r265788 I made cxx_eval_outermost_constant_expr more insistent that
> the returned value have the right type, it became more important that
> initialized_type be correct. These two PRs were cases of it giving the wrong
> answer.
On 20/01/2019 15:48, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jan 17, 2019 at 03:02:00PM +, Tamar Christina wrote:
>> This test was added back when builtins were being used instead of ACLE
>> intrinsics. The test as far as I can tell is really testing vcombine,
>> however some of these
On 17/01/2019 15:02, Tamar Christina wrote:
> Hi All,
>
> This test was added back when builtins were being used instead of ACLE
> intrinsics. The test as far as I can tell is really testing vcombine,
> however some of these builtins no longer exist and causes an ICE.
>
> This fixes the
On 03/12/2018 16:39, Ard Biesheuvel wrote:
> On Mon, 3 Dec 2018 at 10:55, Ramana Radhakrishnan
> wrote:
>>
>> For quite sometime the kernel guys, (more specifically Ard) have been
>> talking about using a system register (sp_el0) and an offset from that
>> for a cana
On 10/01/2019 15:49, James Greenhalgh wrote:
> On Mon, Dec 03, 2018 at 03:55:36AM -0600, Ramana Radhakrishnan wrote:
>> For quite sometime the kernel guys, (more specifically Ard) have been
>> talking about using a system register (sp_el0) and an offset from that
>> for
On Thu, Jan 10, 2019 at 11:05 AM Jakub Jelinek wrote:
>
> On Thu, Jan 10, 2019 at 10:53:32AM +, Ramana Radhakrishnan wrote:
> > > 2018-11-23 Ramana Radhakrishnan
> > >
> > > * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New
> >
On Mon, Dec 3, 2018 at 9:55 AM Ramana Radhakrishnan
wrote:
>
> For quite sometime the kernel guys, (more specifically Ard) have been
> talking about using a system register (sp_el0) and an offset from that
> for a canary based access. This patchset adds support for a new set of
&g
On Wed, Jan 9, 2019 at 9:50 AM Andrew Haley wrote:
>
> On 1/9/19 9:45 AM, Kyrill Tkachov wrote:
> > Hi Kay,
> >
> > On 09/01/19 08:29, Kay F. Jahnke wrote:
> >> Hi there!
> >>
> >> I am developing software which tries to deliberately exploit the
> >> compiler's autovectorization facilities by
Blomqvist
Cc: Fortran List; GCC Patches; nd; kyrylo.tkac...@foss.arm.com; Ramana
Radhakrishnan; Richard Earnshaw
Subject: Re: [Committed] XFAIL gfortran.dg/ieee/ieee_9.f90
Hi
On 25/12/18 5:13 PM, Steve Kargl wrote:
> On Tue, Dec 25, 2018 at 09:51:03AM +0200, Janne Blomqvist wrote:
>> On Mo
Hi Wuyuan,
On 06/12/2018 01:31, wuyuan (E) wrote:
> Hi ARM maintainers:
> The taishanv110 core uses generic pipeline scheduling, which
> restricted the performance of taishanv110 core. By adding the pipeline
> scheduling of taishanv110 core in GCC,The performance of taishanv110 has
1 - 100 of 1493 matches
Mail list logo
