linaro-toolchain

linaro-toolchain@lists.linaro.org

6 participants
5796 discussions

by Renato Golin

== Progress == * Short week - Two days off due to a messy implant bloating my face - Should be better on Monday * Cambridge LLVM Day, Cambridge University Computer Lab - Presented the status of the auto-vectorizer in LLVM * Releasing candidate 1 of LLVM 3.4 - All tests green, running benchmarks - http://people.linaro.org/~rengolin/llvm/ * Buildbots - Adding Chromebook self-hosting (fixing MCJIT tests) - Adding Chromebook test-suite (fixing ClamAV) - Will turn off the old Chromebook and re-install it for benchmarks - Will add an Odroid XU in pair with the community one to be added next week * Background - Patch reviews, discussions * EEMBC rgbcmy implementation requires extensive changes to the compiler - Will deal with them on the background over the next months - While checking other EEMBC problems == Plan == * Continue the 3.4 release * Look at vectorization pragmas * Look at other EEMBC results

12 years, 10 months

[ACTIVITY] Week 47

by Will Newton

== Progress == * Committed a couple of gdb patches * Debug malloc to a working state, performance improved * First version of glibc aarch64 ifunc support * Found a couple of bugs in binutils aarch64 ifunc support == Issues == * Missed two days due to illness * Power cut and broadband outage on Wednesday afternoon == Plan == * Respin and submit glibc docs patches * Submit glibc aarch64 ifunc code -- Will Newton Toolchain Working Group, Linaro

12 years, 10 months

Is there any description about the toolchain release file naming rule?

by YongQin Liu

Hi, All Under this site http://releases.linaro.org/13.09/components/toolchain/binaries/, there are many files released. but do we have any description on the file naming rules? Sorry for my simple question, I just want to know what the files are used for. which one I should select when I need to use toolchain. Like the files below, I can guess that aarch64 means that it will generate files run on aarch64 platform, but I can not guess what's the difference between linux and none, and not know what's the difference between gnu and elf. So if you have any wiki/link about the the naming rules or description about the file, please share me. crosstool-ng-linaro-1.13.1-4.8-2013.09-01.tar.bz2 crosstool-ng-linaro-1.13.1-4.8-2013.09.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_runtime.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_src.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64-linux-gnu-4.8-2013.09-20130912_win32.exe gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64-linux-gnu-4.8-2013.09_runtime.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09_src.tar.bz2 gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip.xz gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_runtime.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_runtime.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_src.tar.bz2 gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.bz2 gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.bz2 gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.xz gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip.xz gcc-linaro-arm-linux-gnueabihf-4.8-2013.09-20130912_win32.exe gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.bz2 gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.xz gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2 gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_src.tar.bz2 gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip.xz gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.bz2 gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.xz gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2 gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip.xz -- Thanks, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org> http://lists.linaro.org/pipermail/linaro-validation

12 years, 10 months

CortexM toolchain recommendations

by Trevor Woerner

Hi toolchain gurus, I am about to start some projects working with CortexMx devices and am wondering if anyone has an opinion on which toolchain(s) I should use/investigate? Being a fan of Linaro, my first instinct would be to use cbuild2 to build an arm-none-eabi- toolchain from a 4.8.x tree. But looking around I can't help notice https://launchpad.net/gcc-arm-embedded. Does anyone know if gcc-arm-embedded has things the Linaro toolchain doesn't wrt Cortex M0, M3, and M4 device/instruction support? Best regards, Trevor

12 years, 10 months

Fwd: [Bug target/59216] [ARM] negdi*extendsidi regression

by Christophe Lyon

-------- Original Message -------- Subject: [Bug target/59216] [ARM] negdi*extendsidi regression Date: Wed, 20 Nov 2013 18:06:14 +0100 From: christophe.lyon at st dot com <gcc-bugzilla(a)gcc.gnu.org> To: Christophe LYON <christophe.lyon(a)st.com> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59216 --- Comment #2 from christophe.lyon at st dot com --- Basically, the working code does: asrs r3, r2, #31 negs r2, r2 sbc.w r3, r3, r3, lsl #1 while the failing one does: negs r2, r2 asrs r3, r2, #31 -- You are receiving this mail because: You reported the bug.

12 years, 10 months

Testing Android on LAVA

by Renato Golin

Hi LAVA folks, I don't know if you guys know, but Android is moving to LLVM for the next release or so. As such, we'll need to do a lot of testing between now and next release to make sure each component can be compiled (and runs correctly) with LLVM on an incremental basis. We're trying to come up with a way for remotely testing the Linux kernel booting on ARM devices, more specifically an Android stack, and I'm finding it hard to do that with my home equipment. Doing that in LAVA would be ideal, and I know the Android team does it already, but our constraints could be a little different. Basically, there are two fronts: 1. Building Android components with LLVM, using a GCC-compiled kernel booting on an ARM board, in LAVA. This is something we should work internally on how to do it, and it'll be between Android, LAVA and Toolchain groups. 2. Building the Linux kernel with LLVM, and using a GCC-compiled image (like stock CyanogenMod) to test the kernel. We don't have such a kernel (many patches), but the LLVMLinux guys do, and that's where they come in. On the second case, the topic of this email, we'd have to liaise with them to fire jobs at LAVA from their own infrastructure (originally, manually only), and that might need some thinking. But ultimatelly, we want to have those jobs running on LAVA, so that later on we'd be able to have a third layer: Linux+Android built with LLVM with the same system level tests. Since the LLVMLinux guys don't have access to much ARM hardware, and since it's easier for us to scale (or to re-define) hardware requirements, having them running on LAVA makes even more sense. Is this something we can do? Is this being done already? Is this just a question of legal/corporate decision, or is there any technical issues we have to look into? Android folks, It might make more sense if you guys just grab their kernel and build the Android system based on that internally, so that we don't need external access to job submissions in LAVA, but that would mean work from you guys to patch it up, and that might not be in the roadmap for the next months. Is that a feasible route? cheers, --renato

12 years, 10 months

[ANNOUNCE] Linaro GCC 4.7 and 4.8 2013.11 released

by Christophe Lyon

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.8 and Linaro GCC 4.7. Linaro GCC 4.7 2013.11 is the twentieth release in the 4.7 series. Based off the latest GCC 4.7.4+svn204656 release, this is the seventh release after entering maintenance. Interesting changes include: * Updates to GCC 4.7.4+svn204656 Linaro GCC 4.8 2013.11 is the eighth release in the 4.8 series. Based off the latest GCC 4.8.2+svn204657 release, it includes performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.8.2+svn204657 * Fixes for bugs LP #1243656, #1243022 * Backport fix for PR/58423 * AArch64: added support for tiny model GOT access. * Improved Aarch32 A-profile multilibs support (--with-multilib-list option) The source tarballs are available from: http://releases.linaro.org/13.11/components/toolchain/gcc-linaro/4.7 http://releases.linaro.org/13.11/components/toolchain/gcc-linaro/4.8 Downloads are available from the Linaro GCC page on Launchpad: http://www.linaro.org/downloads/ More information on the features and issues are available from the release pages: https://launchpad.net/gcc-linaro/4.7/4.7-2013.11 https://launchpad.net/gcc-linaro/4.8/4.8-2013.11 Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain Bugs: https://bugs.launchpad.net/gcc-linaro/ Questions? https://ask.linaro.org/ Interested in commercial support? Inquire at support(a)linaro.org

12 years, 10 months

[Activity] Nov 10-16

by Rob Savoye

= Progress == * Created Cards for the infrastructure Team TODO list. * Finished Cbuildv2 support for building GDB binary tarballs. * Got Arch linux up on Odroid XU board again, seems stable, did a build and test run. * Experimented with lava-tool. * Tried to get GCC trunk building native on aarch64 for libsanitizer patch testing. * Upgraded gmp to 5.1.3 in infrastructure/ to work around a configure bug triggered by crouton native builds on a chromebook. * Setup chromebook slaves in new toolchain build farm. * Started adding support to Cbuildv2 to handle git URLs with a user name, ie.. git(a)staging.git.linaro.org to work around git repo problem. == Plan == * Finish support for user names in URLs. * Continue on remote testing support. * Keep trying gcc trunk on aarch64 native. * Fix git repo. == Issues == * GCC git repo hasn't been auto updating the svn branch of linaro-4.8-branch. It used to work... updating manually is now broken as well. * Somehow qemu snapshots tarballs are overwriting the toolchain directories on snapshots.linaro.org. * I don't think lava-tool is going to be useable for toolchain testing, as it only queues up an executable test case to be run later, whereas GCC expects the test to get run right away.

12 years, 10 months

[ACTIVITY] 12-15 November 2013

by Christophe Lyon

One day off == Progress == * Prepared 4.7 and 4.8 2013.11 releases. Some delay because of board crashes and disk full issues. * Aarch64: committed 'frame grows downward' patch. This removes a dependency for libsanitizer and libssp. * libsanitizer on Aarch64: blocked by GCC trunk not bootstrapping currently on Aarch64 HW (reported by Rob) * Looked at cross-build failures of trunk after new -fisolate-erroneous-paths. Ramana pointed me to Marcus' glibc patch, and I could switch my builds from eglibc to glibc. * cross-validations: updated list of configurations built&tested after discussion with Richard during Connect. == Next == * Announce 4.7 and 4.8 2013.11 releases * Continue investigating 'extended neg' fix (aka tar regression) * Look for patches to fix AArch64 bootstrap, so that we can test libsanitizer

12 years, 10 months

[ACTIVITY] Week 46

by Yvan Roux

One day off. == Issues == * Various cbuild issues: - disk full, boards down and benchmarks launched on different boards == Progress == * LRA on AArch32: - Proposed a ARM backend fix for the Fortran issue http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01997.html - Performance analysis ongoing * Merge reviews and backports. == Next == * Continue on LRA

12 years, 10 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain