On Fri, Mar 7, 2025 at 11:07 PM Richard Sandiford
wrote:
>
> Wilco Dijkstra writes:
> > Hi Richard,
> >
> >>> Basically the small and large model are fundamentally incompatible. The
> >>> infamous
> >>> "dumb linker" approach means it doesn't try to sort sections, so an ADRP
> >>> relocation
>
On Tue, Mar 4, 2025 at 11:47 PM Wilco Dijkstra wrote:
>
> Hi Kyrill,
>
> > This restriction should be documented in invoke.texi IMO.
> > I also think it would be more user friendly to warn them about the
> > incompatibility if an explicit -moutline-atomics option is passed.
> > It’s okay though t
> On 19 Nov 2024, at 4:18 PM, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
>> -Original Message-
>> From: Andrew Pinski
>> Sent: Friday, November 15, 2024 7:16 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
On Fri, Oct 4, 2024 at 9:25 PM Andre Vieira (lists)
wrote:
>
> Hi,
>
> The patch for 'arm: Fix missed CE optimization for armv8.1-m.main [PR
> 116444]' introduced regressions with arm targets that used 'noce' before.
> This is because it would approve all noce optimisations without using
> the def
On Fri, Sep 27, 2024 at 2:11 PM Andre Vieira (lists)
wrote:
>
>
>
> On 26/09/2024 18:56, Ramana Radhakrishnan wrote:
> >
>
> >> +/* Helper function to determine whether SEQ represents a sequence of
> >> + instructions representing the Ar
On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>
> From: Fangrui Song
>
> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor). The sh port simply upgrades -fno-pic to -fpie by setting
> fl
> On 25 Sep 2024, at 7:38 PM, Andre Vieira (lists)
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> This patch restores missed optimizations for armv8.1-m.main targets that
> were missed when the generation of csinc, csinv and csneg were enabled
> or the sa
On Thu, Sep 12, 2024 at 8:42 PM Richard Earnshaw wrote:
>
> This short patch series adds the ability to unset the -mcpu and -march
> options on the Arm port. This helps to avoid ambiguities and warnings
> if, for some reason, the compiler flags need to be overridden.
>
> The main intent of this i
On Thu, Sep 5, 2024 at 4:30 PM Victor Do Nascimento
wrote:
>
>
> Changes from previous revision:
>
> As was done for the equivalent aarch64 patch, we rework this patch to do away
> with
> mission creep, keeping changes as simple as possible.
>
> We thus remove the `gimple_fold_builtin' changes th
> On 9 Sep 2024, at 10:34 PM, Andi Kleen wrote:
>
> External email: Use caution opening links or attachments
>
>
> Andi Kleen writes:
>
> Ping^4
>
> Could someone please approve this (nearly trivial) patch?
>
> Thanks,
> -Andi
>
>> Andi Kleen writes:
>>
>> Ping^3
>>
>>> Andi Kleen wr
> On 6 Aug 2024, at 4:14 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Kyrylo Tkachov writes:
>>> On 5 Aug 2024, at 18:00, Richard Sandiford
>>> wrote:
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Kyryl
As $Subject.
Pushed.
Ramana
commit 01691a6d0582a921bbcc09ab5e0cd9e7deca2cca
Author: Ramana Radhakrishnan
Date: Tue Jun 18 16:05:31 2024 +0530
[MAINTAINERS] Update my email address and move to DCO.
Signed-off-by: Ramana Radhakrishnan
* MAINTAINERS: Update
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, teachi
+ 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 param
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.
>
> Bootstr
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 t
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 val
e 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 instructio
be in gcc/config/arm but its possibly ok given the usage
statistics.
Reviewed-by: Ramana Radhakrishnan.
regards
Ramana
>
> --
> Evandro Menezes
>
>
>
> gcc/ChangeLog:
>
> * config/a
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
> 'branch-p
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
o the tree 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
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 > wri...@arm.com
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 symbo
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 po
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 (TAR
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/h
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 en
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
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, at
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 uncha
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 t
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 f
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 targe
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
&g
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 t
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 sugg
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 functi
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 (thumb1_expand_prologue)
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 en
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/
> * config/a
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
>
> >assign
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 file
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. non
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 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 as
>
> 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: U
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 defaults
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 th
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 th
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 t
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 name
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
> gain
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
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 arm_configu
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 a
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 Ar
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, a
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 (GC
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, co...@sdf.
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 we
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 a/gcc/config/aarch
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 co
ased we have
> the issue 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
>
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
t
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 not
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 t
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) wr
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 testin
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 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 w
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 mor
Tamar Christina
> 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 20
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. O
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 bui
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 testcase
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 a cana
1 - 100 of 1421 matches
Mail list logo
