== Issues ==
* None
== Progress ==
* Jan. 31 - Feb. 6: Chinese Spring Festival holidays .
* Test codes to duplicate shared compares to get more conditional
compares. But still get unexpected bootstrap fail on Chrome book.
* Test codes to enable shrink-wrap for TARGET_APCS_FRAME.
* Update patch for PR 59837.
* Create a reference linaro-arm-linux-gnueabihf-raspbian build .
== Plans ==
* Tuning ccmp performance
* Enable shrink-wrap for TARGET_APCS_FRAME.
== Progress ==
- Started implementing TARGET_ATOMIC_ASSIGN_EXPAND_FENV (5/10)
- Regression testing with the implementation; found some issues and
discussed with Matt
- Working on fixing them
- Patch for Vectorizer generates unaligned access when
-mno-unaligned-access committed upstream (2/10)
- This also triggered some regression with ARMv5 and looking into them
(2/10)
- Set-up qemu aarch64 for gcc testing (1/10)
== Plan ==
- Check ARMv5 regression for unaligned access
- Look into vectorizer cost model/benchmarking
This is an attempt to build TI mcsdk 3.0.3.15 with
bitbake tisdk-server-rootfs-image
It fails trying to make rpms for the linaro toolchain.
| DEBUG: Python function write_specfile finished
| DEBUG: Executing shell function BUILDSPEC
| error: line 4: invalid tag value("^[A-Za-z0-9+._]+$") Release:
Release: r2-arago3
| error: Package has no %description:
external-linaro-toolchain-2.15.armv7ahf_vfp_neon
| Building target platforms: armv7ahf_vfp_neon-oe-linux-gnueabi
| DEBUG: Python function do_package_rpm finished
| DEBUG: Python function do_package_write_rpm finished
| ERROR: Function failed: BUILDSPEC (see
/home2/ghannon/keyDSP/build/mcsdk/build/arago-tmp-external-linaro-toolch
ain/work/armv7ahf-vfp-neon-oe-linux-gnueabi/external-linaro-toolchain-20
13.03-r2-arago3/temp/log.do_package_write_rpm.8491 for further
information)
ERROR: Task 40
(/home2/ghannon/keyDSP/build/mcsdk/sources/meta-linaro/recipes-devtools/
external-linaro-toolchain/external-linaro-toolchain.bb,
do_package_write_rpm) failed with exit code '1'
If I change Release: r2-arago3 to not have a - in the spec file then I
can build the rpms manually with the same command.
Is there a place where I can change that globally?
Gary Hannon
Sr. Software Engineer
CSP Inc.
43 Manning Road Billerica, MA 01821
978-663-7598 x1509
ghannon(a)cspi.com
== Progress ==
* IAS
- Having a go at .dn/.qn aliases
- Some Dwarf 2/3 discussions, kernel build flags, etc
* EHABI
- Tables being generated even when no EH in C
- Will need some tinkering in Clang and LLVM
- Huge discussion about EHABI, Dwarf unwinding and exception tables
- Starting the refactory of EHABI to cope with the differences
* Compiler-RT
- Finding the best way to use compiler-RT with Clang (not an easy task!)
* Background
- Usual patch reviews & discussions
- Mapping AArch64 features implemented for Connect session
- Playing with the Calxedas for some benchmarks
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue with EHABI refactoring
* Implement --rtlib in Clang for compiler-rt usage
* Continue .dn/.qn implementation
== Progress ==
* 3 day week
* Further work on longjmp/setjmp Systemtap probes on ARM (1/10, TCWG-378)
* Research and analysis of malloc workloads for benchmarking (5/10, TCWG-160)
== Issues ==
* None
== Plan ==
* More work on an application level malloc benchmark framework
* Resurrect glibc benchmark graphing script
* newlib release
* gdb 7.7 release (build an rc to troubleshoot releasing from git)
--
Will Newton
Toolchain Working Group, Linaro
Hello Ulrich,
I'm on a freescale mx53 (single core, cortex a8) and trying to find a
nasty problem in our $CUSTOMER's application. Working hardware watch
point support in gdb should solve the problem, or at least brings us a
big step forward. I stumbled over your about three years old thread[1]
about the cortex a8 memory mapped debug registers problem. Do I
understand correctly, that you had a8 watch point running on at least
one board? Have you got any code and or pointers to get watch point
support running?
regards,
Marc Kleine-Budde
[1]
http://lists.linaro.org/pipermail/linaro-toolchain/2011-February/000820.html
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
*Hi LINARO-TEAM,*
I would like start a software development on a “Renesas RZ (ARM Cortex-A9)
MPU (R7S721010xxx” by using Eclipse IDE (Kepler - 4.3.1).
> Global objective = Use free SW development tools
I have read, that the “Linaro GCC Toolchain Release Supports Full Range of
ARM Cortex-A Processors” and it’s an open source software for the ARM
architecture, including the GCC toolchain.
> Well – I think that is what I need.
So, I have installed the Linaro Toolchain
(gcc-arm-none-eabi-4_7-2013q3-20130916-win32.exe) and test the compilation
of the “*Hello World ARM C Project*” for the Target Processor “cortex-A9”
> So, the compilation is OK.
*NOW, I would like prepare a small TEST-Project with FreeRTOS.*
FreeRTOSV8.0.0_Release_Candidate_2
> I have found the “Renesas RZ (ARM Cortex-A9) RTOS Demo”:
http://www.freertos.org/Renesas_RZ_Cortex-A9-RTOS.html
But the two projects are provided to be built with the* IAR Embedded
Workbench <http://www.iar.com/ewarm>* or the *ARM DS-5
<http://arm.com/products/tools/software-tools/ds-5/index.php> embedded
development tools*.
> I have seen that the DS-5 Development Studio is not for free but it use
also the Linaro GNU Compiler (GCC) toolchain.
So, I have tried to import the “Renesas RZ (ARM Cortex-A9) RTOS Demo”
project to Eclipse, *but the import doesn’t work – and I’m not sure that
the project uses the Linaro GNU GCC Compiler**.*
> I think that Demo project for DS-5 use also special plugins/configuration
settings from the Development Studio – so this can’t work ?!…
*HELP:*
*I’m new in the “Eclipse IDE / Compiler (GCC) toolchain” WORLD … *
So, can you help me to give me a good direction - *what I need to do *to
make running this small “Blinky-Demo for Renesas RZ (ARM Cortex-A9) with
the FreeRTOS” by using the Linaro GCC Toolchain.
> Or have you another small Demo project for the Linaro GCC Toolchain which
uses the FreeRTOS for the Renesas RZ (ARM Cortex-A9) family?
… Or you think that is not easily possible to do that for a Newcomer like
me?
I hope that you can help me to put me on the right road.
Best regards,
*Steffen SPRUNGACTIA Automotive*
=================
Software Engineer
=================
*ACTIA* Automotive
5 Rue Jorge SEMPRUN – BP 74215
31432 TOULOUSE Cedex 4 (FRANCE)
Tél.: + 33 (0)5 61 17 68 75
Fax: +33 (0)5 61 55 42 31
Skype: steffen.sprung
EMAIL: steffen.sprung(a)actia.fr
ACTIA: http://www.actia.com
[image: image001]
*P* Avant d’imprimer ce mail, demandez-vous si ceci est nécessaire.
Before printing this email, assess if it is really needed.
Hi,
The systemtap test suite compilation failed with below error.
ARCH: arm
---------------
kernel location:
kernel version: 3.13.0-1-linaro-arndale
systemtap location: /usr/local/bin/stap
systemtap version: version 2.5/0.157, non-git sources
gcc location: /usr/bin/gcc
gcc version: gcc (Ubuntu/Linaro 4.8.1-10ubuntu8) 4.8.1
**** failed systemtap kernel-devel smoke test:
In file included from /usr/local/share/systemtap/runtime/sym.c:16:0,
from /usr/local/share/systemtap/runtime/linux/runtime.h:198,
from /usr/local/share/systemtap/runtime/runtime.h:24,
from /tmp/stapvEzrD5/stap_f7468ebd0051d533d2bae853173fe5a7_892_src.c:24:
/usr/local/share/systemtap/runtime/vma.c: In function '_stp_vma_mmap_cb':
/usr/local/share/systemtap/runtime/vma.c:133:21: error: pointer targets in
initialization differ in signedness [-Werror=pointer-sign]
const char *name = (dentry != NULL) ? dentry->d_name.name : NULL;
^
cc1: all warnings being treated as errors
make[4]: ***
[/tmp/stapvEzrD5/stap_f7468ebd0051d533d2bae853173fe5a7_892_src.o] Error 1
make[3]: *** [_module_/tmp/stapvEzrD5] Error 2
WARNING: kbuild exited with status: 2
Pass 4: compilation failed. [man error::pass4]
**** aborting testing.
Please let me know if you need more information.
Best regards
Naresh kamboju
== Progress ==
* Fixed remaining issues in rework of hwbreakpoint and watchpoint
implementation for arm
native targets. Tested and submitted patch. [TCWG-177] [8/10]
* Installation and Setting up of new desktop machine. [2/10]
== Plan ==
* Run testsuites to see current status of arm gdb.
* Follow up on submitted patches.
* Public holiday on Wednesday 5th February.
* Libsanitizer for AArch64: (4/10)
- seems to be mostly working, but trouble with validation both using
the Foundation Model and qemu-aarch64.
- Some tests seems to loop forever while unwinding under qemu, but
run fine under the Foundation model
- Conversely the Foundation Model shows some random errors, and the
corresponding tests pass under qemu
- Some random timeouts with the Foundation Model, despite using ssh
multiplexing
- Added a small patch to qemu to hande missing mmap flag. Need to
send upstream.
- asked Rob to run GCC testsuite with my patch on AArch64 but it's
too unstable these days
* Cross-validation (2/10)
- script now able to validate a GCC patch and compare results with
unmodified GCC trunk
- added arm-none-eabi target
- using qemu-aarch64 for aarch64-none-linux-gnueabi but the
validations now time out. Need investigation, but I might have to
revert to no execution for this target.
- identified a problem with the recent armv7-ve patch
* Benchmarks: (1/10)
- collecting data for 4.8 tables
* Peeling: (1/10)
- backported new vectorizer cost model to check it if's OK to
include it in our next release
* Misc (2/10): conf-calls, meetings, docs (howtos for TCWG)
== Next ==
* libsanitizer on AArch64
* fix cross-validation on aarch64-none-linux-gnu
* benchmarks: complete table
* backports: chek new vectorizer cost model, monthly branch merge,
review Michael's backports of Crypto intrinsics
* 2 days week (university & child care).
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (0/10)
- No progress this week
o TCWG-345 : Analyse performance of LRA for ARM. (1/10)
- Configured and ran benchmarks on Cortex-a15.
* Looked at Linaro 4.8 release performance on Cortex-a15. (2/10)
* Misc. (1/10)
o Booked Hotel and flight for connect
== Next ==
* Back on LRA and lib GMP
== Progress ==
* Investigate "PGO" for Aarch64 (3/10).
Bootstap testing aarch64 with PGO for GCC.Stage 2, feedback profile in progress.
Tested a small test case for -fbranch-probabilities, works same as x86_64.
Working on checking the "gcda" files generated and profile runs for coremark.
* Cbuild2 discussed with rob, ryan on using cbuild2 for developement. (3/10)
Thanks Rob for fixing some issues and adding features that I
requested. Tested some features added. Captured it as FAQ.
* Reinstalled ubuntu OS on my laptop (2/10)
Misc (2/10)
-------------
AMD internal meetings and did some investigations
== Plan ==
- Continue run EMBCC and coremark benchmarks with -PGO enabled.
- Going on marriage vacation from 07-Feb till 06 March
== Issues===
Follow up upstream libssp GCC discussions. No response yet after 2 pings :(
== Progress ==
* Got binary release building working again. (2/10)
* Added a node_selector to Jenkins for the new Beagle Board Blacks, and
get those working for native builds. (TCWG-379, 1/10)
* Fix configuration of 'build-all' project in Jenkins, now fires up
cross builds for supported targets, plus native builds on
Chromebooks and Beagle Board Blacks. (1/10)
make networking route externally. (TCWG-380)
* Meetings and Misc. (3/10)
* Got TCWG build farm, all nodes offline fixed.
* Wrote wiki page on the build farm.
* Updated Java to 1.6 on the Beagle Board Blacks in the TCWG
build farm.
* Added support to specify an alternate prefix for installation.
* Got QEMU and Foundation Model running on TCWG x86_64 build slaves
so Jenkins can use them for native builds. (TCWG-380 - 2/10)
* Got Rasberry PI softfp image running under QEMU, tried to do
build. (TCWG-380 - 1/10)
== Plan ==
* Build static gdbserver for target via Cbuildv2.
* Add Win32 installer for Canadian cross built binary
releases to Cbuildv2.
* Get Kugan's benchmark branch running on build farm.
* More Jenkins maintainance.
== Potential Leave ==
* Still working out the huge amount of details, but strongly
considering going to Mt Everest after Connect. It'd be a long and
rough trip, but a once in a lifetime opportunity.
== This week ==
- Successfully submitted crypto using git-review
- Completed merge of ILP backports from trunk to Linaro 4.8 branch: 201164,
201165, 201166, 201167, 201168, 201170 and 201175
- Attended ARM architecture training on Friday
== Next week ==
- Submit ILP backports for review using git review
- New backports
== Future ==
== Progress ==
* Rework QEMU patch for AArch32 ARMv8 16<->64bit VCVT (2/10, TCWG-51)
* Further work on longjmp/setjmp Systemtap probes on ARM (4/10, TCWG-378)
* Research and analysis of malloc workloads for benchmarking (4/10, TCWG-160)
== Issues ==
* None
== Plan ==
* Finish testing setjmp/longjmp changes
* malloc benchmarking and improvements
--
Will Newton
Toolchain Working Group, Linaro
== Progress ==
* EHABI
- Turning EHABI on by default on non-Darwin ARM
- Had to add some relocations to MCJIT
- Re-enabled EH tests on test-suite
- Check-all, self-hosting and test-suite bots green
* Compiler-RT
- Enabling RT+San libraries to compile on ARM
- Changing Clang to look for the generic libraries (arm, not armv7l)
* MCJIT
- Remote protocol fixed, all tests passing on self-hosting bot
- All tests re-enabled on ARM
* Background
- More IAS, Compiler RT patch reviews
- Buildbot cleaning up before every build (more stable)
- Cambridge LLVM Social
- Rumours that LLVM can compile the kernel with the integrated assembler
on ARM
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* FOSDEM
- Talking about LLVM auto-vectorization this Sunday
* EHABI
- ARM detected some conflicts with Dwarf stack unwinding, investigate
Compiler-RT
- Run test-suite, benchmarks, applications with it
* IAS
- Confirm the rumours about the kernel compiling clean
- Pick up some remaining task to implement
I had a look at the missing target hook TARGET_ATOMIC_ASSIGN_EXPAND_FENV
to fix the C11 memory model testcase in regressions in trunk.
I looked at the x86 implementation of this target hooks and x86 has
instructions (FNSTENV,FLDENV,FNSTSW,FNCLEX) for feholdexcept,
feclearexcept and feupdateenv. Does ARM has something similar? Any
pointers/links I can refer to.
Please see the gcc internal documentation for the target hook below.
— Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *hold, tree
*clear, tree *update)
ISO C11 requires atomic compound assignments that may raise
floating-point exceptions to raise exceptions corresponding to the
arithmetic operation whose result was successfully stored in a
compare-and-exchange sequence. This requires code equivalent to calls to
feholdexcept, feclearexcept and feupdateenv to be generated at
appropriate points in the compare-and-exchange sequence. This hook
should set *hold to an expression equivalent to the call to
feholdexcept, *clear to an expression equivalent to the call to
feclearexcept and *update to an expression equivalent to the call to
feupdateenv. The three expressions are NULL_TREE on entry to the hook
and may be left as NULL_TREE if no code is required in a particular
place. The default implementation leaves all three expressions as
NULL_TREE. The __atomic_feraiseexcept function from libatomic may be of
use as part of the code generated in *update.
Thanks,
Kugan
== Progress ==
- releases (3/10)
* GCC 4.7 and 4.8 releases done
* more cbuild2 feedback
- cross-validations (2/10)
* followup
* adding capability to test a patch over a given revision on several
targets/cpu/fpu/runtestflags
- libsanitizer on AArch64 (3/10)
* most tests are now functional
* still some errors in the GCC testsuite, to be analyzed (there are
some timeouts, too despite using SSH multiplexing to the Foundation
model)
- misc (2/10): conf-calls and meetings
== Next ==
- libsanitizer on AArch64: analyze errors, try QEMU
== Future ==
On sick leave starting Feb 11th
== Progress ==
* Libc probes support for Aarch64 (2/10).
Wrote a small patch for setjmp and longjmp LIBC probe.
Requested "will newton" to test them .
* Investigate "PGO" for Aarch64 (3/10).
Bootstap testing GCC with PGO for GCC.
Stage 2, feedback profile in progress.
Ran coremark on foundation model with PGO.
The benchmark builds with profile-generate and runs.
"gcda" files are generated and uses them to profile.
Profile generated runs does not run cleanly.
Cross checking if the generated profile is valid.
* Resubmmited libssp machine description support in GCC (2/10).
* Cbuild2 discussed with rob, ryan on SYSROOT installation while building (1/10)
cross compiler for aarch64. "SYSROOT" is expected to be in
/opt/linaro, but cbuild2 does not do this by default.
Misc (1/10)
-------------
AMD internal meetings and did some investigations
== Plan ==
- Run EMBCC benchmarks with -PGO enabled.
- Follow up upstream libssp GCC discussions.
* 4 days week (university).
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (3/10)
- Looking backend places (ARM and AArch64) where reload_in_progress
is used to verify if lra_in_progress is needed as well: Tested lot of
configurations, testsuite results analysis ongoing.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* GMP library AArch64 port review: (4/10)
o Analyzing code generated from C generic implementation vs assembly.
* Misc. (1/10)
o Various meetings.
== Next ==
* Child care (chickenpox)
* Still some time spend at university
* Continue on LRA and lib GMP
== Progress ==
* Implemented per process hwbreakpoint and watchpoint cache for arm
native targets.
Also added a reference count for per thread hardware breaks. [TCWG-177] [7/10]
* Travelled to Islamabad for Macau visa application. [3/10]
== Plan ==
* Continue work on forking/vforking hardware breakpoints support for arm-native.
Tweak hardware breakpoint cache and thread breaks reference count to
get it in sync with linux-native. [TCWG-177]
== Misc ==
- Monday 27/01/2014 - Public holiday
== Progress ==
- LP#1191909: gold and -flto always fails with an internal error on
arm-linux-gnueabi* (2/10)
- Reproduced it and Looking into the implementation for best fix.
-c11-atomic-exec-5.c (4/10)
- Issue is due to missing target hook and looking at implementing
-LP#1270789: gcc 4.8: "invalid expression as operand" in aarch64
inline asm (2/10)
- came-up with the patch. Still in the process of testing it. APM1
disc seems to be corrupt and that is holding this.
- Benchmarking (1/10)
- added -pgo for coremark
- Set-up a Linux desktop (1/10)
== Plan ==
- Continue with trunk daily regression
- Fix assigned bugs
== Progress ==
* Improve binary releases produced by Cbuildv2. (6/10 TCWG-383)
* Minor changes to source releases produced by Cbuildv2. (1/10)
* Added support to Cbuild to use lsbcc for binary releases. (1/10)
* Meetings. (1/10)
* Started reviewing Kugan's benchmarking branch of Cbuildv2. (1/10)
== Plan ==
* Build static gdbserver for target via Cbuildv2.
* Add Win32 installer for Canadian cross built binary
releases to Cbuildv2. (TCWG-381)
* Once Jenkins has a node_selector for the new Beagle Board Blacks,
get those working for native builds. (TCWG-379)
* Get QEMU and Foundation Model running on TCWG x86_64 build slaves
so Jenkins can use them for native builds. (TCWG-380)
== Progress ==
* Add support for AArch32 ARMv8 16<->64bit VCVT to QEMU (2/10, TCWG-51)
* Triage and report AArch64 gcc bug when building glibc with SystemTap (1/10)
* Debug and submit patch for ARM libffi issue (1/10)
* Add support for longjmp/setjmp Systemtap probes on ARM (4/10, TCWG-378)
* Ported Python cffi package to AArch64, submitted upstream (1/10)
* Fixed bug building glibc for armv4 (1/10)
== Issues ==
* Broadband down for 3 hours on Wednesday afternoon
== Plan ==
* Follow up QEMU patches and maybe post v2
* malloc
--
Will Newton
Toolchain Working Group, Linaro
== Progress ==
* Compiler-RT
- Changing CMake to make it compile on ARM
- Reviewing long div/mod patches for ARMv4/v5/v6, testing and benchmarking
* EHABI
- Investigating EH code generation (landing pads, jump tables, libs)
- Running test-suite EH tests, some failures
* Background
- Loads of patch reviews on IAS, build attributes, EHABI, compiler-rt
- Planning the 3.4.1 release (the first patch-release of LLVM)
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue EHABI tests, try to turn it on by default
* Continue working on RT's CMake for ARM
* Prepare the FOSDEM 14 presentation
== This week ==
- Completed merge of crypto backports from trunk to Linaro 4.8 branch:
- 64-bit backports: 205092, 205383, 205384, 206114, 206115, 206117, 206118,
206149
- 32-bit backports: 206518 AND 206519
- Built and tested 32 and 64-bit compilers with crypto changes
== Next week ==
- Submit backports for review using git review
- New backports
== Future ==
== Progress ==
Deferred US Holiday (MLK day) from Monday to Tuesday
* Debugged what was thought to be a cbuild2 problem but ended up being
due to default enablement of multilib in gcc. (2/10)
* Started working on adding mulit-lib support to cbuild2 (minimal
configuration for installing headers). (8/10) [Jira card forthcoming]
- Moved kernel headers installation to arch based directory in
sysroot and then symlinked appropriate host include directories to
common arch directories.
- Figured out how to build multilib arm libraries for
arm-none-linux-gnueabihf and arm-none-linux-gnueabi.
== Plan ==
* Add cbuild2 scripting to build multilib libraries based on gcc
-print-multi-lib
* Figure out how to get gcc to select the correct multilib headers
directory so that we don't need a merged include directory.
== Issues ==
* None
The Linaro Toolchain Working Group is pleased to announce the
release of both Linaro GCC 4.7 and 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 first stable release, and contains no
known regressions compared to the 2013.12 release.
The next release of GCC 4.7 will be the 2014.04 stable release. There
will be no engineering releases of GCC 4.7 in 2013.02 or 2013.03.
The next stable release of GCC 4.8 will be the 2014.04 release. Next
month's release - 2013.02 - will be an engineering build.
Linaro GCC 4.7 2014.01 is the twenty second release in the 4.7
series. Based off the latest GCC 4.7.4+svn206380 release, this is the
ninth release after entering maintenance.
Interesting changes include:
* Updates to GCC 4.7.4+svn206380
Linaro GCC 4.8 2014.01 is the tenth release in the 4.8 series. Based
off the latest GCC 4.8.3+svn206350 release, it includes performance
improvements and bug fixes.
Interesting changes include:
* Updates to GCC 4.8.3+svn206350
* Enhanced multilib support
The source tarballs are available from:
http://releases.linaro.org/14.01/components/toolchain/gcc-linaro/4.7http://releases.linaro.org/14.01/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 pages:
https://launchpad.net/gcc-linaro/4.7/4.7-2014.01https://launchpad.net/gcc-linaro/4.8/4.8-2014.01
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 ==
* Got got Beagle Board blacks up, installed all necessary
dependencies to build toolchains. (TCWG-379 - 1/10)
* Installed QEMU and Foundation model on all TCWG x86_64 build
slaves. (TCWG-380 - 1/10)
* Minor bug fixes for Cbuildv2 produced source tarballs to be
hopefully now 100% match with what we usually release. (2/10)
* More major bug fixes and some refactoring for Cbuildv2 produced
binary tarballs to match with what we usually release. (3/10)
* Meetings. (1/10)
== Plan ==
* Build static gdbserver for target via Cbuildv2.
* More work on binary tarball building.
* Add Win32 installer for Canadian cross built binary
releases to Cbuildv2. (TCWG-381)
* Once Jenkins has a node_selector for the new Beagle Board Blacks,
get those working for native builds. (TCWG-379)
* Get QEMU and Foundation Model running on TCWG x86_64 build slaves
so Jenkins can use them for native builds. (TCWG-380)
== Issues ==
* I got invited to Mt Everest last week... :-)
* 4 days week (still some times spent at university).
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (3/10)
- Most of the issues fixed or about to be fixed by Vladimir :
* iWMMXT issue and Thumb1 udivmoddi4 : fixed.
* Thumb1 code size issue : partial patch proposed.
- Looking backend places (ARM and AArch64) where reload_in_progress
is used to verify if lra_in_progress is needed as well.
Validation ongoing.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* Loop specialisation patch review: (1/10)
o Sent feedback to Samsung.
* 2014.01 release: (1/10)
o Branch merge review
* [Bug 1258013] Re: Cannot build arm64 kernel with CONFIG_DEBUG_INFO=y (1/10)
o Issue due to a wrong .align directive in an assembly source file which is
already fixed upstream.
* GMP library sAArch64 port review: (1/10)
o Started to review Anil work.
* Misc. (1/10)
o Various meetings.
== Next ==
* Still some time spend at university
* Continue on LRA and lib GMP.
- 2014.01 releases: (2/10)
* 4.7 ready, 4.8 needed a short daily to include our multilib patch
to support our binary releases.
* retried cbuildv2 and sent feedback. Should be mostly OK by now.
- cross-validations: (2/10)
* followup-up, bugzilla
* thinking about short term Neon intrinsics testsuite use without dejagnu
- libsanitizer (2/10)
* resumed work for aarch64
- misc (2/10): conf-call and meetings
- internal support (2/10)
* issue:
boards used for benchmarking have been off for several weeks. Pending
jobs disappeared from the list, but I got no log.
== Progress ==
* Implement fork over HW breaks support for arm native targets.
[TCWG-177] [6/10]
* ARM Process Record:
- All patches accepted and upstream.
- Spent time making changes to VFP, SIMD etc patch. [2/10]
- Configuration and Git ssh setup for gdb commit rights . [1/10]
* Submitted a new fix and worked with community for the fix. [1/10]
== Plan ==
* Continue to work on fork over HW breaks support for arm native
targets. [TCWG-177]
* Patch updates and submission to all in progress upstream submissions.
* Travel to Islamabad for Macau visa application.
== Progress ==
* Libc probes support for Aarch64.
Testing the patch for "libc" probes support to "__longjump".
Native compiling in openemebedded.
Obtained a Linaro open embedded image with system tap enabled.
Getting Assembler Error during "malloc" module linking in "glibc"
configured with --enable-systemtap.
In libc_mallopt invalid "asm", invalid expression as operand for
LIBC_PROBE call.
Cross compiling.
Tried copying header files from system tap source to SYSROOT for cross
compiling glibc. The cross compiled GCC does not recognize the header
files.
* Investigate "PGO" for Aarch64.
Started bootstap testing GCC with PGO for GCC.
Stage 1 completed. stage profile in progress.
== Plan ==
- Run EMBCC benchmark with -PGO enabled.
- Work on "glibc" probe.
== Issues ==
Waiting for feedback on "libssp" machine descriptions changes.
Misc
------
14-Jan-2014 Local holiday.
== Issues ==
* None.
== Progress ==
* Test Linaro cbuildv2.
- Write a reference script to support windows installer in cbuildv2.
- Do some basic validation work against the binaries built from cbuildv2.
* Reproduce and work out a patch for "ICE when building
linux-linaro-tracking" (lp:1268893, PR59837) .
* Test to merge Linaro local armv4t multilib patch to Linaro 4.8.
* Investigate CCMP chance by taking a Bool_ var as var != 0.
== Plans ==
* cbuildv2 validation
* Tuning ccmp performance
== Planed leaves ==
* Jan. 31 - Feb. 9.
== This week ==
- Completed merge of crypto backports 206128, 206130, 206131, 206132 and
206149 from trunk to Linaro 4.8 branch
- Out sick Friday
== Next week ==
- Build and test crypto backports
- Begin merging aarch64 crypto backport to Linaro 4.8 branch
== Future ==
== Progress ==
* Cbuildv2 fix for *_release() functions which were changing out of
the build directory but then not changing back to the builddir, which
caused problems with paths relative to the builddir. (1/10)
* TCWG-340 Enable Glibc remote testsuite integration - (7/10)
- Working with upstream community on scoping and designing remote
testsuite integration.
- Setting up arm chroot environment on chromebook with documentation
on how to make this reproduceable.
* TCWG-352 AArch64 clone is missing some CFI markup - (2/10)
- Setup aarch64 environment for testing and built static clone tests
to test the patch.
== Plan ==
* Start implementing (code) for glibc remote testsuite integration.
== Issues ==
None
== Progress ==
* Buildbots
- Odroid U2 died after a few days on USB stick, too. (I guess we're stuck
with Chromebooks)
- Upgrading chromebooks (to Saucy) due to a new GCC/libstdc++ 4.7+
restriction
- Shuffling chromebooks, we now have three buildbots:
- llvm-chrome-01: quick-build+check
- llvm-chrome-02: self-host+check
- llvm-chrome-03: test-suite
* MCJIT Remote
- Re-factored the communication protocol of MCJIT for remote processes
- Still seeing one random failure on ARM, investigating
* Compiler-rt
- Investigating how to get it compiling all libraries and sanitizers on ARM
* Background
- Patch reviews, especially IAS and EH
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue MCJIT and Compiler-RT investigations
* Continue reviewing IAS and EH patches
* Try to run the EH tests on the test-suite with the current changes
== Progress ==
* Add support for AArch32 ARMv8 VRINT to QEMU (4/10, TCWG-50)
* Add support for AArch32 ARMv8 VCVT to QEMU (4/10, TCWG-49)
* Add support for AArch32 ARMv8 16<->64bit VCVT to QEMU (1/10, TCWG-51)
* Fixed gas ARM VCVT encoding bug (1/10)
== Issues ==
* None
== Plan ==
* Complete outstanding QEMU work
* ARM setjmp/longjmp SystemTap probes
* malloc
--
Will Newton
Toolchain Working Group, Linaro
Hi,
I've been playing with linux-linaro-tracking and the 2013.12 (and
2013.10, 2013.11) toolchain release and when turning on the NEON in
kernel option I get:
CC lib/raid6/neon4.o
lib/raid6/neon4.c: In function 'raid6_neon4_gen_syndrome_real':
lib/raid6/neon4.c:113:1: internal compiler error: in
dwarf2out_frame_debug_adjust_cfa, at dwarf2cfi.c:1078
}
^
Use the attached .txt as .config and do 'make zImage' to replicate the
problem. You will probably need to attached patch as well since some of
the linaro patches break namespace support :(
regards,
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
* Two days week (due to compilation courses given at university).
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (1/10)
- iWMMXT issue : back on the issue.
- Thumb1 issues : looked at bugzilla's reports.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* Loop specialization patch review: (1/10)
o Back on the task.
* [Bug 1258013] Re: Cannot build arm64 kernel with CONFIG_DEBUG_INFO=y (1/10)
o Tried to reproduce the issue.
* Misc. (1/10)
o Catching up with email, etc
o Meeting
== Next ==
* Still some time spend at university
* Continue the ongoing tasks.
* Branch merge reviews.
== Progress ==
* ARM Process Record:
- Follow up on patches, almost all patches accepted. [0.5/10]
- Got GDB committ rights and set up git for pushing patches. [0.5/10]
* Spent time to read through fortran functions prologue to find a new fix
for TCWG-267. [1/10]
* Initial investigation of handling breakpoint over fork [TCWG-177] [1/10]
* Getting documentation ready for Macau visa application [2/10]
== Plan ==
* Update and send patches where required and committ all approved patches.
* Work on breakpoints issues [TCWG-177] and reverse stepping through solib
issue [TCWG-315]
* Apply for Macau visa, given all documents get ready.
== Progress ==
* Libc probes support for Aarch64.
Posted patch for "libc" probes support to "__longjump". Worked on
review comments from Maintainers. Upstream discussions in progress.
Working on testing "glibc" by using --enable-systemtap.
* Experimented with "Cbuildv2" native building.
== Plan ==
- Continue Cbuildv2.
- Investigate "PGO" for Aarch64.
- Work on "glibc" probe.
== Issues ==
Waiting for feedback on "libssp" machine descriptions changes.
misc
===
14-Jan-2014 leave.
== Progress ==
* Draft wiki page (under ACL--let me know if you want to see) for
instructions for setting up chroots on chromebooks for glibc testing:
https://collaborate.linaro.org/display/~ryan.arnold@linaro.org/Configuring+…
* Investigated expanding remote testing possibilities in glibc.
* RFC email to libc-alpha discussing proposal for glibc host testsuite
in chroots:
https://sourceware.org/ml/libc-alpha/2014-01/msg00222.html
== Issues ==
* Shortened week (3-days) because of unplanned school closures on
Monday and Tuesday due to freezing temperatures, during which I had to
watch my kids.
== Plan ==
* Start code scaffolding for glibc host testsuite in chroot.
* Start cbuild2 scaffolding for building remote chroots for glibc testing.
* Add glibc multi-lib builds and IFUNC system libraries.
* Work on cbuild2 support for local tar files.
== Progress ==
* Two day week
* Catching up on email etc. after break (0.5/10)
* Investigate setjmp/longjmp SystemTap probe support in ARM glibc
(1/10, TCWG-378)
* Investigate toolchain bug reports for ARM and AArch64 (0.5/10)
== Issues ==
* None
== Plan ==
* Resume QEMU ARMv8 AArch32 work
* Hopefully push glibc ARM pointer encryption fix for 2.19
--
Will Newton
Toolchain Working Group, Linaro
- 2013.12 releases (1/10)
* Sent announcements for 4.7 and 4.8 releases.
- 2014.01 releases (2/10)
* Created 4.7 and 4.8 branch merge requests (had handle some conflicts in 4.8)
* Looked at backporting the crypto intrinsics support into 4.8, but
there are dependencies with several other patches we haven't
backported yet.
- cross validation (4/10)
* Restarted them since I had to stop them during the holidays. Still
catching up with the backlog, should be OK during the week-end.
* Analyzed and reported several regressions or new tests failing in
some configurations.
- Neon intrinsics tests (1/10)
* Looked at Rob's neon-intrinsics branch and sent him some feedback.
- misc (2/10): conf-calls and meetings.
== Next ==
- 2014.01 releases
- cross-validation: look at results and report regressions if any
- resume libsanitizer work for AArch64
== Progress ==
* Release 3.4 went out
* Buildbots
- Using powered USB hub for the external harddrive, but all boards fail
one time or another...
- Maybe it's the hard-drive type (mobile, power-saving), reverting to USB
sticks for now
- Leaving an odroid U2 running on USB stick for a week, used to work...
- C++11 features will need GCC 4.7+, looking for an easy way to upgrade
the Chromebooks
* MCJIT
- Finished work on remote MCJIT to re-enable the failing tests
- http://llvm-reviews.chandlerc.com/D2527
* Pragma Vectorize
- New discussions hint that my parser patch is moot, for now
- Agreement is to use C++11 attributes for now, and add pragmas later
- I can't continue implementing them, though...
* Background
- Huge number of patch reviews during holidays & this week
- Good progress on new features for the IAS
- More progress on EHABI, including IAS support
* Time
- CARD-862 8/10
- Others 2/10
== Plan ==
* Continue reviewing IAS features, maybe implement some
* Work out how to create a libcxx bot
* re-introduce llvm-chrome-01 as second self-host
* Migrate all buildbots to GCC 4.7+
* Check out EHABI tests and assess progress
Hi,
I filed this on bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59744 but I thought I'd
mention it here too.
This slightly strangely written program (it's distilled down from
frame_offset_overflow in the gcc source itself) should print "bigger" if
the first argument is bigger than 10 (or negative, but let's ignore that
please):
#include <stdlib.h>
#include <stdio.h>
int a[2] = { 10, 20 };
int
is_bigger (long offset, int index)
{
unsigned long size = -offset;
if (size > a[index])
{
printf("bigger\n");
return 1;
}
return 0;
}
int
main (int argc, char** argv)
{
long v;
v = atol(argv[1]);
is_bigger(-v, 0);
return 0;
}
When compiled at -O1 or above (and with inlining disabled at -O2 and
above), though, it bungles the 0 case:
(t-doko)mwhudson@arm64:~$ gcc-4.9 -O3 test.c -o test -fno-inline -Wall
(t-doko)mwhudson@arm64:~$ ./test 1
(t-doko)mwhudson@arm64:~$ ./test 11
bigger
(t-doko)mwhudson@arm64:~$ ./test 0
bigger
(t-doko)mwhudson@arm64:~$ gcc-4.9 -O0 test.c -o test -Wall
(t-doko)mwhudson@arm64:~$ ./test 1
(t-doko)mwhudson@arm64:~$ ./test 11
bigger
(t-doko)mwhudson@arm64:~$ ./test 0
(t-doko)mwhudson@arm64:~$
What's going on? Here's the disassembly of is_bigger (at O3):
0000000000400608 <is_bigger>:
400608: b0000082 adrp x2, 411000 <_GLOBAL_OFFSET_TABLE_+0x28>
40060c: 91010042 add x2, x2, #0x40
400610: a9bf7bfd stp x29, x30, [sp,#-16]!
400614: 52800003 mov w3, #0x0 // #0
400618: 910003fd mov x29, sp
40061c: b8a1d841 ldrsw x1, [x2,w1,sxtw #2]
400620: ab00003f cmn x1, x0
400624: 540000a2 b.cs 400638 <is_bigger+0x30>
400628: 90000000 adrp x0, 400000 <_init-0x3f8>
40062c: 911b6000 add x0, x0, #0x6d8
400630: 97ffff90 bl 400470 <puts@plt>
400634: 52800023 mov w3, #0x1 // #1
400638: 2a0303e0 mov w0, w3
40063c: a8c17bfd ldp x29, x30, [sp],#16
400640: d65f03c0 ret
Basically it seems that the condition "-offset > val" is being compiled
as "val + offset does not overflow", which is not valid for offset == 0.
This seems to me to be the underlying cause behind
https://bugs.launchpad.net/ubuntu/+source/gcc-4.8/+bug/1263806 ("gccgo
fails to compile tomb.go on arm64").
Cheers,
mwh
Hi,
We are trying to build android Kitkat (for our own platform) using
linaro android toolchain version
4.7.4 from 13.12 release. We are observing following while compiling
some shared libraries:
~arm-linux-androideabi-4.7/bin/../libexec/gcc/arm-linux-androideabi/4.7.4/real-ld:
warning: shared library text segment is not shareable
~arm-linux-androideabi-4.7/bin/../libexec/gcc/arm-linux-androideabi/4.7.4/real-ld:
error: treating warnings as errors
We tried to suppress thisn warning by setting LDFLAGS but the
tool-chain does not seem to identify this flag:
LOCAL_LDFLAGS := --no-warn-shared-textrel
We need some help to fix this, so posting on both android and
tool-chain mailing lists.
Thanks,
Sandeepa
Hi folks,
As most of you are on the GNU side of the fence, I believe this is the
right crowd to first ask this question, before attempting a wider audience.
For a while, Clang/LLVM wasn't in any position to add unheard-of features,
and most of what we needed would be covered by something GCC already did.
But in the last year or so, there were a number of "features" we'd like to
add that aren't present in GCC (like pragmas, attributes, asm directives)
which is neither part of the language specifications, nor something that
another standard (like OpenMP or ABIs) already support.
As a concrete example, we're trying to come up with some vectorisation
annotation and there is a heated discussion on whether it should be C++11
attributes, pragmas, or changing the __attribute__ semantics to allow it to
be used in lexical blocks, not just declarations. Any of that, but most
strikingly the latter, would add Clang-specific behaviour which GCC
probably won't implement, and we all know how that feels.
In this discussion, and others regarding ARM-specific behaviour (notably
about assembly directives), I have used the same argument twice already, so
it's time to ask the GCC crowd once and for all:
For non-standard, domain or platform specific changes, do we want to have a
joint task force, GCC+LLVM, to homogenize the efforts in extending the
languages we support in the same say, so that we can call it the "OSS
Compiler Extensions" (or whatever) instead of two separate GCC-extensions
and Clang-extensions?
Historically, GCC has *a lot* more extensions, so this new standard would
probably be 99% GCC, but the goals of such a task force for the future
would be to:
1. Make sure all OSS compilers implement the same extensions, when they so
chose. So, extensions to the language should go in a shared forum, and not
to Clang/GCC lists.
2. Document each extension and record all discussions (threads, bugs, etc),
so that new compilers can have an easier time implementing them.
3. Reason about the existing hazardous or redundant extensions, and mark
them for deprecation.
This is also pertinent to the Linux kernel, which is driving its own task
force to compiler the kernel with Clang, so that it can rid itself from
outdated GNU extensions that lingered for far too long in their code.
I appreciate the size of this proposal, the political issues and the
endless discussions, but this is the same on every standard committee, and
I'd rather have something than nothing at all.
Perhaps, as it happened before, some of these changes could be more easily
persuaded to move back to the language standards and platforms ABIs, than
if it's just implemented, undocumented, by one compiler.
So, ignoring just for a moment the political side of it, would that make
technical sense for the GCC community as well?
cheers,
--renato
Folks,
Since LLVM is moving on to C++11, I need to replace our buildbot GCCs with
4.7+ (the new minimum requirement), but I'd like to use whatever is the
most stable and modern GCC version for native compilation. I could get the
latest and greatest on our repository, but I know how compilers are
written, and pardon me if I don't trust new releases... ;)
Does any one have an opinion on which is the most stable, preferably 4.8,
release of native ARMv7 GCC binaries?
For some odd reason, we just release cross-compilers, so, in that case,
where would I look for a native GCC, other than in my Ubuntu/Arch
repositories? ARM? CodeSourcery?
I *really* don't want to compile it myself... My lack of available fast ARM
hardware is disturbing, and I don't want to spend a week cross-compiling
GCC.
cheers,
--renato
== Progress ==
* Pointer mangling Aarch64 glibc.
Worked on review comments from Maintainer. Rebased and posted the patch.
Upstream completed and closed the card.
https://cards.linaro.org/browse/TCWG-373
* Experimented with Cbuildv2 native building.
== Plan ==
- Continue Cbuildv2.
- Investigate PGO for Aarch64.
== Issues ==
Waiting for feedback on libssp machine descriptions changes.
== Issues ==
* None
== Progress ==
* One day off (Jan. 1)
* Do some basic validations for 2013.12 toolchain binaries release.
* R/M Mac toolchain validation
* Branch-cost related tuning for Cortex-M.
== Plans ==
* Continue on branch-cost related tuning.
== Progress ==
- Short week (4 Days)
- TCWG-291 zero/sign extension elimination 4/10
- made re-factoring and ran the regression
- benchmarking in progress
- TCWG-134 divmod 4/10
- converted into latest pass structure and re-based the patch
- found some regression failures and fixed them
- regression testing ongoing
== Plan ==
- post divmod and vrp patches
== Progress ==
* ARM Process Record: [TCWG-336] [TCWG-338] [TCWG-339][TCWG-317] [TCWG-315]
- Configured and learnt to use git format-patch and git send-email. [1/10]
- Incorporated and tested changes suggested by maintainers in previous
arm process record patches. [2/10]
- Created a new patch series indicating bug fixes separate from features. [1/10]
- Submitted version 2 of arm process record replay improvements.
* Debugging of stepping over and single stepping heurisitic code.
[TCWG-315] [4/10]
* Review of open JIRA cards and pending patches [1/10]
* Time off for setting up new office space. [0.5/10]
* Macau visa information gathering and document preparation [0.5/10]
== Plan ==
* Reverse engineering stepping code heuristics in gdb to find a fix
for reverse debugging of solib code on arm. [TCWG-315]
* Find and submit a new fix for TCWG-267.
* New office space setup and Macau visa application, will be away from
my desk for few hours.
Just before having to rename it to 2014, the Linaro Toolchain and Builds
and Baselines Working Groups are pleased to announce the 2013.12 release of
the Linaro Toolchain Binaries, a pre-built version of Linaro GCC and Linaro
GDB that runs on generic Linux or Windows and targets the glibc Linaro
Evaluation Build.
Uses include:
* Cross compiling ARM applications from your laptop
* Remote debugging
* Build the Linux kernel for your board
What's included:
* Linaro GCC 4.8 2013.12
* Linaro GDB 7.6.1 2013.12
* Linaro Binutils 2.24 2013.12
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link your
programs against.
Interesting changes include:
* Binutils has been updated to 2.24, bringing many improvements
* Various bugs have been fixed
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian 6.0.2,
Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation 5.7 and
later, and should run on any Linux Standard Base 3.0 compatible
distribution. Please see the README about running on x86_64 hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://releases.linaro.org/13.10/components/toolchain/binaries/
Need help? Ask a question on https://ask.linaro.org/
Already on Launchpad? Submit a bug at
https://bugs.launchpad.net/linaro-toolchain-binaries
On IRC? See us on #linaro on Freenode.
Other ways that you can contact us or get involved are listed at
https://wiki.linaro.org/GettingInvolved.
== Progress ==
* Pointer mangling Aarch64 glibc.
Posted patch on pointer mangling. Worked on review comments from maintainer.
Tested on V8 foundation model.
== Plan ==
- Continue working on review comments for Pointer Guard support in
Aarch64 glibc,
- Continue Cbuildv2.
- Investigate PGO for Aarch64.
== Issues ==
Waiting for feedback on libssp machine descriptions changes.
== Issues ==
* None
== Progress ==
* One day off (Dec. 27).
* Prepare toolchain binaries release
- Backport the newlib patches for ftruncate() and truncate() stubs
- Test and update binutils version to linaro-2.24-2013.12 and
workaround gold compile fail issue.
* Retest -fira-loop-pressure performance on cortex-m4. But get
regression in several suites of eembc-v1. Will re-investigate it when
aarch64 performance test is ready since it is enabled in ia64 and
rs6000, and the comment says:
/* Numerous experiment shows that IRA based loop pressure
calculation works better for RTL loop invariant motion on targets
with enough (>= 32) registers. It is an expensive optimization.
So it is on only for peak performance. */
* R/M toolchain related work.
== Plan ==
* Linaro toolchain binaries 2013.12 release
== Progress ==
* ARM Process Record made the changes pointed out in maintainers
comments. [3/10] [TCWG-336] [TCWG-338] [TCWG-339]
- Put the new bug fixes patches on hold as they can be sent in the
same series.[TCWG-317] [TCWG-315]
* Time off for setting up new office space. [4/10]
- Found a good room for office in a central location, need to get
internet and other stuff working before shifting. I will get started
on that once I get the possession of the space next week.
* Time off for Macau visa information [1/10]
* 25th December Public Holiday [2/10]
== Plan ==
* ARM Process Record:
- Create new patches as per maintainers suggestions, incorporating bug
fixes as separate patches in the list.
- Test and send all patches upstream.
* New office space setup, will be away from my desk for few hours.
Hi,
seen in a segfault running the tests in the coinor-osi package,
https://launchpad.net/bugs/1263576, both in saucy and trusty, version 0.106.4
and 0.106.5. Version 0.103 doesn't show the issue.
both the 4.7 and 4.8 linaro branches show this behaviour, and trunk 20131121
(didn't build a newer one yet).
William Grant tracked that down to a bug with very negative vcall_offsets in
aarch64 multiple inheritance thunks. The example below has two consecutive
thunks, with the second adding 263 instead of subtracting 264.
aarch64_build_constant seems to not handle negative integers. He tried a quick
gcc patch to avoid using aarch64_build_constant, and the coinor-osi tests succeed.
0000000000401ca4 <_ZTv0_n256_N1C2adEv>:
401ca4: f9400010 ldr x16, [x0]
401ca8: f8500211 ldr x17, [x16,#-256]
401cac: 8b110000 add x0, x0, x17
401cb0: 17fffff9 b 401c94 <_ZN1C2adEv>
[...]
0000000000401cc4 <_ZTv0_n264_N1C2aeEv>:
401cc4: f9400010 ldr x16, [x0]
401cc8: d28020f1 mov x17, #0x107 // #263
401ccc: f8716a11 ldr x17, [x16,x17]
401cd0: 8b110000 add x0, x0, x17
401cd4: 17fffff8 b 401cb4 <_ZN1C2aeEv>
Any chance for a quick 2013 review?
Thanks, Matthias
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -2540,8 +2540,8 @@
addr = plus_constant (Pmode, temp0, vcall_offset);
else
{
- aarch64_build_constant (IP1_REGNUM, vcall_offset);
- addr = gen_rtx_PLUS (Pmode, temp0, temp1);
+ aarch64_add_constant (IP0_REGNUM, IP1_REGNUM, vcall_offset);
+ addr = temp0;
}
aarch64_emit_move (temp1, gen_rtx_MEM (Pmode,addr));
== Progress ==
* Lots of little changes to the Jenkins configure files and
Cbuildv2 so Jenkins can do a builds in a 32 bit chroot. (4/10)
* Misc - meetings and misc tasks (2/10).
* Helped with binutils & GCC releases. 4/10)
* New Arndale Octa arrived.
== Plan ==
* Get back to adding the neon intrinsics tests to the GCC
testsuite.
* More Jenkins hacking for 32bit chroot builds.
* More hacking on binary release automation.
* Review Kugan's benchmarking support in Cbuildv2.
== Issues ==
* Loosing ssh access to many of the machines we work on is a
problem...
== Leave ==
* A bit complicated. On the road till Jan 13, offline some, mixed with
some work days depending on the weather. Should have email
access most nights.
Hi All,
I am getting a weird error while building binutils from
http://cbuild.validation.linaro.org/snapshots/Latest/binutils-linaro-2.23.2…
GCC version gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
Ubuntu 13.10
Steps:
1)
/work/sources/binutils/configure --target=aarch64-unknown-linux-gnu
--prefix=/work/builds/gcc-fsf-trunk/tools
--with-sysroot=/work/builds/gcc-fsf-trunk/sysroot-aarch64-unknown-linux-gnu
2)
make
(Snip)
gcc -c -DHAVE_CONFIG_H -g -O2 -I.
-I/work/sources/binutils/libiberty/../include -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic
/work/sources/binutils/libiberty/regex.c -o regex.o
In file included from /work/sources/binutils/libiberty/regex.c:128:0:
/usr/include/stdlib.h:510:35: error: expected ‘,’ or ‘;’ before
‘__attribute_alloc_size__’
__THROW __attribute_malloc__ __attribute_alloc_size__ ((2)) __wur;
^
make[2]: *** [regex.o] Error 1
make[2]: Leaving directory
`/work/builds/gcc-fsf-trunk/obj-aarch64-unknown-linux-gnu/binutils/libiberty'
(Snip)
Can anyone point me what is going wrong here.
regards,
Venkat,
### About Linaro binutils
Linaro binutils is a release of the GNU binutils with bug fixes and
enhancements for ARM platforms. GNU binutils is a collection of tools
including the ld linker and as assembler.
### Linaro binutils 2.24 2013.12
The Linaro Toolchain Working Group is pleased to announce the 2013.12
release of Linaro binutils 2.24.
This release is based on the latest GNU binutils 2.24 stable branch, but
with additional features and bug fixes.
### Additional Features
* Support for GNU indirect functions
### Bug Fixes
* Fixed miscalculation of GOTPLT offset for ifunc syms
* Handle static links with ifunc correctly
* Fixup IFUNC tests to work on all targets
### Source
### Release Tarball
* https://releases.linaro.org/13.12/components/toolchain/binutils-linaro
### Development Tree
* git://git.linaro.org/toolchain/binutils-gdb.git
This release was built from the linaro_binutils-2_24-2013_12_release tag.
### Feedback and Support
Subscribe to the important Linaro mailing lists and join our IRC channels to
stay on top of Linaro development.
* Linaro Toolchain Development [mailing
list](http://lists.linaro.org/mailman/listinfo/linaro-toolchain)
* Linaro Toolchain IRC channel on irc.freenode.net at `#linaro-tcwg`
* Questions? [ask Linaro](http://ask.linaro.org/).
* Interested in commercial support? inquire at [Linaro
support](mailto:support@linaro.org)
== Issues ==
* none
== Progress ==
* LRA on AArch32:
o TCWG-343 : Make LRA the default for the ARM backend (8/10)
- Validated and committed a fix from Vladimir for Thumb1 issues.
- iWMMXT issue : Tried a fix without success, continue working on it.
o TCWG-345 : Analyse performance of LRA for ARM. (0/10)
- No progress this week.
* Various meetings. (2/10)
== Next ==
* Vacation
== Progress ==
* Debugged and Fixed process record memory corruption problem.
[TCWG-315][TCWG-317][8/10]
* Sick Time off [2/10]
== Plan ==
* Send patches for bug fixes and look into remaining arm-native gdb issues.
* Respond to maintainer's suggestion on process record patches.
* Public Holiday on 25th
* Time off for setting up new office space.
== Progress ==
* Libssp GCC patch
Replied to Marcus comments on libssp machine description support for
stack protect and test. Analyzed other ports implementations on
clearing register that loaded canary value. Waiting for his feedback.
* Pointer mangling Aarch64 glibc.
Investigated mangling support and implemented a patch. Testing glibc
test suites in V8 Foundation model is in progress.
* Attend Linaro Tool chain status meeting.
* Attend 1-1 with Christophe (Linaro).
* Attend 1-1 with Matt (Linaro) .
== Plan ==
- Pointer Guard support in Aarch64 glibc
- Continue tesing Cbuildv2
== Issues ==
* None.
== Progress ==
* Rebase aarch64 build scripts to crosstool-ng upstream, test and send
out the patch for community review (2/10).
* Investigate https://ci.linaro.org/jenkins/job/openembedded-armv8b-rootfs/gcc_version=4.….
It seams build configure issue. Some MICRO is not correctly defined.
Can not follow-up it due to no access to the build system.
* Continue on "uninit warning testsuite failures" (CARD 304 7/10)
- Identify another reason why uninit-pred-8_b.c FAIL: The control
flow is too complex, it can not normalize the condition at line 22 to
( n < 10 || m > 100 || r < 10 ).
- Work on patch to fix PHI issue to make uninit-pred-9_b.c PASS.
* Test builds for backporting "ftruncate() and truncate() stubs"
related patches in Linaro newlib.
== Plan ==
* Linaro toolchain binaries 2013.12 release.
== 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
== Issues ==
* None.
== Progress ==
* 1.5 days off.
* Misc update for Linaro crosstool-ng
- Re-enable parallel build for do_cc_core.
- Add linaro-armeb-none-eabi config.
- Update all CT_TOOLCHAIN_PKGVERSION to "Linaro GCC 2013.11"
* Share toolchain binaries configures to cbuild2 group.
* Backporting r200103 and r205509 to linaro 4.8.
* Collect Spec2k INT results with -fno-move-loop-invariants and
-fira-loop-pressure on X86-64 and ARM Chrome book. Performance of
different cases waves from -2% - 2%. But the overall performance
changes < 0.5%.
== Plan ==
* Continue on CCMP.