== Progress ==
- Integrate benchmarking into Cbuildv2 (TCWG-360 7/10)
- Implementation mostly complete
- Started testing to ensure compatible with cbuild1
- Code available for comments at
https://git.linaro.org/toolchain/cbuild2.git/shortlog/refs/heads/benchmarki…
- Binutils Bug 16340 (1/10)
- Posted the patch after regression testing and analysing the results
- Mics (2/10)
- Read relocation handling of tls and its implementation for aarch64
== Plan ==
- Complete Integrate benchmarking into Cbuildv2
- Address comments for Binutils Bug 16340 and look to come up with a
simple testcase
== Progress ==
* Android LLVM
- Discussions on progress, trying to line up kernel+AOSP together
- Google has bailed Clang/LLVM for L release, will consider for next one
* Vectorizer
- Progressing on the implementation of the pragma parser
- http://llvm.org/PR18086
- Discussions about introduction of generic function vectorizer (ARM)
* Release 3.4
- Tested RC3, no regressions on tests or benchmarks
- http://people.linaro.org/~rengolin/llvm/
- http://llvm.org/pre-releases/3.4/rc3/
- Looked at a bug on the vectorizer for pentium3/freebsd
- Work around found, not easy enough to get them to RC4
* Background
- Many discussions, many support requests, many patch reviews
- Adding BOF notes to dev meeting site
- Booking train and hotel for FOSDEM 14
* Time
- CARD-862 8/10
- Others 2/10
* Happy Holidays! And see you in January!
== Issues ==
* Running benchmarks on my Chromebook is very unstable.
- Even though the standard deviation is small in two different moments,
the two results are statistically incompatible.
- The wireless network on the Chromebook, as widely known,
is unstable and unpredictable.
- I need a graphical interface, so I can do stuff during Connects,
or to see Phoronix results and that is probably the responsible
for all instability
- Next release, I'll use an ODroid (or Arndale) for benchmarks
== Plan ==
* Holidays!
== Progress ==
- 2013.12 releases (4/10)
* Handover to Michael
* Committed remaining backports/branch merges
* Unexpected regression in 4.7 branch narrowed to a linker bug, now fixed.
- cross validations (2/10)
* stabilized armeb+qemu validations
- misc (4/10): misc conf-calls and meetings; internal meetings
== Next ==
Next 2 weeks off (Dec 23rd Jan 3rd)
Merry Christmas and happy new year to all of you.
Hello,
I am using the pre-built toolchain gcc-arm-none-eabi-4_6-2012q2 from linaro
to compile u-boot (u-boot-linaro-stable) and to compile my standalone
applications to run on target(PandaBoard ES rev b2)
hello_world standalone application which comes with u-boot is executing
fine on target when I disable CONFIG_SYS_THUMB_BUILD, but when I enable it,
target gets reset with following information
Panda # go 82000000 hello
## Starting application at 0x82000000 ...
undefined instruction
pc : [<8200000c>] lr : [<bff83147>]
sp : bfeffe40 ip : bfeffc10 fp : 00000000
r10: 00000003 r9 : bffac954 r8 : bfefff68
r7 : bff01d88 r6 : 82000000 r5 : bff01d8c r4 : 00000003
r3 : 82000000 r2 : bff01d8c r1 : bff01d8c r0 : 00000002
Flags: nzCv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot SPL 2013.01.-rc1-g0f45941 (Dec 17 2013 - 14:23:41)
OMAP4460 <http://www.ti.com/product/OMAP4460> ES1.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.bin
reading u-boot.bin
......
Can anyone please help me why thumb mode build is failing?
On 18/12/13 05:06, Jonathan S. Shapiro wrote:
> At the risk of sticking my nose in, this isn't a startup code issue.
> It's a contract issue.
>
> First, I don't buy Richard's argument about memcpy() startup costs and
> hard-to-predict branches. We do those tests on essentially every
> *other* RISC platform without complaint, and it's very easy to order
> those branches so that the currently efficient cases run well. Perhaps
> more to the point, I haven't seen anybody put forward quantitative
> data that using the MMU for unaligned references is any better than
> executing those branches. Speaking as a recovering processor
> architect, that assumption needs to be validated quantitatively. My
> guess is that the branches are faster if properly arranged.
>
> Second, this is a contract issue. If newlib intends to support
> embedded platforms, then it needs to implement algorithms that are
> functionally correct without relying on an MMU. By all means use
> simpler or smarter algorithms when an MMU can be assumed to be
> available in a given configuration, but provide an algorithm that is
> functionally correct when no MMU is available. "Good overall
> performance in memcpy" is a fine thing, but it is subject to the
> requirement of meeting functional specifications. As Jochen Liedtke
> famously put it (read this in a heavy German accent): "Fast, ya. But
> correct? (shrug) Eh!"
>
> So: we need a normative statement saying what the contract is. The
> rest of the answer will fall out from that.
>
> I do agree with Richard that startup code is special. I've built
> deeply embedded runtimes of one form or another for 25 years now, and
> I have yet to see a system where optimizing a simplistic byte-wise
> memcpy during bootstrap would have made any difference in anything
> overall. That said, if the specification of memcpy requires it to
> handle incompatibly aligned pointers (and it does), and the contract
> for newlib requires it to operate in MMU-less scenarios in a given
> configuration (which, at least in some cases, it does), it's
> completely legitimate to expect that bootstrap code can call memcpy()
> and expect behavior that meets specifications.
>
> So what's the contract?
>
I disagree with your assertion that newlib *requires* it to operate in
an MMU-less scenario for all targets; it only does so when the target
can reasonably be expected to not have an MMU.
The only contract that exists is the one written in the C standard:
7.23.2.1#2 The memcpy function copies n characters from the object
pointed to by s2 into the object pointed to by s1. If copying takes
place between objects that overlap, the behavior is undefined.
But that is written on the assumption that we're in a normal execution
environment, not in some special case.
What you're missing is that AArch64 is (in ARM ARM terms) an A-profile
only environment where an MMU is mandated in the system. Furthermore,
processors implementing the architecture will *expect* that the MMU be
turned on as soon as possible after boot, since without this the caches
cannot be used and without those the performance will be truly horrible.
Once the caches are enabled, it's perfectly reasonable to assume that
memcpy will only be used for copies to and from NORMAL memory, since
other types of memory have potential side effects, which means that use
of memcpy would be unsafe.
If you want to write an MMU-less memcpy, then feel free to write one;
but please install it with a different interface -- something like
__memcpy_nommu(). Don't penalise the standard case for the non-standard
exceptional one.
R.
Hi all,
I have a bit of a strange one. I'm not after a full solution, just any
hints that quickly come to mind :)
After a few simple patches I have a build of mongodb for aarch64 (built
with gcc-4.8). However, all of the test binaries that the build spits
out immediately segfault. gdb-ing shows that they segfault inside this
macro:
TSP_DECLARE(OwnedOstreamVector, threadOstreamCache);
This expands to:
# define TSP_DECLARE(T,p) \
extern __thread T* _ ## p; \
template<> inline T* TSP<T>::get() const { return _ ## p; } \
extern TSP<T> p;
And indeed, it's mongo::TSP<mongo::OwnedPointerVector<...> >::get()
const that we're segfaulting in. This is the disassembly of this
function (at -O0) with the faulting instruction marked:
0x00000000004b4b6c <+0>: stp x29, x30, [sp,#-32]!
0x00000000004b4b70 <+4>: mov x29, sp
0x00000000004b4b74 <+8>: str x0, [x29,#16]
0x00000000004b4b78 <+12>: adrp x0, 0x64c000
0x00000000004b4b7c <+16>: ldr x0, [x0,#776]
0x00000000004b4b80 <+20>: nop
0x00000000004b4b84 <+24>: nop
0x00000000004b4b88 <+28>: mrs x1, tpidr_el0
0x00000000004b4b8c <+32>: add x0, x1, x0
=> 0x00000000004b4b90 <+36>: ldr x0, [x0]
0x00000000004b4b94 <+40>: ldp x29, x30, [sp],#32
0x00000000004b4b98 <+44>: ret
And the registers:
(gdb) info registers
x0 0x7fb863fd70 548554407280
x1 0x7fb7ff76f0 548547819248
x2 0x0 0
x3 0x7fb7fc11b8 548547596728
x4 0x1 1
x5 0x0 0
x6 0x50 80
x7 0x0 0
x8 0x0 0
x9 0x6165727473676f4c 7018141438804717388
x10 0x0 0
x11 0x0 0
x12 0x2 2
x13 0x10 16
x14 0x0 0
x15 0x7fb7e5e590 548546143632
x16 0x64b3d8 6599640
x17 0x7fb7f667d0 548547225552
x18 0x7fffffdab0 549755804336
x19 0x7fffffed50 549755809104
x20 0xb 11
x21 0xb 11
x22 0x6500b0 6619312
x23 0x650070 6619248
x24 0x7fffffff 2147483647
x25 0x64db40 6609728
x26 0x7fffffeda0 549755809184
x27 0x653d00 6634752
x28 0x7fffffe750 549755807568
x29 0x7fffffe4d0 549755806928
x30 0x4b4ed4 4935380
sp 0x7fffffe4d0 0x7fffffe4d0
pc 0x4b4b90 0x4b4b90 <mongo::TSP<mongo::OwnedPointerVector<std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> > > >::get() const+36>
cpsr 0x20000000 536870912
fpsr 0x0 0
fpcr 0x0 0
If I recompile this object file without -fPIC, it works.
I guess I see three things that could be wrong:
1) The operand to "adrp x0, 0x64c000"[1]
2) The operand to "ldr x0, [x0,#776]"
3) The value of tpidr_el0
Oh, and I guess:
4) The setup of tls has gone wrong and the address in x0 _ought_ to be
accessible but isn't for some reason.
Any hints on which of these seems mostly likely to be the culprit?
Chers,
mwh
[1] FWIW, objdump reports 0x64c000 as "_GLOBAL_OFFSET_TABLE_+0x2d0", not
sure why that doesn't show up in gdb's disassembly).
== Progress ==
* Bugfixing and testing QEMU AArch64 FP patches (3/10, VIRT-183)
* Debugging and submitting a patch for ARM gdb ifunc test failures (1/10)
* Two day week due to holidays
== Issues ==
* None
== Plan ==
* Back on the 9th January, have a good Christmas and New Year everybody!
--
Will Newton
Toolchain Working Group, Linaro
Hi,
We've noticed an issue trying to use the Linaro AArch64 binary bare metal
toolchain release with the MMU turned off for some low-level tests.
Anytime puts, sprintf, etc. gets called, a reent structure gets created with
references to STDIN, STDOUT, STDERR FILE types. A member in the __sFile
struct, _mbstate, is an 8 byte struct, but is not aligned on an 8 byte
boundary. This means that when memset (or a similar function) gets called on
this struct, and doesn't operate one byte at a time, a data alignment fault
will be generated when operating out of device memory, such as on a system
where the MMU has not yet been turned on yet.
I'm still examining possible fixes (I'll probably look at building with
-mstrict-align first), but I wanted to check if anyone had thoughts on the
subject and if Newlib upstream or Linaro consider using Newlib with the MMU
turned off to be a valid use case or if running the code that turns on the MMU
is considered a prerequisite to everything else.
Thanks,
Christopher
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.
== Progress ==
TCWG-293 (9/10)
- wrote and tested 64bit division code
- it seems to work
- still need to do performance testing
TCWG-347 Fix PR59142 (1/10)
- split into series of 3 patches
- patch almost ready, was held up by non-availability of the lab
- need to bootstrap on Thumb-1 to prove change made in response to
review comments
TCWG-346 AArch64 Benchmarking: CoreMark & Dhrystone
- no significant progress, no access to the lab
== Next ==
Pick up aarch64 benchmarking when the board becomes accessible again
Submit PR59142
== Progress ==
- 2013.12 releases (4/10):
* stalled due to lab unavailability.
* A couple of backports are waiting for approval, another one is
being debugged.
- cross-validation (4/10): fixed arneb+qemu validations.
- misc (2/10): misc conf-calls and meetings
== Next ==
- Make 2013.12 releases
- cbuild2: continue testing, try to make 4.7 source release
- libsanitizer on AArch64: resume work
== Future ==
Next 2 weeks off (Dec 23rd-Jan 3rd)
== Issues ==
* 1.5 day of due to car issue. (3/10)
* Calxedas are down after lab maintenance.
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (5/10)
- Turn LRA on by default committed as rev205887
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01088.html
- New Thumb regressions reported (Cortex-m0 and bootstrap),
analysis ongoing.
- Analysed last week regressions and reported them upstream,
Vladimir fixed them at rev205974.
- iWMMXT issue : work ongoing.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* Reviewed some merge requests. (1/10)
* Various meetings. (1/10)
== Next ==
* Continue LRA, merge and patch reviews.
== Progress ==
* Debugging and analysis of various gdb test suite failures [TCWG-34] [5/10]
Updated googledoc sheet with action items and comments on different failures.
Investigated remote core file generation issues.
Prepared a patch to turn off corefile dependent tests in remote configs.
* Debugged gdb.reverse testsuite failures [TCWG-197] [4/10]
Found a memory corruption issue where execution log is being corrupted
in memory.
* Time off for dentist appointment and office relocation stuff [1/10]
== Plan ==
* Figure out a reason and fix for process record memory corruption problem.
* Further analysis of test suite failures in arm-native Vs x86-native
and arm-remote Vs
x86-remote test results.
* Send patch to disable corefile tests in remote mode. Ping process
record and other previous patches.
== Progress ==
- Libssp GCC (4/10)
- Rebased GCC source and added patch for stack protect and test
based on global stack guard. Discussing with Marcus on
generic stack protect set and test versus machine descriptions.
Discussed with ARM and Glibc Maintainers, Dropped my patches
for TLS based stack guard.
- Cbuildv2 experiments (3/10)
- Built cross compiler with Cbuilv2.
- Discussing with Ryan on building tool chain without
cbuild.validation.linaro.org dependency
- PGO support for aarch64 (1/10)
Read a paper on PGO optimization in GCC
- Cross build some benchmarks(2/10). There were omp.h file missing
errors when Linaro tool chain was used. The issue is the tool chain is
not built with libgomp library. Rebuilt the tool chain after checkign
configuration changes with Zhenqiang Chen .
== Plan ==
- Inverstigate Pointer Guard support in Aarch64 glibc
- Continue tesing Cbuildv2
- Continue PGO investigations
== Issues ==
* None.
== Progress ==
* Enable libomp for aarch64*-linux-gnu builds in Linaro crosstool-ng.
* Backporting r200103 and r205509 to Linaro 4.8.
* Try to enable lra and test Spec2k with -fno-move-loop-invariants and
-fira-loop-pressure. But still no overall performance improvement.
(2/10)
* Try conditional compare related changes (CARD 313: 3/10)
- Set LOGICAL_NON_SHORT_CIRCUIT to false in fold-const.c.
- Do ifcombine twice.
- Logs show lots of new FAILs in vrp related cases and no
performance improvement in Spec2k INT.
* Identified the root causes of "uninit warning testsuite failures"
(CARD 304: 3/10)
- Some values are from PHI, which is not handled when checking subset.
- Function is_included_in is conservative. Here is its comments:
/* ... It returns false if ONE_PRED's domain is
not a subset of any of the sub-domains of PREDS (
corresponding to each individual chains in it), even
though it may be still be a subset of whole domain
of PREDS which is the union (ORed) of all its subdomains.
In other words, the result is conservative. */
== Plans ==
* 2013.12 toolchain binaries release.
* Continue on CARD 313 and 304.
== Progress == (4/10)
* TCWG-372 fix Cbuildv2 parsing to handle the new binutils-gdb repository (4/10)
- Completed Card with following commits.
commit e6e39f5d1f7963332b3d7dd2e4400de91847219c
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Tue Dec 10 16:08:17 2013 -0600
Correct get_toolname to work with unified repo: binutils-gdb.git
Secondary fixes required:
- Set config/binutils.conf and config/gdb.conf to use unified repo
binutils-gdb.git.
- Re-enable binutils-gdb.git in config/sources.conf.
- get_toolname now calls get_git_tool and determines the actual toolname
for binutils and gdb from the branch name if the repository is unified.
- Made all other usages of get_git_tool use get_toolname instead.
- checkout() now uses ${repo} as returned from get_git_repo as the git
repository instead of ${tool}.git. This allows a unified repository to
only be checked out once.
- The git parser now determines whether an http:// in a url means a git
service or an svn service.
- The git parser now returns branch names for launchpad urls with branches
in the url.
- The git parser now returns the tool name properly for an svn service.
- The git parser testsuite now has testcases for all new additions.
Also
- Added --snapshots functionality to allow specifying an existing snapshots
directory.
- Add testcases to test.sh to test --snapshots functionality.
- Changes test.sh --snapshots directive to --md5sums to avoid confusion
with cbuild2.sh --snapshots.
* TCWG-323 Interface hardening (5/10)
- Card in progress with following commits:
commit cc7193d8ddb86c4ed7d16086f8ee968ae4bae87f
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Thu Dec 12 11:40:00 2013 -0600
cbuild2.sh: All error exit paths should use build_failure().
commit 2a4ec7fa0b7c48e0c6e05a7549f64e3336022f45
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Wed Dec 11 14:08:51 2013 -0600
cbuild2.sh: Added check_directive() to unify bounds checking.
Also added accompanying top-level test.sh fragments to test
check_directive.
Change-Id: Ia42a4b241a5ca62d41dccf1d8e023980ad0a04d0
commit c9ec21200260bdb26d9fe9b26d7ce390579a0ca2
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Wed Dec 11 13:07:15 2013 -0600
test.sh: Fixed to work with a temporary host.conf file.
Require change due to commit 3b5c576630a8ac08cd3b9ab9eab781308549a858
which requires a host.conf file for finding the cbuild topdir.
Change-Id: I991bb5f2a7949267bf69fba093d6becd202ad138
commit 16a45027be798b06160916234713f5dc35b2ecbb
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Tue Dec 10 18:16:09 2013 -0600
cbuild2.sh: Bounds check --set input.
Change-Id: I8ebffd1809b17962aef58f2a08277d5f639d7e3e
commit d7ee602c24231e24457c93208f749cbdd0357115
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Tue Dec 10 18:03:04 2013 -0600
cbuild2.sh: Remove --srcdir. It didn't do anything.
Change-Id: I5b99c7ae8dc542cb62516104bd0bf9d1888afc52
commit 53e9c74966442c41cc9512f27f46ef849d62bcc8
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Tue Dec 10 17:58:54 2013 -0600
cbuild2.sh: Remove --dispatch support. It didn't do anything.
commit 289ade38f100872653218da4792fbb1650d3b231
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Wed Dec 11 10:27:37 2013 -0600
cbuild2.sh: Bounds check --release switch.
Change-Id: I90804ea02b995d476b148fb68db955d164bc674c
commit 9bae259ebbff193e29899edf8a47190747d2bc1b
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Wed Dec 11 10:09:00 2013 -0600
lib/configure.sh: Add missing closing "
Change-Id: I9eee9a934a6cbb60bd1e2db6b0af9faf19fa5188
commit 16a45027be798b06160916234713f5dc35b2ecbb
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Tue Dec 10 18:16:09 2013 -0600
cbuild2.sh: Bounds check --set input.
Change-Id: I8ebffd1809b17962aef58f2a08277d5f639d7e3e
commit d7ee602c24231e24457c93208f749cbdd0357115
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Tue Dec 10 18:03:04 2013 -0600
cbuild2.sh: Remove --srcdir. It didn't do anything.
Change-Id: I5b99c7ae8dc542cb62516104bd0bf9d1888afc52
commit 53e9c74966442c41cc9512f27f46ef849d62bcc8
Author: Ryan S. Arnold <ryan.arnold(a)linaro.org>
Date: Tue Dec 10 17:58:54 2013 -0600
cbuild2.sh: Remove --dispatch support. It didn't do anything.
Change-Id: I4b6ee8db0d3e74510b95c816469b0c100207972f
* Misc (1/10)
- Now using gerrit with git review for handling cbuildv2 development.
- Reviewed V Chong's proposed outline for toolchain documentation and
made suggestions and edits.
== Plan ==
* Move onto working primarily on glibc Jira cards.
== Issues ==
* Lab migration took cbuild.validation.linaro.org down for several
unplanned days and therefore toolchain sources were unavailable during
that time. I made do by adding some features into cbuildv2 to use
alternative snapshots directories.
== This week ==
- Completed backport of 202259, 202407, 202020, 201261 and 201263
- Submitted merge requesSt for completed backports
== Next week ==
- Begin work on other assigned backports
== Future ==
Document missing features of cbuild for backports
== Progress ==
* Pragma Vectorize
- Comparing pragma OMP to mimic for vectorize
- Implementing the lexer/parser
- http://llvm.org/PR18086
* Android LLVM
- Wasting time for the last time with Odroid XU and Android
- Will focus on Nexus 4, 5 and 7
* Integrated AS
- Changed to enabled by default
- Discussing some bugs found on Android unwind library (inline asm)
- http://llvm.org/PR18231
* Release 3.4
- There were some muddled merges, folks are trying to fix
- Bero found a serious bug, seems to be result of the bad merge
- http://llvm.org/PR18201
- Tested RC2, waiting for RC3
* Background
- Discussions, lots of patch reviews
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue implementing pragma vectorize in Clang
* Wait for the next release candidate, test, benchmark
* Follow up in the IAS issues raised
* If RemoteChild is gone by then, continue the MCJIT refactoring
* Have a look at TableGen users
== Issues ==
I saw a black cat, under a ladder, with a hockey mask...
== Progress ==
* Bugfixing and testing QEMU AArch64 FP patches (7/10, VIRT-183)
* Debugging and submitting a patch for issue with Ruby and ARM pointer
encryption (2/10)
* Other miscellaneous work: glibc patch review, binutils testsuite
patch, expenses (1/10)
== Issues ==
* None
== Plan ==
* 2 day week next week then off until Jan 8th
* Wrap up qemu work to a good state to handover
--
Will Newton
Toolchain Working Group, Linaro
== Progress ==
- cross-validation: (1/10). Follow-up, minor maintenance and
discussions on a few regressions. Now able to share top-level
reports.
- backports (1/10):
* multilib_defaults for 4.7
* committed all approved backport
* helped Michael solve some conflicts
- disable peeling: (3/10)
* confirmed it is now done by default on trunk, as part
-fvect-cost-model=XXX.
* Looked at benchmarks, comparing
-fvect-cost-model=cheap (default) and
-fvect-cost-model=unlimited.
- benchmarks on trunk (1/10): observed some variations from one month to
another on a few cases (checked June-November). This confirms
the need to run benchmarks regularly on trunk, in addition to
release branches.
- cbuild2 (3/10): continued working on source release. Submitted a few
small patches for review+integration.
- misc (1/10): various conf-calls and meetings.
== Next ==
- Make 2013.12 releases
- cbuild2: continue testing, try to make 4.7 source release
- libsanitizer on AArch64: resume work
== Issues ==
* Tcpanda03 seems unusable.
== Progress ==
* LRA on AArch32:
o TCWG-345 : Analyse performance of LRA for ARM. (5/10)
- Installed Saucy on Chromebook, lot of time wasted due to defective SD card
- Frequency governor now set to performance.
- Benchmark setting ongoing
- Tcpand03 SSH access re-enabled, board setting seems ok, but respawned
benchmarks are stuck and the board is no more reachable
o TCWG-343 : Make LRA the default for the ARM backend (2/10)
- Reduce iWMMXT testcase, analysis ongoing.
- Trunk testsuite with LRA shows a couple new faillures.
* Reviewed some merge requests. (1/10)
* Loop specialization patch review started. (1/10)
* Various meetings. (1/10)
== Next ==
* Continue LRA, merge and patch reviews.
== Progress ==
* Updated, tested and submitted new patches for a couple of gdb
testsuite failure on arm. [TCWG-269] [TCWG-34] [1/10]
* Performed GDB git repository testing suite results comparison:
[TCWG-34] [2/10]
Compared results and prepared googldocsheets for the following:
arm-native Vs arm-remote
arm-native Vs x86-native
arm-remote Vs x86-remote
* Investigated difference/failures in arm-native vs arm-remote
comparison sheet. [TCWG-34] [5/10]
Re-ran timeout failures with different values of timeouts.
Figured out causes of failures.
Figured out why some tests exit without emitting any logical result.
* In response to comments upstream tried to figure out alternate fix for
dwarf2 fortran parameter test. [TCWG-267] [TCWG-34] [1/10]
* Miscellaneous activities [1/10]
== Plan ==
* Analyze new failures in arm-native Vs x86-native and arm-remote Vs
x86-remote test results.
* Fix test suite failures and submit patches if any.
* Spend some time pining/updating/re-submit previous patches.
== Progress ==
- libssp gcc
Initiated mails for upstream discussion on supporting global and TLS
based libssp ABI for Aarch64. Now waiting for feedback from ARM
maintainers.
- Built few benchmarks with Linaro tool chain binaries. Faced some
openmp failures, compiler disabled for libgomp. Looking to rebuild
the linaro cross tool chain.
- Rebased glibc trunk and ran cross glibc tests on V8 foundation
model. With TLS SSP patch glibc's libresolve.so fails to build
because the stage 1 GCC compiler emits global stack_chk_guard. The
glibc dos not export global stack_chk_gaurd, when TLS based stack
guard is set. Now looking at supporting and test both TLS and global
stack guard ABI, but before that waiting for confirmation from ARM
maintainers.
- Reinstalled linux 13.04 ubuntu on my laptop
- Tested the patch
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00170.html for
aarch64-none-elf target. No regressions found.
== Plan ==
- Continue upstream discussions and post RFC patches for glibc and gcc libssp
- Explore on cbuildv2
- Cross Build few openmp benchmarks
