== Progress ==
- Travelling from TCWG sprint (2/10)
- Zero/sign extension elimination (TCWG-291) 2/10
* Posted the modified patch and some discussions. Further testing.
-SHA1 regression (TCWG-468) 4/10
* Looked at IRA's uses of back end cost model. It might be a
limitation (See the notes below). Looking at the test-case from sha1
which also has inline asm whose constraints are causing further issues.
- Misc (2/10)
* Looked at bugs assigned (https://bugs.linaro.org/show_bug.cgi?id=85)
* Set-up LLVM
== Plan ==
- Sha1 regressions
- Fixing assigned Bugs
---------------------------------------------------------------------
In AArch64, some of the integer operations support “w” constraint
(FP_REGS). For example *addsi3_aarch64 pattern supports it. However, not
all of the integer operations supports it. In the cases where it is
supported, all the operands have to be in FP_REGS and it will not work
if we have one operand in FP_REGS and other in GENERAL_REGS.
If there is an allocno whose pseudo register is used only in
*addsi3_aarch64 insns, it will have low cost for register class FP_REGS
(as in the case of a28 below exacted from an example). If the other
pseudo register used in *addsi3_aarch64 (a27 in the example below) is
also used in instructions (rorsi3_insn in the exaple below) that does
not support “w” constraint, there is going to be a cost involved in
moving it from FP_REGS to GENERAL_REGS (or other way)
Currently IRA dosent seems to be considering this dependency in
considering this inter dependency in cost calculation.
=Progress=
cbuild2 benchmarking - TCWG-360 [7/10]
* Integrated benchmarking more into the core of cbuild2
* 'Audited' the benchmarks lying around on toolchain64
* Persuaded cbuild2 to use git-over-ssh
Meetings/mail/etc [3/10]
=Plan=
cbuild2 benchmarking
* Convert eembc integration into reviewable patches
* Get cross-compilation working
* Get remote targets working
== This week ==
* Neon intrinsic testing (4/10)
- Patched sources with Christophe's patches
- Ran Neon intrinsic tests for vclz and vqadd
- Investigating regressions
* On leave Monday and Tuesday; out sick Wednesday (6/10)
== Next week ==
* Continued Neon intrinsic testing
== Issues ==
* None.
== Progress ==
* Rework the patch to fix pr61225 in Combine pass. (4/10)
* Investigate code-size regression when skipping arm_split_constant in
expand (TCWG-486, 4/10).
- For reg & 0xffff, zero_extendhi instruction is more efficient.
- For "PLUS", the define_insn_and_split "*arm_addsi3" is only
available when "reload_completed || !arm_eliminable_register
(operands[1])". The cprop and combine passes can not recover it back
when there is no chance to optimize the constant.
* R/M toolchain related work (2/10).
== Plans ==
* Send out the patches for review.
* Refine ccmp related patches.
== Planed leaves ==
* Aug. 18 - 22.
== Progress ==
* Toolchain (CARD-862 2/10)
- Helping debug some sanitizer work
- Re-evaluating compiler-rt on ARM with CMake
* LLVM 3.5 Release (TCWG-476 2/10)
- Working on SPEC to run with LLVM
* Background (6/10)
- Code review, meetings, discussions, patches, etc.
- Email and patch backlog due to Cauldron and sprint
- Investigating and fixing buildbot/build failures
== Plan ==
* Finish SPEC-LLVM integration, run against 3.5 vs. 3.4.2
* Test Release Candidate 2, when it comes
* Back to compiler-rt work...
== Progress ==
* Various small tasks (3/10)
- Catching up on email
- Bug report investigations
- Expenses from Cauldron/Sprint
- Pushing patches
- Tidy some JIRA cards
* Investigated gdb testsuite failures on Chromebook (2/10)
- Looks like a kernel issue, need to try a newer kernel on Chromebook
* Investigated state of ARM and AArch64 glibc testsuites for 2.20 release (2/10)
- Results look ok but a couple of things need investigation at some point
* Triaged bugzilla bugs (1/10)
* Built releases of binutils, eglibc and gdb for 2014.08 (2/10)
== Issues ==
* None
== Plan ==
* Get a newer kernel booting on Chromebook
* Look at improving src-release for xz tarballs
* Figure out what to do with glibc testsuite failures on AArch64
--
Will Newton
Toolchain Working Group, Linaro
Hi guy,
In order to have soft-float support in toolchain, I tried to build our toolchain using Linaro ct-ng script.
I used "linaro-armeb-linux-gnueabihf" configuration then change floating point option from hard to soft.
There is the error I have:
[ERROR] /projects/broadcom-linux/joelz/r/linaro-gcc-build/.build/armeb-linux-gnueabi/build/gcc-core-shared/lib/gcc/armeb-linux-gnueabi/4.8.3/../../../../armeb-linux-gnueabi/bin/ld: error: /projects/broadcom-linux/joelz/r/linaro-gcc-build/.build/armeb-linux-gnueabi/build/gcc-core-shared/lib/gcc/armeb-linux-gnueabi/4.8.3/libgcc.a(bpabi.o) uses VFP register arguments, /projects/broadcom-linux/joelz/r/linaro-gcc-build/.build/armeb-linux-gnueabi/build/build-libc/elf/librtld.map.o does not
For short, libgcc.a(bpabi.o) uses VFP register arguments, but librtld.map.o does not.
The C library used is eglibc version (Linaro 2.19-2014.04), is this a way to make eglibc work with sfot-float?
Thanks!
Joel
I was using arm-eabi builds on Linaro Android 4.9 toolchain 2014.06.
I've just downloaded 2014.07 and found out there is not an arm-eabi
toolchain.
I need arm-eabi to build Linux kernels and arm-none-eabi toolchain from
here:
http://releases.linaro.org/14.07/components/toolchain/binaries/gcc-linaro-a…
is not capable of building LTO kernels.
Error pops up : "cc1: error: -fno-fat-lto-objects are supported only with
linker plugin"
TL;DR, I need arm-eabi builds from Linaro Android toolchains.
arm-none-eabi builds are not built with linker plugin enabled.
