The Linaro Toolchain Working Group is pleased to announce the 2014.02
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 first engineering release. The next stable
release will be the 2014.04 release.
Linaro GCC 4.8 2014.02 is the eleventh release in the 4.8 series. Based
off the latest GCC 4.8.3+svn207411 release, it includes performance
improvements and bug fixes.
Interesting changes include:
* Updates to GCC 4.8.3+svn207411
* ARM-v8 crypto intrinsics support
* New vectorizer cost model
The source tarball is available from:
http://releases.linaro.org/14.02/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.02
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
This should match what we have in meta-linaro/dora, which is the linaro
2013.12 toolchain release.
---------- Forwarded message ----------
From: Koen Kooi <koen(a)dominion.thruhere.net>
Date: 17 January 2014 19:35
Subject: Fwd: seemingly bug in Linaro gcc 4.8
To: Koen Kooi <koen.kooi(a)linaro.org>
Begin doorgestuurd bericht:
> Van: Khem Raj <raj.khem(a)gmail.com>
> Onderwerp: seemingly bug in Linaro gcc 4.8
> Datum: 17 januari 2014 17:56:23 CET
> Aan: Koen Kooi <koen(a)dominion.thruhere.net>
>
> Hey Koen
>
> I am seeing a problem with linaro gcc-48 basically angstrom/2013.12
release
> The issue is attached sample C file. When compiled and run on my ArchLinux
> box which is running upstream gcc 4.8.2 it works ok
>
> but on beagleboard it fails.
>
>
> to compile
>
> $CXX -pthread -std=gnu++11 a.cpp
>
> on ARCH
>
> kraj@leo ~ > g++ b.cpp -std=gnu++11 -pthread
> kraj@leo ~ > ./a.out
> 140309495478016 i: 1
> 140309503870720 i: 2
>
> on Beagleboard
>
> root@beagleboard:~# ./std-thread
> pure virtual method called
> terminate called without an active exception
> Aborted
>
> Can you pass this to right folks in Linaro and get some help in resolving
it
>
> I havent yet trried it with OE-Core gcc which is also gcc 4.8
>
> The issue is most probably ARM related as it seems to me.
>
> Thanks for help
>
> -Khem
>
Hello,
I'm maintaining an older release we have which uses the older toolchian
binaries in gcc-linaro-arm-linux-gnueabi-2012.03-20120326_linux. I've
identified a bug in glibc we appear to be encountering and would like to
port the fix back.
I initially went the route of compiling the above toolchain binaries from
source as described in the readme.txt but then found that the cross
compiler binary build does not include the e/glibc build and these appear
to be sucked in in binary form (oneiric-sysroot-r1).
Are there any documents how these prebuilt libc binaries were created?
Please note that I'm not asking in general how to build glibc. I've built a
version with and without this bug patched to verify that it is indeed what
we are hitting. I'm more hoping to get an idea of how the specific binaries
mentioned above were built.
Thanks in advance for any help!
Evan Carson
== This week ==
- Backported 206261 and 201263 - AArch64 support NEG in vector registers
- Backported 202020 - Support SISD shifts
- Backported 202259 - AARCH64, fix return types for vaddvq_s64, vaaddvq_u64
- Travel back to US on Friday, February 7th
== Next week ==
- Submit backport for review once crypto instruction review is complete
and approved
- Continue backports from trunk
- New backports
== Future ==
--
Michael Collison
Linaro Toolchain Working Group
michael.collison(a)linaro.org
Hello,
The binutils 2.24-2013.12 release page says that the release was built
from the linaro_binutils-2_24-2013_12_release tag, but that tag
doesn't seem to actually be present in the git repo at
http://git.linaro.org/toolchain/binutils.git . Could that tag please
be pushed?
Thanks and regards,
Gregory
== Progress ==
* Cbuildv2 now builds a static gdbserver for cross linux targets. (1/10)
* Fixed Cbuildv2 bugs and added feature requests from Venkat, who
is bravely being our beta site. (1/10)
* Got .sum files produced from Jenkins builds copied to
tcwgweb. Much of this was getting everything setup to allow files
to be copied securely. (TCWG-386 - 3/10)
* QEMU image prep for softfp and Rasberry PI testing. (TCWG-380 - 2/10)
* Meetings and misc. (3/10)
- Tweaks to Jenkins support so build names the remote directory
in a way tcwgweb expects.
- Added more info to TCWG Build Farm wiki page.
(https://wiki.linaro.org/TCWG%20build%20farm)
== Plan ==
* Figure out how to make tcwgweb run test comparisons.
* Now that SSH is setup correctly in the TCWG build farm, GCC
testing tries to execute the remote tests, but hits an error in
DejaGnu, which needs to be debugged and fixed. (TCWG 324)
* Add Win32 installer for Canadian cross built binary
releases to Cbuildv2. (TCWG-381)
== 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. (3/10)
- Continue analysis on Cortex-a15.
* LRA on AArch64: (2/10)
o Start to look at PR 59222 (ICE with ILP32).
* Branch merge and backports reviews. (2/10)
* Continued Linaro 4.8 release performance on Cortex-a15. (2/10)
* Various meetings. (1/10)
* Misc:
o start to prepare AArch64 toolchain status for Connect session.
== Next ==
* Continue the on-going tasks
* 4.8 2014.02 Engineering release
== Progress ==
* Libsanitzer for AArch64: (3/10)
- QEMU patch to handle missing mmap flag accepted.
- Charles was able to build GCC + run the sanitizer tests on board
- cleanup patch, ready to be sent to the LLVM list for approval
* Cross-validation: (1/10)
- extending timeout to 5h for aarch64-linux seems to be sufficient
when using qemu-aarch64
* 2014.02 release preparation: (4/10)
- branch merge
- backported new vectorizer cost model (cheap, dynamic, unlimited),
and ran some benchmarks.
- asked Kugan to check the few improvements observed when using
-fvect-cost-model=unlimited
- reviewed Crypto intrinsics backport from Michael Collison.
Discussed the use of gerrit+jenkins with him and Rob.
- Charles ran the validation of the Crypto intrinsics backport on
AArch64 hardware
- I cross-validated it using binutils-linaro-2.24-2013.12, to make
sure we release components capable enough to interoperate.
- upgrading binutils in cbuildv1/tcwg-web would help, until we can
switch to jenkins+cbuildv2+gerrit
* Misc (2/10): conf-calls, meetings
== Next ==
* libsanitizer on AArch64: post patch to LLVM list
* crypto intrinsics: commit patch for 2014.02 release
== Progress ==
* Short week: Public holiday on Wednesday 5th Feburary 2014. [2/10]
* Ran gdb testsuites for arm and x86 (native + remote) with all in
progress patches applied. [1/10]
* Investigated and triaged arm only failures. [2/10]
* Investigated gdb.dwarf2/implptr-64bit.exp failure and submitted
patch to disable it for 32-bit targets.[2/10]
* Installation and configuration of new desktop machine. [1/10]
* Investigation of stack unwinding failures on arm. [1/10]
* Investigation of work required to implement record and replay on
aarch64. [1/10]
== Plan ==
* Setup gdb for aarch64 and try to run a demo application.
* Investigate remaining arm only failures in gdb for arm and work
towards closeout of CARD-321.
* Travel to Islamabad to receive passport back from Chinese embassy
for Macau visa.
== Week of February 3rd ==
- Various administrative bits and account setup. (6/10)
- Worked my way through to getting access to LAVA board lab. Tried to reproduce performance regression on STREAM benchmark. (2/10)
- Public holiday. (2/10)
== Week of February 10th ==
- Continue account setup. Get work environment up.
- Get to know the team.
- Continue investigation of STREAM benchmark.
--
Maxim Kuvyrkov
www.linaro.org
== 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.