On 17 May 2012 18:23, Zhenqiang Chen <zhenqiang.chen(a)linaro.org> wrote:
>> Some are marked as unsupported but shouldn't be:
>>
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11a.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11b.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-11c.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-25.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-26.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-28.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-2.c
>> +UNSUPPORTED: gcc.dg/tree-ssa/gen-vect-32.c
>
> The root cause is "target vect_cmdline_needed". For those cases, they
> have notes as:
>
> /* { dg-do run { target vect_cmdline_needed } } */
>
> In function "check_effective_target_vect_cmdline_needed" of
> lib/target-supports.exp, it check_effective_target_arm_neon.
>
> For our build, it is arm neon,
> check_effective_target_vect_cmdline_needed return 0.
>
> A quick fix is to add another dg-do run like:
> /* { dg-do run { target arm*-*-*eabihf } } */
I've looked into this further and the tests make no sense. The test
themselves are turned off unless the compiler needs extra command line
arguments to enable some type of SIMD. See PR21292. Let's discuss
this on Monday.
I've put an updated list at:
http://people.linaro.org/~michaelh/incoming/hard-float-builder-diff-2.txt
The interesting ones below. They're a mix of assembler faults, ICEs,
and testisims. None are due to the change in triplet so please
propose your patch upstream.
-- Michael
+FAIL: gcc.c-torture/compile/sync-1.c -O0 (test for excess errors)
+FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for excess errors)
/tmp/ccGuCO1R.s:463: Error: co-processor offset out of range
** Doesn't happen with a natty sysroot. Assembler fault?
+FAIL: gcc.dg/builtin-apply2.c execution test
** Testism. Skips if an explicit float-abi=hard is passed.
+FAIL: gcc.dg/pr48335-5.c (test for excess errors)
(insn 11 10 12 3 (set (reg:DI 141)
(unspec:DI [
(mem/c:DI (plus:SI (reg/f:SI 129 virtual-stack-vars)
(const_int -8 [0xfffffffffffffff8])) [2 S8 A32])
] UNSPEC_MISALIGNED_ACCESS))
/cbuild/slaves/ursa2/gcc-linaro-4.7+bzr114985~michaelh1~hard-builder-test/gcc/gcc-linaro-4.7/gcc/testsuite/gcc.dg/pr48335-5.c:16
-1
(nil))
** The unaligned access support doesn't include an unaligned DI pattern?
+FAIL: gcc.dg/torture/stackalign/builtin-apply-2.c -Os execution test
** Testism. Assumes doubles are passed in core registers.
+UNSUPPORTED: gcc.target/arm/mmx-1.c
/cbuild/slaves/ursa2/gcc-linaro-4.7+bzr114985~michaelh1~hard-builder-test/gcc/gcc-linaro-4.7/gcc/testsuite/gcc.target/arm/g2.c:12:1:
sorry, unimplemented: Thumb-1 hard-float VFP ABI
** Various forms. Needs thought.
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro QEMU 2012.05.
Linaro QEMU 2012.05 is the latest monthly release of qemu-linaro. Based
off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes
and enhancements.
New in this month's release:
- Beagle bootrom emulation now correctly handles FAT12/FAT16
images (thanks to Peter Chubb for the bug report and patch).
- We now support running ARM BE8 userspace binaries (ie
byte-invariant big-endian data and little-endian code).
Known issues:
- Graphics do not work for OMAP3 based models (beagle, overo)
with 11.10 Linaro images.
- Audio may not work on Versatile Express models with the latest
Linaro kernel/hardware packs (LP:977610).
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.05
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
There will be no release of Linaro GDB this month. We're busy working
on upstreaming Android support and will backport them as they come
ready.
-- Michael
The Linaro Toolchain Working Group is pleased to announce the 2012.05
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.05 is the second release in the 4.7 series. Based
off the latest GCC 4.7.0+svn187448 release, it includes performance
improvements especially around 64 bit operations.
Interesting changes include:
* Updates to GCC 4.7.0+svn187448
* Uses the new /lib/ld-linux-armhf.so.3 loader for hard float binaries
* Adds support for negating 64 bit values in NEON
* Improves loading of 64 bit immediate values in NEON
Fixes:
* LP: #959242 ICE: in vect_is_simple_use_1, at tree-vect-stmts.c
* LP: #968766 GCC 4.6.3 (cc1) crashes when compiling MPFR 3.1.0
Linaro GCC 4.6 2012.05 is the fifteenth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn187273 release, this is the second
release after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn187273
Fixes:
* LP: #959242 ICE: in vect_is_simple_use_1, at tree-vect-stmts.c
* LP: #968766 GCC 4.6.3 (cc1) crashes when compiling MPFR 3.1.0
* LP: #972648 ICE (segfault) in gsi_for_stmt
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.05https://launchpad.net/gcc-linaro/+milestone/4.6-2012.05
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
More information on the features and issues are available from the
release page:
https://launchpad.net/gcc-linaro/4.7/4.7-2012.05
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
-- Michael
Hi,
OpenEmbedded-Core/meta-linaro:
* reverted the gcc 4.7 support from the denzil branch as it's causing
too much trouble
* instead we'll use a oe-core master snaphsot for 4.7
* committed a fix to our kernel bbappend
* started to look into cbuild
* added configurations to support building the images for all
oe-core targets
* created lp:~kwerner/cbuild/oecore
* kicked off a build for ARM, MIPS, PPC, X86, X86_64 using Linaro
GCC 4.6 2012.04
Misc:
* IBM internal meetings
* public holiday on Thu, vacation on Fri
I'll be back on monday
Regards,
Ken
Hi Ramana. FYI, gcc trunk fails to bootstrap with:
../../../../gcc-4.8~/libgcc/libgcc2.c: In function '__mulvdi3':
../../../../gcc-4.8~/libgcc/libgcc2.c:397:1: internal compiler error:
in df_uses_record, at df-scan.c:3179
A cross compiler fails when building EEMBC with:
(insn 1166 1165 1167 155 (set (reg:CC 24 cc)
(compare:CC (reg:SI 2148 [ D.6766 ])
(const_int 5000 [0x1388]))) iirflt01/bmark.c:501 -1
(nil))
iirflt01/bmark.c:1138:1: internal compiler error: in extract_insn, at
recog.c:2131
The last revision that bootstrapped was 187203. 187223 and 187275 failed.
-- Michael
The GCC 4.7 merge testing is currently in progress. We're a little late
with it, so I'm spinning the release speculatively. This being the case
I've made the lp:gcc-linaro branch read-only, just in case.
This shouldn't prevent anybody from reading the branch with
"lp:gcc-linaro", but the "lp:~linaro-toolchain-dev/gcc-linaro/4.7" name
will be broken for a while, so you may find "bzr pull" broken. (The
reason being that the only way to make a bzr branch read-only is to
change its owner.)
I will put the branch back to its normal state as soon as the release is
done.
Andrew
Hi there. We'd like to run a Fast Model in the validation lab for KVM
testing. Is there a blueprint for this? What's the status?
Paul and I discussed a rough plan a few months ago. It was along the lines of:
* A x86 machine as the Fast Model host
* An emulated vexpress-a15 as the KVM host
* A vexpress-a15 as the KVM guest
* LAVA treats the Fast Model as a board
* Jobs are spawned into the LAVA scheduler
* Once the KVM host is running, everything else is toolchain specific
and done via shell scripts
The dispatcher would:
* Grab the hwpack
* Grab the nano rootfs
* Build the rootfs with separate kernel, initrd, and dtb using
linaro-media-create
* Start the Fast Model with the boot wrapper, kernel, and rootfs
* Use the console to run the test script
There's more information on the steps required at:
https://wiki.linaro.org/MichaelHope/Sandbox/KVMUseCase
-- Michael
== GCC ==
* Checked in patch to fix LP #959242 (GCC PR tree-optimization/52633)
to Linaro GCC 4.7 and 4.6.
* Completed design of new optimization sub-pass to improve
re-association of plus/minus chains for types with undefined
overflow (to improve end-of-loop value computation);
started implementation.
* Investigated GCC PR target/44141.
* Started investigation of TSVC vectorizer test kernels.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
* Linaro GCC
Did the merges from upstream ahead of the Linaro releases next week.
Unfortunately, with the Linaro office move the test system is running
slowly, and it took a long while for Uli's concerns about the 4.7 merge
to be confirmed, so this might cause a bit of delay while I remerge, and
retest.
Begun looking at a solution for GCC Bugzilla pr53189. I've rewritten the
anddi3, iordi3 and xordi3 patterns to avoid the problems when NEON is
not available, and also improved the situation when NEON is enabled.
There are still a few kinks that need to be ironed out with poorly
optimized extend-and-operate sequences, and then I'm done, I hope.
* Other
Public holiday on Monday.
Summary:
* arm-linux-gnueabihf and multilib support for linaro toolchain.
Details:
1. Make arm-linux-gnueabihf and multilib work together for linaro toolchain
* Tuning the include and link path and order.
* The build requires a sysroot with both soft and hard float support
(Refer precise-sysroot-armhf-r0c.tar.bz2 at
http://people.linaro.org/~michaelh/incoming/). With the sysroot, a
reference multilib toolchain build is at
http://people.linaro.org/~zhenqiangchen/
* Update the Makefiles in tests to support armv4t build.
* Setup a pandaboard and run some tests.
Plans:
* Investigate other code size regressions in 4.7.
* Prepare for linaro binary toolchain 2012.05 release.
Best regards!
-Zhenqiang
<Short week given bank holiday>
Progress
* Committed the VFP addressing modes patch.
* Investigated PR48941 patch a bit more - looks like an issue with the
register allocator around vzip and vuzp patterns and not sure what the
easiest way of sorting this really is. I wonder if we should be
looking at some of the issues around secondary reloads or friends for
this particular patch - we generate too many vmov's for my liking and
with more complex code this ends up as spills !
* Backported gnu_unique_objects patch. Need approval to commit in Linaro tree.
Plans
* Backport VFP addressing patch to Linaro tree.
* Finish smin-umin idiom patch in the backend.
* smin - umin idiom patch in middle-end - investigate further.
Absences:
* May 28- June 3 : Away to Linaro Connect.
(short week, bank holiday)
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || ||
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 ==
* various fixes following Rusty's review
* attempted to fix an issue where we would leak the hashtable
every time a new thread is created in linux-user mode. This
has run into the problem that qemu's current "copy this cpu
object" function has no place to insert cpu-specific code to
handle state which can't be simply shallow copied. This might
introduce a dependency on some object model rework, though
I'd prefer to avoid that.
== other ==
* put together and tested qemu-linaro 2012.05 prerelease tarball
* usual upstream review: couple of ARM fixes sent in for 1.1
-- PMM
Hi,
OpenEmbedded-Core/meta-linaro:
* finished script to automate the checkout, build and test of
oe-core+meta-linaro (denzil)
* currently supports GCC 4.6 based toolchains only
* pushed support for Linaro GCC 4.7 to meta-linaro/master
* backported support for GCC 4.7 based toolchains to the denzil branch
of meta-linaro
* when using GCC 4.7 against the oe-core release:
* Qt 4.8 fails to build (probably needs backporting a fix)
* sato images are booting but don't show the matchbox wm
Regards,
Ken
Hi Ken. I've checked in a rough script that builds OpenEmbedded
inside the cbuild Makefile-based auto builders.
To run it yourself:
* bzr branch lp:cbuild
* cd cbuild
* cp oecore.mk lib
* mkdir -p slaves/`hostname`
* cd slaves/`hostname`
* make -f ../../lib/oecore.mk
It's a Makefile which runs locally or remotely. Everything is under
cbuild/lib. The steps are driven by steps.mk which use stamp files to
see what is finished and what needs running. The normal steps are
configure; build; install; testsuite; run. I've split the build and
similar steps into one per architecture and added a ping to the
scheduler (http://ex.seabright.co.nz/helpers/scheduler) between each
one as it will take some time. Logs end up in gcc-native/*.txt.
To toast everything, do 'rm -rf gcc-native results'. The top level
build directory is $LBUILD (gcc-native/oecore). The variant build
directory (think -O3 vs -O2) is $VBUILD (gcc-native/oecore/$variant).
The architecture directory is $VBUILD/$arch. I've left $ARCHITECTURES
and $IMAGE as fallbacks so they can be overridden by the incoming job.
You should implement 'get-sizes' so we track the final image and package sizes.
I'd add a patch-% rule for any architecture specific patching such as
using the vexpress-a9 model. Use patch-% as the fallback and the
specific patch-arm for ARM specific. Add it as part of the configure.
It fetches a snapshot of OpenEmbedded and bitbake. The following are
snapshotted on change:
* kwerner/meta-linaro
* openembedded-core/denzil
and end up at:
http://builds.linaro.org/toolchain/snapshots/
We don't want download problems stopping us from running. The script
uses my normal tactics:
* Everything over HTTP
* Use a in-network proxy, set in ~/.wgetrc
* Pull from a mirror first or only
(http://builds.linaro.org/toolchain/misc/mirror/openembedded/)
Install polipo and echo http_proxy=http://localhost:8123/ > ~/.wgetrc.
I've seeded the mirror. We should keep track of any extras needed
such as due to other architectures.
BTW, I'm wondering about doing the build in zram backed ramdisk.
Might speed the build and not wear the build disk out.
-- Michael
Hi,
GDB for Android:
* Reviewed Carlos O'Donell response to my message in lsb-discuss to think
about the pros and cons of the approaches he mentioned, did some
investigation. Maybe the ABI-tag is not needed, at least for debugging
purposes (there may be other uses).
* Wrote patch which detects an Android app by looking at the ELF
interpreter field in the binary.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
GDB for Android:
* Struggled with creating and running a Linaro Android 2012.04 QEMU image.
* Failed to set up a network between the image and the host to run
gdbserver on it.
* Studied how GDB copes with uclibc and dietlibc regarding the jump buffer
format to compare it how Android GDB solves the problem. It turns out
that they both use the same format that glibc uses so nothing is needed
on GDB side.
* Researched Pandaboard and accessories to purchase.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
* Linaro
Continued trying to understand lower-subreg and its impact on ARM
optimization. After much staring at RTL dumps and trying to minimize
test cases from large code bases I've not found an example of code where
disabling the lowering of pseudo-to-pseudo copies made the code larger
for anything other than unfortunate random knock-on effects (such as no
longer being able to use 16-bit thumb1 opcodes). I posted a message to
this effect on the gcc list, and I'll try benchmarking a patch for this
next week.
In the process of looking at lower-subreg, discovered a silly
missed-optimization bug with many DImode operations, and reported it to
GCC Bugzilla as pr53189.
Hi,
OpenEmbedded-Core/meta-linaro:
* created meta-linaro denzil branch to be used in conjunction with the
oe release
* added a patch that prevents GCC from installing libssp and
libstdc++-v3 to lib64 on X86_64 Linux
* merged patches that use vexpress defconfig only for qemuarmv7a
* built and tested all supported QEMU tarted (ARM, MIPS, PPC, X86,
X86_64) using Linaro GCC 4.6 2012.04
* All images (minimal, sato and Qt) are booting!
* started to work on the automation
Regards,
Ken
Summary:
* arm-linux-gnueabihf and multilib support for linaro toolchain.
* Code size benchmark analysis.
Details:
1. arm-linux-gnueabihf support for linaro toolchain
* Update gcc, libgcc and libstdc++ config to support the triplet.
* Update build scripts to gnueabihf.
* Add sample config for gnueabihf.
2. Multilib support for linaro toolchain
* Merge Terry's multilib patches
(http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00975.htmlhttp://gcc.gnu.org/ml/gcc-patches/2012-05/msg00083.html) and revise
them for linaro.
* Update gcc.c and incpath.c to make multiarch and multilib work together.
* libgcc for armv4t (-mfloat-abi=soft) build fail: ld: error:
armv4t/libgcc_s.so.1.tmp uses VFP register arguments, ... does not.
Root cause: crt*.o from precise sysroot use VFP_args, while other
objects are built with -mfloat-abi=soft. We need additional crt*.o to
build libgcc for armv4t.
3. Code size regression analysis
We find more regression cases introduced by ivopt and loop invariant.
Plans:
* Investigate other code size regressions in 4.7.
* Finalize the arm-linux-gnueabihf and multilib support for linaro toolchain.
Best regards!
-Zhenqiang
I've lost track of the benchmark builds so I've started a manual todo list at:
https://wiki.linaro.org/MichaelHope/Sandbox/Todo
It's been messy with the validation lab being down and some builds
being in my home office and some in Cambridge. Let me know if I'm
missing any.
-- Michael
Hi folks,
We really need to push on with getting the loader path for armhf
standardised. The path that was agreed months ago is
/lib/arm-linux-gnueabihf/ld-linux.so.3
but clearly not everybody is using that yet. Dann has just posted an
updated patch for gcc, and we want to get this reviewed / fixed up /
accepted ASAP. Then we may need to backport it to older gcc releases.
This is *important* so that we can help vendors release binaries that
work on any hard-float distribution. For people who have made binaries
that still use the old, broken location /lib/ld-linux.so.3, we can put
symlinks in place *for now* but in the longer term as many distros
switch to multi-arch the symlink is not an acceptable solution.
I'm working on a more complete spec document for armhf to help us with
this kind of thing, but it's not going as smoothly as I'd hoped and I
don't want to wait for that as a blocker on the linker path.
Cheers,
--
Steve McIntyre steve.mcintyre(a)linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
