== Progress ==
* IAS (TCWG-377)
- Abandoning softvfp implementation, we should not use it
- Both softvfp and dwarf flags went back to kernel/android
- Macro issue has been solved, IAS is now Gold!
- Still doesn't compile the kernel, though... ;)
- Discussions about inline assembly bailing on asm garbage
* AArch64 (TCWG-387)
- Trying to get the build working and passing tests
- Some worries about config.guess updates (license)
- Commented out some old JIT tests, they will never work
- Memory allocation failures look real bugs, though
- At least Five real bugs in test-suite
* Background
- Patch reviews
- Further discussions about Dwarf vs. EH unwind tables
- Discussing vectorizer pragmas with GCC list
- Reviewing EuroLLVM14 papers
- Helping Rob upgrade TCWG Chromebooks
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Take a look at Compiler-RT
* Check some of the AArch64 errors
* Maybe EH/unwind issues
* Connect
Hi,
I finally got around to checking the attached patch for the
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1270789
I noticed attached patch causes regression for pr38151.c in gcc test-suite.
A reduced test-case that triggers this is:
static unsigned long global_max_fast;
int __libc_mallopt (int param_number, int value)
{
__asm__ __volatile__ ("# %[_SDT_A2]" :: [_SDT_A2] "nor"
((global_max_fast)));
global_max_fast = 1;
}
In this regard I have couple of questions:
1. Is the in-line asm valid? Look ok to me.
2. For the pr38151.c regression, asm diff is as shown below.
< add x0, x0, :lo12:.LANCHOR0
< ldr x0, [x0]
---
> ldr x0, [x0,#:lo12:.LANCHOR0]
This causes:
pr38151.c:(.text+0x10c): relocation truncated to fit:
R_AARCH64_LDST64_ABS_LO12_NC against `.rodata'
collect2: error: ld returned 1 exit status.
If I however increase the alignment of .rodata where .LANCHOR0 is
defined, this passes. Is alignment of BITS_PER_UNIT valid for
SYMBOL_REF? If I change it as I am doing this attached patch, is there
anything else I need to do.
Thanks,
Kugan
Hi Linaro'ites
We have upgraded eglibc to 2.19 in OpenEmbedded and I started to notice
WARNING: No recipes available for:
/home/kraj/angstrom/sources/meta-linaro/meta-linaro-toolchain/recipes-core/eglibc/eglibc_2.18.bbappend
NOTE: Resolving any missing task queue dependencies
And it seems in this bbappend the SRC_URIs are overridden to point to a Linaro
release of eglibc
I wanted to know if there is a 2.19 head for linaro eglibc being created ?
in that case that bbappend needs fixing too.
Thanks
-Khem
Ganesh,
Thank you for your email - please note this question is best directed
at linaro-toolchain(a)lists.linaro.org where it is more likely to get
picked up quickly.
Our general rules for benchmarking are to use -mcpu=cortex-a## -O3 as
the compiler flags (where ## is the particular CPU you are interested
in).
Linaro's philosophy is to try and get the best results possible that
normal users will see, we don't go looking for 'magic' options that
may give better performance on one benchmark, but not in general.
Thanks,
Matt
On 20 February 2014 09:22, Gopalasubramanian, Ganesh
<Ganesh.Gopalasubramanian(a)amd.com> wrote:
> Hi,
>
> We would like to run some benchmarks in the foundation model.
> I like to know which is the best option-set (GCC compiler options) that the linaro community recommends for aarch64.
>
> Regards
> Ganesh
>
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
== Progress ==
- vectorizer (7/10)
- Looked into vectorizer target-hooks
- enablement of half-float for vectorising; dropped the patch after
discussing
- Started analysing code generated with unlimited model
- gcc 4.8 regression (1/10)
- Built Novemnebr and December release (native with system libc)
- Ran spec2k fp. Can see regression for ammp with -O3 (with
-march=armv7-a and -mthumb)
-Started bisecting
- Chromebook reset-up (2/10)
- SD card died and setup again
- Using hdd for gcc testing
== Plan ==
- Check ARMv5 regression for unaligned access
- Look into vectorizer cost model/benchmarking
Richard,
I found some emails about you implementing softvfp back in 2003, and
I'd like to know what is the expected behaviour when it conflicts with
the target triple, for example:
-triple arm-linux-gnueabihf + -mfpu=sofvfp+vfp
In this case, in LLVM, the triple sets "-float-abi=hard" but the fpu
would set "+soft-float-abi", which are contradictory flags.
Is that case even possible? If so, what's the expected behaviour? Soft
or hard float?
Do the extra flags always override the triple behaviour? Is it
expected that *every* compiler flag will work on a
last-seen-sets-behaviour manner?
cheers,
--renato
== Week of February 10th ==
- Reproduced STREAM performance regression. Started investigation. (3/10)
- Setup development environment on HP Chromebook 11. (3/10)
-- Chrome OS + crouton + ubuntu 12.04 + ppa/chromebook-arm -- produced a nice dev board environment.
- Continued account setup and preparations for Connect. (2/10)
- Misc. (2/10)
-- Various meetings.
-- Volunteered as admin for GCC's GSoC 2014. Filled in the application, started to stir up buzz in the GCC community.
== Week of February 17th ==
- Continue investigation of STREAM performance regression.
- Prepare FSF GCC 4.10 presentation for Connect.
- Look more into how LAVA does things and how to customize rootfs'es for boards.
-- In particular I'm interested in how to boot rootfs with matching kernel and linux-tools (perf is what I need) with ssh server on keystone board.
--
Maxim Kuvyrkov
www.linaro.org
== Progress ==
* Updated, tested and re-submitted patch for arm native
watchpoint/hwbreak rework. [2/10]
* Updated, split-up and tested patches for process record ASIMD, VFP
etc support. [TCWG-251] [TCWG-252] [3/10]
* Tried setting up gdb for aarch64, no luck yet. [TCWG-389] [1/10]
* Investigation of work required for catchpoints support for remote
gdb and gdbserver. [TCWG-263] [2/10]
* Study armv8 instruction set for record replay support. [TCWG-389] [2/10]
== Plan ==
* Follow up on upstream patches.
* Study aarch64 code and create task breakdown for record/replay
support. [TCWG-389]
* Setup gdb for aarch64 and try to run a demo application. [TCWG-389]
* Write how-to for using scripts to compare two gdb testsuite runs. [TCWG-96]
* Out of office on Tuesday and Wednesday for follow up on Macau visa
application.
== Issues ==
* none
== Progress ==
* 4.8 2014.02 Engineering release. (3/10)
* TCWG-58 : AArch64: Enable libsanitizer (2/10)
o re-based christophe's patch on fresh LLVM sources.
o committed in LLVM (Thanks Renato for your help)
o Progress stopped on this card until 4.10 GCC is opened
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (0/10)
- No progress this week on my side.
- Vladimir upstreamed a fix for Thumb code size regression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59535
o TCWG-345 : Analyse performance of LRA for ARM. (1/10)
- re-run Spec2K on Cortex-a15.
* Misc:
o LCA'14 : AArch64 toolchain status session. (1/10)
o Support Christian Bruel in his Linaro ramp up. (1/10)
o Various meetings. (2/10)
== Next ==
* Continue the on-going tasks
* backports review
