The Linaro Toolchain Working Group (TCWG) is pleased to announce the 2014.12
release of the Linaro GCC 4.9 source package.
Linaro GCC 4.9 2014.12 is the ninth Linaro GCC source package release. It is
based on FSF GCC 4.9.3-pre+svn218412 and includes performance improvements and
bug fixes.
With the imminent release of ARMv8 hardware and the recent release of the
GCC 4.9 compiler the Linaro TCWG will be focusing on stabilization and
performance of the compiler as the FSF GCC compiler. The Linaro TCWG provides
stable[1] quarterly releases and monthly enginering[2] releases.
Interesting changes in this GCC source package release include
* Updates to GCC 4.9.3-pre+svn218412
* Backport of [AArch64] arm_neon.h - add vpaddd_f64, vpaddd_s64,
vpaddd_u64 intrinsics
* Backport of [AArch64] Move some code around in aarch64_expand_mov_immediate
* Backport of [AArch64] Improve codegen of vector compares inc. tst instruction
* Backport of [AArch64] Remove vector compare/tst __builtins
* Backport of [AArch64] Add execution tests of vget_low and vget_high
* Backport of [AArch64] Replace temporary inline assembler for vget_high
* Backport of [AArch64] PR 61749: Do not ICE in lane intrinsics when
passed non-constant lane number
* Backport of [AArch32] Disable xordi3-opt.c/iordi3-opt.c on thumb1 target
* Backport of [AArch64] Fix scan-assembler test false alarm on aarch64-linux-gnu
* Backport of [AArch64] Add test of vld[234]q? intrinsic
* Backport of [AArch64] Extend test of vld1+vst1 intrinsics to cover
more variants
* Backport of [AArch64] Add a test of vldN_dup intrinsics
* Backport of [AArch64] Add a test of the vldN_lane intrinsic
* Backport of [AArch64] Add a test of the vst[234](q?) intrinics
* Backport of [AArch64] Add execution test of vset(q?)_lane intrinsics.
* Backport of [AArch64] Add cost handling of CALLER_SAVE_REGS and POINTER_REGS
* Backport of [AArch64] Fix cost for Q register moves
* Backport of [AArch64] Add regmove_costs for Cortex-A57 and A53
* Backport of [AArch64] Add aarch64 to list of targets that support gold
* Backport of [testsuite] whole_vector_shift
* Backport of [testsuite] vect-reduc-or
* Backport of [testsuite] Fix race in libstdc++ testsuite
* Backport of [testsuite] update testcases for GNU11
* Backport of [testsuite] fix gcc-dg-prune glitch when filtering
"relocation truncation" error
* Backport of [testsuite] Update testcases for GNU11
* Backport of [testsuite] fix wrap_compile_flags
* Backport of Increase PARAM_MAX_COMPLETELY_PEELED_INSNS when branch is costly
* Backport of Add -mthunderx option
* Backport of Accept cortex-m7/fpv5-sp-16/fpv5-d16
* Backport of Remove unused variable and marco
* Backport of Target Legitimize Address
* Backport of Hookize and remove *_BY_PIECES_P
* Backport of Remove no-longer-needed fp-bit target macros.
* Backport of Fix CLZ_DEFINED_VALUE_AT_ZERO for vector modes
* Backport of ifcvt: Allow CC mode if HAVE_cbranchcc4
* Backport of Fix predicate and constraint mismatch in logical atomic operations
* Backport of Migrate to new reduc_plus_scal_optab
* Backport of Migrate to new reduc_[us](min|max)_scal_optab
* Backport of Change CORE_REGS in GENERAL_REGS
* Backport of Fix IRA ICE tmpdir-gcc-.dg-struct-layout-1/t028
* Backport of Fix IRA ICE tmpdir-gcc-.dg-struct-layout-1/t028 -addon
* Backport of PR target/63937 fix 216996
* Backport of PR rtl-optimization/63210 IRA
* Backport of PR 63173 fix vldX_dup
* Backport of PR 63442 libgcc_cmp_return_mode not always return word_mode
Feedback and Support
Subscribe to the important Linaro mailing lists and join our IRC channels to
stay on top of Linaro development.
** Linaro Toolchain Development "mailing list":
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
** Linaro Toolchain IRC channel on irc.freenode.net at @#linaro-tcwg@
* Bug reports should be filed in bugzilla against GCC product:
http://bugs.linaro.org/enter_bug.cgi?product=GCC
* Questions? "ask Linaro":
http://ask.linaro.org/.
* Interested in commercial support? inquire at "Linaro support":mailto:
support(a)linaro.org
[1] Stable source package releases are defined as releases where the full Linaro
Toolchain validation plan is executed.
[2] Engineering source package releases are defined as releases where the
compiler is only put through unit-testing and full validation is not
performed.
Folks,
Me and Nick have been back and forth with the IFC6410, using Linaro's
utopic Ubuntu + 3.17 kernel, and I can now declare it stable enough to
run toolchain tests, maybe not yet builds.
The reason is that the kernel, although stable, is only just because
it throttles speed to a minimum. So, the core runs at 920MHz and the
memory bus is at its minimum frequency. Nick gathers we could speed it
up by a factor of 30% and 40% respectively while remaining on the
safety zone.
However, that would still be not enough. Currently, the boards build
LLVM in 7hs, when a Panda does it in 5h, a Chromebook does in 3.5hs
and a Chrome2 in 2hs. Improving it by 85% would get us just under 4hs,
which is still worse than a Chromebook. If we increase the CPU clock
to 1.5GHz per core, we may get it fast enough (but still slower than
the Chrome2), to be useful.
Their form-factor are better for rack-usage (remote serial, remote
reboot, small footprint), so even being slower than Chrome 2s, they'll
be faster than Chrome 1s and much more rack-friendly. That, of course,
assuming they remain stable at 1.5GHz. Heating will be an issue, but
we now have a decent server room and we can buy rack-mounted fans for
them, if we need it.
In a nutshell, I won't give up on them just yet, but I won't speed up
replacing the other boards with them either. We may have to wait a few
more releases to be sure, but I'm not expecting anything going in
production before February.
cheers,
--renato
PS: Nick, if you want to increase the clock speeds now just to see
what happens, I'm game.
Hi,
The latest toolchain on the following page appears to be broken.
http://www.linaro.org/projects/armv8/
Looking around one comes across the following path.
http://releases.linaro.org/latest/components/toolchain/.binaries
However the tarballs there yield: "You do not have permission to access this
file."
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
== Progress ==
QEMU kernel debugging setup [5/10] [TCWG-568]
-- Setup arm Linux kernel debugging to debug watchpoints
GDB with cygwin build/testing process [2/10]
-- Figured out GDB build and test procedure on cygwin.
Miscellaneous [3/10]
-- Meetings, Emails etc
-- Hong Kong visa application: re-submission of application.
== Plan ==
QEMU kernel debugging setup [TCWG-568]
-- Try to figure out kernel debugging help for ptrace debug
GDB with cygwin build/testing process
-- Document cygwin gdb work flow
-- Buid arm-remote gdb on cygwin
-- Identify gdb-remote issues on a cygwin host if any
== This week ==
* GCC modularization project
- Fixed df.h flattening patch to build on all targets in config-list.mk
- Flattening expr.h patch in progress.
== Next week ==
- complete expr.h patch
- Submit df.h flattening patch to gcc-patches for review
- Test cfgloop.h flattening patch on all targets with ISL enabledin
config-list.mk and submit to gcc-patches for review.
Holiday [6/10]
Misc [3/10]
* Mail backlog
* Moved all current AArch64 work off 'my' Juno, as ARM needed it back
* A little bit of a look at another possible memcpy performance issue
libm exercising - TCWG-558 [1/10]
* Reduced 'needless calls to pow' to a simple test case
** Found that this is actually an all-targets thing (at least AArch32,
AArch64, x86)
* Looked through benchfft output
** Looks like only one implementation calls libm much
** This is probably just bad code, but could do with a comparison run
on non-AArch64 to be sure
=Plan=
Switch to TCWG Junos
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
=Absences=
On holiday Monday 22nd Dec to Friday 2nd Jan
== 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
