Hi,
I'd like to check vzip/vuzp patch in big endian mode. But when I try
to compile with -mbig-endian flag, I get
> ~/mainline/bin/bin/gcc -O3 -mfloat-abi=softfp -mfpu=neon neon-vtrnu8.c -mbig-endian
/home/irar/mainline/bin/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../libgcc_s.so.1:
could not read symbols: File in wrong format
collect2: ld returned 1 exit status
What am I missing?
Thanks,
Ira
The Linaro Toolchain Working Group is pleased to announce the release
of Linaro GDB 7.2.
Linaro GDB 7.2 2011.02-0 is the third release in the 7.2 series. Based
off the latest GDB 7.2, it includes a number of ARM-focused bug fixes
and enhancements.
Interesting changes include:
* Backtracing is more reliable through using the ARM specific
exception tables for unwinding
* Better supports debugging functions compiled with GCC's -fstack-protector
* Multiple testsuite related fixes
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.2-2011.02-0
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
-- Michael
The Linaro Toolchain Working Group is pleased to announce the release
of both Linaro GCC 4.4 and Linaro GCC 4.5.
Linaro GCC 4.5 is the seventh release in the 4.5 series. Based off the
latest GCC 4.5.2, it includes many ARM-focused performance
improvements and bug fixes.
Interesting changes include:
* Improved code generation in the __sync primitives
* Better modelling of the Cortex-A9 NEON pipeline
* Added a performance improvement that converts a tree of ifs into a switchs
* Many bug fixes
Linaro GCC 4.4 is the seventh release in the 4.4 series. Based off the
latest GCC 4.4.5, it is a maintenance release that fixes one fault
found with offsets on NEON loads.
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.5-2011.02-0https://launchpad.net/gcc-linaro/+milestone/4.4-2011.02-0
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
-- Michael
The Linaro Toolchain Working Group is pleased to announce the release
of Linaro QEMU 2011.02-0.
Linaro QEMU 2011.02-0 is the first official release of qemu-linaro. Based
off upstream qemu, it includes a number of ARM-focused bug fixes and
enhancements.
- This initial qemu-linaro release includes all the ARM code generation
fixes from the qemu-meego tree; these are mainly Neon related
- The OMAP3 support from qemu-meego is also included
- Various bugs which prevented newer Linaro snapshots from booting
on the beagle model have been fixed
- Bugs causing linaro-media-create to print warnings about unimplemented
syscalls and ioctls have been fixed
Known issues:
- There is no support for USB keyboard or mouse, so only a serial console
is usable (#708703)
- Images built with linaro-media-create's --swap_file option will not
boot (#713101)
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2011.02
Binary builds of this qemu-linaro release are available for users of
Ubuntu. Natty users can find qemu-linaro 2011.02-0 in the Ubuntu archive.
Users of Ubuntu 10.04 LTS and Ubuntu 10.10 can find packages in the
linaro-maintainers tools ppa:
https://launchpad.net/~linaro-maintainers/+archive/tools/
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
== Linaro GCC 4.5 ==
Reviewed, tested and merged all the outstanding patches waiting to go
into Linaro GCC 4.5. Michael reported that there was a build failure on
i686 and amd64. I attempted to reproduce this but my builds completed
successfully - very strange. Eventually I found that I had a corrupted
checkout and managed to reproduce the problem - thanks bzr! The problem
is in Tom's recent changes to stmt.c, so I informed him and backed out
the patches, temporarily.
Spun the Linaro GCC 4.4 and 4.5 release tarballs and passed them to
Michael Hope for final testing.
== GCC 4.6 ==
Tested a more recent version of GCC 4.6 and pushed it to the bazaar
repository. Already out of date by the time testing finished of course,
but never mind. The number of test failures is greatly reduced. Started
another build/test with an even more up-to-date check-out.
Begun work merging the 4.5 patches into 4.6. Pushed 1 patch upstream.
Got another ready to go, once I've tested it.
== Android ==
Tried to unpick a large patch I was sent that supposedly added Android
support to Linaro GCC 4.5. The patch was suspicious from the start
because it had large changes to gcc/ChangeLog that clearly backed out
the 4.5.2 release. After comparing it against various sources I
concluded that it was a 4.6 snapshot from last May with (at least some
of) the Linaro patches forward ported, and the release numbers fudged to
look like it was 4.5.2 based. This was not terribly helpful - I can't
very well backport that into our 4.5 branch!
== Upstream GCC ==
Upstream patches requiring review:
* Thumb2 constants:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* Kazu's VFP testcases:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html
== Last week ==
* Backported the fixes for lp693502, lp710623 and lp710652 to linaro 4.6
and linaro 4.5. Tested and sent merge requests.
* Wrote several more ifunc tests, and fixed the bugs they showed up.
Found that ARM generates unnecessary dynamic relocs against GOT entries,
so fixed that as a prerequisite. Improved the tracking of STB_LOCAL
ifuncs, so that they're treated more like STB_GLOBAL.
* Submitted a request for R_ARM_IRELATIVE to be added to the ARM EABI.
== This week ==
* More ifunc.
I'm away next week (14th-18th)
Richard
Hello,
Matthias noticed the following ICE when attempting to build the SPU
compiler from the Linaro GCC 4.5 sources:
../../../../src-spu/libgcc/../gcc/libgcc2.c: In function '__fixunssfdi':
../../../../src-spu/libgcc/../gcc/libgcc2.c:1344:1: internal compiler
error: in
spu_expand_mov, at config/spu/spu.c:4575
It turns out that this is due to the new "extension elimination" pass that
was recently added in Linaro GCC, as port from the CodeSourcery compiler.
This patch has also been proposed, but not yet included upstream.
The problem is that this patch seems to frequently introduce instructions
that *set* a sub-word lowpart subreg of a register. Now such
instructions, according to the docs, are probably valid RTL, but since the
effect of the instruction onto the highpart of the register is deliberately
left unspecified, they tend to be very infrequently used. Probably
because of this, there seem to be parts of the compiler that simply don't
handle such instructions correctly. This has been already noticed in the
case of the RTL loop optimizers (see discussion here
http://gcc.gnu.org/ml/gcc/2010-11/msg00552.html).
The failure in the SPU back-end is another instance of the same problem.
SPU needs special code to handle subregs (since a "lowpart" SImode subreg
of a DImode register is not actually valid on the SPU, because SImode
values live in bytes 0..3 while DImode values live in bytes 0..7 of the
otherwise big-endian 16-byte SPU registers), and this code simply aborts
when given an assignment to a sub-word lowpart subreg.
Now, I guess there's two ways forward: either the outcome of the ongoing
discussions on gcc-patches is that it is in fact not a good idea to
generate such sets, and the EE pass is subsequently rewritten to avoid
them; or else, if those instructions are considered valid, I'll have to
extend the SPU move expander to handle them. Thoughts?
Matthias, if you need a quick workaround for now, I guess you could disable
the new pass for SPU by adding a line "flag_ee = 0;" to
spu_override_options.
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
I've had a go with running the QEMU release candidate. Short story is
that it boots to a prompt against the 11.05 alpha2 release so I'm
happy.
It was a messy road so I've written up my train of though here:
https://wiki.linaro.org/MichaelHope/Sandbox/QEMU
Note that if you follow the instructions on:
https://wiki.linaro.org/Releases/GettingInstallingTesting
and turn on a swap file then it halts during boot.
-- Michael
== String routines ==
* After some discussions about IT semantics managed to shave a
couple of instructions out of a couple of routines
* Got around to trying a suggestion that was made some months ago,
that LDM is faster than LDRD on A9's; and indeed
it does seem to be in some cases; those cases seem pretty hard to
define though - it's no slower than LDRD, so it seems
best to avoid LDRD.
* Digging around eglibc's build/configure system to see how to add
assembler routines to only get used on certain build
conditions (i.e. v7 & up)
== SPEC ==
* Compiled lbm -O2 and ran it on our local panda and on Michael's
ursa1 - it seems happy (with a drop of swap); so I'd say that
confirms the issues I previously had were local to something on canis.
That's a bit of a pain since it's the only machine with enough
RAM to run the rest of the suite.
== Other ==
* Tested a headless Alpha-2 install on our Beagle C4 - mostly worked
* Tested qemu-linaro release on the realview-pbx kernel/nfs setup I had
* A simple smoke test for pldw on qemu
* Tripped over ltrace not working while trying to profile git's use
of memcpy and memcmp; it does some _very_ odd things;
it's predominant size of memcpy seems to be 1 byte.
