Hi toolchain gurus,
I am about to start some projects working with CortexMx devices and am
wondering if anyone has an opinion on which toolchain(s) I should
use/investigate?
Being a fan of Linaro, my first instinct would be to use cbuild2 to
build an arm-none-eabi- toolchain from a 4.8.x tree. But looking
around I can't help notice https://launchpad.net/gcc-arm-embedded.
Does anyone know if gcc-arm-embedded has things the Linaro toolchain
doesn't wrt Cortex M0, M3, and M4 device/instruction support?
Best regards,
Trevor
-------- Original Message --------
Subject: [Bug target/59216] [ARM] negdi*extendsidi regression
Date: Wed, 20 Nov 2013 18:06:14 +0100
From: christophe.lyon at st dot com <gcc-bugzilla(a)gcc.gnu.org>
To: Christophe LYON <christophe.lyon(a)st.com>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59216
--- Comment #2 from christophe.lyon at st dot com ---
Basically, the working code does:
asrs r3, r2, #31
negs r2, r2
sbc.w r3, r3, r3, lsl #1
while the failing one does:
negs r2, r2
asrs r3, r2, #31
--
You are receiving this mail because:
You reported the bug.
Hi LAVA folks,
I don't know if you guys know, but Android is moving to LLVM for the next
release or so. As such, we'll need to do a lot of testing between now and
next release to make sure each component can be compiled (and runs
correctly) with LLVM on an incremental basis.
We're trying to come up with a way for remotely testing the Linux kernel
booting on ARM devices, more specifically an Android stack, and I'm finding
it hard to do that with my home equipment. Doing that in LAVA would be
ideal, and I know the Android team does it already, but our constraints
could be a little different.
Basically, there are two fronts:
1. Building Android components with LLVM, using a GCC-compiled kernel
booting on an ARM board, in LAVA. This is something we should work
internally on how to do it, and it'll be between Android, LAVA and
Toolchain groups.
2. Building the Linux kernel with LLVM, and using a GCC-compiled image
(like stock CyanogenMod) to test the kernel. We don't have such a kernel
(many patches), but the LLVMLinux guys do, and that's where they come in.
On the second case, the topic of this email, we'd have to liaise with them
to fire jobs at LAVA from their own infrastructure (originally, manually
only), and that might need some thinking. But ultimatelly, we want to have
those jobs running on LAVA, so that later on we'd be able to have a third
layer: Linux+Android built with LLVM with the same system level tests.
Since the LLVMLinux guys don't have access to much ARM hardware, and since
it's easier for us to scale (or to re-define) hardware requirements, having
them running on LAVA makes even more sense.
Is this something we can do? Is this being done already? Is this just a
question of legal/corporate decision, or is there any technical issues we
have to look into?
Android folks,
It might make more sense if you guys just grab their kernel and build the
Android system based on that internally, so that we don't need external
access to job submissions in LAVA, but that would mean work from you guys
to patch it up, and that might not be in the roadmap for the next months.
Is that a feasible route?
cheers,
--renato
= Progress ==
* Created Cards for the infrastructure Team TODO list.
* Finished Cbuildv2 support for building GDB binary tarballs.
* Got Arch linux up on Odroid XU board again, seems stable, did a
build and test run.
* Experimented with lava-tool.
* Tried to get GCC trunk building native on aarch64 for libsanitizer
patch testing.
* Upgraded gmp to 5.1.3 in infrastructure/ to work around a configure
bug triggered by crouton native builds on a chromebook.
* Setup chromebook slaves in new toolchain build farm.
* Started adding support to Cbuildv2 to handle git URLs with a user
name, ie.. git(a)staging.git.linaro.org to work around git repo
problem.
== Plan ==
* Finish support for user names in URLs.
* Continue on remote testing support.
* Keep trying gcc trunk on aarch64 native.
* Fix git repo.
== Issues ==
* GCC git repo hasn't been auto updating the svn branch of
linaro-4.8-branch. It used to work... updating manually is now
broken as well.
* Somehow qemu snapshots tarballs are overwriting the toolchain
directories on snapshots.linaro.org.
* I don't think lava-tool is going to be useable for toolchain
testing, as it only queues up an executable test case to be run
later, whereas GCC expects the test to get run right away.
One day off
== Progress ==
* Prepared 4.7 and 4.8 2013.11 releases. Some delay because of board
crashes and disk full issues.
* Aarch64: committed 'frame grows downward' patch. This removes a
dependency for libsanitizer and libssp.
* libsanitizer on Aarch64: blocked by GCC trunk not bootstrapping
currently on Aarch64 HW (reported by Rob)
* Looked at cross-build failures of trunk after new
-fisolate-erroneous-paths. Ramana pointed me to Marcus' glibc patch,
and I could switch my builds from eglibc to glibc.
* cross-validations: updated list of configurations built&tested after
discussion with Richard during Connect.
== Next ==
* Announce 4.7 and 4.8 2013.11 releases
* Continue investigating 'extended neg' fix (aka tar regression)
* Look for patches to fix AArch64 bootstrap, so that we can test libsanitizer
One day off.
== Issues ==
* Various cbuild issues:
- disk full, boards down and benchmarks launched on different boards
== Progress ==
* LRA on AArch32:
- Proposed a ARM backend fix for the Fortran issue
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01997.html
- Performance analysis ongoing
* Merge reviews and backports.
== Next ==
* Continue on LRA
== Progress ==
* Wrote ARM and Thumb stub handlers for simd, vfp and coprocessor
instruction recording.
* Read documentation on VFP and Neon register set to figure out a register
recording method.
* Follow up on upstream patches.
* Investigating a un-handled instruction test suite failure in arm process
record.
* 9th/10th Muharram Public holiday on Thursday and Friday.
== Plan ==
* Fix failures in arm process record due to un-handled instruction.
* Get started on writing handlers for coproc, vfp and simd instructions.
== Issues ==
* None.
== Progress ==
* One day (Nov. 15) off.
* Misc update for Linaro crosstool-ng
- Use newlib-linaro-2.0.0-2013.11-1.
- Update fortran support related scripts and configs according to
Matt's comments.
* Propose to support S2_<op1>_<Cn>_<Cm>_<op2> system register in AARCH64 GAS.
- Yufeng followed-up it and added full TRACE registers support.
* Investigate heuristic to tune ifcombine (TCWG-313)
- Got some new fails in regression tests since some optimizations
can not get the expected result.
- Collect Spec2k INT result. Overall there is no changes. But there
are -2 - 1% changes for several cases.
- PGO tests are ongoing.
== Plans ==
* Continue on CCMP.
* Continue on ifcombine tuning.
== Progress ==
* Preparing presentation on auto-vec for LLVM
- For Cambridge LLVM Day next Monday
- If accepted, also for FOSDEM 14
* Tracing strided access changes needed in auto-vec (PR17677)
- Reading the paper, preparing a reference implementation
- Discussing details and preparing the LLVM code to introduce it
- After a few attempts, it's clear that the code is not yet ready to cope
with the changes
- I'll have to work on the surrounding code to re-factor it for more
robust integration
- As well as triming some other edges (like pragmas) to help implement it
* Planning Android builds
- Trying to get a reference platform (most likely the new Arndale)
- LLVMLinux folks will help streamlining a kernel package for it
* Connect reservations, booking flight, etc.
- All done!
== Plan ==
* Monday at Cambridge LLVM Day at CUCL
* 3.4 Release testing
* Looking at vectorization pragmas and general structure of the memory
dependency checks
