== Progress ==
* GCC trunk/4.9 monitoring (1/10)
- still tracking cause of random "interrupted system call" errors
- flagged a few wrong new Neon testcases
* AArch64 sanitizers (1/10)
- documented build process (based on configure) works on aarch64,
but still unable to run the sanitizer tests
- using supposedly up-to-date but undocumented build process (cmake)
fails when configuring sanitizers libs
- started discussion with upstream, no progress yet
* Neon intrinsics tests (3/10)
- continued conversion to GCC testsuite
- checks for Neon QC flags need fixing
* Misc (5/10)
-meetings, conf-calls, emails, ....
== Next ==
* GCC trunk/4.9 monitoring
* AArch64 sanitizers
* Neon intrinsics tests
* cbuild2/abe: look at backport and tcwgweb
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
