[ACTIVITY] Week 46
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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 12-15 November 2013
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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[Activity] Nov 10-16
= 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.. g...@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. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ANNOUNCE] Linaro GCC 4.7 and 4.8 2013.11 released
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 supp...@linaro.org ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Testing Android on LAVA
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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
