linaro-toolchain

linaro-toolchain@lists.linaro.org

3 participants
5629 discussions

by Matthew Gretton-Dann

== Blueprints == Initial Current Actual initial-aarch64-backport 31 Oct 2012 30 Nov 2012 aarch64-baremetal-testing 31 Oct 2012 30 Nov 2012 fix-gcc-multiarch-testing 31 Dec 2012 31 Dec 2012 backport-fma-intrinsic 31 Dec 2012 31 Dec 2012 fused-multiply-add-support 31 Dec 2012 31 Dec 2012 gcc-investigate-lra-for-arm 31 Dec 2012 31 Dec 2012 == Progress == * Returned from Connect and followed up. * Updated performance blueprints for next iteration * Backporting Doko's triplet patches to 4.7 * Patches ready except for problems building Ada * HOT/COLD partitioning * Rebuilt with TBB/TBH disabled always * Started investigated LRA for ARM == Next Week == * Post triplet backport patches upstream * Run HOT/COLD partitioning benchmarks * On ARM to see if TBB/TBH is making the difference previously seen * On x86_64 to see what the actual benefit we could get * initial-aarch64-backport & aarch64-baremetal-testing * Finish documentation * gcc-investigate-lra-for-arm * Benchmark on x86_64 to see what the benfit could be. * fix-gcc-multiarch-testing * Come up with strawman proposal for updating testsuite to handle testing with varying command-line options. == Future == * backport-fma-intrinsic & fused-multiply-add-support * Backport patches once fix-gcc-multiarch-testing has been done. -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

12 years, 10 months

Compilation speed of Linaro's gcc compared to e.g. Ubuntu's version

by "Frank Müller"

Dear all, we have an ARM Cortex-A8 board where we are running our application. I am in charge of maintaining the Linux on it and the toolchain/SDK setup. So far we've been running Poky/OpenEmbedded and using the cross compiler that came about during the compilation. For easier maintenance, we are now switching to Linaro. The image is set up and I can compile, however I notice a peculiar fact: the binary distribution of Linaro's gcc (https://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc…) has a significantly larger compilation speed than a version of arm-linux-gnueabihf-gcc that is shipping with Ubuntu. In our particular case, using Ubuntu's version it takes less than 6 minutes to compile our software, but 10 minutes when we use Linaro's version. The makefiles and source are exactly the same, only the compiler is different. I also tried an older version (4.6) of Linaro's gcc to match the Ubuntu one (tested the 12.04 shipped version), with no significant difference. Compiler flags for the system are -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard Running with -ftime-report, most of the additional time seems to be spent in the parser. Adding -fno-graphite-identity -fno-graphite for Linaro's gcc did not make a difference. I believe I tried to use crosstool-ng to make my own version, but I don't remember the results as this was over 7 weeks ago. I also did not have a chance to compare performance of the binaries. I do notice a difference in compilation sizes (4.8 MB for Ubuntu's 4.6 version, 4.1 MB for Linaro's 4.7 versions - can't test anything other right now). I would like to use Linaro's gcc as the crosscompiler for our project, as it is an easy setup. Repackaging Ubuntu's version is an option, though (some of the team do not use Ubuntu, plus I'd like everybody to use EXACTLY the same version of the crosscompiler). So there is no real "problem" for me, per se, but I am extremely curious as to what is going on here. It seems that Linaro's gcc has additional patches or maybe just different default settings that cause additional time to be spent in the parser. It would be interesting to know what exactly this is and whether/how it can be disabled in those cases where time of compilation is more important than e.g. performance gain. TIA for replying. Best Frank

12 years, 10 months

Initial aarch64 plans

by Michael Hope

This is the first of a few Connect follow up emails. KVM and Cortex-A15 tuning are to come. Matt and I have entered the initial aarch64 blueprints. These are part of the bootstrap that clear the way for us and the community to port packages on top. The high priority ones are: * Add support for AArch64 to Boehm GC[1] * Add support for GProf to AArch64 backend of GCC[2] After those we have: * Add IFUNC support for AArch64[3] * AArch64 GCC support for Stack Protection[4] All are linked off the parent blueprint at: https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-initial-meta and we'll add more there as time goes by. The plan is to commit to the first two and do them this iteration. The latter two aren't critical and will be done as part of our general work. -- Michael [1] https://launchpad.net/linaro-toolchain-misc/+spec/aarch64-boehm-gc [2] https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-gprof-support [3] https://launchpad.net/binutils-linaro/+spec/aarch64-gcc-ifunc [4] https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-ssp-support

12 years, 10 months

[ACTIVITY] report week 44

by Peter Maydell

* Attended Linaro Connect; notable sessions: + Ubuntu plans for QEMU for Ringtail release = upstream qemu has merged qemu-kvm back in so Ubuntu will switch to qemu from qemu-kvm for x86 = also makes sense now to use upstream qemu for all archs (following Debian) rather than using qemu-linaro for non-x86: reasons for using q-l in Ubuntu now mostly fixed (ie upstream ARM support no longer dire). Ubuntu will carry omap3 patches to avoid dropping that feature in the changeover = makes sense for Linaro too as we now have an automated package-to-PPA setup for people who need bleeding-edge and also will want Ubuntu to transition to a more stably released and supported QEMU codebase to use for KVM-on-ARM-servers + KVM Testing plans = worked through a list of things that would be nice to test; useful feedback from people in the session about what matters. Missing: specific commitment by anybody to write tests :-) + various informal discussions about possibilities for v8 QEMU * this week: at LinuxCon Europe / ELC-Europe / KVM-Forum / QEMU Summit -- PMM

12 years, 10 months

Daylight savings changes

by Michael Hope

Hi toolchain people, I've gone through and massaged our meetings and 1-on-1s to handle the recent daylight savings changes. Most meetings now start at 9:15 am GMT and 1-on-1s are packed before them if possible. Let me know if I should massage them further, -- Michael

12 years, 10 months

[ACTIVITY] 29 Oct - 2 Nov

by Matthew Gretton-Dann

== Progress == * Attended Linaro Connect * Worked out focus for performance in next iteration: * Cortex-A15 * Other discussions on: * Transitioning from cbuild->LAVA * ARMv8 GNU Tools support * big.LITTLE Toolchain tuning == Next Week == * Backport Doko's configury changes for arm-none-linux-gnueabihf support * Remerge HOT/COLD partitioning to test like for like (TBB generation) * Benchmark LRA vs Reload on x86 and x86-64 * Write up strawman for non-multitest testing in GCC == Future == * Decide whether the effort to develop HOT/COLD partitioning is worth it. * Support LRA on ARM. * Attend Connect in Hong Kong... -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

12 years, 10 months

ARM cross mismatch error

by naveen yadav

Dear All, We have ARM cross compiler, and building our code. we got below error. we have GCC Linaro 4.6.4. arm-linux-gnueabi/bin/ld: DIV usage mismatch between /home/Release/libasm.a(Blt32_Neon.o) and /home/Release/liblayer.so arm-linux-gnueabi/bin/ld: failed to merge target specific data of file /home/Release/libasm.a(Blt32_Neon.o) is it related to below link ? http://sourceware.org/ml/binutils/2012-03/msg00211.html thanks

12 years, 10 months

Some ugly patches for gcc-linaro on Android

by Bernhard Rosenkränzer

Hi, here's some patches for gcc-linaro to make it work with --host=arm-linux-androideabi They're the quick and dirty thing to do and look like they could have been written by Microsoft, needed something working in time for Connect ;) gcc-4.7-android-workarounds.patch: Workarounds for things that go wrong, but where the true cause is yet to be determined (e.g. why would configure think we have fread_unlocked and friends when we don't?) gcc-4.7-libitm-android.patch: Workaround for Bionic not knowing Elf32_auxv_t gcc-4.7-no-unneeded-multilib.patch: Get the multilib config in sync with regular Linux gcc-4.7-stlport.patch: Use stlport instead of libstdc++ (yes, this sucks - but it's what Android decided to do). Still needs to link libstdc++ because Bionic contains a libstdc++.so (but it's more like a libsupc++ - no STL there, but needed for stlport to work). ttyl bero

12 years, 10 months

[ACTIVITY] 22-26 October

by Matthew Gretton-Dann

== Progress == * HOT/COLD partitioning for PGO * Initial look at results * Patch Tracking & Backporting * Testing Doko's configury changes for arm-none-linux-gnueabihf support * Connect Prep * LRA Investigations * Sign/zero extension II == Next Week == * Linaro Connect == Future == * Attend Connect * HOT/COLD partitioning for PGO: * Get two current patches accepted upstream * Post question upstream about register allocation 'mistakes' I am seeing -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

12 years, 10 months

[Activity] Week 43

by Zhenqiang Chen

Summary: * Validate and release Linaro binary toolchain 2012.10 * Test Details: 1. Release Linaro binary toolchain 2012.10 * Fix windows installer issue due to version format change. * Validate and release Linaro binary toolchain 2012.10. 2. Identify the root cause of PR 54902 (lp:1065559), and Richard Biener fixed it. 3. Enable SPEC2006 test. Testing is ongoing. Planed Leaves: * Nov. 5-7: Off site teambuilding event. * Nov. 9, 12-13: Annual leaves Plans: * Performance test for shrink-wrap. Best regards! -Zhenqiang

12 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain