linaro-toolchain

linaro-toolchain@lists.linaro.org

1 participants
5787 discussions

[ACTIVITY] 26-30 May 2014

by Christophe Lyon

Short week (2 days off) (4/10) == Progress == * GCC trunk cross-validation (CARD-647) (2/10) - reported 2 new compiler build failures and 2 regressions - tested one proposed patch, which did not fix the regression - trunk now builds OK again * Neon intrinsics tests (1/10) - cleaned branch to prepare submission - working on Cumulative Saturation Neon flag support for AArch64 * aarch64 libsanitizer support - resumed work: libsanitizer no longer builds with recent glibc, will need to patch it upstream before bringing it back to GCC. - testing will be difficult using qemu since libsanitizer reserves a huge chunk of memory at startup (8GB) which may not be available on the host machine * Misc (meetings, conf-calls, ....) (3/10) - 1:1 calls, weekly calls - backports review == Next == * GCC trunk cross-validation: - test Kugan's patch before submission - evaluate effort to develop a mail-driven support for testing patches vs trunk befiore submission - add support for validation of FSF-4.9 branch * Neon intrinsics tests - add support for Cumulative Saturation Neon flags on AArch64 * AArch64 libsanitizer - discuss how to make cross-testing more practical

12 years, 3 months

[ACTIVITY] Week 22

by Yvan Roux

Short week (3 days) == Issues == * None == Progress == * CARD-1162 : Linaro GCC 4.9 and CARD-1355 : stabilization and optimization effort for ARMv8-a (4/10) - Enhanced my backporting script - Looked at the merge process (4.9, 4.8 and 4.7 merge are comming) - 40 backports stiil need validation * Misc: (2/10) o Various meetings. o Discussed schroot testing == Next == * FSF branch merges * Document backporting script usage * Continue feedback and help with the validation

12 years, 3 months

[ACTIVITY] 26 - 30 May 2014

by Kugan

== Progress == * Zero/sign extension elimination (TCWG-15) (7/10) - regression tested and fixed all the issues - final bootstrap and regression testing for arm and x86_64 are ongoing - will post the patch for comment after checking the results * benchmarking (TCWG-468) (1/10) - Set-up chrome-book for a15 release benchmarking * SAH1 performance (TCWG-413) (2/10) - Christophe noted regression for aarch64_be due to clean-up patch. - register_move_cost hook in aarch64 does not handle all the cases (CORE_REGS and POINTER_REGS) and due to this, it calculates FP2FP cost for these classes . With CORE_REGS gone, costs for register classes are now different. Cost table needs adjustment. * FENV for C11 TCWG-447 - Committed ARM part. == Plan == * Benchmarking. * Upstream zero/sign extension elimination activities. * sha1 performance.

12 years, 3 months

[ACTIVITY] Week 22

by Renato Golin

== Progress == * Kernel (CARD-1246 2/8) - Fixed edge cases for named registers - http://llvm.org/PR19841 - http://llvm.org/PR19837 * Background (6/8) - Code review, meetings, discussions, etc. - TCWG Rack re-org - Trying to set up native Chromebooks - Trying to set up APM - Trying to add Compiler-RT to our buildbots == Plan == * Continue rack re-org * Continue RT support on current bots * Try libc++ bot * Have a look at sanitizer bot

12 years, 3 months

[ACTIVITY] 26 - 30 May 2014

by Will Newton

== Progress == * Bank Holiday Monday (2/10) * Got a postgresql malloc benchmark running (4/10, TCWG-441) * Started refactoring malloc microbenchmark based on review (2/10, TCWG-160) * Patch review and testing (2/10) == Issues == * None == Plan == * Holiday Tuesday and Wednesday * Finish refactoring malloc microbenchmark * Work on results plotting code for benchmarks -- Will Newton Toolchain Working Group, Linaro

12 years, 3 months

Prebuilt Linaro 2014.04 arm-linux-gnueabihf: cannot find /lib/ld-linux-armhf.so.3

by Denys Dmytriyenko

Hi, I've been having this issue with latest binary Linaro 2014.04 toolchain from http://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-a… It comes with own sysroot, but linker fails to locate /lib/ld-linux-armhf.so.3 $ make arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o nvs.o nvs.c arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o misc_cmds.o misc_cmds.c arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o calibrator.o calibrator.c arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o plt.o plt.c arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o wl18xx_plt.o wl18xx_plt.c arm-linux-gnueabihf-gcc -I/tmp/include/libnl3/ -DCONFIG_LIBNL32 -c -o ini.o ini.c arm-linux-gnueabihf-gcc -L/tmp/lib/ nvs.o misc_cmds.o calibrator.o plt.o wl18xx_plt.o ini.o -lm -lnl-3 -lnl-genl-3 -o calibrator /opt/linaro-2014.04/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/ld-linux-armhf.so.3 collect2: error: ld returned 1 exit status Makefile:26: recipe for target 'all' failed make: *** [all] Error 1 And when I pass my own sysroot, it works fine. Is it supposed to work as a standalone toolchain with its own bundled sysroot? Thanks. -- Denys

12 years, 3 months

x86_64 libsanitizer test case bug

by Rob Savoye

I've been digging through test logs, and for gcc 4.9.1 native x86_64 tests, all the libsanitizer test cases fail to link due to unresolved symbols from libpthread and libdl. Does anybody know more about this bug, or care to fix it ? :-) It still exists in gcc trunk. - rob -

12 years, 3 months

[Weekly] 19-23 May 2014

by Michael Collison

== This week == - Completed GCC Launchpad bug dispositions [CARD-300][2/10] - Backported PR61202 - gcc generated invalid sqdmulh instruction [TCWG-485](2/10) - Triaged and investigated Launchpad bug 1295738- Unable to find a register to spill in class 'LO_REGS' [Card 300](3/10) - Triaged and investigated Launchpad bug 1248752 - ARM assembly instruction compile error [Card-300](3/10) == Next week == - Resolve Launhpad bugs 1295738 and 1248752 - Triage and investigate other bugs as time warrants == Future == No Plans. == Planned holidays == No Plan

12 years, 3 months

[Activity] May 19-25

by Rob Savoye

== Progress == * Worked on building binary tarballs from Jenkins. (TCWG 383 - 4/10) * Continuing work on regression test analysis and reporting. (TCWG 448 - 3/10) - now copying the check.log from make check to toolchain so tcwgweb.sh can scan it for build errors in the test cases. - Got the delimiter for concurrent Jenkins builds changed, now glibc build problems are gone. - Track down and try to fix testsuite build issues. * Meetings and Misc. (3/10) - Worked on making remote testing go faster. Setting ControlPersist seems to help. - Much debugging of Jenkins related issues. == Plan == * Continuing work on validating test results and fixing testsuite build issues. (TCWG 448) * Probably more work on binary tarballs. (TCWG 383) * More tracking down and fixing Jenkins related issues. == Issues == * For some reason libgloss isn't getting built for *-elf via Jenkins/Cbuildv2.

12 years, 3 months

Parallel cross-testing of GCC

by Maxim Kuvyrkov

Hi, I have tried out a prototype of using binfmt_misc, and it does not appear to be a worthwhile solution at this point. Bottom line: with a nice fast multi-core x86 server and a pool of ARM boards we can test GCC in ~20min. Testing setup: - Core i3 2-core host - Chromebook 2-core target, SSD disk - WiFi network - GCC mainline built from sources with same flags both natively and cross: C, C++, Fortran. General observations about testing ARM toolchains: - When testing natively target is busy 100%: around 50% of time is spent compiling testcases, 40-45% in dejagnu/expect, 5-10% on actual test execution. Target is the bottleneck. -- 21633.22user 4400.13system 4:13:11elapsed - With testing cross using standard rsh_prog=ssh, rcp_prog=scp, target is busy 40% of the time: 30% on ssh, 10% on actual test execution. Host is the bottleneck. -- - When testing cross (using method below) target is busy only 15-20% of the time: 10% on ssh and 10% on actual test execution. Host is the bottleneck. -- 9490.16user 2882.54system 1:10:57elapsed I've got a prototype implementation of parallelized cross-testing of GCC that I'm happy with using rsh_prog and rcp_prog dejagnu wrappers: General observations on dejagnu cross-testing process: - All communication with the target is done by Dejagnu via rsh_prog and rcp_prog hooks. These are normally defined to ssh and scp respectively. - Dejagnu copies every testcase to /tmp/ on the target with scp. - Dejagnu executes every testcase via ssh off target's /tmp/. In total there is 1 scp and 3 ssh invocations per testcase. The idea of below scripts is to assume shared filesystem between host and a pool of target boards, and skip copying executables to target's local filesystem. Since there is no longer local state (local state == contents of /tmp) on the target boards, testcases can be executed on any of the boards in the pool. This happens transparently to dejagnu: dejagnu issues "rsh_prog chromebook-pool ./test" and then rsh_prog converts this to "ssh chromebook-XX ./test", where XX chosen at random. Script implementation notes: - For some unholy reason there is no way of correctly parse command line from dejagnu and give it to bash. The reason why myssh script ssh'es onto host itself is because that's the only way I've found to reliably execute the command. Hey! The command line was intended for ssh anyway! - Myssh script translates hostname of foobar-pool-01-03-08 into foobar01, foobar03 or foobar08 chosen at random. If there is no "-pool-" mentioned in hostname, then it is used verbatim. -- Maxim Kuvyrkov www.linaro.org

12 years, 3 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain