RE: ILP32 toolchain status update

> 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

RE: ILP32 toolchain status update

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 <andrew.pin...@cavium.com&

RE: ILP32 toolchain status update

[mailto:yao...@linaro.org] Sent: Wednesday, November 8, 2017 1:16 AM To: Pinski, Andrew <andrew.pin...@cavium.com> Cc: Maxim Kuvyrkov <maxim.kuvyr...@linaro.org>; Linaro Toolchain <linaro-toolchain@lists.linaro.org>; Szabolcs Nagy <szabolcs.n...@arm.com>; Ellcey, Steve <steve

RE: Linaro toolchain: libstdc++.so: file format not recognized; treating as linker script

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

RE: Some questions about the gcc __sync intrinsics

> 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

RE: ldr instruction selection in the aarch64 backend

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.

RE: [ACTIVITY] 25-29 Jan 2016

-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

RE: debug information in libc.a

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

RE: mixed LTO support for 'ld -r'

, January 4, 2016 5:33 AM To: Pinski, Andrew <andrew.pin...@caviumnetworks.com>; Nicolas Pitre <nicolas.pi...@linaro.org> Cc: Jim Wilson <jim.wil...@linaro.org>; Linaro Toolchain Mailman List <linaro-toolchain@lists.linaro.org> Subject: Re: mixed LTO support for 'ld -

RE: mixed LTO support for 'ld -r'

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

RE: Configuration question

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 <andrew.pin...@caviumnetworks.com> Cc: Linaro Toolchain Mailman List <linaro-toolchain@lists.linaro.org>; Barry Spinney <spi

RE: Configuration question

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

Re: [lng-odp] Runtime inlining

> 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

Fw: [Bug target/67877] New: Split stack needs to be support for AARCH64

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:

ILP32 is a parity feature to x86_64 (x32)

___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org https://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: [ACTIVITY] 28 September-2 October 2015

> 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

Re: [ACTIVITY] 04 May -- 08 May

It would be best to file a bug in glibc then and fix it there. From: Kugan kugan.vivekanandara...@linaro.org 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

Re: [ACTIVITY] 04 May -- 08 May

- 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 one

Re: Does gcc know about ldp

It does but not in GCC 4.9. It was added for GCC 5. Thanks, Andrew Pinski From: linaro-toolchain-boun...@lists.linaro.org linaro-toolchain-boun...@lists.linaro.org on behalf of Edward Nevill edward.nev...@linaro.org Sent: Thursday, March 5, 2015 1:19

RE: Debian Multiarch Tuple Style Naming With ABE

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:

RE: Problems porting Boost.Context to aarch64 gcc

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

RE: [ACTIVITY] 8th - 12th December

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

Fw: strange behavior in GCC for use of uninitialized variables

ola.liljed...@linaro.org Sent: 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 stdint.h typedef volatile uint32_t odp_atomic_u32_t; static

Re: [ACTIVITY] 20th - 24th October

Try fpmarks. On Oct 27, 2014, at 8:48 AM, Bernie Ogden bernie.og...@linaro.org 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

RE: [Weekly] 20-24 OCT 2014

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 a

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 == -

RE: [ACTIVITY] 28 July - 1 August 2014

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

Re: help, here is a armV8 32bit question for linaro 4.8: the code I given below adopt sembedding ARMV8 assembly , but the compile result with Linaro GCC 4.8 aarch32 is not correct

On Jul 25, 2014, at 11:22 PM, Panshilin (Peter) peter.panshi...@hisilicon.commailto: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)] {

RE: [Weekly] 23-27 JUNE 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

RE: [ACTIVITY] 23 - 27 June 2014

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

RE: [ACTIVITY] Week 24

* 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 of

RE: [ACTIVITY] Week 24

From: Zhenqiang Chen zhenqiang.c...@linaro.org 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 andrew.pin...@caviumnetworks.com wrote: * Investigate how to optimize large constant. Patch

Re: ld can't deal with LTO bytecode in static libraries

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 bernhard.rosenkran...@linaro.org wrote: Hi, I've run into some compile errors after updating to 4.9 -- usually getting undefined references to

Re: pthread_self() alignment when heap grows up

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 michael.hud...@canonical.com wrote: Hi all, I've just filed a bug on glibc I'd love you to take a look at:

RE: detecting the linaro toolchain via C/C++ preprocessor

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

RE: Building 4.8 without multilib

You just want not to use --enable-multiarch​. Thanks, Andrew Pinski From: linaro-toolchain-boun...@lists.linaro.org linaro-toolchain-boun...@lists.linaro.org on behalf of Diane Holt holt.di...@gmail.com Sent: Wednesday, March 05, 2014 2:33 PM To: Zhenqiang

Re: [ACTIVITY] Week 51

On Dec 22, 2013, at 5:17 PM, Zhenqiang Chen zhenqiang.c...@linaro.org wrote: == Issues == * None. == Progress == * Rebase aarch64 build scripts to crosstool-ng upstream, test and send out the patch for community review (2/10). * Investigate

RE: [ACTIVITY] Week 49

- 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.

RE: [ACTIVITY] 12 - 16 August 2013

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

RE: [ACTIVITY] 12 - 16 August 2013

This will work, except it will be -4 and w1 for ILP32. Thanks, Andrew Pinski From: Venkataramanan Kumar venkataramanan.ku...@linaro.org Sent: Sunday, August 18, 2013 10:09 PM To: Pinski, Andrew Cc: Linaro Toolchain Subject: Re: [ACTIVITY] 12 - 16 August 2013 Hi

RE: How to make gcc generate optimized code for statically linked TLS

Yes don't compile with -fPIC or compile with -ftls-model=local-exec . Thanks, Andrew Pinski From: linaro-toolchain-boun...@lists.linaro.org linaro-toolchain-boun...@lists.linaro.org on behalf of Vitali Sokhin vitali.sok...@gmail.com Sent: Sunday, July 14, 2013

RE: [ACTIVITY] Week 13

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

RE: [ACTIVITY] Week 12

* 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

RE: Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks

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

RE: [ACTIVITY] 18th Feb 2013 - 22nd Feb 2013

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:

RE: [ACTIVITY] 4-8 Feb 2013

* 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