This is the first announcement on upcoming changes to the supported
Linaro GCC versions.
GCC 4.7 is expected out in the next two weeks. We plan to switch to
4.7 for the Linaro GCC 2012.04 release and, as part of that, will put
Linaro GCC 4.6 into maintenance and retire Linaro GCC 4.5. While in
maintenance we will continue to update, fix bugs, and do releases on
4.6. No further changes or releases will be made to 4.5. All
historical releases and branches will stay available.
For more informatio, please see the flyer at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer
especially the section on Lifecycle:
https://wiki.linaro.org/WorkingGroups/ToolChain/Flyer#Lifecycle
The formal change notes will be sent after the 2012.04 release.
-- Michael
Hi,
OpenEmbedded:
* rebased against current OE-core
* my patch that introduces an image fs alignment is now upstream
* noticed that the newly introduced bdwgc recipe (the Hans Boehm
Garbage collector which is needed by guile) uses a version of libatomic
that fails when building in Thumb mode
* has been fixed upstream already
* pulseaudio/libatomics-ops_1.2.bb has the same issue and just sets
ARM_INSTRUCTION_SET to "arm" (probably until a new version gets pulled in)
* we can use the same workaround till then
* found a bug in the recipe for the Linaro external binary toolchain
where some header files are placed into a wrong directory during the
install step
* which prevents python from being built
* now fixed
Please note that I'll be on vacation till 04/13/2012.
Regards,
Ken
Hi Ken. I've made a meta-linaro project on Launchpad and created the
near term blueprints. See:
https://blueprints.launchpad.net/meta-linaro
You're almost done with the initial layer work. Next is scripting up
the build and integrating with LAVA followed by turning on the build
for other architectures.
I've dropped the build in the cloud investigation. Let's use
tcserver01 as it works and is fast enough. Keep an eye on the
validation lab cloud the Validation guys are talking about - we might
shift there later.
I've sent the draft card to Loïc who will massage the text and get it
on the TSC agenda. The current blueprints focus on toolchain
validation and come to a hard stop past there. Once we have TSC
approval we can go further and talk with the Platforms guys about who
does what.
-- Michael
The Validation lab is shifting to a new location this week so I've
started a graceful shutdown of the tcpanda boards. Merge requests
will continue to queue and run on x86 but will back up until the lab
comes online at the end of this week. If the backlog gets too big
then I'll re-enable an ursa board or two.
Please work as normal but expect the builds results to take longer to
come through.
-- Michael
Hi there. Over the next three months both GCC 4.7 and Ubuntu 12.04
'Precise' are coming out. We'll switch over to these pretty quickly
which will affect our internal testing and anyone using the binary
toolchain.
The changeover plan including dates, details of what's happening, and
backwards compatibility is at:
https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration
Comments and concerns are welcome,
-- Michael
* Linaro GCC
Spun release tarballs for Linaro GCC 4.5 and 4.6. Launched the build and
test runs. When those completed, briefly checked the results, and
launched the package build tests and benchmark runs.
Continued trying to figure out how my NEON 64-bit immediates patch had
caused a bootstrap failure. The problem turned out to be an assembler
bug ([1]). I've adjusted my patch to work around the problem. This is
the only real way to do it given that, even if I fixed the assembler
right away, there'll be broken assemblers knocking around for some time
to come. The compiler now bootstraps correctly in a manual build. I've
submitted it for testing on Michael's systems, so hopefully this patch
will be ready to post back upstream soonish.
Continued trying to figure out the neon shifts bootstrap failure. I ran
a cross-compiler test suite run, but didn't witness any obvious
problems. Launched a manual bootstrap to reproduce the problem (once the
board because available after testing the immediates patch), so I should
have something to work with next week.
Attempted to merge lp:gcc/4.7 to lp:gcc-linaro/4.7, but got a bzr error.
I asked for help on #bzr, and 'jelmer' is looking into it. Apparently
the history didn't import in quite the same way as lp:gcc/trunk, or
something.
Helped Dmitry Antipov with a relocation (possible) bug.
* Other
Two days leave (Thursday and Friday).
Booked flights and hotels to Hong Kong for Linaro Connect Q2.12
[1] http://sourceware.org/bugzilla/show_bug.cgi?id=13843
Summary:
* Linaro binary toolchain 2012.03 release.
* Make multilib and multiarch work together.
* Failed case analysis for -Os.
Details:
1. Handover Asa's linaro day-to-day jobs (check auto build health,
proposals health and ticket triage)
2. Linaro binary toolchain 2012.03 release.
* Update config to 2012.03
* Fix lp:939008 and patch for lp:939143
3. Multilib/multiarch investigation for linaro toolchain.
* Update the logic in set_multilib_dir to set multiarch_dir when it
matches the format (.:.:$(MULTIARCH_DIRNAME)). Now multilib and
multiarch can work together. A reference build to support
marm/march=armv5t is at http://people.linaro.org/~zhenqiangchen/
* Try to build -mfoat-abi=hard/-fpu=neon. But libgcc build fails
with message "ld: error ... uses VFP register arguments, ..."
4. Investigate new failed cases in -Os regression test.
* For gcc.dg/pr30951.c, both option -O0 and -O2 can optimize (x ==
x + 10) to (0). But -Os can not.
* For gcc.dg/atomic-lockfree.c and gcc.dg/atomic-noinline.c, the
optimization is correct. The test cases can only be test with -O0.
Plans:
* Code size benchmark tuning.
Best regards!
-Zhenqiang
Hi!
* V8 - SunSpider
The pieces for building in cbuild and parsing with the
linaro-toolchain-benchmark scripts are in place. Ran the SunSpider
benchmark across a few toolchains with the o2-neon and o3-neon variants.
I have documented my work on this page, but not analyzed the results yet.
https://wiki.linaro.org/AsaSandahl/Sandbox/JavaScriptBenchmark
What worries me is that there is too much variation in some of the test
results. Probably caused by the garbage collection kicking in at
unpredictable times. I will try to monitor the gc and investigate if it can
be controlled somehow.
I would like to do a gcc-4.4 run as well. Android's original toolchain is
based on gcc-4.4.3(?) and that is what I compared against when doing
measurements internally.
However, I have problem compiling C++ with gcc-4.4 - it is this one again:
home/asa-san/cbuild/slaves/ursa3/gcc-4.4.5/gcc-binary/bin/../libexec/gcc/armv7l-unknown-linux-gnueabi/4.4.5/cc1plus:
/home/asa-san/cbuild/slaves/ursa3/gcc-4.4.5/gcc-binary/lib/libstdc++.so.6:
version `GLIBCXX_3.4.14' not found (required by /usr/lib/libppl.so.7)
* Handed over daily tasks to Zhenqiang.
Regards
Åsa
Hi,
OpenEmbedded:
* verified that the release candidate of our 2012.03 toolchain
(both source and binary) is able to build the sato and qt4e images of
oe-core+meta-linaro - they are booting fine using QEMU
* out sick starting from Tue :/
Regards,
Ken
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-03-30 || ||
Historical Milestones:
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 ||
== cp15-rework ==
* converted crn=1; still TODO: crn=0, some loose ends; then reassess
the design in the light of experience doing register conversion
* I've estimated another two weeks here but this might be out, because
in practice much of my time is sucked up by 'other' issues
== other ==
* tracked down cause of LP:947888 gpg crash bug: newer glibc use
/proc/self/maps to decide whether a printf format string using '%n'
is in writable memory, and qemu's maps emulation wasn't good enough
* fixed a thumb decoder bug where we were treating 'setend' like 'cps'
* investigated whether we had any conveniently testable cores which take
advantage of the ARM ARM latitude for UNDEFfing even on failed condition
code checks (answer, not really but the KVM code to handle this case
should be small enough not to worry about its not-yet-tested nature)
* qemu-linaro 2012.03 release (lots of bug fixes, plus exynos4 and
highbank models thanks to Samsung and Calxeda)
* code review: imx31 board patches
* rebased qemu-linaro on upstream and applied some new patches from
Christoffer for ARM KVM support
* LP:956799: added ppoll to QEMU arm-linux-user (a one liner...)
* boot-wrapper: moved initrd load address up so we can handle large
kernels (like Android!)
* sent pullreqs for target-arm, arm-devs patchqueues
