== Progress ==
Bug#403/#418/PR63870 [7/10]
. Prepared patches for vldN_lane/vstN_lane
. reviewed related patches on list
. code changes are ready, but reveal errors in the testsuite
Misc [3/10]
. mailing llists
. meetings
. some help with lab config with Renato
= Progress ==
* TSAN support for Aarch64 (6/10)
* Emails, linaro/AMD status meetings. (4/10)
1-1 with maxim, Christophe.
== Plan ==
* TSAN support for Aarch64.
* Fix Linaro Bug 863
== This week ==
* GCC Modularization Project (9/10)
- Flattening header files
- tree-core.h, and tree.h, c-common.h
- Completed
- Bootstrap successful on x86
- Testing in progress on all platforms listed in config-list.mk
- Reviewed and tested patches from Prathamesh
* Misc (1/10)
- Conference calls
== Next week ==
- Submit tree.h and related patches for review
Hi all,
I've asked ITS to install a git post-commit hook to send an email
after commits in the toolchain git repos.
It turns out that they prefer to send such email to mailing-lists, to
avoid having to maintain the list of recipients themselves, which of
course really makes sense.
So far, we already have a cbuild2 mailing-list for commits, which Rob
asked to now point to abe instead of cbuild2 repo.
I was thinking about asking a single new mailing-list (eg
tcwg-commits) and send commit emails to that list for all ours repos,
instead of having a list per repo to which interested team members
would have to subscribe.
We currently have the following git repos:
abe
backflip
backport-tools
binutils-gdb
binutils
cbuild2
cortex-malloc
cortex-strings
cross-build-tools
dejagnu
dmucs
eglibc
fakebench
gcc-new
gcc
gdb
glibc
lavabench
newlib
release-notes
spec2xxx-utils
tcwg-sysadmin
Any objection to having such a list?
(I do not plan to force subscription of any of you :-)
Christophe.
== Progress ==
* Automation Framework (CARD-1378 5/8)
- Re-adding Junos and D01s to the rack
- Planning access from remote servers
- Following up new rack setup
- Moving lab bridge to a VM
- Re-checking all boards for stability
- Working on the dragon boards to get them stable
* Background (3/8)
- Code review, meetings, discussions, etc.
- Trying to get the LLVM Perf system back online
- Multiple bot breakages
- Reviewing patches for 3.5.1 release
- Jira farming
* 1 day off
== Plan ==
* Continue working on the dragon boards
* Try to get an internal ARM64 buildbot
* Hopefully finish off the lab move
== Progress ==
* GCC trunk/4.9 monitoring (2/10)
- still tracking cause of random "interrupted system call" errors
- checked possible regressions
* AArch64 sanitizers (1/10)
- managed to build on board, didn't try to run the tests yet
* Neon intrinsics tests (2/10)
- fixed a couple of bugs in the already upstreamed tests
- continued conversion to GCC testsuite
- support to external user (LLVM based compiler)
* 4.9-2014.12 release (1/10)
- backports+branch reviews
* Misc (4/10)
- meetings, conf-calls, emails....
== Next ==
* GCC trunk/4.9 monitoring
* AArch64 sanitizers
* Neon intrinsics tests
* cbuild2/abe: look at backport and tcwgweb
Holidays: Dec 22nd - Jan 2nd
Apology for sending this out late.
== Progress ==
Debugging ARM gdb watchpoint failures [4/10] [TCWG-567]
-- Prepared a testsuite patch for unsupported tests on ARM
-- Investigation of other failures due to watchpoints installation
rejected through ptrace interface.
QEMU kernel debugging setup [4/10] [TCWG-568]
-- Setup arm Linux kernel debugging to debug watchpoints
Studying arm debug unit architecture versions for possible upgrade to
watchpoint/hwbreak implementation. [1/5] [TCWG-569]
Miscellaneous [1/10]
-- Meetings, Emails etc
-- Follow up on Hong Kong Visa
== Plan ==
Figure out unexplained arm gdb watchpoint rejection from ptrace interface.
More work to figure out a way to debug arm Linux kernel using QEMU
Some further study on arm debug unit architecture versions.
== Progress ==
Holiday [1/10]
Investigated bug #928 [4/10]
. turns out to be invalid implementation of memset in old linux kernels
. raises a question - do we want to provide support for users of old
Linux kernels on new compilers? We could spend a long time rehashing
work the kernel community has already done.
bugs #403/418 [3/10]
. working on fixing error reporting for Aarch64 vldN_lane/vstN_lane
. trickier than expected, but have found a plan to implement this week
Misc [2/10]
== Plan ==
submit patch for #403/418 vldN_lane and work on more intrinsics
== Issues ==
* Validation unusable all week, seems to be operational now.
== Progress ==
* GCC 4.9 2014.12 (5/10)
- Struggle with backports validation,
- everything is in the pipe now ... wait and see
* Misc: (5/10)
- Scripted the GCC revisions management, now able
to track ARM related trunk contribution and fill the backport
spreadsheet, and will be able to generate the release notes.
- Various meetings.
== Plan ==
* Backports
* Branch merge
* Libunwind (AArch64_be review)
Back from Vacation 24, 26, 27 and 28 November. (8/10)
= Progress ==
* TSAN support for Aarch64 (1/10)
* Emails, linaro and AMD status meetings. (1/10)
1-1 with maxim
== Plan ==
* TSAN support for Aarch64.
* Fix Linaro Bug 863
* catchup emails and other discussions
== This week ==
* GCC Modularization Project
- created initial patch for flattening cfgloop.h.
- created initial patch for flattening df.h.
== Next Week ==
- Finalizing patches for cfgloop.h and df.h.
- Continue working on flattening header files.
== Progress ==
* Zero/sign extension elimination with widening types (1/10)
- Addressing comments from the review
* BUG #398 #412 (5/10)
- built kernel revision with provided config and toolchain binary
release to reproduce gcc segafult. Couldn’t reproduce it. Since there
is no more details to reproduce, closed it as cant reproduce.
- Spec2k gcc optimization issue was reproduced and reduced test-case
was created.
- dumps shows that this issue could be related to splitting constants
for early during expand might be the root cause.
* Holiday (4/10)
== Plan ==
* Continue with Zero/sign extension.
* BUG #412
== Planned Leave ==
* 11/12/2014 to 24/12/2014 - 10 days
== Progress ==
* 2 days sick
* Lab move (2/6)
* Buildbots (TCWG-76 2/6)
- Created a buildmaster at Linaro to help local development
- Put a dragonboard as a slave, which lasted 2 days up
* Background (2/6)
- Code review, meetings, discussions, etc.
== Plan ==
* I have no idea
== Progress ==
* Building an ILP32 toolchain for AArch64 (3/10, TCWG-559)
- More work on tidying patches
- Trying to get a test environment for ILP32
* LLD for ARM and AArch64 (5/10)
- Submit more reloc cleanups for LLVM
- Patch review
- Reading code
* glibc patch review (1/10, CARD-341)
* Email, meetings, etc. (1/10)
== Issues ==
* OE on Junos no good for building toolchains
* Ubuntu on Junos still seems vaporware
* Running out of disk space on development machine (bought an external HD)
== Plan ==
* More work on LLD
* Try QEMU for ILP32 work
--
Will Newton
Toolchain Working Group, Linaro
ABE benchmarking - TCWG-360 [4/10]
* Implemented most of a solution to the 'must be in same network' restriction
libm exercising - TCWG-558 [4/10]
* lulesh generates needless calls to pow on AArch64 (as opposed to
'pow is slow')
** Working on a reduced test case
* Ran a chunk of benchfft, left a process searching the perf reports
for libm calls
* More chroot/glibc fiddling
* Decided Graph500 was unlikely to be interesting
Misc - [2/10]
=Plan=
On holiday Monday - Wednesday
More lulesh, benchfft results
Think about where to go next with libm exercising
Complete 'same network' workaround, test benchmark repeatability
Port benchmarking scripts to ABE repo
Get storage/automation started, if Rob has time
Hi All,
Currently linaro toolchain for arm-linux-gnueabihf built with crosstool-ng scripts uses prebuilt sysroot.
I am trying to build eglibc on my own without using prebuilt sysroot. I am not able to exactly create same layout in the library layout.
Linaro build layout looks:
gcc-linaro-arm-linux-gnueabihf-4.8-2014.01_linux\arm-linux-gnueabihf\libc\usr\lib --> arm-linux-gnueabi arm-linux-gnueabihf
one for soft float and other for hard float fp. Can anybody please tell how we tell build system to create directories like above while building eglibc?
I used following commands to build eglibc:
../src_eglibc/configure --disable-profile --without-gd --without-cvs --prefix=/usr libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes --with-headers=<some_dir>/arm-linux-gnueabihf/libc/usr/include --host=arm-linux-gnueabihf
Make all
make install install_root= <some_dir>/arm-linux-gnueabihf/libc/
Thank you very much for your help.
//Mallikarjuna
Forwarding this message to the linaro toolchain list instead. I am not the person who should be supporting the Linaro ODP project with GCC questiosn; the toolchain team inside Linaro should be instead.
Thanks,
Andrew Pinski
________________________________________
From: Ola Liljedahl <ola.liljedahl(a)linaro.org>
Sent: Monday, November 24, 2014 2:31 PM
To: lng-odp(a)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 inline uint32_t odp_atomic_fetch_inc_u32(odp_atomic_u32_t *ptr)
{
return __sync_fetch_and_add(ptr, 1);
}
static inline void odp_spin(void)
{
#ifdef __SSE2__
__asm__ __volatile__ ("pause");
#else
__asm__ __volatile__ ("rep; nop");
#endif
}
typedef struct {
int count;
odp_atomic_u32_t bar;
} odp_barrier_t;
void odp_barrier_wait(odp_barrier_t *barrier)
{
uint32_t count;
int wasless;
// wasless = barrier->bar < barrier->count; <<<lost on git add -p
__atomic_thread_fence(__ATOMIC_SEQ_CST);
count = odp_atomic_fetch_inc_u32(&barrier->bar);
if (count == 2*barrier->count-1) {
barrier->bar = 0;
} else {
while ((barrier->bar < barrier->count) == wasless)
odp_spin();
}
__atomic_thread_fence(__ATOMIC_SEQ_CST);
}
While fixing and cleaning up this code, the indicated line that
initializes 'wasless' was dropped (because it reappears in a later
patch in the patch set after the odp_atomic_fetch_inc call). To my
surprise, GCC did not complain when compiling this file (using -O2
-Wall). But it does complain when compiling with -O0 -Wall. With some
investigation, it seems like GCC understands that if a statement does
not have any side effects so it can optimize away everything,
including the usage of the uninitialized variable and thus also the
corresponding warning.
olli@macmini:~/hacking/gcc-wunit$ gcc -O2 -Wall -c odp_barrier.c
olli@macmini:~/hacking/gcc-wunit$ gcc -O0 -Wall -c odp_barrier.c
odp_barrier.c: In function ‘odp_barrier_wait’:
odp_barrier.c:42:9: warning: ‘wasless’ may be used uninitialized in
this function [-Wmaybe-uninitialized]
while ((barrier->bar < barrier->count) == wasless)
^
However the proper code seems to be generated in both cases (there is
a "pause" instruction inlined or a call to odp_spin). So odp_spin() is
not without side effects and is not optimized away. This contradicts
my hypothesis.
Consider this minimalistic example:
olli@macmini:~/hacking/gcc-wunit$ cat wunit.c
#include <stdlib.h>
void test(void)
{
int wasless;
int wasmore;
if (wasless) (void)0;
if (wasmore) abort();
}
olli@macmini:~/hacking/gcc-wunit$ gcc -O0 -Wall -c wunit.c
wunit.c: In function ‘test’:
wunit.c:9:5: warning: ‘wasmore’ is used uninitialized in this function
[-Wuninitialized]
if (wasmore) abort();
^
olli@macmini:~/hacking/gcc-wunit$ gcc -O2 -Wall -c wunit.c
wunit.c: In function ‘test’:
wunit.c:9:5: warning: ‘wasmore’ is used uninitialized in this function
[-Wuninitialized]
if (wasmore) abort();
^
Here GCC warns when used with both -O0 and -O2 but only for the usage
where there is a side effect. The use of 'wasless' that does not lead
to any side-effects is ignored (and possibly rightly so, I can imagine
this is undefined behavior, fortunately I did not attempt to run this
program or my computer could have melted).
It is a bit worrying to me that instances of use of initialized
variables is sometimes missed by GCC. Both because of lack of
diagnostics for what is most likely a bug but also because I don't
understand why GCC does this and the implications of that (at least it
is a known unknown now).
-- Ola
cbuild2/ABE benchmarking - TCWG-360 [1/10]
* Attempted to use LAVA for benchmarks
** Fell over on lack of TCWG machines in same network
libm exercising - TCWG-558 [6/10]
* Much fiddling with chroots
* Some fiddling with benchfft
* Little actual progress
Meetings/mail/etc - [3/10]
=Plan=
libm exercising
* Run benchfft in chroots
* Investigate Graph500
* Validate existing results with consistent methodology
** Hopefully this is reaching the point of handle-turning
ABE benchmarking
* Port 'cbuild2' benchmarking to ABE repository
* Test ABE benchmarking in TCWG lab (and LAVA?)
* Test repeatability (assuming the above go well)
* Get storage/automation started, if Rob has time
Holiday *next* week (Tuesday and Wednesday, perhaps Monday as well)
== Progress ==
* Building an ILP32 toolchain for AArch64 (4/10, TCWG-559)
- Applied a few simple ILP32 patches to glibc
- Rebasing and reworking existing ILP32 glibc patches
* LLD for ARM and AArch64 (5/10)
- Submit first set of reloc cleanups for LLVM
* Email, meetings, etc. (1/10)
== Issues ==
* None
== Plan ==
* Submit more ILP32 patches for glibc
* Further LLVM/LLD changes
--
Will Newton
Toolchain Working Group, Linaro
The Linaro Toolchain and Platform Working Groups are pleased to
announce the 2013.07 release of the Linaro Toolchain Binaries, a
pre-built version of Linaro GCC and Linaro GDB that runs on generic
Linux or Windows and targets the glibc Linaro Evaluation Build.
Uses include:
* Cross compiling ARM applications from your laptop
* Remote debugging
* Build the Linux kernel for your board
What's included:
* Linaro GCC 4.8 2013.07-1
* Linaro Newlib 2.0 2013.06
* Linaro Binutils 2.23 2013.06
* Linaro Eglibc 2.17-2013.07-2
* Linaro GDB 7.6 2013.05
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link
your programs against.
Interesting changes include:
* The sysroot is based on Linaro versions of Eglibc. About details of
Linaro Eglibc, please refer
https://releases.linaro.org/13.07/components/toolchain/eglibc-linaro.
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian
6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation
5.7 and later, and should run on any Linux Standard Base 3.0
compatible distribution. Please see the README about running on x86_64
hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://launchpad.net/linaro-toolchain-binaries/trunk/2013.07
Need help? Ask a question on https://ask.linaro.org/
Already on Launchpad? Submit a bug at
https://bugs.launchpad.net/linaro-toolchain-binaries
On IRC? See us on #linaro on Freenode.
Other ways that you can contact us or get involved are listed at
https://wiki.linaro.org/GettingInvolved.
Know issues:
* Some version information in README are incorrect.
* gdb can not backtrace into libc.
Notes:
* To use all of the features of Linaro eglibc, the sysroot in 32-bit
toolchain release is updated to Linaro eglibc, which is 2.17. If you
get runtime errors about libc version, please get the sysroot from the
release tarball
(gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/arm-linux-gnueabihf/libc/)
or download from launchpad
https://launchpad.net/linaro-toolchain-binaries/support/01/+download/linaro…
If you do not want to use Linaro sysroot, you'd add option to gcc to
find your sysroot:
--sysroot=<directory>
* To run 32-bit application built from arm-linux-gnueabihf toolchain
in aarch64 system, you'd copy sysroot and runtime from release package
to your root of aarch64 system. i,e.
scp -r gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/arm-linux-gnueabihf/libc/*
AARCH64-SYSTEM:/
scp -r gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_runtime/* AARCH64-SYSTEM:/