== Progress ==
- 8th and 9th on holiday (4/10)
- Zero/sign extension elimination (TCWG-291) 3/10
* Patch one is accepted
* Posted the modified patch 2 after some discussions
* Started analysing the code generated for coremark and spec2k
* Looks there are more places that can be improved. I will post
additional patches after completing it
- Launchpad bugs (3/10)
* https://bugs.launchpad.net/gcc-linaro/+bug/1320965
* https://bugs.launchpad.net/gcc-linaro/+bug/1331112
== Plan ==
- sha1 regressions
- 15th and 16th on holiday
== Progress ==
* One day off.
* Test and send out the local NLS patch for community review (1/10).
* Test ccmp patches. Can not reproduce a FAIL in previous regression
test with the latest trunk(TCWG-488, 1/10).
* Test codes to skip arm_split_constant (TCWG-486, 3/10). Performance
results seam OK for spec2000, coremark dhystone and eembc.
* R/M toolchain related work (3/10).
== Plans ==
* Ping pending patches.
* Update ccmp patches.
== Planed leaves ==
* Jul. 15 - 25: Travel to Cambridge.
* Aug. 4 -8: Annual leaves.
== This week ==
Provide ldp/stp peephole optimization for Aarch64 [TCWG-446] [0/10]
- Halted development due to duplicate ARM development project by
Bin Cheng
Launchpad 1318831 - Invalid unpoisoning of stack redzones on ARM [3/10]
- Verifying test results
Launchpad 1267761 - miscompilation of unsigned comparison on aarch64 [2/10]
- Testing under way on Jenkins
Neon intrinsic tests [4/10]
- background work to gain familiarity with effort
Misc Meetings [1/10]
== Next week ==
- Verify testing on Launchpad 1267761 and 1318831
- Begin investigating compiler bugs discovered by neon intrinsic tests
== Future ==
== Progress ==
* GCC trunk cross-validation
- reported a few regressions
* Automation Framework (2/10)
- looked at Jenkins configuration & logs of some failures
* AArch64 libsanitizer (1/10)
- tried to use cbuild2 in the lab to build & test on HW, but all my
build attempts failed for various reasons
* Neon intrinsics tests (3/10)
- feedback from upstream requests some renaming changes + GNU coding
style fixes
- since reformating the existing testsuite is a manual and
error-prone task, it will bring additional delay in improving GCC
testsuite.
- it's probably more efficient to run the existing tests regularly
and start reporting & fixing the bugs identified, not waiting for the
full conversion
- updated the existing tests for fp16 and poly* types support with
GCC (reference built with armcc)
- interestingly, compiling the original testcases with armcc for
aarch64 caused ICE on 28 source files.
* Misc (meetings, conf-calls, ....) (4/10)
== Next ==
Holidays for 2 weeks
== Progress ==
* Monday holiday
* Automation Framework (CARD-1378 6/8)
- TCWG D01 moved in, Chromebooks out
- Movng LLVM buildbots to D01s
- D01s have no NEON support... :S
- We might have to move some Chromes back in
- Moving hackboxes to Chromebook 2s
* Background (2/8)
- Code review, meetings, discussions, etc.
== Plan ==
* Deal with NEON issue in the rack
* Finish Cauldron presentation
* Try to get the D01s as buildbots, even without NEON
== Progress ==
* AArch64 GDB reverse watchpoints issue. [TCWG-503] [4/10]
-- Found a new fix in generic process record implementation.
Testing stalled by too many 2500 failures seen on arm-linux-gdb in
general and some 850 record/replay implementation.
* AArch64 GDB handling of functions with empty prologue. [TCWG-504] [4/10]
-- Analysis of prologue generated by aarch64-gcc
-- Make an understanding of code implementation for arm-linux-gdb.
-- Try to reproduce reported bugs.
* Testing and Analysis of testsuite failures in arm-linux-gdb [TCWG-509] [1/10]
* Browsing gdb related upstream discussions. [1/10]
== Plan ==
* AArch64 GDB reverse watchpoints issue. [TCWG-503]
-- Test and submit fix for target record for the case where we cant
step breakpoints.
* Investigate issues in arm-linux-gdb testsuite results. [TCWG-509]
* Travel preparations to UK for Tools cauldron and TCWG sprint.
-- Obtain health certificate for international travelers.
* On Holiday from 14th to 17th July 2014.
=Progress=
memcpy regression on A9 - TCWG-390 [7/10]
* Tweaked bench.py some more
* Cobbled together a bare metal version of cortex-strings benchmark
* Was surprised to find that the problem does not relate to Linux
* Have some evidence that points at the branch predictor
Meetings/mail/etc [3/10]
=Plan=
See if A9 performance is recoverable without sacrificing other targets
Push some of my improvements into the cortex-strings repo
Possibly write up my cortex-strings-benchmarking-in-lava method
Back to cbuild benchmark automation
== Progress ==
Zero/sign extension elimination (TCWG-291) 10/10
- Patch updated based on review comments.
- Regression tested with standard set-up
- Created test-cases.
- Set-up additional architectures for validation
* aarch64-none-elf --with-abi=ilp32 (Foundation model)
* aarch64-none-linux-gnu --with-abi=ilp32 seems to be broken.
* Set-up qemu based s390x-ibm-linux
* Tried x86_64-linux -mx32 but ran into many issues.
- Patch now waiting for s390x-ibm-linux. All others are OK.
- will post once the results are available
== Plan ==.
- Spec2k regressions
- sha1 regressions
- 8th and 9th on holiday.
== This week ==
Provide ldp/stp peephole optimization for Aarch64 [TCWG-446] [6/10]
- Investigated options for improving ldp/stp pairing and developed
patch
- Testing underway
Launchpad 1267761 - miscompilation of unsigned comparison on aarch64 [1/10]
- Backported revision 206529 from trunk
- Testing under way on Jenkins
Launchpad 1296942 - marked fixed released based on backport by Yvan Roux
[1/10]
- July 4th holiday [2/10]
== Next week ==
Complete testing on Launchpad 1267761 and TCWG-446 and initiate code review
== Future ==
Travel to Cambridge on July 11th for Cauldron and TCWG Spring
Am 05.07.2014 17:36, schrieb Emilio Pozuelo Monfort:
> Control: reassign -1 gcc4.8,gcc4.9
>
> Hi,
>
> This is still a problem with GCC 4.9. Is there any progress on this? This is
> making aegisub FTBFS on armel, blocking the libass transition.
afaik, no. See also https://gcc.gnu.org/ml/gcc/2014-07/msg00000.html
== 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
== Week of June 23rd ==
- Continued working on toolchain testing improvements (CARD-1378, 6/10)
-- Various cleanups and improvements to cbuild2.
-- Troubleshooting of Jenkins stability problems.
-- Increasing test coverage for arm big-endian toolchains.
- Various meetings and discussions (3/10)
--
Maxim Kuvyrkov
www.linaro.org