On 24/09/2024 22:20, Maxim Kuvyrkov wrote:
On Sep 25, 2024, at 05:13, Richard Earnshaw (lists)
wrote:
On 21/09/2024 08:49, ci_not...@linaro.org wrote:
Dear contributor, our automatic CI has detected problems related to your
patch(es). Please find some details below. If you have any
track this report status in https://linaro.atlassian.net/browse/GNU-1349 ,
please let us know if you are looking at the problem and/or when you have a fix.
In arm-eabi cortex-m23 soft after:
| commit gcc-15-3607-g9a94c8ffdc8b
| Author: Richard Earnshaw
| Date: Thu Sep 12 14:24:55
s://linaro.atlassian.net/browse/GNU-1149
<https://linaro.atlassian.net/browse/GNU-1149> , please let us know if
you are looking at the problem and/or when you have a fix.
In arm-eabi cortex-m33 hard after:
| commit gcc-14-8887-gd9459129ea8
| Author: Richard Earnshaw
On 02/10/2023 18:12, Wilco Dijkstra wrote:
Hi Ramana,
I used --target=arm-none-linux-gnueabihf --host=arm-none-linux-gnueabihf
--build=arm-none-linux-gnueabihf --with-float=hard. However it seems that the
default armhf settings are incorrect. I shouldn't need the --with-float=hard
since
tha
On 22/07/16 05:21, Jeffrey Walton wrote:
> On Fri, Jul 22, 2016 at 12:19 AM, Jim Wilson wrote:
>> On Thu, Jul 21, 2016 at 9:13 PM, Jeffrey Walton wrote:
>>> So I guess the question is, what do I use for -mfpu=neon-vfp3 (or
>>> -mfpu=neon-vfp3-d32)? Is -mfpu=neon enough?
>>
>> The -mfpu=neon optio
On 20/07/16 22:33, Jim Wilson wrote:
> On Wed, Jul 20, 2016 at 2:14 PM, Jeffrey Walton wrote:
>> I'm having trouble with ARMv8/Aarch64. One is an early Mustang server
>
> ARMv8 implies 32-bit code (aarch32). Aaarch64 implies 64-bit code.
> These are two different compilers, with two different set
On 03/03/16 00:44, kugan wrote:
>
>
>>> I have just switched to gcc 5.2 from 4.9.2 and the code quality does
>>> seem to have improved significantly. For example, it now seems much
>>> better at using ldp/stp and it seems to has stopped gratuitous use of
>>> the SIMD registers.
>>>
>>> However, I s
On 02/03/16 11:35, Edward Nevill wrote:
> Hi,
>
> I have just switched to gcc 5.2 from 4.9.2 and the code quality does seem to
> have improved significantly. For example, it now seems much better at using
> ldp/stp and it seems to has stopped gratuitous use of the SIMD registers.
>
> However, I s
On 02/03/16 14:25, Renato Golin wrote:
> On 2 March 2016 at 11:35, Edward Nevill wrote:
>> cmp x2, 8 <<< (1)
>> (1) If count as a 64 bit unsigned is <= 8 then it is probably still <= 8 as
>> a 32 bit unsigned.
>
> You mean to use "cmp w2, 8" instead? Is there any difference?
On 27/01/16 16:57, Jim Wilson wrote:
> On Wed, Jan 27, 2016 at 8:37 AM, Christophe Lyon
> wrote:
>> I confirm the trampolines are not inserted for ld -r.
>
> We can't insert the trampolines with ld -r. We don't have all of the
> symbols required for this with a relocatable link. Also, for the
>
On 27/01/16 14:52, William Mills wrote:
>
>
> On 01/27/2016 08:35 AM, Richard Earnshaw wrote:
>> On 26/01/16 17:25, Christophe Lyon wrote:
>>> On 26 January 2016 at 18:23, Dan Murphy wrote:
>>>> Christophe
>>>>
>>>>
>>>>
On 26/01/16 17:25, Christophe Lyon wrote:
> On 26 January 2016 at 18:23, Dan Murphy wrote:
>> Christophe
>>
>>
>> On 01/26/2016 10:58 AM, Christophe Lyon wrote:
>>>
>>> On 25 January 2016 at 17:21, Dan Murphy wrote:
Hi!
When using the linaro-4.9-2015.05 toolchain on the Linux
On 13/06/14 09:52, Matthias Klose wrote:
> Am 13.06.2014 10:10, schrieb Yvan Roux:
>> Linaro GCC 4.9 2014.06 is the third Linaro GCC source package release in the
>> 4.9 series. It is based on FSF GCC 4.9.1+svn211054 and includes performance
>> improvements and bug fixes.
>
> This sounds like 4.9
On 15/05/14 00:22, Kugan wrote:
Hi All,
AAarch64 back-end defines GENERAL_REGS and CORE_REGS with the same set
of register. Is there any reason why we need this?
target hooks like aarch64_register_move_cost doesn’t handle CORE_REGS.
In addition, IRA cost calculation also has logics like make co
On 18/02/14 12:59, Renato Golin wrote:
> Richard,
>
> I found some emails about you implementing softvfp back in 2003, and
> I'd like to know what is the expected behaviour when it conflicts with
> the target triple, for example:
>
> -triple arm-linux-gnueabihf + -mfpu=sofvfp+vfp
>
> In this ca
On 18/12/13 05:06, Jonathan S. Shapiro wrote:
> At the risk of sticking my nose in, this isn't a startup code issue.
> It's a contract issue.
>
> First, I don't buy Richard's argument about memcpy() startup costs and
> hard-to-predict branches. We do those tests on essentially every
> *other* RISC
On 16/12/13 17:54, Christopher Covington wrote:
> Hi,
>
> On 11/20/2013 03:45 PM, Matthew Gretton-Dann wrote:
>> On 20 November 2013 17:57, Christopher Covington wrote:
>>> Hi,
>>>
>>> We've noticed an issue trying to use the Linaro AArch64 binary bare metal
>>> toolchain release with the MMU tur
On 03/07/13 17:41, Renato Golin wrote:
On 3 July 2013 17:22, Mans Rullgard mailto:mans.rullg...@linaro.org>> wrote:
I repeat, the 4460 will run at 1.2GHz indefinitely without thermal
management.
My mistake, I said 1.3GHz when it was actually 1.2GHz. So, at 1.2GHz, it
freezes every few
On 25/03/13 06:00, Pinski, Andrew wrote:
Yes I know what you want to do but I think this is better to without adding a
new tree code.
You want to expand the following:
a = x < y
c = z ? a : b
Where a is only used in the assignment of a.
I think this is better to add target specific hook for do
lue.v1), "r" (value.v2)
);
} while (status);
do you think that it is the right way to do it ?
Sadly, no. Only the STXP instruction is single-copy atomic. To get
atomicity on a read you need to repeat the sequence
LDXPXn, Xm, [addr]
STXPWs
On 21/02/13 15:54, Yvan Roux wrote:
Hi,
in the example below I want to explicitly generate a "store exclusive
pair" instruction with an asm statement:
typedef struct {
long unsigned int v1;
long unsigned int v2;
} mtype;
int main () {
mtype val[2] ;
val[0].v1 = 1234;
val[0]
On 13/02/13 02:08, Wink Saville wrote:
Thanks, I install ia32-lib and now it works, but what a poor error
message. To bad i would at least tell you what file wasn't found.
I agree, but that's a feature of the OS, rather than the program you
were trying to run. The programs you installed neve
On 11/12/12 19:39, Matthew Gretton-Dann wrote:
On 10 December 2012 14:53, Zhangfei Gao wrote:
We met build error when using arm-linux-gnueabihf-gcc 3.7.3 for Huawei
s40v200 kernel, which is 3.0.8, log is below.
HAVE issue:
gcc-linaro-arm-linux-gnueabihf-4.7-2012.11-20121123_linux.tar.bz2
gcc-l
On 03/08/12 13:49, Mans Rullgard wrote:
> I have noticed gcc has a preference for generating UXTB instructions
> when an AND with #255 would do the same thing. This is bad, because
> on A9 UXTB has two cycles latency compared to one cycle for AND. On
> A8 both instructions have one cycle latency.
On 02/08/12 18:39, Mans Rullgard wrote:
> Nevertheless, the tags in the .ARM.attributes section are the standard,
> published way to identify FP ABI as well as a number of other properties
> that might be relevant to a linker.
1) The attributes only visible in the section view (as used by linkable
On 25/07/12 05:16, Michael Hope wrote:
> FYI GCC trunk r189808 fails to build with a bootstrap comparison error:
>
> Comparing stages 2 and 3
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1objplus-checksum.
On 02/05/12 13:25, Mans Rullgard wrote:
> On 2 May 2012 05:15, Michael Hope wrote:
>> On 27 April 2012 11:59, Michael Hope wrote:
>>> On 23 April 2012 14:23, Jon Masters wrote:
On 04/22/2012 06:06 PM, Michael Hope wrote:
> On 21 April 2012 09:10, Jon Masters wrote:
>> Hey everyone,
On 18/04/12 18:36, Ulrich Weigand wrote:
>
> Hello,
>
> I've been following up on the discussion we had on Monday regarding stack
> alignment, and noticed that I had mis-remembered the current state of
> affairs. Ramana asked me on Tuesday to provide a write-up of the actual
> status, so here we
On 13/04/12 12:05, Richard Earnshaw wrote:
> On 13/04/12 11:58, Mans Rullgard wrote:
>> On 13 April 2012 11:47, Richard Earnshaw wrote:
>>> On 12/04/12 20:10, Allen Martin wrote:
>>>> I have a cross toolchain I configured with "--with-arch=armv7-a
>>>
interworking veneer\n"));
> - fprintf (file, _(" --use-blx Enable use of BLX
> instructions\n"));
> + fprintf (file, _(" --[no-]use-blx Disable/enable use of BLX
> instructions\n"));
>fprintf (file, _(" --vfp11-denorm-fix
On 13/04/12 11:58, Mans Rullgard wrote:
> On 13 April 2012 11:47, Richard Earnshaw wrote:
>> On 12/04/12 20:10, Allen Martin wrote:
>>> I have a cross toolchain I configured with "--with-arch=armv7-a
>>> --with-cpu=cortex-a9 --with-tune=cortex-a9" and
x27;ll need to ensure that
*all* your libraries are built to support back-conversion to v4,
including those that are normally built as part of the toolchain
(libgcc, etc).
R.
--
Richard Earnshaw Email: richard.earns...@arm.com
Engineering Manager Phone: +44 1223 400
On 12/04/12 19:29, Dennis Gilmore wrote:
>
> off topic but i find aarch64 weird and too generic is it arm alpha amd
> atom.
>
That's only 'cos it's new. It's no different from names like ia64.
R.
___
linaro-toolchain mailing list
linaro-toolchain
Number is back up, but no host...
On 5 Mar 2012, at 09:38, "Richard Earnshaw" wrote:
> Call went silent on me. Redialing is giving number unobtainable :-(
>
>
>
> On 4 Mar 2012, at 22:35, "Michael Hope" wrote:
>
>> On Mon, Mar 5, 2012 at
Call went silent on me. Redialing is giving number unobtainable :-(
On 4 Mar 2012, at 22:35, "Michael Hope" wrote:
> On Mon, Mar 5, 2012 at 11:31 AM, Peter Maydell
> wrote:
>> On 4 March 2012 22:21, Michael Hope wrote:
>>> The new conference call numbers have arrived. Let's use them f
On 23/02/12 10:27, Aneesh V wrote:
> Ok. Agree. I never used to use %function when I wrote assembly
> functions earlier. I am sure a lot of code will break if this was
> enforced.
If you've not used %function on ARM, then your code is semantically
broken even if it isn't syntactically broken.
The
s if you start doing operations directly when
it comes to dealing with big-endian as there is a degree of divergence
between GCC's own interpretation of vectors and the intrinsic view;
mixing and matching can lead to subtle problems with lane numbering.
--
Richard Earnshaw Em
On 10 Nov 2011, at 23:47, "Loïc Minier" wrote:
> On Thu, Nov 10, 2011, Richard Earnshaw wrote:
>> You can't rely on finding it. Executable images are only required to
>> have segment headers an d the attributes system uses section headers.
>> Section heade
; wrote:
On Thu, Nov 10, 2011, Richard Earnshaw wrote:
The build attributes were never intended to be used in executables; the
format is too expensive to decode in most situations. Instead the ABI
specification included an optional PHEADER that had a highly simplified
indication of the executabl
intended to be used in executables; the
format is too expensive to decode in most situations. Instead the ABI
specification included an optional PHEADER that had a highly simplified
indication of the executable compatibility of an image (essentially the
architecture). Unfortunately this has never
On 16/09/11 15:12, Ulrich Weigand wrote:
> Richard Sandiford wrote:
>> David Gilbert writes:
>>> My current patch:
>>> * adds armv6 and armv7 to config.sub
>>> * adds arm/eabi/armv7 and arm/eabi/armv6t2 and one assembler
>>> routine in there.
>>> * If $machine is just 'arm' then it autode
On Fri, 2011-03-04 at 15:33 +0200, Revital1 Eres wrote:
> Hello,
>
> I am looking for a way to disable '-gtoggle' flag in the run of stage 2 in
> bootstrap; when
> configuring ARM with (*).
> The flag seems to be applied in stage 2 but not in stage 3 which seems to
> cause bootstrap failure when
On Thu, 2010-12-09 at 13:31 +1300, Michael Hope wrote:
> On Wed, Dec 8, 2010 at 7:10 PM, Michael Hope wrote:
> -fno-common also gives a small improvement in various benchmarks, but
> may break some programs.
Any breakage with -fno-common would be detected at link time, so if your
program compile
On Fri, 2010-12-03 at 10:49 +1300, Michael Hope wrote:
> Hi there. Currently you can't use NEON instructions in inline
> assembly if the compiler is set to -mfpu=vfp such as Ubuntu's
> -mfpu=vfpv3-d16. Trying code like this:
>
> int main()
> {
>asm("veor d1, d2, d3");
>return 0;
> }
>
>
On Wed, 2010-11-03 at 17:39 +0800, Yao Qi wrote:
> Hi,
> I am backporint some patches from FSF mainline, which may improve Linaro
> 4.5 gcc on thumb2 speed.
>
> The first one is done by Richard E. "Improve optimization to transform
> TST into LSLS"
> http://gcc.gnu.org/ml/gcc-patches/2010-06/ms
On Wed, 2010-09-22 at 08:36 -0700, Mark Mitchell wrote:
> On 9/22/2010 8:34 AM, Loïc Minier wrote:
>
> > Which component is to blame here? Are we looking at a binutils or a
> > gcc bug for not being able to set or read enough data that the
> > architecture mismatch isn't detected? What could
On Mon, 2010-09-20 at 09:14 +0100, Dave Martin wrote:
> On Fri, Sep 17, 2010 at 11:31 PM, Loïc Minier wrote:
> > On Wed, Sep 15, 2010, Michael Hope wrote:
> >> GLIBC a mechanism for picking the best routines to use based on the
> >> CPU capabilities. This means that GLIBC can include A8 and A9
>
On Fri, 2010-09-17 at 18:21 +0800, Yao Qi wrote:
> Michael Hope wrote:
> > It's only part of the puzzle, but I run speed benchmarks as part of
> > the continious build:
> > http://ex.seabright.co.nz/helpers/buildlog
> > http://ex.seabright.co.nz/helpers/benchcompare
> >
> > http://ex.seabright
t this could be:
>
> pop {r3, r4, r5, r6, r7, pc}
>
> >0x1c56 <+58>: nop
> >0x1c58 <+60>: andeq r0, r0, r0
> >0x1c5c <+64>: andeq r0, r0, r0
> > }}}
> > Register r8 is
On Tue, 2010-09-07 at 13:09 +0100, Andrew Stubbs wrote:
> On 07/09/10 13:01, Yao Qi wrote:
> >> * Investigate reduced alignment constraints?
> >
> > Any details on this?
>
> No, I just know that some targets like to align functions to
> cache-lines. This is a useful speed optimization, but does
50 matches
Mail list logo
