> Where such a decision was discussed?
This was discussed back in the end of June. Mark Hambleton of ARM sent a
response to Cavium to that effect.
-Original Message-
From: Maxim Kuvyrkov [mailto:maxim.kuvyr...@linaro.org]
Sent: Wednesday, November 8, 2017 10:32 PM
To: Pinski, And
I thought the decision Linaro/Arm was going to take over the development of the
ILP32?
What happened to that decision?
Thanks,
Andrew
-Original Message-
From: Yao Qi [mailto:yao...@linaro.org]
Sent: Wednesday, November 8, 2017 9:50 AM
To: Pinski, Andrew
Cc: Maxim Kuvyrkov ; Linaro
[mailto:yao...@linaro.org]
Sent: Wednesday, November 8, 2017 1:16 AM
To: Pinski, Andrew
Cc: Maxim Kuvyrkov ; Linaro Toolchain
; Szabolcs Nagy ;
Ellcey, Steve
Subject: Re: ILP32 toolchain status update
On 7 November 2017 at 13:35, Pinski, Andrew wrote:
> Note gdb patches are located at:
>
Note gdb patches are located at:
https://sourceware.org/ml/binutils/2017-03/msg00075.html
https://sourceware.org/ml/gdb-patches/2017-03/msg00051.html
>2. [GLIBC] LP64 glibc libthread_db does not support ILP32.
No change to glibc was needed to fix this, only the above changes to gdb were
needed
Actually NTFS can be made to be case sensitive.
-Original Message-
From: linaro-toolchain [mailto:linaro-toolchain-boun...@lists.linaro.org] On
Behalf Of Jim Wilson
Sent: Thursday, April 7, 2016 5:26 PM
To: Gunnar Arndt
Cc: Linaro Toolchain Mailman List
Subject: Re: Linaro toolchain:
> Also, is it worthwhile putting a prfm before the ldaxr. EG
There is already a thread upstream about this:
https://gcc.gnu.org/ml/gcc-patches/2016-03/msg00508.html
I reject adding this to -mcpu=generic as it will hurt ThunderX more than it
will help. Prfm is single issue for ThunderX so it caus
aarch64_legitimate_address_hook_p is the place where the result of
aarch64_classify_address is returned to the middle-end. The middle-end then
knows that possibility for a+b is a legitimate address so it forces x3 << 3
into a register and tries aarch64_legitimate_address_hook_p again.
Thanks,
-Original Message-
From: linaro-toolchain [mailto:linaro-toolchain-boun...@lists.linaro.org] On
Behalf Of Prathamesh Kulkarni
Sent: Sunday, January 31, 2016 1:58 PM
To: Linaro Toolchain Mailman List
Subject: Re: [ACTIVITY] 25-29 Jan 2016
On 1 February 2016 at 03:27, Prathamesh Kulkarni
For a release like the Linaro binary release, having the debugging info
included is correct. For your use you can strip out the debugging info before
releasing it to your customers. For shared libraries you can strip out the
debug info to a separate file and release that separately. This is w
, January 4, 2016 5:33 AM
To: Pinski, Andrew ; Nicolas Pitre
Cc: Jim Wilson ; Linaro Toolchain Mailman List
Subject: Re: mixed LTO support for 'ld -r'
These are orthogonal requests, let's track them independently. Also, although
I noticed s390 work to add split-stack support, m
Note I rather see split stack support than ld -r LTO support done. I think
most enterprise folks would too.
Thanks,
Andrew
-Original Message-
From: linaro-toolchain [mailto:linaro-toolchain-boun...@lists.linaro.org] On
Behalf Of Nicolas Pitre
Sent: Wednesday, December 23, 2015 9:41 AM
Why not runtime instead of compile time?
From: Bill Fischofer [mailto:bill.fischo...@linaro.org]
Sent: Tuesday, November 17, 2015 2:14 PM
To: Pinski, Andrew
Cc: Linaro Toolchain Mailman List ; Barry
Spinney
Subject: Re: Configuration question
Thanks, however we were hoping that this is
Sounds like HWCAP should be checked at runtime for these features and then have
a fallback to software one.
This might mean using function pointers and initializing the correct ones. Or
better yet use ifunc directly to check on them.
Thanks,
Andrew
From: linaro-toolchain [mailto:linaro-toolcha
> On Nov 10, 2015, at 7:28 AM, Zoltan Kiss wrote:
>
>
>
>> On 10/11/15 15:08, Grant Likely wrote:
>>> On Tue, Nov 10, 2015 at 3:04 PM, Zoltan Kiss wrote:
>>>
>>>
On 10/11/15 12:04, Grant Likely wrote:
On Tue, Nov 10, 2015 at 11:08 AM, Maxim Uvarov
wrote:
>
>>
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
FYI. This is a parity feature with both PowerPC64 and x86_64. Needed to
support GCCgo. Note full gold support is needed too.
-- Forwarded message --
From: pinskia at gcc dot gnu.org
Date: Tue, Oct 6, 2015 at 3:30 PM
Subject: [Bug target/67877] New: Split stack needs to be supp
> On Oct 2, 2015, at 8:38 AM, Christophe Lyon
> wrote:
>
> == Progress ==
> 2 days off (4/10)
>
> * Infrastructure/validation: (3/10)
> further checking of cross-testing results stability on aarch64-linux
> - found a workaround for a timestamp problem (_Pragma3 testcase)
contrib/gcc_update
usage.
Thanks,
Andrew Pinski
From: Virendra Kumar Pathak
Sent: Wednesday, June 10, 2015 12:06 AM
To: Pinski, Andrew
Cc: Linaro Toolchain Mailman List
Subject: Re: mfpu=neon and -march=native on aarch64-linux-gnu toolchain
Hi Andrew,
Thanks for the information.
So do
-march=native was not included in GCC 5.1 that Linaro provided. I don't know
if Linaro has plans to backport the support it but it is already there for GCC
6.
You don't need -mfpu=neon for AARCH64 at all. AARCH64 defaults to having simd
turned on.
Thanks,
Andrew Pinski
___
om: linaro-toolchain on behalf of
Pinski, Andrew
Sent: Friday, June 5, 2015 3:05 AM
To: Maxim Kuvyrkov; Jim Wilson
Cc: Nicolas Pitre; Linaro Toolchain Mailman List
Subject: RE: new gas feature: section name substitution sequence
I am just going to say, I don't like this extension at all. It al
I am just going to say, I don't like this extension at all. It allows for
abuse than it is good.
Thanks,
Andrew Pinski
-Original Message-
From: linaro-toolchain [mailto:linaro-toolchain-boun...@lists.linaro.org] On
Behalf Of Maxim Kuvyrkov
Sent: Friday, June 5, 2015 5:58 PM
To: Jim Wil
It would be best to file a bug in glibc then and fix it there.
From: Kugan
Sent: Sunday, May 10, 2015 10:46 PM
To: Pinski, Andrew; Linaro Toolchain
Subject: Re: [ACTIVITY] 04 May -- 08 May
On 11/05/15 15:24, Pinski, Andrew wrote:
>> - Trunk is brok
> - Trunk is broken and narrowed down the failure to
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66066
No the code is broken in SPEC ;). SPEC INT has been known to be broken C and
they are not willing to do anything about it after the fact. This has been
true for all versions of SPEC and on
It does but not in GCC 4.9. It was added for GCC 5.
Thanks,
Andrew Pinski
From: linaro-toolchain-boun...@lists.linaro.org
on behalf of Edward Nevill
Sent: Thursday, March 5, 2015 1:19 AM
To: linaro-toolchain@lists.linaro.org
Subject: Does gcc know abo
Really the vendor here should be Linaro.
Thanks,
Andrew Pinski
-Original Message-
From: linaro-toolchain-boun...@lists.linaro.org
[mailto:linaro-toolchain-boun...@lists.linaro.org] On Behalf Of Christopher
Covington
Sent: Wednesday, February 25, 2015 11:52 AM
To: linaro-toolchain@lists.
Why don't you just have Boost.Context be a wrapper around
getcontext/setcontext/swapcontext and ignore the save_fp argument? Then you
don't need to write anything special for AARCH64 or any new target?
Thanks,
Andrew
-Original Message-
From: linaro-toolchain-boun...@lists.linaro.org
[
Why not use perf instead of gprof?
Perf works on ARM64 and I think on Juno already. It also easier to use gprof
as you don't need to recompile.
Thanks,
Andrew
-Original Message-
From: linaro-toolchain-boun...@lists.linaro.org
[mailto:linaro-toolchain-boun...@lists.linaro.org] On Behalf
: Monday, November 24, 2014 2:31 PM
To: lng-...@lists.linaro.org; Pinski, Andrew
Subject: strange behavior in GCC for use of uninitialized variables
Consider the following code fragment (from real life):
#include
typedef volatile uint32_t odp_atomic_u32_t;
static inline uint32_t
Try fpmarks.
> On Oct 27, 2014, at 8:48 AM, Bernie Ogden wrote:
>
> cbuild2 benchmarking - TCWG-360 [2/10]
> * Figured out how to cook my own OE images
> * Started remembering how to build spec
>
> libm exercising - CARD-1693 [2/10]
> * Borrowed a usable Juno
> * Found that lapack tests segf
A couple of notes.
About " vector Extensions Project"
Have you looked into
https://sourceware.org/ml/libc-alpha/2014-09/msg00176.html and all of the
follow ups?
Including https://sourceware.org/glibc/wiki/libm#Vector_Entry_Points ?
Also dealing with " GCC Modularization Project" I think this is
I think this is not scalarable.
Why not use a switch instead of multiple ifs. Something like this (copied from
our internal build scripts):
# Convert the target triplet into a linux target.
case ${target} in
arm*) linux_target=arm ;;
powerpc*) linux_target=powerpc ;;
i[34567]86-* | x
You should also look into https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
which looks exactly the same issue as your LTO issue you are seeing. There is
some debugging notes there too.
Thanks,
Andrew
-Original Message-
From: linaro-toolchain-boun...@lists.linaro.org
[mailto:linaro-t
See below.
-Original Message-
From: Kugan [mailto:kugan.vivekanandara...@linaro.org]
Sent: Monday, August 4, 2014 12:50 AM
To: Pinski, Andrew; Linaro Toolchain
Subject: Re: [ACTIVITY] 28 July - 1 August 2014
>
>
See below.
Thanks,
Andrew
-Original Message-
From: linaro-toolchain-boun...@lists.linaro.org
[mailto:linaro-toolchain-boun...@lists.linaro.org] On Behalf Of Kugan
Sent: Monday, August 4, 2014 12:19 AM
To: Linaro Toolchain
Subject: [ACTIVITY] 28 July - 1 August 2014
== Progress ==
- Tr
On Jul 25, 2014, at 11:22 PM, "Panshilin (Peter)"
mailto:peter.panshi...@hisilicon.com>> wrote:
Hi all concerned:
this test code I given below: AARCH32
[https://email-cn04.huawei.com/owa/14.3.158.1/themes/base/pgrs-sm.gif]
Test function[cid:(null)][cid:(null)]
{
volatile unsigned int val
> Testing on a target that support PTR_EXTEND
AARCH64 ILP32 is also a target which does PTR_EXTEND.
Thanks,
Andrew Pinski
-Original Message-
From: linaro-toolchain-boun...@lists.linaro.org
[mailto:linaro-toolchain-boun...@lists.linaro.org] On Behalf Of Kugan
Sent: Sunday, June 29, 2014
Note this patch can cause wrong code in some cases due to the load pair
converting:
ldr x0, [x0]
ldr x1, [x0, 8]
into
ldp x0, x1, [x0].
I have a fixed up patch which combines what Naveen did and enhances it some
more to handle reg-size,reg.
I can provide a version if you want to start with my ve
y I was optimizing it.
Thanks,
Andrew Pinski
From: Zhenqiang Chen
Sent: Sunday, June 15, 2014 8:29 PM
To: Pinski, Andrew
Cc: linaro-toolchain
Subject: Re: [ACTIVITY] Week 24
On 16 June 2014 10:38, Pinski, Andrew wrote:
>> * Investigate how to optimize large constant. Patch is in te
> * Investigate how to optimize large constant. Patch is in testing (TCWG-486,
> 5/10). Basic idea is:
> - Do not split large constant when expanding.
> - Improve cprop pass to check the rtx_cost when propagating constants.
I did this basic idea for MIPS64 and also caused cse to ignore the cost
You need to use gcc-ar wrappers when creating the archive in the first place.
Thanks,
Andrew
> On May 26, 2014, at 3:19 AM, "Bernhard Rosenkränzer"
> wrote:
>
> Hi,
> I've run into some compile errors after updating to 4.9 -- usually getting
> undefined references to symbols defined in helpe
I have a fix I think. I found this while working on ilp32 too.
Thanks,
Andrew
> On Apr 1, 2014, at 8:20 PM, "Michael Hudson-Doyle"
> wrote:
>
> Hi all,
>
> I've just filed a bug on glibc I'd love you to take a look at:
> https://sourceware.org/bugzilla/show_bug.cgi?id=16796
>
> Here's the d
Huh? Long long is 64bit using the linaro toolchains. Are you using just %ld
rather than %lld ?
Anyways this sounds like a bug which should be reported rather than worked
around if it is truely a bug in the toolchain rather than your code.
Thanks,
Andrew
__
You just want not to use " --enable-multiarch​".
Thanks,
Andrew Pinski
From: linaro-toolchain-boun...@lists.linaro.org
on behalf of Diane Holt
Sent: Wednesday, March 05, 2014 2:33 PM
To: Zhenqiang Chen
Cc: Linaro Toolchain
Subject: Re: Building 4.8 without m
> On Dec 22, 2013, at 5:17 PM, "Zhenqiang Chen"
> wrote:
>
> == Issues ==
>
> * None.
>
> == Progress ==
>
> * Rebase aarch64 build scripts to crosstool-ng upstream, test and send
> out the patch for community review (2/10).
>
> * Investigate
> https://ci.linaro.org/jenkins/job/openembedd
>- Discovered a bug in glibc when using upstream (4.9) gcc that isn't present
>in 4.8.
This is due to a bug in both glibc and gcc. See
https://sourceware.org/ml/libc-alpha/2013-11/msg00291.html for some information
about the glibc side of things.
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg
This is the same patch which we (Cavium) uses internally if that matters.
Thanks,
Andrew
Sent from my iPad
> On Oct 1, 2013, at 6:52 PM, "Michael Hudson-Doyle"
> wrote:
>
> ---
> Hi,
>
> Can you review this patch for me and help me get it upstream?
>
> This is an official request for help f
I think a better way of doing some of these functions is using ifunc with a
vdso. So the glibc does not have to be updated; only the kernel.
Thanks,
Andrew
Sent from my iPad
On Aug 26, 2013, at 8:17 PM, "Michael Hudson-Doyle"
wrote:
> Hi all,
>
> There has been interest from LEG members to
This will work, except it will be -4 and w1 for ILP32.
Thanks,
Andrew Pinski
From: Venkataramanan Kumar
Sent: Sunday, August 18, 2013 10:09 PM
To: Pinski, Andrew
Cc: Linaro Toolchain
Subject: Re: [ACTIVITY] 12 - 16 August 2013
Hi Andrew,
I am not changing the
I think changing TCB will be changing the ABI. So we don't want to do that I
think.
Also have you thought about how TCB changes are going to change ILP32 too. I
am almost ready to submit the patches for ILP32 out for review on the binutils,
glibc, gcc, and kernel lists.
Thanks,
Andrew
_
Yes don't compile with -fPIC or compile with -ftls-model=local-exec .
Thanks,
Andrew Pinski
From: linaro-toolchain-boun...@lists.linaro.org
on behalf of Vitali Sokhin
Sent: Sunday, July 14, 2013 12:21 AM
To: linaro-toolchain@lists.linaro.org
Subject: How to mak
More about 1) Even if you are able to expand to cond_exec during expand, the
rest of GCC including reload does not know how to handle it except for the
passes after reload. See http://gcc.gnu.org/ml/gcc/2010-09/msg00252.html . So
using if_then_else is much better for before reload as mentione
To: Pinski, Andrew
Cc: linaro-toolchain
Subject: Re: [ACTIVITY] Week 12
On 25 March 2013 12:05, Pinski, Andrew wrote:
>>* Investigate how to expand conditional compare GIMPLE to RTL and emit asm.
>
> I think maybe we should start adding target specific expanders. Then all you
>
>* Investigate how to expand conditional compare GIMPLE to RTL and emit asm.
I think maybe we should start adding target specific expanders. Then all you
need to do is take that expander and when you get a COND_EXPR and then looks at
TRE provided information which then can exapnd the conditiona
Actually SPEC 2006 is broken if you read the blog post correctly and GCC 4.8
just exposes it.
Thanks,
Andrew
From: linaro-toolchain-boun...@lists.linaro.org
[linaro-toolchain-boun...@lists.linaro.org] on behalf of Mans Rullgard
[mans.rullg...@linaro.org
Seems like most of the python scripts are duplicated of the
contrib/test_summary and contrib/compare_tests scripts in the GCC repo (both
understand gdb dejagnu .sum already).
Why didn't you use those instead of creating your own?
Thanks,
Andrew Pinski
From: lin
>* Start analysis on jump threading in GCC.
What kind of analysis are you going to do? I have some helpful hints dealing
with the jump threading in VRP. Really DOM should be removed fully as most if
not all the other optimizers already do its job. Also you should do this
analysis on the GCC
56 matches
Mail list logo
