Hi,
Thank you all for an interesting and pleasant experience. I am very
grateful to Linaro for the opportunity to meet and work with such an
amazing group of people. I wish you all the best, and hope to meet you
again (at least online).
You can find me at irar(a)il.ibm.com or ira.rsn(a)gmail.com.
Ira
Summary:
* Read armV7-A/R reference manual; crosstool-ng patches and wrapper scripts.
Details:
1. Patches for crosstool-ng:
* Fix symlink issue when CT_USE_SYSROOT is not enabled.
* Update sample/linaro-arm-none-eabi (baremetal) to disable
SYSROOT. So that both include and lib files are in the same dir.
2. Study armV7-A/R reference manual.
3. Validate embedded toolchain Dec. release.
4. Enhance the wrapper to use crosstool-ng for embedded toolchain.
Plan:
* Ramp-up on gcc.
Best regards!
-Zhenqiang
Submitting patch for Bug #879725:
http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01459.html
Looking at the performance results running SMS with automatic testing.
This is my last week in Linaro so I would also like to thank you all
for the interesting year -- it was a great experience for me to work
in this project. I wish you all good luck and happy holidays!
Revital
Hi,
OpenEmbedded-Core:
* No response on the CSL patches I posted to the ml yet
* khem says someone (other than me) needs to try them
* Linaro binary toolchain
* Runs on Oneiric-X86_64 after installing lsb-core
(interpreter: /lib/ld-lsb.so.3)
* The do_rootfs tasks fails with runtine dependecy issues when
using the external-linaro-toolchain_arm-2011.11.bb recipe.
When re-using my CSL 2011.03 recipe with the linaro toolchain
the error doesn't show up - strange.
* OE-Core build gets confused by the (arm-linux-gnueabi-)pkg-config
of the external linaro toolchain. As a workaround I just renamed
this script.
* The qemuarm MACHINE configuration uses "-march=armv5te -mno-thumb"
Since the linaro toolchain defaults to thumb and -mno-thumb has no
effect some inline assemblies are failing (i.e. on the umull insn).
GNU #47930 suggests using -marm instead -> OE-Core patch posted.
* Got the core-image-minimal to build, but it doesn't run yet
(I suspect some basic runtime dependencies like libc again)
* The build of the sato image fails
(seems libtool and/or C++ related - need to investigate)
Regards
Ken
Hi,
* Continued with comparison of eembc results for gcc4.4 and gcc 4.6 (FSF
and Linaro). Collecting results for 4.6 with loop-unrolling turned off.
* Working on a plotbench.py script that will use matplotlib for plotting
the results. Right now the script plots the geomean value, for instance for
eembc. I now try to make it plot all subtest as well. Then it should also
show relative improvements instead of just the numbers, and then also
sorted from best to worse. This script depends on Michaels script
libtabulate.py for transforming the tabulated file back to python records.
* Will be back January 9
/Regards
Åsa
== GDB ==
* Ongoing work on remote support for "info proc" and core file
generation. Completed implementation of latest solution
via accessing arbitrary files on the remote site, only to
run into a fundamental design problem ... so it's probably
back to the previous approach. Discussion on the list is
ongoing.
* Fixed a GDB 7.4 test suite failure on ARM: PR tdep/12797
* Fixed another GBD 7.4 test suite failure on ARM, by enabling
pthread_t thread debugging on core files.
== GCC ==
* Patch review week.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi there. I've looked further into the intermittent
gcc/testsuite/g++.dg/cdce3.C test failures. Taking Ira's
vectoriser-only fix-pr51301-4.6 branch and comparing it with it's
predecessor r106845:
* cdce3.o itself is identical across compilers
* Fault occurs in a parallel test run as part of the normal auto build
* Fault occurs every time
* Fault occurs with a manual 'make check-gcc RUNTESTFLAGS="dg.exp=cdce*'
* Fault doesn't occur when building from the command line
* Fault doesn't occur after updating binutils
I'm suspicious of the linker. The auto builders are Natty based and
come with ld 2.21.0.20110327. Updating them to Oneiric's
2.21.53.20110810 clears the problem.
I've saved the build trees. I see no reason not to commit
~ramana/gcc-linaro/fix-lp-900426 and ~irar/gcc-linaro/fix-pr51301-4.6.
-- Michael
== GDB ==
* Ongoing work on remote support for "info proc" and core file
generation. Implemented initial version of latest solution
via accessing arbitrary files on the remote site.
== GCC ==
* Started familiarizing myself with current status of various
performance patches in programm, in preparation of my taking
on GCC performance work next year.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Summary
* make check-gcc on windows.
* crosstool-ng patches
Details:
1. Two patches for crosstool-ng:
* Fix the compile error when CT_USE_SYSROOT is not "y". With this
fix, we can config crosstool-ng to remove the symbol link for windows
build.
* Add scripts to build manual for newlib.
2. make check-gcc on Windows:
* Wrap gcc/g++ for windows test. testglue.c should be compiled with
gcc not g++.
* Enhance scripts to convert path using "cygpath -w"
3. Analyze and root cause the pseudo new failed cases on windows.
* gcc fail cases (gcc.dg/cpp/assert3.c, gcc.dg/cpp/include7.c and
gcc.dg/cpp/trad/assert3.c)
Root cause: " in options are removed in the test scripts. e.g.
When reading gcc.log, you can find “-Aabc = jkl” in "Executing
on host" as:
Executing on host: …/cpp/assert3.c -A abc=def -A abc(ghi)
"-Aabc = jkl" …
But in spawn: the “” are removed.
spawn …/cpp/assert3.c -A abc=def -A abc(ghi) -Aabc = jkl
* g++ fail cases (dwarf2/lineno-simple1.C, dwarf2/pr44641.C and
dwarf2/pr46527.C)
The assembler codes generated from windows g++ and linux g++ are
same except the PATH string. And all PASS on linux test.
It seams the scripts can not grep the expected string on windows.
* Tests on windows are not stable. For each test, there will have
random fail cases (pass when retesting separately).
Plans:
* Create Makefile for embedded toolchain in linaro crosstool-ng.
Best regards!
-Zhenqiang
