Re: [PATCH][AArch64][doc] Clarify -msve-vector-bits=128 behaviour

On Thu, Dec 13, 2018 at 10:15 AM Richard Sandiford wrote: > > Thanks for doing this. > > "Kyrill Tkachov" writes: > > @@ -15716,16 +15716,19 @@ an effect when SVE is enabled. > > > > GCC supports two forms of SVE code generation: ``vector-length > > agnostic'' output that works with any size

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On Tue, Dec 4, 2018 at 12:58 PM Florian Weimer wrote: > > * Wilco Dijkstra: > > >> For userland, I would like to eventually copy the OpenBSD approach for > >> architectures which have some form of PC-relative addressing: we can > >> have multiple random canaries in (RELRO) .rodata in sufficiently

Re: [RFC][AArch64] Add support for system register based stack protector canary access

On 03/12/2018 09:59, Jakub Jelinek wrote: > On Mon, Dec 03, 2018 at 09:55:36AM +0000, Ramana Radhakrishnan wrote: >> + if (aarch64_stack_protector_guard == SSP_GLOBAL >> + && opts->x_aarch64_stack_protector_guard_offset_str) >> +{ >> + error (&

[RFC][AArch64] Add support for system register based stack protector canary access

with his kernel patches. Thoughts ? regards Ramana gcc/ChangeLog: 2018-11-23 Ramana Radhakrishnan * config/aarch64/aarch64-opts.h (enum stack_protector_guard): New * config/aarch64/aarch64.c (aarch64_override_options_internal): Handle and put in error checks

Re: [PATCH] PR libstdc++/67843 set shared_ptr lock policy at build-time

Firstly thanks a lot for working on this. On 28/11/2018 12:49, Jonathan Wakely wrote: > On 28/11/18 12:30 +, Jonathan Wakely wrote: >> 3) We could change libstdc++'s configure to automatically override >> --with-libstdcxx-lock-policy for arm-linux so it always uses "atomic" >> (because we

Re: [PATCH, arm] Backport -- Fix ICE during thunk generation with -mlong-calls

On 07/11/2018 17:49, Mihail Ionescu wrote: > Hi All, > > This is a backport from trunk for GCC 8 and 7. > > SVN revision: r264595. > > Regression tested on arm-none-eabi. > > > gcc/ChangeLog > > 2018-11-02 Mihail Ionescu > > Backport from mainiline > 2018-09-26 Eric Botcazou

Re: [ARM] Implement division using vrecpe, vrecps

On 26/10/2018 06:04, Prathamesh Kulkarni wrote: > Hi, > This is a rebased version of patch that adds a pattern to neon.md for > implementing division with multiplication by reciprocal using > vrecpe/vrecps with -funsafe-math-optimizations excluding -Os. > The newly added test-cases are not

Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)

On Thu, Nov 1, 2018 at 10:42 AM Joern Wolfgang Rennecke wrote: > > > On 30/10/18 08:36, Richard Biener wrote: > > On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke > > wrote: > >> I want to submit some vectorizer patches, what would be a suitable > >> regression test? > > I am sure you

Re: [PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

c: Likewise. > * gcc.target/arm/thumb2-slow-flash-data-4.c: Likewise. > * gcc.target/arm/thumb2-slow-flash-data-5.c: Likewise. > * gcc.target/arm/tls-disable-literal-pool.c: Likewise. > > Is this ok for trunk? > > Best regards, > > Thomas > > On Tue, 2 Oc

Re: [PATCH] bring netbsd/arm support up to speed. eabi, etc.

On Wed, Oct 24, 2018 at 12:30 PM wrote: > > Thanks for the detailed response. > Sorry to give only a partial reply. > > On Tue, Oct 23, 2018 at 02:36:57PM +0100, Richard Earnshaw (lists) wrote: > > Thanks for posting this. Before we can commit it, however, we need to > > sort out the authorship

Re: [PATCH, ARM] Clean up arm backend using the @ construct for MD patterns

On 09/10/2018 09:27, Mihail Ionescu wrote: > Hi all, > > This patch removes some of the machine mode checks from the arm backend when > emitting instructions by using the '@' construct (Parameterized Names[2]). It > is based on the previous AArch64 patch[1]. > >

Re: [PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

On 02/10/2018 11:42, Thomas Preudhomme wrote: Hi Ramana, On Thu, 27 Sep 2018 at 11:14, Ramana Radhakrishnan wrote: On 27/09/2018 09:26, Kyrill Tkachov wrote: Hi Thomas, On 26/09/18 18:39, Thomas Preudhomme wrote: Hi, GCC ICEs under -mslow-flash-data and -mword-relocations because

Re: [PATCH, AArch64 08/11] aarch64: Add out-of-line functions for LSE atomics

On 26/09/2018 06:03, rth7...@gmail.com wrote: From: Richard Henderson This is the libgcc part of the interface -- providing the functions. Rationale is provided at the top of libgcc/config/aarch64/lse.c. * config/aarch64/lse.c: New file. * config/aarch64/t-lse: New file.

Re: [PATCH, AArch64 00/11] LSE atomics out-of-line

On 27/09/2018 17:40, Richard Henderson wrote: On 9/27/18 6:07 AM, Ramana Radhakrishnan wrote: I do have an additional concern that I forgot to mention in Vancouver - Thanks Wilco for reminding me that this now replaces a bunch of inline instructions with effectively a library call therefore

Re: [PATCH, AArch64 00/11] LSE atomics out-of-line

Graf of SuSE, and Ramana Radhakrishnan of ARM, at last week's Linaro Connect in Vancouver. The current state of the world is that one could distribute two different copies of a given shared library and place the LSE-enabled version in /lib64/atomics/ and it will be selected over the /lib64/ version

Re: [PATCH, GCC/ARM] Fix PR87374: ICE with -mslow-flash-data and -mword-relocations

On 27/09/2018 09:26, Kyrill Tkachov wrote: Hi Thomas, On 26/09/18 18:39, Thomas Preudhomme wrote: Hi, GCC ICEs under -mslow-flash-data and -mword-relocations because there is no way to load an address, both literal pools and MOVW/MOVT being forbidden. This patch gives an error message when

Re: [GCC][PATCH][Aarch64] Added pattern to match zero extended bfxil

On Mon, 17 Sep 2018, 23:56 Christophe Lyon, wrote: > On Fri, 14 Sep 2018 at 12:04, Sam Tebbs wrote: > > > > > > > > On 08/28/2018 11:54 PM, James Greenhalgh wrote: > > > > > > > > > > OK once the other one is approved, with the obvious rebase over the > renamed > > > function. > > > > > >

Re: [PATCH] Schedule by INSN_COST in case of tie

> > > This to me feels like the wrong approach as it feels like you are assuming > > INSN_COST is latency in some way ? Surely, we shouldn't be introducing > > INSN_COST based stuff into the scheduler. > > > > Have you investigated using TARGET_SCHED_ADJUST_COST (IIRC, look for the > > right

Re: [PATCH] Schedule by INSN_COST in case of tie

On Tue, 11 Sep 2018, 14:38 Vlad Lazar, wrote: > Hi. > > This patch makes the scheduler prefer instructions with higher cost if two > given instructions are equally good. > Issuing more restricted instructions first is particularly useful on > in-order cores because it increases the > number of

[arm-8-branch] Backport spectre v1 patches

=== --- gcc/ChangeLog.arm (revision 263529) +++ gcc/ChangeLog.arm (working copy) @@ -1,3 +1,190 @@ +2018-08-14 Ramana Radhakrishnan + + Backport spectre v1 mitigation patches. + 2018-08-06 John David Anglin + PR target/86785 + * config/pa/pa.c

[Patch wwwdocs] Document arm-8-branch

As $subject. Ok ? regards Ramana ? htdocs/svn.html.~1.223.~ Index: htdocs/svn.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v retrieving revision 1.223 diff -a -u -p -r1.223 svn.html --- htdocs/svn.html 18 Jul 2018

Re: [arm-8-branch] Add Linaro version string and macros

On Fri, Aug 10, 2018 at 5:00 PM, Yvan Roux wrote: > On Fri, 10 Aug 2018 at 17:01, Ramana Radhakrishnan > wrote: >> >> On Fri, Aug 10, 2018 at 3:35 PM, Yvan Roux wrote: >> > On Fri, 10 Aug 2018 at 14:31, Yvan Roux wrote: >> >> >> >>

Re: [PATCH] Come up with TARGET_GET_VALID_OPTION_VALUES option hook (PR driver/83193).

On Mon, Aug 13, 2018 at 1:49 PM, Martin Liška wrote: > PING^1 > > On 07/24/2018 02:05 PM, Martin Liška wrote: >> Hi. >> >> I'm sending updated version of the patch. It comes up with a new target >> common hook >> that provide option completion list. It's used both in --help=target and >> with

Re: [arm-8-branch] Add Linaro version string and macros

On Fri, Aug 10, 2018 at 3:35 PM, Yvan Roux wrote: > On Fri, 10 Aug 2018 at 14:31, Yvan Roux wrote: >> >> On Fri, 10 Aug 2018 at 13:45, Ramana Radhakrishnan >> wrote: >> > >> > On Fri, Aug 10, 2018 at 11:09 AM, Yvan Roux wrote: >> > > Hi,

Re: [arm-8-branch] Add Linaro version string and macros

On Fri, Aug 10, 2018 at 11:09 AM, Yvan Roux wrote: > Hi, > > This patch adds Linaro version string and release macros to ARM GCC 8 > vendor branch. > > Ok to commit? > Ok if no regressions. (I'm assuming you've built and eyeballed that the pre-processor macros are being produced). (I have a

Re: [RFC] Adding Python as a possible language and it's usage

On Fri, Jul 27, 2018 at 3:38 PM, Joseph Myers wrote: > On Fri, 27 Jul 2018, Michael Matz wrote: > >> Using any python scripts as part of generally building GCC (i.e. where the >> generated files aren't prepackaged) will introduce a python dependency for >> distro packages. And for those distros

Re: [PATCH] haiku: Initial build support

On Thu, Jul 26, 2018 at 6:26 PM, Joseph Myers wrote: > On Mon, 16 Jul 2018, Alexander von Gluck IV wrote: > >> * We have been dragging these around since gcc 4.x. >> * Some tweaks will likely be needed, but this gets our foot >> in the door. >> >> Authors: >> Fredrik Holmqvist >> Jerome

Re: [Patch] [Aarch64] PR 86538 - Define __ARM_FEATURE_LSE if LSE is available

On Tue, Jul 24, 2018 at 10:55 PM, Steve Ellcey wrote: > On Tue, 2018-07-24 at 22:04 +0100, James Greenhalgh wrote: >> >> >> I'd say this patch isn't desirable for trunk. I'd be interested in use cases >> that need a static decision on presence of LSE that are not better expressed >> using higher

Re: GCC 8.2 Status Report (2018-07-19), branch frozen for release

On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener wrote: > > Status > == > > The GCC 8 branch is frozen for preparation of the GCC 8.2 release. > All changes to the branch now require release manager approval. > > > Previous Report > === > >

Re: GCC 8.2 Status Report (2018-07-19), branch frozen for release

On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener wrote: > > Status > == > > The GCC 8 branch is frozen for preparation of the GCC 8.2 release. > All changes to the branch now require release manager approval. > > > Previous Report > === > >

Re: [Patch-86512]: Subnormal float support in armv7(with -msoft-float) for intrinsics

On Mon, Jul 23, 2018 at 12:09 PM, Umesh Kalappa wrote: > Hi Richard, > > We tested on the SP and yes the problem persist on the SP too and > attached patch will fix the both SP and DP issues for the denormal > resultant. > We bootstrapped the compiler ,look ok to us with minimal testing , Have

Re: RFC: Patch to implement Aarch64 SIMD ABI

On Thu, Jul 19, 2018 at 8:31 AM, Richard Sandiford wrote: > Hi, > > Thanks for doing this. > > Steve Ellcey writes: >> This is a patch to support the Aarch64 SIMD ABI [1] in GCC. I intend >> to eventually follow this up with two more patches; one to define the >> TARGET_SIMD_CLONE* macros and

Re: Subnormal float support in armv7(with -msoft-float) for intrinsics

On Tue, Jul 17, 2018 at 10:41 AM, Umesh Kalappa wrote: > Hi Nagy, > > Please help us with your comments on the attached patch for the issue > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512) > > Thank you and waiting for your inputs on the same. Patches should be sent to

[Patch AArch64] Add early clobber for the store_exclusive patterns.

behaviour. Bootstrapped and regression tested on AArch64 , no regressions. Ok ? Thanks, Ramana * config/aarch64/atomics.md (aarch64_store_exclusive): Add early clobber. commit 0608cb64b97368dc1bbea87e3a9541cfb832c015 Author: Ramana Radhakrishnan Date: Tue Jun 12 16:03:24 2018 +0100

Re: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.

On Fri, Jul 6, 2018 at 1:13 PM, Tamar Christina wrote: >> >> >> >> So I am curious as to why this shows up in Christophe's test but not >> >> in any of your test runs or indeed the testruns with our scripts. >> >> > > The test was changed before sending out, the individual entries moved to > a

Re: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.

On Fri, Jul 6, 2018 at 1:04 PM, Christophe Lyon wrote: > On Fri, 6 Jul 2018 at 13:56, Ramana Radhakrishnan > wrote: >> >> On Fri, Jul 6, 2018 at 10:16 AM, Tamar Christina >> wrote: >> > Hi All, >> > >> > This fixes a -Wpedantic error wi

Re: [committed][aarch64][gcc][patch] Fix -Wpedantic issue with testcase.

On Fri, Jul 6, 2018 at 10:16 AM, Tamar Christina wrote: > Hi All, > > This fixes a -Wpedantic error with the testcase because of extra ; left after > the > functions. > > Regtested single test on aarch64-none-elf and no issues. > > Committed under the GCC obvious rule. So I am curious as to

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

On Thu, Jun 7, 2018 at 10:35 AM, Richard Biener wrote: > On Thu, Jun 7, 2018 at 10:45 AM Ard Biesheuvel > wrote: >> >> On 7 June 2018 at 10:21, Christoffer Dall wrote: >> > On Thu, Jun 07, 2018 at 09:56:18AM +0200, Ard Biesheuvel wrote: >> >> On 7 June 2018 at 09:48, Christoffer Dall >> >>

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

On Tue, Jun 5, 2018 at 9:16 AM, Laszlo Ersek wrote: > On 06/05/18 08:04, Ard Biesheuvel wrote: >> On 4 June 2018 at 20:10, Laszlo Ersek wrote: >>> Hi! >>> >>> Apologies if this isn't the right place for asking. For the problem >>> statement, I'll simply steal Ard's writeup [1]: >>> KVM on

Re: [RFC] [aarch64] Add HiSilicon tsv110 CPU support

On 23/05/2018 03:50, Zhangshaokun wrote: Hi Ramana, On 2018/5/22 18:28, Ramana Radhakrishnan wrote: On Tue, May 22, 2018 at 9:40 AM, Shaokun Zhang <zhangshao...@hisilicon.com> wrote: tsv110 is designed by HiSilicon and supports v8_4A, it also optimizes L1 Icache which can access L1

Re: [RFC] [aarch64] Add HiSilicon tsv110 CPU support

On Tue, May 22, 2018 at 9:40 AM, Shaokun Zhang wrote: > tsv110 is designed by HiSilicon and supports v8_4A, it also optimizes > L1 Icache which can access L1 Dcache. > Therefore, DC CVAU is not necessary in __aarch64_sync_cache_range for > tsv110, is there any good

Re: [PATCH] PR gcc/84923 - gcc.dg/attr-weakref-1.c failed on aarch64

On Fri, Apr 13, 2018 at 7:08 AM, wrote: > From: Vladimir Mezentsev > > When weakref_targets is not empty a target cannot be removed from weak_decls. > A small example is below when 'wv12' is removed from the weak list on aarch64: >

Re: Dealing with default recursive procedures in Fortran

On Thu, Apr 12, 2018 at 10:50 PM, Thomas König wrote: > Hello world, > > with Fortran 2018, recursive is becoming the default. This will likely > have a serious impact on many user codes, which often declare large > arrays which could then overflow stacks, leading to segfaults

Re: [PATCH, GCC/ARM] Fix PR85261: ICE with FPSCR setter builtin

On 06/04/2018 16:54, Thomas Preudhomme wrote: > Instruction pattern for setting the FPSCR expects the input value to be > in a register. However, __builtin_arm_set_fpscr expander does not ensure > that this is the case and as a result GCC ICEs when the builtin is > called with a constant literal.

[Patch ARM] Fix PR81863.

in a day or so. regards Ramana * config/arm/arm.c (arm_valid_symbolic_address): Handle arm_word_relocations gcc/testsuite * gcc.target/arm/pr81863.c: New test. commit 22e3c20b7e6b5027f07b71ca31c9f65e66537b0b Author: Ramana Radhakrishnan <ramana.radhakrish...@arm.com> Date: Tue Mar

Re: [Patch AArch64] Turn on -fasynchronous-unwind-tables and -funwind-tables by default.

On Mon, Mar 19, 2018 at 12:12 PM, James Greenhalgh <james.greenha...@arm.com> wrote: > On Tue, Mar 13, 2018 at 01:35:56PM +0000, Ramana Radhakrishnan wrote: >> Jakub commented here that >> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01325.html we don't turn >> on

[Patch AArch64] Turn on -fasynchronous-unwind-tables and -funwind-tables by default.

*): New TARGET_DEFAULT_ASYNC_UNWIND_TABLES common/config/aarch64/aarch64-common.c (aarch64_optimization_table[]): Turn on fasynchronous-unwind-tables and funwind-tables. commit ef1b5fa855a369b9996ccd7041255ff75a4b5b63 Author: Ramana Radhakrishnan <ramana.radhakrish...@arm.com> Date: Mon Mar 5

Richard Sandiford appointed SVE maintainer in AArch64 port.

I am pleased to announced that the GCC Steering Committee has appointed Richard Sandiford as SVE maintainer in the AArch64 port. Please join me in congratulating Richard on his additional role. Richard, please update your listing in the MAINTAINERS file. regards Ramana

Re: [SFN+LVU+IEPM v4 9/9] [IEPM] Introduce inline entry point markers

On Fri, Mar 9, 2018 at 9:48 AM, Bin.Cheng wrote: > On Wed, Feb 28, 2018 at 6:17 AM, Alexandre Oliva wrote: >> On Feb 21, 2018, Alexandre Oliva wrote: >> >>> On Feb 15, 2018, Szabolcs Nagy wrote: i see

Re: [Aarch64] Fix conditional branches with target far away.

On Wed, Feb 14, 2018 at 8:30 AM, Sameera Deshpande wrote: > Hi! > > Please find attached the patch to fix bug in branches with offsets over 1MiB. > There has been an attempt to fix this issue in commit > 050af05b9761f1979f11c151519e7244d5becd7c > > However, the

Re: Fw: GCC interpretation of C11 atomics (DR 459)

On Mon, Feb 26, 2018 at 10:45 PM, Ruslan Nikolaev via gcc wrote: > Thanks, everyone, for the output, it is very useful. I am just proposing to > consider the change unless there are clear roadblocks. (Either design choice > is probably OK with respect to the standard formally

[Patch AArch64] Turn on frame pointer / partial fix for PR84521

on AArch64-none-linux-gnu but I see one regression in gcc.c-torture/execute/960419-2.c which needs to be looked at next (PR84528, thanks Kyrill). Ok to put in and then look at PR84528 ? gcc/ChangeLog: 2018-02-23 Ramana Radhakrishnan <ramana.radhakrish...@arm.com> PR target

[Patch ARM] Fix probe_stack constraint.

The probe_stack pattern uses r0 as a fixed register. This can cause issues if we have auto-increment instructions coming out that have r0 as the base register. Tested with a bootstrap and regression run. richi reports that the original issue was fixed in the run. I did consider whether

Re: [patch, fortran] Implement maxloc and minloc for character

On Thu, Nov 23, 2017 at 1:53 PM, Janne Blomqvist wrote: > On Thu, Nov 23, 2017 at 2:56 PM, Janne Blomqvist > wrote: >> On Wed, Nov 22, 2017 at 8:10 PM, Thomas Koenig wrote: >>> Hi Janne, >>> > So, attached is a new

[Patch AArch64] Fixup floating point division with -march=armv8-a+nosimd

Hi, I received a private report from a customer that gcc was putting out calls to __divdf3 when compiling with +nosimd. When the reciprocal math support was added this was probably an oversight or a typo. The canonical examples is : double foo (double x, double y) {

Re: [PATCH] Set default to -fomit-frame-pointer

On 3 Nov 2017 16:55, "Wilco Dijkstra" wrote: Almost all targets add an explict -fomit-frame-pointer in the target specific options. Rather than doing this in a target-specific way, do this in the generic options so it works identically across all targets. In many cases

Re: [COMMITTED][AArch64] Fix frame tests

Why do we need fno-omit-frame-pointer on aarch64 ? Ramana From: James Greenhalgh Sent: Friday, 17 November, 22:02 Subject: Re: [COMMITTED][AArch64] Fix frame tests To: Wilco Dijkstra Cc: GCC Patches, nd, Richard Earnshaw, Marcus Shawcroft, Ramana Radhakrishnan On Thu, Nov 16, 2017 at 11:34

Re: [patch 0/5] nios2 address mode improvements

On Fri, Oct 20, 2017 at 9:18 AM, Richard Biener wrote: > On Fri, Oct 20, 2017 at 10:12 AM, Richard Biener >> How do other targets handle this situation? Naiively I'd have handled >> the splitting at reload/LRA time ... (which would make the flag >> to test

Re: [PATCH 2/2] PR libgcc/59714 complex division is surprising on aarch64

On Fri, Oct 13, 2017 at 10:25 PM, Richard Earnshaw wrote: > On 13/10/17 18:28, vladimir.mezent...@oracle.com wrote: >> On 10/12/2017 03:40 AM, Richard Earnshaw wrote: >>> On 12/10/17 06:21, vladimir.mezent...@oracle.com wrote: From: Vladimir Mezentsev

Re: [PATCH] Fix PR82396: qsort comparator non-negative on sorted output

On Wed, Oct 4, 2017 at 2:39 PM, Alexander Monakov <amona...@ispras.ru> wrote: > On Wed, 4 Oct 2017, Ramana Radhakrishnan wrote: >> However we need a scheduler maintainer or global reviewer to please >> help review this patch or help come up with an alternative patch. A >&

Re: [PATCH] Fix PR82396: qsort comparator non-negative on sorted output

On Wed, Oct 4, 2017 at 12:01 PM, Richard Sandiford wrote: > Wilco Dijkstra writes: >> Christophe Lyon wrote: >> >>> FWIW, I confirm that this patch fixes the build failure I reported at: >>>

Re: [PATCH, ARM] fix .cfi inconsistency out of builtin_eh_return

On Thu, Aug 3, 2017 at 10:02 AM, Olivier Hainque wrote: > Hello, > > Activating dwarf2 based eh for real on VxWorks6 (patch to come) triggers a > libgcc build failure, where most functions resorting to __builtin_eh_return > fail this check from maybe_record_trace_start in

Re: [patch][arm] (respin) Improve error checking in parsecpu.awk

On 9/22/17 4:58 PM, Vidya Praveen wrote: Hello, This patch by Richard Earnshaw was reverted along with the commit that preceded it as the preceding commit was causing cross-native builds to fail and I presumed this patch was related too. Now I am respinning as the issue that caused the

Re: [patch][arm] (respin) auto-generate arm-isa.h from CPU descriptions

On 22/09/17 16:54, Vidya Praveen wrote: Hello, This patch by Richard Earnshaw was reverted earlier as it was breaking cross-native builds. Respinning now with a minor change that fixes the build issue - adding arm-isa.h to GTM_H. Also remove a redundant dependency (TM_H includes GTM_H). Tested

Re: "GOT" under aarch64

On Fri, Sep 22, 2017 at 12:29 PM, Wilco Dijkstra wrote: > Hi, > > You'll get GOT relocations to globals when you use -fpic: > > int x; > int f(void) { return x; } >>gcc -O2 -S -o- -fpic > > f: > adrpx0, :got:x > ldr x0, [x0, #:got_lo12:x] >

Re: [PING, ARM] Handle DWARF2_UNWIND_INFO in arm_except_unwind_info

On Wed, Sep 20, 2017 at 1:32 PM, Olivier Hainque wrote: > Hello, > > Ping for > > https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00278.html > >> On Aug 3, 2017, at 11:39 , Olivier Hainque wrote: >> >> On top of the correction for fallouts proposed in >>

Re: [RFC][AARCH64][PATCH 5/5] add aarch64_loop_unroll_adjust to limit partial unrolling in rtl based on strided-loads in loop

On Fri, Sep 15, 2017 at 2:33 AM, Kugan Vivekanandarajah wrote: > This patch adds aarch64_loop_unroll_adjust to limit partial unrolling > in rtl based on strided-loads in loop. > > Thanks, > Kugan > > gcc/ChangeLog: > > 2017-09-12 Kugan Vivekanandarajah

Re: Help out/New to the Project

On Sat, Sep 9, 2017 at 4:27 AM, nick wrote: > Greetings All, > > I am interested in helping out with the gcc project. I understand there is a > bugzilla I can get started on > but is there anything else in terms of things I should be reading outside the > core docs in the

Announcing ARM and AArch64 port maintainers.

I'm pleased to announce that the steering committee has appointed - James Greenhalgh as a full maintainer for the AArch64 port and - Kyrylo Tkachov as a full maintainer for the ARM port. James & Kyrylo, if you could update your entries in the MAINTAINERS file to reflect these roles, it would

Re: [PATCH][GCC][ARM] Fix code generation from parsecpu.awk to remove duplicates.

On 7/25/17 1:59 PM, Tamar Christina wrote: Hi All, The new ARM options parser generates from the following entry begin cpu cortex-a55 ... architecture armv8.2-a+fp16+foo option crypto add FP_ARMv8 CRYPTO option dotprod add FP_ARMv8 FOO option nofp remove ALL_FP ... end cpu

Re: [COMMITED][AArch64] Fix PR79041

On Tue, Jul 25, 2017 at 1:13 PM, Wilco Dijkstra wrote: > James Greenhalgh wrote: >> >> OK. Either like this, or with the conditions swapped around as Yvan >> suggested to make backporting easier. > > I swapped the conditions around, not sure whether it helps... > Also I

Re: Linux and Windows generate different binaries

On Wed, Jul 12, 2017 at 3:57 PM, Sandra Loosemore wrote: > On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote: >> >> I have seen reproducible builds being discussed here, but what is the >> position on inter c-lib and OS reproducible builds? > > > I think we

[Patch ARM] Remove %? string from some Advanced SIMD patterns.

Ramana Radhakrishnan <ramana.radhakrish...@arm.com> * config/arm/neon.md (fma4): Remove %?. (fma4_intrinsic): Likewise. (*fmsub4): Likewise. (*fmsub4_intrinsic): Likewise. regards Ramana commit b510e80f861b97496386fe58e6b6976a94a3afa1 Author:

Re: [PATCH] [AArch64] Fix PR71112

On Wed, Nov 23, 2016 at 5:25 AM, Hurugalawadi, Naveen wrote: > Hi, > > Please find attached the patch that fixes PR71112. > > The current implementation that handles SYMBOL_SMALL_GOT_28K in > aarch64_load_symref_appropriately access the high part of RTX for

Re: [PATCH][AArch64] Fix ILP32 memory access

On Tue, Jul 4, 2017 at 2:53 PM, Michael Matz wrote: > Hi, > > On Tue, 4 Jul 2017, Wilco Dijkstra wrote: > >> > You'll probably also have to set GNATBIND and GNATMAKE to the >> > appropriately suffixed variants. Just saying, because that's what I'm >> > usually forgetting and end up

Re: [PATCH][AArch64] Fix ILP32 memory access

On Tue, Jul 4, 2017 at 1:56 PM, Arnaud Charlet wrote: > On Tue, Jul 04, 2017 at 12:19:35PM +, Wilco Dijkstra wrote: >> Andreas Schwab wrote: >> > @@ -5207,6 +5209,7 @@ aarch64_print_operand (FILE *f, rtx x, int code) >> > >> >case MEM: >> > output_address

Re: [PATCH] rs6000 branch probability changes

On Fri, Jun 30, 2017 at 2:36 PM, David Edelsohn wrote: > Convert the rs6000 port to use the new API for branch probabilities. > > Okay? > > Thanks, David > > * config/rs6000/rs6000.c (emit_unlikely_jump): Adjust to new branch > probability data type. > > Index: rs6000.c >

Re: Convert profile probabilities to new type

On Thu, Jun 29, 2017 at 11:24 PM, Jan Hubicka wrote: >> On Thu, Jun 29, 2017 at 11:19 PM, Jan Hubicka wrote: >> >> After this commit (r249800), GCC builds fail for arm and aarch64: >> >> >> >> /gccsrc/gcc/except.c: In function ???void >> >>

Re: Convert profile probabilities to new type

On Thu, Jun 29, 2017 at 11:19 PM, Jan Hubicka wrote: >> After this commit (r249800), GCC builds fail for arm and aarch64: >> >> /gccsrc/gcc/except.c: In function ???void >> sjlj_emit_function_enter(rtx_code_label*)???: >> /gcc-fsf/gccsrc/gcc/except.c:1183: error: conversion from

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

On Wed, Jun 28, 2017 at 2:02 AM, Kugan Vivekanandarajah <kugan.vivekanandara...@linaro.org> wrote: > Hi Ramana, > > On 27 June 2017 at 18:01, Ramana Radhakrishnan > <ramana.radhakrish...@foss.arm.com> wrote: >> On 27/06/17 02:20, Kugan Vivekanandarajah wrote: >

Re: [PATCH][AArch64] Improve Cortex-A53 shift bypass

On 6/28/17 1:49 PM, Wilco Dijkstra wrote: Ramana Radhakrishnan wrote: I'm about to run home for the day but this came in from https://gcc.gnu.org/ml/gcc-patches/2013-09/msg02109.html and James said in that email that this was put in to ensure no segfaults on cortex-a15 / cortex-a7 tuning

Re: [PATCH][AArch64] Improve Cortex-A53 shift bypass

On Wed, Jun 14, 2017 at 2:55 PM, James Greenhalgh wrote: > On Fri, May 05, 2017 at 05:02:46PM +0100, Wilco Dijkstra wrote: >> Richard Earnshaw (lists) wrote: >> >> > --- a/gcc/config/arm/aarch-common.c >> > +++ b/gcc/config/arm/aarch-common.c >> > @@ -254,12 +254,7 @@

Re: [AARCH64] Disable pc relative literal load irrespective of TARGET_FIX_ERR_A53_84341

On 27/06/17 02:20, Kugan Vivekanandarajah wrote: https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00614.html added this workaround to get kernel building with when TARGET_FIX_ERR_A53_843419 is enabled. This was added to support building kernel loadable modules. In kernel, when

[Patch AArch64 / libstdc++] Update baseline symbols for aarch64-none-linux-gnu

Regenerate symbols file for aarch64-none-linux-gnu. Tested with make check in libstdc++ and eyeballing outputs. Applied as obvious. Tested on aarch64-none-linux-gnu with no issues in libstdc++ tests. regards Ramana * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate diff

Re: [PATCH][AArch64] Add crypto_pmull attribute

On Tue, Jun 20, 2017 at 10:26 AM, Hurugalawadi, Naveen wrote: > Hi James, > > Thanks for the approval. > >>> From an AArch64 perspective, this is OK - but please wait for an ARM >>> approval before you commit it. > > Can anyone from ARM comment on the patch so that

Re: [PATCH 00/30] [ARM] Reworking the -mcpu, -march and -mfpu options

On Fri, Jun 16, 2017 at 10:11 PM, Richard Earnshaw wrote: > On 13/06/17 18:35, Richard Earnshaw (lists) wrote: >> On 09/06/17 13:53, Richard Earnshaw wrote: >>> >>> During the ARM BoF at the Cauldron last year I mentioned that I wanted >>> to rework the way GCC on

[Patch emit-rtl.h] Update comment about is_leaf

crtl->is_leaf has a comment above it referring to "Local Register Allocation". However this is set by IRA and not LRA since the meaning of Local Register Allocator in GCC has changed quite drastically since 1999 when this comment was introduced above the variable current_function_is_leaf. From

Re: [Patch AArch64] Do not increase data alignment at -Os and with -fconserve-stack.

Ping.. Ramana On Tue, May 2, 2017 at 10:52 AM, Ramana Radhakrishnan <ramana.radhakrish...@foss.arm.com> wrote: > We unnecessarily align data to 8 byte alignments even when -Os is specified. > This brings the logic in the AArch64 backend more in line with the ARM > backend and

Re: [PATCH][GCC][AArch64][ARM] Modify idiv costs for Cortex-A53

On Tue, Jun 6, 2017 at 1:56 PM, James Greenhalgh wrote: > On Tue, May 02, 2017 at 04:37:21PM +0100, Tamar Christina wrote: >> Hi All, >> >> This patch adjusts the cost model for Cortex-A53 to increase the costs of >> an integer division. The reason for this is that we

Re: [PATCH, rs6000] Fold vector absolutes in GIMPLE

On Wed, May 31, 2017 at 3:02 PM, Richard Biener wrote: > On Wed, May 31, 2017 at 3:56 PM, Will Schmidt > wrote: >> On Tue, 2017-05-30 at 09:00 +0200, Richard Biener wrote: >>> On Mon, May 29, 2017 at 2:21 PM, Segher Boessenkool >>>

Re: [PATCH][GCC][AArch64][ARM] Modify idiv costs for Cortex-A53

On Tue, May 2, 2017 at 4:37 PM, Tamar Christina wrote: > Hi All, > > This patch adjusts the cost model for Cortex-A53 to increase the costs of > an integer division. The reason for this is that we want to always expand > the division to a multiply when doing a division by

Re: [PATCH, GCC/ARM 2/2] Allow combination of aprofile and rmprofile multilibs

On Thu, Oct 13, 2016 at 4:35 PM, Thomas Preudhomme wrote: > Hi ARM maintainers, > > This patchset aims at adding multilib support for R and M profile ARM > architectures and allowing it to be built alongside multilib for A profile > ARM architectures. This specific

Re: [PATCH, GCC/ARM, Stage 1] Enable Purecode for ARMv8-M Baseline

On Thu, May 04, 2017 at 09:50:42AM +0100, Prakhar Bahuguna wrote: > > > > Otherwise ok. Please respin and test with an armhf thumb32 bootstrap > > and regression test run. > > > > regards > > Ramana > > I've respun this patch with the suggested changes, along with a new changelog > for docs:

Re: [PATCH, GCC/ARM, Stage 1] Enable Purecode for ARMv8-M Baseline

On Tue, May 02, 2017 at 11:45:48AM +0100, Prakhar Bahuguna wrote: > This patch adds support for purecode to ARMv8-M Baseline, in addition to the > existing support for ARMv7-M and ARMv8-M Mainline. > > gcc/ChangeLog: > > 2017-01-11 Prakhar Bahuguna > Andre

[Patch AArch64] Do not increase data alignment at -Os and with -fconserve-stack.

We unnecessarily align data to 8 byte alignments even when -Os is specified. This brings the logic in the AArch64 backend more in line with the ARM backend and helps gain some image size in a few places. Caught by an internal report on the size of rodata sections being high with aarch64 gcc.

Re: [Patch, GCC/ARM, gcc-5-branch] Fix PR68390 Incorrect code due to indirect tail call of varargs function with hard float ABI

On Wed, Apr 12, 2017 at 6:55 PM, Christophe Lyon wrote: > Hi, > > It looks like we forgot to backport the fix for PR68390 to gcc-5-branch. > The patch applies cleanly, and fwiw we've had it in the linaro-5 > branch for a while. > > OK to apply to gcc-5-branch? > OK if

Re: One more path to fix PR70478

On Tue, Apr 11, 2017 at 5:26 PM, Christophe Lyon wrote: > On 11 April 2017 at 17:42, Vladimir Makarov wrote: >> >> >> On 04/11/2017 03:30 AM, Christophe Lyon wrote: >>> >>> Hi Vladimir, >>> >>> On 10 April 2017 at 17:05, Vladimir Makarov

Re: [PATCH, GCC/ARM, gcc-5-branch] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

-03-22 Thomas Preud'homme <thomas.preudho...@arm.com> PR target/80082 * gcc.target/arm/atomic_loaddi_10.c: New testcase. * gcc.target/arm/atomic_loaddi_11.c: Likewise. Is this ok for gcc-5-branch? OK. Ramana Best regards, Thomas On 06/04/17 14:05, Ramana Radhakr

Re: [PATCH, GCC/ARM, gcc-6-branch] Fix PR80082: LDRD erronously used for 64bit load on ARMv7-R

On Mon, Mar 27, 2017 at 12:15 PM, Thomas Preudhomme wrote: > Hi, > > Currently GCC is happy to use LDRD to perform a 64bit load on ARMv7-R, > as shown by the testcase on this patch. However, LDRD is only atomic > when LPAE extensions is available, which they are

Re: [PATCH, GCC/testsuite/ARM, stage4, ping] Compile atomic_loaddi_11 for Cortex-R5

On Tue, Apr 4, 2017 at 6:00 PM, Thomas Preudhomme wrote: > Hi, > > gcc.target/arm/atomic_loaddi_11.c testcase contributed in r246365 does > not test the changed code since ARMv7-R does not have division > instructions in ARM state. This patch changes it to target

<    1   2   3   4   5   6   7   8   9   10   >