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
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
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
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 (&
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
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
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
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
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
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
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
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].
>
>
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
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.
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
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
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
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.
> > >
> > >
>
> > 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
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
===
--- 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
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
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:
>> >>
>> >>
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
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,
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
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
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
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
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
> ===
>
>
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
> ===
>
>
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
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
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
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
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
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
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
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
>> >>
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
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
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
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:
>
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
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.
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
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
*): 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
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
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
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
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
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
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
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
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)
{
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
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
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
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
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
>&
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:
>>>
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
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
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
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]
>
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
>>
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
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
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
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
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
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
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:
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
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
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
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
>
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
>> >>
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
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:
>
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
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 @@
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
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
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
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
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
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
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
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
>>>
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
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
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:
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
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.
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
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
-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
101 - 200 of 1495 matches
Mail list logo