== Progress ==
* Toolchain (CARD-862 2/9)
- Investigating LLD, MCLinker
* Automation Framework (CARD-1378 4/9)
- Lots of validation and lab meetings
- Planning and designing a new rack:
- Replace all chromebooks with D01s
* Background (3/9)
- Code review, meetings, discussions, etc.
- A bit more on Cauldron's presentation
- Revamping LLVM plan, TCWG mission, Validation docs
* Some illness...
== Plan ==
More rack stuff... Monday holiday.
== Progress ==
* Patch review, testing and follow-up (3/10, CARD-341)
- glibc 2.20 freeze still not announced
- submit more warning fix patches
- reviewed series of gdb thumb prologue patches
* Get postgresql malloc benchmark using unix domain sockets (2/10, TCWG-441)
* Built releases of eglibc and binutils for 2014.07 (3/10)
* Started looking at moving binutils and gdb bugs in launchpad to
bugzilla (1/10)
* Other small things (1/10)
- Investigated a couple of other small issues for various people
- Meetings
== Issues ==
* None
== Plan ==
* Clear up more old bugs and move to bugzilla/JIRA/upstream
* malloc benchmarking
* glibc patches
--
Will Newton
Toolchain Working Group, Linaro
The Linaro Toolchain Working Group is pleased to announce the 2014.06
release of Linaro GCC 4.7.
As announced at Linaro Connect USA 2013 Linaro GCC moved to a pattern
of quarterly stable releases, with engineering releases in the
intervening months. This is the third stable release, and contains no
known regressions compared to the 2014.04 release.
Linaro GCC 4.7 2014.06 is the twenty forth release in the 4.7 series.
Based off the latest GCC 4.7.5+svn211571 release, this is the eleventh
release after entering maintenance and the final one.
Interesting changes include:
* Updates to GCC 4.7.4+svn211571
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 Launchpad against "Linaro GCC
project":http://bugs.launchpad.net/gcc-linaro/+filebug.
* Questions? "ask Linaro":http://ask.linaro.org/.
* Interested in commercial support? inquire at "Linaro
support":mailto:support@linaro.org
== Progress ==
* AArch64 GDB reverse watchpoints issues. [TCWG-503] [6/10]
-- Proposed a fix which failed testing now working on an alternate
fix in gdb process record target implementation.
* Further progress on AArch64 GDB handling of functions with empty
prologue. [TCWG-504] [2/10]
-- Analysed different type of obj files and how they are being handled by gdb.
* Investigate and improve ARM gdb frame unwinding [TCWG-157] [1/10]
-- Try to reproduce reported bugs.
* Miscellaneous [1/10]
-- Setting up gdb remote testing with hackboxes.
-- Meetings etc.
== Plan ==
* AArch64 GDB reverse watchpoints issue. [TCWG-503]
-- Figure out a new fix in gdb process record implementation, test
it and then justify it.
* AArch64 GDB handling of functions with empty prologue. [TCWG-504]
-- Further investigation.
=Progress=
memset performance improvement - TCWG-156 [2/10]
* Bugfixed/improved cortex-strings-bench-on-lava
memcpy regression on A9 - TCWG-390 [6/10]
* Scanned through lots of data
* Learned some perf and some streamline
* Still don't know what's going on here
lowlevellock performance bugs - TCWG-435 [0/10]
* Stalled until someone reacts to my pings
Meetings/mail/etc [2/10]
* Including some questions about whether we need softfloat support in
binary releases
=Plan=
Keep prodding at memcpy with perf/streamline
Explore repeatability of cortex-strings benchmark
See how much quicker I can make cortex-strings benchmark without
compromising repeatability
Possibly try out a bare metal version of (a subset of) cortex-strings benchmark
* Analysis of PR61411 (CARD-341) [2/10]
* Attempted to analyse VP8 decode performance on Aarch64 vs Aarch32
(TCWG-?) [6/10]
. took a while to find compatible libvpx source and compilers :(
. can't find a good way to profile on Aarch64, perf is broken, gprof
results look implausible
* Misc [2/10]
== Issues ==
* None
== Progress ==
* Take care Linaro binaries release (1/10).
* Send out ccmp patches for community review (TCWG-488, 1/10).
* loop2_invariants heuristics tune (1/10, TCWG-469). One patch was
committed @r212135.
* Constant optimization (TCWG-486, 7/10 )
- Try to keep constant in register when expanding. But benchmark
results show regression due to combine behavior changes.
- Try to keep unsigned constant when expanding. For crc |= 0x8000,
crc is unsigned short. If 0x8000 is represented as unsigned value, no
need to split 0x8000. But in middle-end, wide_int_storage::set_len and
trunc_int_for_mode always do sign extension. "trunc_int_for_mode
(INTVAL (op), mode) == INTVAL (op)" is always checked when checking
operand (e.g. in general_operand of recog.c). And in RTL, there is no
"unsigned" information at all.
== Plans ==
* Update ccmp patches according to comments.
* Continue on constant optimization.
* Ping pending patches.
== Progress ==
* Zero/sign extension elimination (TCWG-15) (10/10)
- Posted two patches for review and gone through few iterations
- Looked at flag_wrapv and !flag_strict_overflow regressions
* ARM (and possibly some other targets) truncates negative values and
this makes them incompatible with the value range in SSA. One solution
is to ignore any gimple statements that load negative constants when
eliminating zero/sign extension elimination.
* We also loose the OVF(INF) information in tree when they are
converted to wide_int and propagated to SSA.
- Testing on a target that support PTR_EXTEND
* Trying to set-up x86_64-linux with -mx32. Still not able to compile
as I am getting various errors in glibc. Looking into it,
== Plan ==
* Upstream zero/sign extension elimination activities
