On 16/01/15 10:20, Marcus Shawcroft wrote:
On 15 January 2015 at 09:50, James Greenhalgh wrote:
2015-01-15 James Greenhalgh
* config/arm/cortex-a57.md: New.
* config/aarch64/aarch64.md: Include it.
* config/aarch64/aarch64-cores.def (cortex-a57): Tune for it.
On Thu, Nov 13, 2014 at 5:54 AM, Bin Cheng wrote:
> Hi,
> As commented at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00684.html,
> this is a simple patch enabling neon memset inlining on
> cortex-a53/cortex-a57 in AArch32 mode.
>
> Test on
> arm-none-linux-gnueabihf/--with-cpu=cortex-a57/--with
On Fri, Jan 16, 2015 at 3:06 PM, Maxim Kuvyrkov
wrote:
> On Nov 19, 2014, at 12:27 PM, Ramana Radhakrishnan
> wrote:
>
>>
>
> Hi Ramana,
> Hi Vladimir,
>
> I still don't have SPEC2000/SPEC2006 benchmark numbers for this patch. Since
> stage3 is about to
On Fri, Jan 16, 2015 at 3:06 PM, James Greenhalgh
wrote:
> On Fri, Jan 16, 2015 at 10:20:40AM +, Marcus Shawcroft wrote:
>> On 15 January 2015 at 09:50, James Greenhalgh
>> wrote:
>>
>> > 2015-01-15 James Greenhalgh
>> >
>> > * config/arm/cortex-a57.md: New.
>> > * config/
On 16/01/15 16:56, Kyrill Tkachov wrote:
Hi all,
As the simple PR says we should call va_end before returning early from
a function that started processing the va_list with va_start.
The C spec agrees:
"Each invocation of the va_start and va_copy macros
shall be matched by a corresponding invo
> What is aarch64 specific on the testcase?
The number of if-then-else's required to get the compiler to generate
branch sequences rather than the tbnz instruction.
Ramana
t documentation and looked at it.
Applied.
Ramana
Ramana Radhakrishnan
PR target/64532
* doc/md.texi (ARM Constraints): Document register constraints.
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index 7bc7842..0050ba7 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -1800,8
On 19/01/15 21:05, James Greenhalgh wrote:
On Mon, Jan 19, 2015 at 08:57:31PM +, Gerald Pfeifer wrote:
On Monday 2015-01-19 17:52, James Greenhalgh wrote:
OK after the Cortex-A57 scheduling description goes in to the ARM port?
Yes, thanks, except that once will be sufficient. ;-) (The
On 19/01/15 18:14, Maxim Kuvyrkov wrote:
On Jan 19, 2015, at 6:05 PM, Richard Earnshaw wrote:
On 16/01/15 15:06, Maxim Kuvyrkov wrote:
@@ -1874,7 +1889,8 @@ const struct tune_params arm_cortex_a15_tune =
true, true, /* Prefer 32-bit encodings. */
tru
On Tue, Jan 13, 2015 at 1:32 PM, Matthew Wahab wrote:
> Hello,
>
> The LRA register alloator is enabled by default for the ARM backend and
> -mno-lra should no longer be used. This patch removes the -mlra/-mno-lra
> option from the ARM backend.
>
> arm-none-linux-gnueabihf passes gcc-check with no
On Thu, Jan 15, 2015 at 12:10 PM, Tony Liu wrote:
> Hi,
>
> This is the patch to improve the test case gcc.target/arm/scd42-1.c for both
> UAL and non-UAL. It now checks UAL format assembly code for Thumb1 and
> Thumb2 while non-UAL format assembly code for ARM mode.
OK.
Ramana
>
> With this pa
On Mon, Jan 19, 2015 at 5:44 PM, James Greenhalgh
wrote:
>
> On Fri, Jan 16, 2015 at 11:14:42AM +, Ramana Radhakrishnan wrote:
>>
>>
>> On 16/01/15 10:20, Marcus Shawcroft wrote:
>> > On 15 January 2015 at 09:50, James Greenhalgh
>> > wrot
On Fri, Jan 9, 2015 at 7:43 AM, Terry Guo wrote:
>
>
>> -Original Message-
>> From: Richard Earnshaw
>> Sent: Monday, December 08, 2014 7:31 PM
>> To: Terry Guo; gcc-patches@gcc.gnu.org
>> Cc: Ramana Radhakrishnan
>> Subject: Re: [Patch, ARM/Th
On Tue, Jan 27, 2015 at 4:06 PM, Alex Velenko wrote:
>
> Hi,
>
> This patch fixes arm/atomic-op-consume.c test to expect safe "LDAEX"
> instruction to be generated when __ATOMIC_CONSUME semantics is requested.
>
> This patch was tested by running the modified test on arm-none-eabi and
> arm-none-l
On 29/01/15 11:40, Kyrill Tkachov wrote:
Hi all,
This is another cleanup patch that simplifies some expressions of the
form ( ? true : false) or if (boolean == true) and other minor
cleanups.
Tested arm-none-eabi.
Ok for trunk? Or should this wait for the next stage?
Thanks,
Kyrill
2015-01
Hi,
I decided to spend some time looking at the large number of guality
test failures on arm. I see a number of fails with
gcc.dg/guality/pr36728-1.c as below. pr36728-2.c also fails in similar
sort of ways. Before I go adjusting too many other tests I'd like to get
some feedback regarding t
>
> Changelog:
>
> * gcc.dg/guality/pr36728-1.c: Skip some tests for arm.
>
Segher and I discussed an alternative approach - marking these as "m"
(arg1) , "m" (arg2) etc in the asm blocks also gives us the same
effect and then probably removes the need to rely on such target
markers. I've ju
On 04/02/2015 11:10, Jakub Jelinek wrote:
On Wed, Feb 04, 2015 at 11:03:29AM +, Ramana Radhakrishnan wrote:
Changelog:
* gcc.dg/guality/pr36728-1.c: Skip some tests for arm.
Segher and I discussed an alternative approach - marking these as "m"
(arg1) , "m" (arg2)
On 04/02/2015 11:40, Jakub Jelinek wrote:
On Wed, Feb 04, 2015 at 11:33:19AM +, Ramana Radhakrishnan wrote:
--- a/gcc/testsuite/gcc.dg/guality/pr36728-1.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
@@ -49,5 +49,6 @@ main ()
int l = 0;
asm ("" : "=r" (l) : &
On Wed, Feb 4, 2015 at 12:57 PM, Marcus Shawcroft
wrote:
> On 4 February 2015 at 10:35, Matthew Wahab wrote:
>> Hello,
>>
>> The Cortex-A72 is an ARMv8 core with the same architectural features as the
>> Cortex-A57. This patch adds support for the command line option
>> -mcpu=cortex-a72 with the
On Wed, Feb 4, 2015 at 10:36 AM, Matthew Wahab wrote:
> Hello,
>
> The Cortex-A72 is an ARMv8 core with the same architectural features as the
> Cortex-A57. This patch adds support for the command line option
> -mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, with
> only the n
On Fri, Jan 23, 2015 at 8:23 AM, Thomas Preud'homme
wrote:
> Hi Ramana,
>
>> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
>> Sent: Wednesday, January 14, 2015 7:21 PM
>> On Wed, Jan 14, 2015 at 10:20 AM, Thomas Preud'homme
>> wrote:
On Tue, Jan 20, 2015 at 5:06 AM, Thomas Preud'homme
wrote:
> Currently on GCC 4.8 and 4.9, constant pool entries for QImode, HImode and
> SImode values are filled as 32-bit quantities. This works fine for little
> endian system but gives some incorrect results for big endian system when the
> v
On Fri, Jan 23, 2015 at 2:07 AM, Sandra Loosemore
wrote:
> The ARM run-time ABI says that long long division by zero should return the
> result of calling __aeabi_ldiv0 with an argument that is either zero if the
> numerator is zero, the largest value of the type if the numerator is
> positive, or
On Tue, Oct 28, 2014 at 11:46 AM, Matthew Fortune
wrote:
>> >> > Do you have an objection to allowing an option to disable these
>> >> instructions (despite the reason for wanting to do so)?
>> >>
>> >> Yes this seems like a bad workaround for broken code.
>> >>
>> > Well, we work around broken
On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
wrote:
> Hi,
>
> In PR61153, the vbic and vorn tests fail because when compiled at -O0
> the expected Neon instructions are not generated, making
> scan-assembler fail.
>
> This patch:
> - replaces -O0 by -O2
> - moves the declaration of local varia
On Wed, Oct 29, 2014 at 4:31 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This fixes an arm build failure due to removing the 'enum' keyword from
> machine_mode.
> Since libgcc2 is compiled with C rather than C++ we need it there for the
> definition of CUMULATIVE_ARGS.
>
> Another place where machine_
ss) for the target.
Sure, fixed thusly for ARM after verifying a build succeeds for
arm-none-linux-gnueabihf cross (after verifying that reverting
Kyrill's patch breaks the build) . Will have to deal with AArch64 in
the morning unless someone beats me to it.
Ramana
2014-10-29 Ramana Radhakr
On Wed, Oct 29, 2014 at 1:22 PM, Christophe Lyon
wrote:
> Hi,
>
> Following discussions after Thomas's patches improving bswap support
> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01279.html
>
> I noticed that:
> * the associated tests weren't executed on aarch64_be
> * ARM targets older than v
On Wed, Oct 22, 2014 at 10:49 PM, Michael Collison
wrote:
>
> Patch that removes extraneous comment attached.
>
> The CLZ_DEFINED_VALUE_AT_ZERO macro is hard coded to return 32. For the
> vector intrinsic vclz this is incorrect and should return the value
vclz_{s,u}8 ...
> eight. The CTZ_DEFINED
On Fri, Oct 24, 2014 at 12:57 PM, Alan Lawrence wrote:
> This migrates ARM from reduc_splus_optab and reduc_uplus optab to a single
> reduc_plus_optab.
>
> Tested, in combination with next patch:
> bootstrap on arm-none-linux-gnueabihf
> cross-tested check-gcc on arm-none-eabi.
>
Ok.
Ramana
> gc
On Tue, Oct 21, 2014 at 10:48 AM, Hale Wang wrote:
> Hi,
>
> This patch is used to tune the gcc for Cortex-M7.
>
> The performance of Dhrystone can be improved by 1%.
> The performance of Coremark can be improved by 2.3%.
>
> Patch also attached for convenience.
>
> Is it ok for trunk?
>
> Thanks
On Tue, Oct 21, 2014 at 10:18 AM, Terry Guo wrote:
> Hi There,
>
> This is the first patch to enable GCC generate UAL assembly code for Thumb1
> target. This new option enables user to specify which syntax is used in
> their inline assembly code. If the inline assembly code uses UAL format,
> the
On Tue, Oct 21, 2014 at 12:19 PM, Terry Guo wrote:
> Hi there,
>
> Attached patch intends to enable GCC generate UAL format code for Thumb1
> target. Tested with regression test and no regressions. Is it OK to trunk?
This is OK - Please don't commit it until we have sorted out patch
1/2 with the
>
> Could you please do a obvious fix? Thank you so much!
applied this as obvious.
Ramana
2014-11-04 Ramana Radhakrishnan
* config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Fix typo in definition
of __ARM_FEATURE_IDIV.
>
> Kind r
On Fri, Oct 24, 2014 at 1:01 PM, Alan Lawrence wrote:
> Similarly to last patch.
>
> Tested, in combination with previous patch:
> bootstrap on arm-none-linux-gnueabihf
> cross-tested check-gcc on arm-none-eabi.
>
> gcc/ChangeLog:
>
> config/arm/neon.md (reduc_smin_ *2): Rename to...
>
On Tue, Oct 21, 2014 at 11:01 AM, Hale Wang wrote:
> Hi,
>
> Some configurations of the Cortex-M0 and Cortex-M1 come with a high latency
> multiplier. This patch adds support for such configurations.
>
> Small multiplier means using add/sub/shift instructions to replace the mul
> instruction for t
On 05/11/14 07:09, Yangfei (Felix) wrote:
Hi,
This patch fixes PR63742 by improving arm *movhi_insn_arch4 pattern to
make it works under big-endian.
The idea is simple: Use movw for certain const source operand instead of
ldrh. And exclude the const values which cannot be handled
On Sun, Oct 26, 2014 at 4:50 PM, Christophe Lyon
wrote:
> On 24 October 2014 10:07, Marcus Shawcroft wrote:
>> On 21 October 2014 14:02, Christophe Lyon wrote:
>>> This patch series is an updated version of the series I sent here:
>>> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00022.html
>>>
e expected output in the PR. Looked
at output in a number of other benchmarks and saw it making sense.
Tested cross with aarch64-none-elf + a BSL patch with no regressions.
Bootstrapped and regression tested with aarch64-none-linux-gnu.
Ok for trunk once James's BSL patch is committed ?
R
On 07/11/14 13:36, Richard Henderson wrote:
On 11/07/2014 01:02 PM, Ramana Radhakrishnan wrote:
+ *cost = COSTS_N_INSNS (aarch64_internal_mov_immediate
+(gen_rtx_REG (mode, 0), x, false));
}
Can't you pass NULL for the register when gen
On 11/11/14 08:40, Terry Guo wrote:
Hi there,
Attached patch intends to fix below trunk failure caused by recent thumb-1
UAL patch:
/tmp/cc9EfnXy.s: Assembler messages:
/tmp/cc9EfnXy.s:69: Error: MOV Rd, Rs with two low registers is not
permitted on this architecture -- `mov r6,r7'
Now for p
On 12/11/14 13:06, Christophe Lyon wrote:
On 12 November 2014 04:50, Yangfei (Felix) wrote:
On Wed, Oct 22, 2014 at 10:49 PM, Michael Collison
wrote:
Patch that removes extraneous comment attached.
The CLZ_DEFINED_VALUE_AT_ZERO macro is hard coded to return 32. For
the vector intrinsic vc
On 07/11/14 13:36, Richard Henderson wrote:
On 11/07/2014 01:02 PM, Ramana Radhakrishnan wrote:
+ *cost = COSTS_N_INSNS (aarch64_internal_mov_immediate
+(gen_rtx_REG (mode, 0), x, false));
}
Can't you pass NULL for the register when gen
I'm happy to retest and resubmit if folks think this is a good idea.
regards
Ramana
2014-11-12 Ramana Radhakrishnan
* lib/wrapper.exp ${tool}_wrap_filename (): Define
* lib/g++.exp (g++_init): Use appropriate filename
for wrapper file.
* lib/gcc.exp (gcc_
27;s.
This is also in line with what we do in the AArch64 backend.
Will apply after a test run tonight on armhf.
regards
Ramana
* config/arm/sync.md (memory_barrier): Use dmb ish.
commit fca60730dee3281db4b688d9029ef08688507843
Author: Ramana Radhakrishnan
Date: Fri Sep 26 09:0
r kicks in.
Bootstrapped and regression tested on armhf.
Applied to trunk.
Ramana
2014-11-12 Ramana Radhakrishnan
* config/arm/arm.md (arith_shift_insn): Fix typo in operand
number.
Index: gcc/config/arm/arm.h
=
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.
elicit some comments
and for Ard to try this out 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_intern
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 (&
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 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 of
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 been
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
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 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 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 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 a
w-flash-data-3.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
>
&g
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 vectoriz
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
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 kn
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 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 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
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
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
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
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 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
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 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
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 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 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 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 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 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
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 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 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 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
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 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
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 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, Jun 27, 2016 at 11:09 AM, Matthew Wahab
wrote:
> Hello,
>
> Tests added for FP16 argument and return values being passed in
> registers only check the case when the FP16 IEEE format is used. This
> patch adds equivalent tests that also check the behaviour when the
> ARM Alternative format
On Thu, Jul 28, 2016 at 12:37 PM, Ramana Radhakrishnan
wrote:
> On Mon, Jul 4, 2016 at 3:02 PM, Matthew Wahab
> wrote:
>> On 19/05/16 15:54, Matthew Wahab wrote:
>>> On 18/05/16 16:20, Joseph Myers wrote:
>>>> On Wed, 18 May 2016, Matthew Wahab wrote:
>>&g
On Mon, Jul 4, 2016 at 3:15 PM, Matthew Wahab
wrote:
> On 17/05/16 15:46, Matthew Wahab wrote:
>> The ARMv8.2-A architecture introduces an optional FP16 extension adding
>> half-precision floating point data processing instructions to the
>> existing Adv.SIMD (NEON) support. A future version of th
On Mon, Jul 4, 2016 at 3:17 PM, Matthew Wahab
wrote:
> On 17/05/16 15:48, Matthew Wahab wrote:
>> Support for using the half-precision floating point operations added by
>> the ARMv8.2-A FP16 extension is based on the macros and intrinsics added
>> to the ACLE for the extension.
>>
>> This patch a
On Mon, Jul 4, 2016 at 3:18 PM, Matthew Wahab
wrote:
> On 18/05/16 11:58, Matthew Wahab wrote:
>> On 18/05/16 02:06, Joseph Myers wrote:
>>> On Tue, 17 May 2016, Matthew Wahab wrote:
>>>
In some tests, there are unavoidable differences in precision when
calculating the actual and the exp
On Mon, Jul 4, 2016 at 3:22 PM, Matthew Wahab
wrote:
> On 17/05/16 15:52, Matthew Wahab wrote:
>> Support for using the half-precision floating point operations added by
>> the
>> ARMv8.2-A FP16 extension is based on the macros and intrinsics added to
>> the
>> ACLE for the extension.
>>
>> This p
On 10/08/16 14:28, Thomas Preudhomme wrote:
> Hi,
>
> Mappings (MULTILIB_MATCHES and MULTILIB_REUSE) in ARM aprofile multilib
> suffer from a number of issues:
>
> * missing mapping of -mcpu=cortex-a7 to -march=armv7-a
You mean -march=armv7ve...
> * typo on vfpv3-d16-fp16 (MULTILIB_MATCHES u
On Fri, Aug 26, 2016 at 11:14 AM, Kyrill Tkachov
wrote:
> Hi all,
>
> The scheduling automata sizes are getting a bit out of control (as the PR
> complains about) and the Cortex-A8
> one is one of the largest offenders. An easy, low-hanging fruit in dealing
> with this are some of the FP/NEON oper
On 10/08/16 17:26, Wilco Dijkstra wrote:
> I noticed it would still be a good idea to add an extra barrier in the epilog
> as the
> scheduler doesn't appear to handle aliases of frame accesses properly.
>
> This patch simplifies the handling of the EH return value. We force the use
> of the
>
>
> diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> index fd999dd..0d23f39 100644
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -2182,8 +2182,10 @@ extern int making_const_table;
> #define TARGET_ARM_ARCH\
>(arm_base_arch) \
>
> -#define TARGET_ARM_V6M
On 09/03/16 12:56, Kyrill Tkachov wrote:
> Hi all,
>
> I notice that the output code for our store exclusive patterns accesses
> unallocated memory.
> It wants to output an strexd instruction with a pair of consecutive registers
> corresponding
> to a DImode value. For that it creates the SImo
On 27/05/16 14:46, Kyrill Tkachov wrote:
>
> On 20/05/16 11:04, Kyrill Tkachov wrote:
>> Hi all,
>>
>> The recent -frename-registers change exposed a deficiency in the way we fuse
>> AESE/AESMC instruction
>> pairs in arm.
>>
>> Basically we want to enforce:
>> AESE Vn, _
>> AESMC Vn, V
On 01/06/16 10:02, Ramana Radhakrishnan wrote:
>
>
> On 09/03/16 12:56, Kyrill Tkachov wrote:
>> Hi all,
>>
>> I notice that the output code for our store exclusive patterns accesses
>> unallocated memory.
>> It wants to output an strexd instruction w
On 01/06/16 11:18, Kyrill Tkachov wrote:
> Hi Ramana,
>
> On 01/06/16 10:07, Ramana Radhakrishnan wrote:
>>
>> On 01/06/16 10:02, Ramana Radhakrishnan wrote:
>>>
>>> On 09/03/16 12:56, Kyrill Tkachov wrote:
>>>> Hi all,
>>>>
>
501 - 600 of 1421 matches
Mail list logo
