== Progress ==
* Off Monday after travelling back from Connect
* Catching up on email and post-Connect admin
* Released Linaro binutils 2.24.0 2014.03
* Submitted aarch64 setcontext patches upstream
* Submitted a patch for ld RELASZ issue
* Looked into eglibc svn mirroring
== Issues ==
* None
== Plan ==
* Resolve eglibc mirror situation
--
Will Newton
Toolchain Working Group, Linaro
== Progress ==
* Get started with Aarch64 GDB testing and development process using
foundation model. [6/10] [CARD-1115]
-- Figured out steps for running gdb in remote mode using foundation model.
-- Wrote a wiki page with steps on development process, still in progress.
-- Completed a gdb testsuite run and made a comparison with arm gdb.
-- All new testsuite results will be available on gdb wiki page.
-- Setup aarch64 gdb remote debugging.
* Updates to GDB pages on wiki.linaro.org [TCWG-96] [2/10]
-- Added pages containing test scripts and gdb testing tips
-- Added page containing current gdb testsuite results in various
configurations
* Add support for fork/vfork/exec events/catchpoints in remote
gdbserver [TCWG-263] [1/10]
-- GDB code review for task break down, still in progress.
* Fix network and internet problems [1/10]
== Plan ==
* Arm v8 reverse debugging support.[CARD-1115]
-- Provide card update and deliverable list.
-- Implement reverse debugging infrastructure for aarch64 gdb.
* Add support for fork/vfork/exec events/catchpoints in remote
gdbserver [TCWG-263]
-- GDB code review for task break down, still in progress.
* Update and cleanup gdb wiki pages on wiki.linaro.org
* All open gdb card review and update.
== Progress ==
* Went through few Linaro Connect - LCA14 slides and videos .
* Restarted upstream discussions on writing machine descriptions for
stack smashing. Working on submitting patches again as per Marcus
suggestions.
* Installed "CPU2006" in foundation model running open embedded image
and tried running 403.gcc benchmark.
* Tried buiding QEMU for aarch64 on ubuntu 12.04,2. I am getting
segment fault on using -L <library path >. Need to debug further.
* PGO runs: GCC boot strap failed when libjava building at stage3.
Need to have re-look further. Issue may be missing package in
opembedded image on foundation model.
Misc
------
Attended some Internal meetings.
== Plan ==
* Continue machine descriptions for stack smashing work.
* Work on using QEMU for running gcc test suites
* Restart PGO bootstrap failure investigations
== Issues ==
* None
== Progress ==
* Validate R/M toolchain 4.8 q1 update release.
* Try Cross-Native build based on Linaro crosstool-ng.
* Handle conditional compare in ifcvt.c to make ccmp and csel work together.
* Read document about FCMP/FCCMP and investigate on how to generate
FCCMP instructions:
- The tree representation of UNORDERED compare (UNLT, etc) can not
fit into current framework to handle CCMP.
- For LT, LE, GT and GE, the compiler will generate FCMPE
instruction, which can not be the first compare of CCMP.
- For NE, EQ, it is easy to handle them based on previous patches.
== Plan ==
* Continue on ccmp performance tuning.
== This week ==
Completed the following backports related to a53 support:
201375 - Insn classification refactoring 7/n Factor out "type" attribute
201376 - Insn classification refactoring 7/n Factor out common
scheduling dependency routines (done)
201399 - Insn classification unification 1/n Define "type" attrib for
all patterns (done)
201400 - Share the a53 pipeline description between arm and aarch64 backends
201436 - Insn classification unification 4/N load/store types
202272 - [AArch64, AArch32][Insn classification refactoring 6/N] Remove
"neon_type" attribute
202291 - [AARCH64][Insn classification unification 3/N] ALU/shift types
202292 - [AArch64] Fix categorisation of the frecp* insns.
202323 - [Patch ARM] Add "type" attribute to Everything!
202328 - [ARM,AARCH64] Insn type reclassification. Split f_cvt type.
202329 - [Patch ARM AARCH64] Split "type" attributes: fdiv
202330 - [Patch AArch64] Fix types for some multiply instructions.
202331 - [AArch64, ARM] Rename the FCPYS type to FMOV
202332 - [AArch64, ARM] Use "multiple" for type, where more than one
instruction is used for a move
== Next week ==
Complete remaining backports for a53 support and complete builds for arm and aarch64.
== Future ==
--
Michael Collison
Linaro Toolchain Working Group
michael.collison(a)linaro.org
The Linaro Toolchain Working Group is pleased to announce the 2014.03
engineering release of Linaro GCC 4.8.
As announced at Linaro Connect USA 2013 Linaro GCC is moving to a
pattern of quarterly stable releases, with engineering releases in the
intervening months. This is the second engineering release. The next stable
release will be the 2014.04 release.
Linaro GCC 4.8 2014.03 is the twelfth release in the 4.8 series. Based
off the latest GCC 4.8.3+svn208264 release, it includes performance
improvements and bug fixes.
Interesting changes include:
* Updates to GCC 4.8.3+svn208264
The source tarball is available from:
http://releases.linaro.org/14.03/components/toolchain/gcc-linaro/4.8
Downloads are available from the Linaro Releases website:
http://www.linaro.org/downloads/
More information on the features and issues are available from the
release page:
https://launchpad.net/gcc-linaro/4.8/4.8-2014.03
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bugs: https://bugs.launchpad.net/gcc-linaro/
Questions? https://ask.linaro.org/
Interested in commercial support? Inquire at support(a)linaro.org
~
== Progress ==
* Ill until Thusrday due to Chinese food allergy/intolerance/poisoning
- Seems I'm not the only one...
* EHABI
- Adding a few more EH tests to test-suite
- Integration with ARM compiler better handled by ARM
- Plugging -fno-unwind-tables to disable EH tables in ARM
* Android
- Implementing __builtin___clear_cache in LLVM
- Need to add parsing to Clang later, and docs to LangRef
* AArch64
- Tested a "fix" on sphereflake, didn't work
- Seems the problem is the sin() results on glibc variants
- We might need to round the result a bit shorter to make it work everywhere
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue ___builtin__clear_cache implementation
* Continue RT and AArch64 test-suite investigation
Dear Linaro toolchain support team:
I am Justin Guo from S3 graphics Inc. I am studying linaro's big-little
codes and is using TC2 Platform.
I used ./linaro_kernel_build_cmds.sh to build kernel, I got no problem
when I set CONFIG_DEBUG_INFO=y to build for kernel.
However, When I trace kernel, the traced line in source code level is
jumping up/down, so I tried to turn off the optimization.
After modified Makefile as below to turn off optimization:
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
KBUILD_CFLAGS += -Os $(call cc-disable-warning,maybe-uninitialized,)
else
KBUILD_CFLAGS += -O0
endif
I got errors when build linaro kernel for TC2:
root@ubuntu:/home/justinguo/linaro/1309# ./linaro_kernel_build_cmds.sh
Directory linaro-kernel exists. If the kernel code exists in this
directory you may continue
without cloning the git repository for the kernel. Are you sure you want
to do this? (y/n)
y
M Makefile
HEAD is now at dafe325... Merge branch 'linux-linaro-lsk' into
linux-linaro-lsk-android
% Total % Received % Xferd Average Speed Time Time Time
Current
Dload Upload Total Spent Left
Speed
100 57281 100 57281 0 0 90703 0 --:--:-- --:--:-- --:--:--
188k
Using /home/justinguo/linaro/1309/linaro-kernel as source for kernel
GEN /home/justinguo/linaro/1309/linaro-kernel/out/Makefile
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
UPD include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/arm/kernel/asm-offsets.s
GEN include/generated/asm-offsets.h
CALL
/home/justinguo/linaro/1309/linaro-kernel/scripts/checksyscalls.sh
CC scripts/mod/empty.o
MKELF scripts/mod/elfconfig.h
CC scripts/mod/devicetable-offsets.s
GEN scripts/mod/devicetable-offsets.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
CC init/main.o
CHK include/generated/compile.h
CC init/version.o
CC init/do_mounts.o
CC init/do_mounts_rd.o
CC init/do_mounts_initrd.o
LD init/mounts.o
CC init/initramfs.o
CC init/calibrate.o
CC init/init_task.o
LD init/built-in.o
CC arch/arm/vfp/vfpmodule.o
AS arch/arm/vfp/entry.o
AS arch/arm/vfp/vfphw.o
CC arch/arm/vfp/vfpsingle.o
CC arch/arm/vfp/vfpdouble.o
LD arch/arm/vfp/vfp.o
LD arch/arm/vfp/built-in.o
CC arch/arm/kernel/elf.o
AS arch/arm/kernel/entry-armv.o
AS arch/arm/kernel/entry-common.o
CC arch/arm/kernel/irq.o
CC arch/arm/kernel/opcodes.o
CC arch/arm/kernel/process.o
CC arch/arm/kernel/ptrace.o
CC arch/arm/kernel/return_address.o
/home/justinguo/linaro/1309/linaro-kernel/arch/arm/kernel/return_address
.c:63:2: warning:
#warning "TODO: return_address should use unwind tables" [-Wcpp]
CC arch/arm/kernel/sched_clock.o
CC arch/arm/kernel/setup.o
CC arch/arm/kernel/signal.o
CC arch/arm/kernel/stacktrace.o
CC arch/arm/kernel/sys_arm.o
CC arch/arm/kernel/time.o
CC arch/arm/kernel/traps.o
CC arch/arm/kernel/atags_parse.o
CC arch/arm/kernel/cpuidle.o
CC arch/arm/kernel/armksyms.o
CC arch/arm/kernel/module.o
AS arch/arm/kernel/sleep.o
CC arch/arm/kernel/suspend.o
CC arch/arm/kernel/smp.o
CC arch/arm/kernel/smp_tlb.o
CC arch/arm/kernel/smp_scu.o
CC arch/arm/kernel/smp_twd.o
CC arch/arm/kernel/arch_timer.o
CC arch/arm/kernel/ftrace.o
CC arch/arm/kernel/insn.o
CC arch/arm/kernel/unwind.o
CC arch/arm/kernel/devtree.o
CC arch/arm/kernel/swp_emulate.o
CC arch/arm/kernel/hw_breakpoint.o
CC arch/arm/kernel/perf_event.o
CC arch/arm/kernel/perf_event_cpu.o
CC arch/arm/kernel/topology.o
CC arch/arm/kernel/io.o
CC arch/arm/kernel/psci.o
/tmp/cciaYmCJ.s: Assembler messages:
/tmp/cciaYmCJ.s:147: Error: .err encountered
/tmp/cciaYmCJ.s:148: Error: .err encountered
/tmp/cciaYmCJ.s:149: Error: .err encountered
/tmp/cciaYmCJ.s:150: Error: .err encountered
/tmp/cciaYmCJ.s:191: Error: .err encountered
/tmp/cciaYmCJ.s:192: Error: .err encountered
/tmp/cciaYmCJ.s:193: Error: .err encountered
/tmp/cciaYmCJ.s:194: Error: .err encountered
make[2]: *** [arch/arm/kernel/psci.o] Error 1
make[1]: *** [arch/arm/kernel] Error 2
make: *** [sub-make] Error 2
root@ubuntu:/home/justinguo/linaro/1309#
Could you Please help fix these issues?
Best regards,
Justin Guo
Hi,
After a solid few months of work the QEMU master branch [1] has now reached
instruction feature parity with the suse-1.6 [6] tree that a lot of people
have been using to build various aarch64 binaries. In addition to the
SUSE work we have fixed numerous edge cases and finished off classes of
instructions. All instructions have been verified with Peter's RISU
random instruction testing tool. I have also built and run many
packages as well as built gcc and passed most of the aarch64 specific tests.
I've tested against the following aarch64 rootfs:
* SUSE [2]
* Debian [3]
* Ubuntu Saucy [4]
In my tree the remaining insns that the GCC aarch64 tests need to
implement are:
FRECPE
FRECPX
CLS (2 misc variant)
CLZ (2 misc variant)
FSQRT
FRINTZ
FCVTZS
Which I'm currently working though now. However for most build tasks I
expect the instructions in master [1] will be enough.
If you want the latest instructions working their way to mainline you
are free to use my tree [5] which currently has:
* Additional NEON/SIMD instructions
* sendmsg syscall
* Improved helper scripts for setting up binfmt_misc
* The ability to set QEMU_LOG_FILENAME to /path/to/something-%d.log
- this is useful when tests are failing N-levels deep as %d is
replaced with the pid
Feedback I'm interested in
==========================
* Any instruction failure (please include the log line with the
unsupported message)
* Any aarch64 specific failures (i.e. not generic QEMU threading flakeiness).
If you need to catch me in real time I'm available on #qemu (stsquad)
and #linaro-virtualization (ajb-linaro).
Many thanks to the SUSE guys for getting the aarch64 train rolling. I
hope your happy with the final result ;-)
Cheers,
--
Alex Bennée
QEMU/KVM Hacker for Linaro
[1] git://git.qemu.org/qemu.git master
[2] http://download.opensuse.org/ports/aarch64/distribution/13.1/appliances/ope…
[3] http://people.debian.org/~wookey/bootstrap/rootfs/debian-unstable-arm64.tar…
[4] http://people.debian.org/~wookey/bootstrap/rootfs/saucy-arm64.tar.gz
[5] https://github.com/stsquad/qemu/tree/ajb-a64-working
[6] https://github.com/susematz/qemu/tree/aarch64-1.6
Hello,
I am building an ELF image using aarch64-linux-gnu-ld from linaro:
GNU ld (crosstool-NG linaro-1.13.1-4.8-2014.02 - Linaro GCC 2014.02)
2.24.0.20131220
I am linking in the libstc++.a, which contains in particular a GOT
entry for __gthread_active_ptr that is of interest to me, pointing to
__pthread_key_create, used for detecting pthread support for
std::thread,
and while I get the relocations for the GOT itself in a .rela.dyn
section, and a nice pointer to it from the dynamic section (RELA), the
dynamic RELASZ entry contains zero:
Here is the comparison of the Dynamic section (note RELASZ) with the
following .rela.dyn relocations:
loader.elf: file format elf64-littleaarch64
loader.elf
architecture: aarch64, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00000000400b0000
Program Header:
LOAD off 0x0000000000000000 vaddr 0x0000000040090000 paddr
0x0000000040090000 align 2**16
filesz 0x0000000000407084 memsz 0x00000000004aa504 flags rwx
TLS off 0x0000000000407080 vaddr 0x0000000040497080 paddr
0x0000000040497080 align 2**3
filesz 0x0000000000000004 memsz 0x0000000000000580 flags rw-
DYNAMIC off 0x0000000000001000 vaddr 0x0000000040091000 paddr
0x0000000040091000 align 2**3
filesz 0x0000000000000120 memsz 0x0000000000000120 flags rw-
EH_FRAME off 0x00000000003ce5fc vaddr 0x000000004045e5fc paddr
0x000000004045e5fc align 2**2
filesz 0x000000000000bae4 memsz 0x000000000000bae4 flags r--
NOTE off 0x0000000000000000 vaddr 0x0000000000000000 paddr
0x0000000000000000 align 2**3
filesz 0x0000000000000000 memsz 0x0000000000000000 flags ---
Dynamic Section:
NEEDED dummy-shlib.so
INIT_ARRAY 0x00000000404841b8
INIT_ARRAYSZ 0x0000000000000330
HASH 0x000000004044bd58
STRTAB 0x00000000403e3320
SYMTAB 0x00000000403a4110
STRSZ 0x0000000000068a33
SYMENT 0x0000000000000018
DEBUG 0x0000000000000000
RELA 0x00000000404780c0
RELASZ 0x0000000000000000
RELAENT 0x0000000000000018
private flags = 0:
...
10 .rela.dyn 00002058 00000000404780c0 00000000404780c0 003e80c0 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
...
and now the .rela.dyn.relocations from aarch64-linux-gnu-readelf -r
loader.elf :
Relocation section '.rela.dyn' at offset 0x3e80c0 contains 345 entries:
Offset Info Type Sym. Value Sym. Name + Addend
0000404832d0 002b00000401 R_AARCH64_GLOB_DA 00000000405339c8
_ZNSt8time_getIwSt19is + 0
0000404832d8 004400000401 R_AARCH64_GLOB_DA 000000004047e450
_ZTISt7codecvtIcc11__m + 0
0000404832e0 004b00000401 R_AARCH64_GLOB_DA 00000000405338c8
_ZGVNSt8numpunctIcE2id + 0
0000404832e8 005800000401 R_AARCH64_GLOB_DA 000000004047c460
_ZTISt8messagesIcE + 0
0000404832f0 006200000401 R_AARCH64_GLOB_DA 000000004047df40
_ZTVSt9strstream + 0
0000404832f8 007200000401 R_AARCH64_GLOB_DA 00000000402870dc
_ZNSt17bad_function_ca + 0
000040483300 008500000401 R_AARCH64_GLOB_DA 0000000040534e58
_ZGVN9__gnu_cxx16bitma + 0
000040483310 00c300000401 R_AARCH64_GLOB_DA 0000000040533a18
_ZNSt6locale2id11_S_re + 0
000040483318 00dd00000401 R_AARCH64_GLOB_DA 000000004047c160
_ZTISt5ctypeIwE + 0
000040483320 00ea00000401 R_AARCH64_GLOB_DA 0000000040534e18
_ZZN9__gnu_cxx9free_li + 0
000040483328 011700000401 R_AARCH64_GLOB_DA 0000000040533968
_ZGVNSt8time_getIwSt19 + 0
000040483330 013500000401 R_AARCH64_GLOB_DA 000000004047cfd8
_ZTISt7num_getIwSt19is + 0
000040483338 017300000401 R_AARCH64_GLOB_DA 000000004021d51c
__pthread_key_create + 0
...
^^...note the __pthread_key_create relocation I am interested in...
I would expect the RELASZ in the dynamic section to be 0x2058 instead of 0.
Any tips to what could be wrong?
Thank you,
Claudio Fontana
Hi,
I'm trying to build the native compiler to a arm a9 using this tutorial,https://wiki.linaro.org/WorkingGroups/ToolChain/Using/GCCNative.Ho…, I need to compile in a x86_64 platform ubuntu, like this --target=arm-unknown-eabi --build=i686-pc-linux-gnu --host=arm-unknown-eabi, but without success.There is any possible solution?
Thank you.Felipe Rocha da Rosa.
Hi all,
We are using Linaro 13.03 toolchain(gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are trying to execute a simple test code to check whether ARM assembly code executes on board or not. Execution is on Arndale Board. Every time We include assembly function, We get segmentation fault. Kindly check if I We are missing any arm related flags in makefile.
We have attached the 'helloworld' test code and makefile.
Regards,
Vishwa
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
If your code is sensitive to the size of long long, can you use the predefine:
__SIZEOF_LONG_LONG__
If that doesn't work, then you can use:
gcc -dM -E - < /dev/null
to tell you what predefines a gcc compiler has (I would probably look for predefines more specific to what your code is sensitive to than look for a particular compiler).
I also wonder a little about your original problem statement since "%lld" should be a way to always print "long long" and if you have a matched set of compiler and library, then it should adjust both together. If you are using "%ld" instead, this works in situations where "long" is the same size as "long long" but may not work when these are different sizes.
--mev, Mike Vermeulen
Hi there!
On Linaro gcc 4.6, I am facing an issue due to "long long" integers
not being 64 bit as they are on other platforms I'm targeting,
which causes different issues, most importantly with printf format
strings. I am now circumventing these by using the C/C++ preprocessor
in order to choose the right format strings. In order to minimize the
necessity for users to manually configure things, I'm wondering if
there is a way to detect the Linaro gcc compiler through preprocessor
macros. Is this possible?
Thanks.
Best regards,
Isidor
Hi all,
We are using Linaro 13.03 toolchain(
gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux We are trying to
execute a simple test code to check whether ARM assembly code executes on
board or not. Execution is on Arndale Board. Every time We include assembly
function, We get segmentation fault. Kindly check if I We are missing any
arm related flags in makefile.
We have attached the ‘helloworld’ test code and makefile.
Regards,
Vishwa
Is that supposed to be possible? When I add --disable-multilib to the
configure options, the build fails on the install, because it hasn't built
any of src/gcc-linaro-4.8-2014.02/libgcc:
/bin/sh ../../../../src/gcc-linaro-4.8-2014.02/libgcc/../mkinstalldirs
/home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3
/usr/bin/install -c -m 644 libgcc_eh.a
/home/ubuntu/work483/build/sysroot/home/ubuntu/opt/cross-gcc-linaro/lib/gcc/arm-linux-gnueabi/4.8.3/
/usr/bin/install: cannot stat `libgcc_eh.a': No such file or directory
make[3]: *** [install-shared] Error 1
make[3]: Leaving directory
`/home/ubuntu/work483/build/gcc/arm-linux-gnueabi/libgcc'
make[2]: *** [install-target-libgcc] Error 2
make[2]: Leaving directory `/home/ubuntu/work483/build/gcc'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/home/ubuntu/work483/build/gcc'
make: *** [stamp/gcc-install] Error 2
I don't want or need multilib, so I'd rather build the toolchain without
it, but before I try to make that happen, I wanted to make sure it's
supposed to be able to get built correctly that way.
Thanks,
Diane
== Progress ==
* IAS (TCWG-377)
- Long discussions about magic in inline asm
- Bottomline is: we're still validating anyway
* AArch64 (TCWG-387)
- Making it build with CMake, discarding some tests
- Similar changes to the test-suite
- All green except sphereflake
* Buildbots
- Investigating one failure on test-suite due
to register allocator changes
- Will continue this during or after Connect
* Background
- Connect preparations
- EuroLLVM 14 sync call, paper discussions
- Researching some kernel C/ASM syntax
- Studying __builtin_constant_p usage
- Patch reviews, etc.
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Connect
(slightly delayed)
== Progress ==
* 3 day week (annual leave Thursday and Friday)
* QEMU ARMv8 CRC instructions (4/10, TCWG-52)
* Slides for Connect (1/10)
* Further work on longjmp/setjmp Systemtap probes on ARM (1/10, TCWG-378)
== Issues ==
* None
== Plan ==
* Complete QEMU CRC instruction work
* Preparation for Connect
--
Will Newton
Toolchain Working Group, Linaro
== This week ==
- US Holiday on Monday, January 17th
- Backported 202407 - Fix parameter to vrsqte_f64
- Backported 202259 (on read/write branch) - AARCH64, fix return types
for vaddvq_s64, vaaddvq_u64
- Backported 202321 - Fix vdup<bhsd>_lane<q>_* instrinsics' lane parameter
- Backported 202322 - Fox register constraints for lane intrinsics
- Installed Qemu64 simulator and attempted to test aarch64 backports.
- Shared library issue is preventing qemu64 from executing; Rob Savoy
is investigating
== Next week ==
- Test pending git review backports with Qemu64 if issues resolved
- Test backports completed this week on Qemu64
- New backports
== Future ==
--
Michael Collison
Linaro Toolchain Working Group
michael.collison(a)linaro.org
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (0/10)
- No progress this week on my side.
o TCWG-345 : Analyse performance of LRA for ARM. (4/10)
- Analysed Spec2K figures on Cortex-a15.
* Backports review: (1/10)
o Start to look at the Gerrit review process.
o Lack of testsuite results
* Misc:
o LCA'14 : AArch64 toolchain status session. (3/10)
o Various meetings. (2/10)
== Next ==
* Backports review
* https://bugs.launchpad.net/bugs/1169164
* Connect
== Progress ==
* Completed testing and submitted patches upstream. [TCWG-251] [TCWG-252] [1/10]
* Travel to capital Islamabad for Macau visa follow up. [3/10]
* Shifting to new office space and setting up office [6/10]
== Plan ==
* 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]
* Setup network and internet etc in new office space.
== Issues ==
* None
== Progress ==
* CCMP for AARCH64.
- Design cases to cover most conditional compare combinations.
- Set up qemu environment and run regression tests. And fix all the new FAILs.
* Respawn 2014.01-01 baremental toolchains by setting
CT_TARGET_LDFLAGS=" --specs=rdimon.specs "
* Rebuild arm-linux-gnueabi toolchain and ran spec2k. But can not
reproduce the regression about Linaro 4.8 based on 2014.01 release.
== Plans ==
* Send out the CCMP patches for community review.
== Progress ==
- TCWG-394 (5/10)
- Found one more issue, regression tested and posted the patch
upstream for review
- http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01282.html.
- TCWG-395 (1/10)
- Started with a google doc for wiki update
- Speck regression analysis with 4.7, 4.8 Nov and Dec releases (2/10)
- Native build of these versions and rank spec2k benchmarking for all
of them
- Not able to reproduce it on a15 as reported
== Misc ==
1 Day off sick
== Plan ==
- Get all the information required for wiki - TCWG-395
- Start working on TCWG-396