Juno cache effects - LDTS-1238 [6/10]
* Ran more experiments
* Cobbled together some gdb/python script to run perf stat within an
address range
* Becoming more confident in my hypotheses
catomics - TCWG-436 [1/10]
* Found and fixed some more sysroot benchmark bugs
* Kicked off a bunch of spec runs, waiting for the results to come back
Benchmark automation - TCWG-360 [1/10]
* A couple of post-lab-maintenance fixups
* Took a first look at result consistency with a broken run intended
for catomics
Misc - [2/10]
* Featuring the start of fixing juno-01
=Plan=
Finish fixing juno-01
Carry on looking at LDTS-1238, hopeful of confirming hypotheses
Analyse catomics results (assuming that they land)
Carry on with Jenkins, if time
== Issue ==
* none
== Progress ==
* Linaro Bugzilla: (5/10)
- #1149: 4.9-2015.01 miscompiles GCC trunk on aarch64-linux-gnu
* Backported upstream bug fix in 2015.01 re-spin branch and our 4.9 one.
- #1291: [4.9 Regression] ICE (segmentation fault) on arm-linux-gnueabihf
* Identified a set of upstream revision that fixe the issue
* Backported them in 2015.01 re-spin branch and our 4.9 one.
- #1314: [4.9 Regression] ICE (in in expand_expr_addr_expr_1, at expr.c:7634)
on arm-linux-gnueabihf
* Identified that it's a duplicate of an upstream bug on 4.9
branch (PR 61207)
which is itself a duplicate of an already fixed bug on trunk (PR 64896)
* Tested backport of the fix on on 4.9 branch.
* Release and Backports (4/10)
- Re-spin 2015.01 source release with fixes for Linaro bugs: #1149 and #1291
- Various supports of backporting activity
- Reviewed some backports
- Discussed our new release/maintenance policy
- Worked on Backflip improvements
* Misc (1/10)
- Various meetings
== Plan ==
* Backport PR 64896 fix into FSF 4.9 branch
* Backport/FSF Merge/Release duty
== Progress ==
Benchmarking 2015.02 [2/10]
. it turns out to be difficult to build previous releases with abe.sh
(bz#776, bz#1307)
. submitted patch to gerrit to improve abe.sh error handling
. benchmarks started on Jenkins
Backports [4/10]
. investigating incorrect merge discovered in review
. resolved... then found more conflicts with other backports
. need to redo backports
bug #1254 [1/10]
. reduced
. started investigating
misc [1/10]
. mailing lists
. meetings
== Plan ==
redo backports of 217440, 217885
start backports of 218021, 218534
bug#1254
vectorization investigation
look at benchmarking results from Jenkins
# Progress #
* aarch64 gdb , TCWG-652, [6/10]
** TCWG-662: Fixed and committed (by Pedro).
** TCWG-660: Rebuild toolchain with ABE.
** TCWG-663: Root cause of fails are known, that test case sets HW
breakpoint on arbitrary address while aarch64 HW breakpoint requires
4-byte align. ARM has the similar HW breakpoint feature, need to
to check on arm target too.
* fsf gdb patch review [2/10]
** Review and approve one patch from IBM which fixes TCWG-669 too.
** Discuss on re-org for syscall catchpoint for different target/arch.
* misc [2/10]
** Meeting.
** Move to the new house.
# Issues #
* Need an ARM board with HW breakpoint support in kernel. I tried
32-bit system on my juno board via schroot, but
PTRACE_SETHBPREGS doesn't work properly.
# Plan #
* TCWG-660: Teach ABE to import systemtap and build glibc with
--enable-systemtap.
* TCWG-663: See how the tests behave on ARM if ARM board is available.
* Other cards under TCWG-652.
--
Yao
== Progress ==
* Validation: (2/10)
- reached a state where Jenkins "green" actually means no regression found
- submitted patches for review
- confirmed that ABE master branch produces results similar to merge branch
- stopped checking the accuracy of report.sh since a few bugzilla
had been submitted, using ST script instead
* Backports (3/10)
- reviews are getting difficult, with lots of conflicts as the 4.9
branch has diverged from trunk quite a lot
* Sanitizers (1/10)
- trying to build LLVM+run the ASAN tests on AArch32
- tried to reconfigure my Hikey 96board with a 42 VA bits enabled
kernel, but it didn't boot: I still don't have access to such a
platform
* GCC FSF trunk/4.9 monitoring
- stopped tracking random "Interrupted system call"
- builds and validations now run faster, but with more frequent such errors
* Misc (4/10)
- meetings, conf-calls, emails, ...
- Release/maintenance branches policy, respin criteria, validation matrix
== Next ==
* Backports: reviews, and improve review-tool
* Sanitizers
Hi,
I have being trying to persuade gcc to generate the ldp instruction without success. I have tried many combinations, below is an example.
--- cut here ---
#define LDP(x,y,p) { \
struct vec { long x, y; } data; \
data = *(struct vec *)p; p += 2; \
x = data.x; y = data.y; \
}
long testp(long *p) {
long x, y;
LDP(x, y, p);
return x+y;
}
--- cut here ---
$ gcc --version
gcc (GCC) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc -S -O3 ldp.c
$ cat ldp.s
.cpu generic+fp+simd
.file "ldp.c"
.text
.align 2
.global testp
.type testp, %function
testp:
ldr x1, [x0,8] ;; why not ldp?????
ldr x0, [x0]
add x0, x1, x0
ret
.size testp, .-testp
.ident "GCC: (GNU) 4.9.1"
What can I do do make it generate ldp?
Ed.
== Progress ==
Bug triage [2/10]
Bug 1199 analysis [4/10]
reproduced, studied IRA dumps for a while, will have to report this upstream
Backports + BackFLiP enhancement [3/10]
Misc [1/10]
meetings, git training presentation, mailing lists
== Plans ==
benchmark 2015.02 release
more bugs
== Progress ==
LLDB development
-- Some code sniffing and created JIRA cards with some task estimation [2/10]
-- Trying AArch64 cross build and update howto [1/10]
-- Trying Arm cross build and update howto [2/10]
GDB patch updates and test cases for ARM record-replay instruction
recording [4/10]
Miscellaneous [1/10]
-- 96board with custom kernel no success with getting ethernet
working on it yet
== Plan ==
Wind up all pending gdb patches
