RAG
Amber: 4.7 2012.07 source release for reasons described below.
Green : 4.6 2012.07 source release done.
== Progress ==
* Worked on auto-inc-dec scheduler changes.First cut patch looking reasonable.
* Committed the neon permute intrinsics upstream.
* Release week : release tarballs prepared for 4.6 . The 4.6 release
is GREEN. I will upload the release on Thursday morning after I am
back in the office.
The 4.7 release had some issues - I had to rerun the release script
because the merge contained some artifacts which were a result of
merge conflicts. Having respun the release it turned out that the
rsync from my machine to cbuild failed, which meant that I ended up
testing the same snapshot twice.Given that the 2 tarballs only differ
in the .rej and the .orig files and nothing more I'm not too worried
about this because it should ideally just work. The good news is that
ubutest and everything else went through ok. The bad news is that the
oe build appears to be borked. We need to investigate that further.
Having looked inside the tarballs and seen that the .rej and .orig
files were the only things different between the 2 tarballs I don't
think it's a huge problem for the release. I;ve spawned off another
set of builds to be absolutely sure .
* Looked at neon costs and vdup improvements . The neon cost changes
could cause regressions with 64 bit arithmetic and hence need to be
looked at carefully. The vdup improvements cause carnage in
gcc.target/arm/neon and tests for intrinsics have to be improved.
== Plans ==
* GNU Tools cauldron next week.
* Deal with release week fall-out.
* Write a patch to check md5sums between local tarball and uploaded
tarball in the release script.
* Look at auto-inc-dec patches more.
* Background look into improving some of the tests that now fail with
the vdup patches.
== Absences ==
* 8th - 11th July - GNU Tools Cauldron.
* 17th Sept - 5th Oct - Vacation planned, yet to be approved.
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-13 || ||
||clean-up-kvm-patches || || || ||
||track-kvm-abi-changes || || || ||
||fake-trustzone || || || ||
Overall KVM plan for 'do by end August': QEMU parts of this are a mix
of clean-up-kvm-patches and track-kvm-abi-changes blueprints, mostly.
http://cards.linaro.org/browse/CARD-167
== a15-lpae-support ==
* did the basic benchmarking of the LPAE series; using 64 bits for
guest physical addresses has between 0 and 0.5% hit to performance,
which IMHO is sufficiently minimal that it is not a problem.
* wrote a set of follow-up patches which allow the vexpress-a15
model to accept large RAM sizes (mostly turning off the "too big"
user-error message, fixing some over-small types in the QEMU boot
loader and adding support for handling device tree blobs with
64 bit address/size fields).
* discovered that Linux will happily throw away the top 32 bits
of a device tree memory node's size field. Wrote a patch for this,
which works but needs redoing to fix in a cleaner way.
== other ==
* qemu-linaro 2012.07 release prep: bug triage, investigation,
rolling tarball, testing
* arm-devs pullreq
KVM blueprint progress tracker:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
-- PMM
Hi,
I didn't look if the files were correctly merged or not. but the .orig and .rej
files don't belong here.
It might be worth to update the merge to r189186, reverting the c++98/c++11 ABI
incompatibility in std::list.
Matthias
revno: 115001 [merge]
committer: Michael Hope <michael.hope(a)linaro.org>
branch nick: 4.7
timestamp: Tue 2012-07-03 20:16:55 +1200
message:
Merge from FSF (GCC SVN branches/gcc-4_7-branch:189098)
added:
gcc/config.gcc.rej
gcc/config/arm/arm.c.orig
gcc/config/arm/arm.c.rej
gcc/config/avr/avr-stdint.h
gcc/configure.ac.rej
gcc/configure.rej
[...]
== Progress ==
* Testing costs changes for Neon intrinsics.
* Fixed the regression I added to the Linaro 4.6 tree - committed
there. Looked at a few vagaries around testresults.
* Started looking at auto-inc-dec scheduler changes.
* 1/2 a day lost to visa application process
* Usual 1:1s .
* Upstream patch review.
== Plans ==
* Work on auto-inc-dec scheduler changes.
* Ping current neon intrinsics patches and get them in.
* Release week dry-run to be done next week - and finish creating the
release tarballs by 6th of July
* Upstream patch review.
* Collect passport on Tuesday / Wed afternoon.
== Absences ==
* 8th - 12th July - GNU Tools Cauldron.
* 17th Sept - 5th Oct - Vacation planned, yet to be approved.
We've had a few testsuite failures recently which were due to the auto
builder itself. I've started a log at:
https://wiki.linaro.org/WorkingGroups/ToolChain/CBuild/FailureLog
so we can track the incident rate and see if there's a pattern.
Zhenqiang, if you see an unexpected failure could you respawn the
build and notify me?
-- Michael
Hi all,
Right now, it's impossible to merge from lp:gcc/4.7 to
lp:gcc-linaro/4.7. This is due to a BZR bug of some kind, so hopefully
we won't have to work around it for too much longer.
According to the nice folks at #bzr, here's how to do the same merge
manually:
bzr branch lp:gcc-linaro/4.7
cd gcc-linaro
bzr log | less
# find the last merge revision (it should be clear from the message)
# grab the *SVN* revision number
bzr log --show-ids lp:gcc/4.7 | less
# search for the *SVN* revision number
# (it should appear on the end of a "revision-id" line, not "parent")
# grab the corresponding *BZR* revision number ("revno")
bzr diff -r <bzr-revno> lp:gcc/4.7 > ../patch
patch -p0 -i ../patch
# resolve conflicts, rejected hunks, etc.
bzr add --file-ids-from lp:gcc/4.7
# if it's doing the right thing you'll get messages like:
# "adding <file> w/ file id from <file>"
# if it just says "adding file" then you got something wrong
# edit Changelog.linaro, as usual
bzr ci
bzr push lp:~.........gcc-linaro/merge-from....
After all that, a future "bzr merge" should just work (once the bug has
been fixed).
Anyway, I doubt there's anybody else needs to know this: I've just
posted it in case I get hit by a bus before next month.
Andrew
== GCC ==
* GCC PR 53636 fix caused regression on powerpc64 and sparc64;
committed fix upstream and to Linaro GCC 4.7.
* Backported GCC PR 53636 fix --including regression fix--
to Linaro GCC 4.6.
* Reworked Andrew's neon-shifts branch to reliably use NEON
for "left shift by register"; fix typo in "left shift by 1";
overall simplification of implementation. Tests restarted.
== GDB ==
* Investigated remaining GDB/Android work; reviewed card.
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
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-13 || ||
||clean-up-kvm-patches || || || ||
||track-kvm-abi-changes || || || ||
||fake-trustzone || || || ||
The blueprints clean-up-kvm-patches and track-kvm-abi-changes include
dependencies on kernel side work which makes it hard to set a date;
however I'm hoping to get them either done or mostly done within the
next two months.
== cp15-rework ==
* patches were committed to master, blueprint complete
== a15-lpae-support ==
* worked on a set of patches to lay groundwork for this: mostly
this is extending the size of QEMU's 'target physical address'
type to 64 bits for ARM (potentially a small perf hit for the
32 bit only ARM cores; benchmarking still to be done)
* wrote patches to implement all the various pieces of LPAE,
confirmed that Linux with LPAE enabled boots, sent patches to list
* started looking into whether there are any bits of LAVA that make
sense to use for QEMU benchmarking
== other ==
* fixed a missing Makefile line that meant qemu-linaro wouldn't build
on ARM targets with KVM enabled
* reviewed a pile of outstanding patches (including SDHCI, i.MX31)
and am now caught up with the post-holiday backlog
KVM blueprint progress tracker:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
-- PMM
Hello,
I tried codesourcy
arm-2012.03-57-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2, and get
below err infos.
Error: selected processor does not support ARM mode `sdiv R2,R0,R1'
Error: selected processor does not support ARM mode `udiv R2,R0,R1'
Does it mean this toolchain version don't support both instructions? and
which toolchain can support them?
Thanks a lot!
Xiao
== GCC ==
* GCC PR 53636 fix caused regression on powerpc64 and sparc64;
investigated, determined root cause, and implemented fix.
== GDB ==
* Took over remaining GDB/Android work from Thiago.
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
The Linaro Toolchain Working Group is pleased to announce the 2012.06
release of the Linaro Toolchain Binaries, a pre-built version of
Linaro GCC and Linaro GDB that runs on generic Linux or Windows and
targets the glibc Linaro Evaluation Build.
Uses include:
* Cross compiling ARM applications from your laptop
* Remote debugging
* Build the Linux kernel for your board
What's included:
* Linaro GCC 4.7 2012.06
* Linaro GDB 7.4 2012.06
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link
your programs against.
Interesting changes include:
* Refine the system root
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian
6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation
5.7 and later, and should run on any Linux Standard Base 3.0
compatible distribution. Please see the README about running on
x86_64 hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://launchpad.net/linaro-toolchain-binaries/trunk/2012.06
Need help? Ask a question on https://ask.linaro.org/
Already on Launchpad? Submit a bug at
https://bugs.launchpad.net/linaro-toolchain-binaries
On IRC? See us on #linaro on Freenode.
Other ways that you can contact us or get involved are listed at
https://wiki.linaro.org/GettingInvolved.
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || ||
||clean-up-kvm-patches || || || ||
||track-kvm-abi-changes || || || ||
||fake-trustzone || || || ||
||a15-lpae-support || || || ||
(dates to come next week)
== cp15-rework ==
* sent out pull request including these patches, so it should get
committed to master in the next few days
== a15-lpae-support ==
* started on getting ARM qemu to work with 64 bit physaddrs
(first stage mostly a tedious code audit)
== other ==
* email catchup following holiday
* rebased various trees, sent out pullreqs for outstanding ARM
QEMU patches
Michael H has set up a web page which tracks progress on KVM related
blueprints here:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
This includes QEMU blueprints related to KVM.
-- PMM
I've gone through and checked the 64 bit operation improvements that
Andrew has made to GCC. For everything but the Cortex-A8, GCC uses
the NEON unit for 64 bit operations and Andrew's improvements mean we
can stay on NEON for longer without having an expensive transfer back
and forth to the core registers.
The results are here:
https://wiki.linaro.org/MichaelHope/Sandbox/64BitOperations
Once we've fixed the shift-left-by-n pattern I'll turn this into an
Outputs[1] page.
Benchmark results have been sent to the linaro-toolchain-benchmarks list.
-- Michael
Hi,
OpenEmbedded-Core/meta-linaro:
* updated OE-Core cbuild to pick up a recent snapshot of meta-linaro
* verified the release candidate of the Linaro binary toolchain 12.06
* prepared meta linaro for the upcoming release of our binary toolchain
* started on a linaro-qemu recipe but didn't finish it
misc:
* boot Linaro Android using QEMU:
https://wiki.linaro.org/KenWerner/Sandbox/AndroidQEMU
Regards,
Ken
== Progress ==
* Tried a number of testcases for the shuffles . Needed to add
support to the C++ frontend for the __builtin_shuffle support.
Fortunately there existed a patch - I tested it and it looked good.
Committed upstream. However the original author had some concerns
whether it would work in C++ or not but we shall see. The OP is
concerned that it might break C++11 and constexpr which need to be
looked at .
* Briefly investigated a regression with Linaro GCC 4.6 with Neon
intrinsics. It looks like my patch to allow LTO to proceed has had
some fall out . We really need some good tests in the GCC testsuite
for intrinsics.
* Looked at the Android documents and commented.
* Some upstream patch review.
== Plans ==
* Follow on the C++11 issues with the __builtin_shuffle patch if any.
* Commit the __builtin_shuffle variation of the neon intrinsics
patch into FSF 4.8. The improvements obtained are real and nice
atleast for the testcases that we could see after finishing up the
testcases.
* There is some follow-up work which should tie in nicely with costs
rework - lower-subreg ends up splitting things a bit badly in some
cases with vld4 style intrinsics and for V4SF copies. So it's better
we try to get the costs right. I suspect this might be harming us in a
few cases with auto-vectorized code as well. Especially where we
vectorize with the large vldn instructions.
* Investigate the 4.6 regression with Neon intrinsics.
* Auto-inc-dec scheduler work.
Hi,
I'm trying to build some shared libraries with the Linaro Android
toolchain.
For all of my libraries I get the following errors from the linker:
|BlaBla.cpp.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
/home/dev/android/android_linaro_toolchain/libexec/gcc/arm-linux-androideabi/4.7.1/real-ld: error: hidden symbol '__dso_handle' is not defined locally
|
I'm using -fPIC in the compiler's flags so I'm not sure why the linker
is complaining.
The |__dso_handle| error is supposed to have been fixed in the NDKr6. I
tried the
Linaro 4.7.1(2012.05) toolchain, the one available for download, one of
the daily
builds from Linaro of the same toolchain(the one from Friday last week)
and I also
rebuilt entirely the toolchain from source but with the same results. I
found a bug
report in the
launchpad(https://bugs.launchpad.net/igloocommunity/+bug/1000200)
which pretty much describes exactly the same problem but unfortunately
none of the
observations made there helped(I do have -fPIC in the compilation flags,
I do not
have any assembly source and I rebuilt the toolchain from source).
Does anyone have any hints on how to fix or overcome the problem?
Thanks,
Marius
== GCC ==
* Fixed vectorizer bug causing unaligned memory accesses
(LP 1010826 / GCC PR 53636); checked in to GCC mainline
and Linaro GCC 4.7. Backports to FSF 4.7 and Linaro
GCC 4.6 are under way.
* Investigated vectorizer performance regression reported
by Mans; main problem seems to be lack of use of the
vectorizer cost model by default on ARM, but other
aspects of the vectorized code could be improved as well.
* Created blueprint to tune vectorizer cost mode on ARM
and enable it by default.
* Ongoing work on reassociation pass.
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
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro QEMU 2012-06.
Linaro QEMU 2012.06 is the latest release of qemu-linaro. Based off
upstream qemu, it includes a number of ARM-focused bug fixes and
enhancements.
There are no major changes with this release, though it has been updated
to the latest (1.1.0) qemu.
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.06
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
We talked at Connect about finishing up the cortex-strings work by
upstreaming them into Bionic, Newlib, and GLIBC. I've written up one
of our standard 'Output' pages:
https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/CortexStrings
with a summary of what we did, what else exists, benchmark results,
and next steps. This can be used to justify the routines to the
different upstreams.
The Android guys are going to upstream these to Bionic. I need a
volunteer to do Newlib and GLIBC.
One surprise was that the Newlib plain C routines are very good on
strings - probably due to a good end of string detector.
-- Michael
Hi,
OpenEmbedded-Core/meta-linaro:
* worked on building oe-core+meta-linaro using the 2012.05 release of
the binary toolchain
* minimal sysroot contains libraries that reference the old
ld-linux.so.3 loader
* created #1011671
* otherwise works fine for oe-core+meta-linaro
* setup the build env on tcserver01
* verified the 2012.06 RC of linaro GCC 4.7 and 4.6
* 4.7 looks good
* 4.6 has ICE when building Qt -mfpu=neon
* reduced testcase available at bug #1013209
* updated meta-linaro (master) to pull in version 2012.06 of Linaro
GCC 4.6/4.7
Regards,
Ken
Hello,
I am wondering if there is support for gettext in the linaro toolchain?
How can I check it if it should work or not?
I can compile and link the "setlocale()" and "bindtextdomain()" and
"textdomain()" functions, however, the translation doesn't work.
Best regards
Tom,
--
*Tom Deblauwe*
*R&D Engineer*
Traficon International N.V.
Vlamingstraat 19
B-8560 Wevelgem
Belgium
Tel.: +32 (0)56 37.22.00
Fax: +32 (0)56 37.21.96
URL: www.traficon.com <http://www.traficon.com>
I noticed this bug upstream about C++11 and C++98 ABI
incompatibilities , in case someone is using the C++11 features,
please be aware that there is an ABI bug lurking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Ramana
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro GDB 7.4 2012.06.
Linaro GDB 7.4 2012.06 is the third release in the 7.4 series. Based off
the latest GDB 7.4.1, it includes a number of bug fixes.
Interesting changes include:
* GDB now expands tildes in solib-search-path entries.
* Updated to the GDB 7.4.1 code base.
https://launchpad.net/gdb-linaro/+milestone/7.4-2012.06
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
The Linaro Toolchain Working Group is pleased to announce the 2012.06
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.06 is the third release in the 4.7 series. Based
off the latest GCC 4.7.0+svn188038 release, it includes performance
improvements especially around 64 bit operations.
Interesting changes include:
* Updates to GCC 4.7.0+svn188038
* Adds multilib support for use in the binary builds
* Improves performance of 64 bit shifts in core registers
Fixes:
* LP: #949805 GCC doesn't by default use %gnu_unique_object
* LP: #990530 internal compiler error: in convert, at lto/lto-lang.c:1292
* An off-by-one error in vrev
Linaro GCC 4.6 2012.06 is the sixteenth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn188320 release, this is the third
release after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn188320
* Uses the new /lib/ld-linux-armhf.so.3 loader for hard float binaries
Fixes:
* LP: #949805 GCC doesn't by default use %gnu_unique_object
* LP: #990530 internal compiler error: in convert, at lto/lto-lang.c:1292
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.06https://launchpad.net/gcc-linaro/+milestone/4.6-2012.06
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.06
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
On 12 June 2012 18:53, Akash D <akashd(a)renuelectronics.com> wrote:
> Hello Michael,
>
> Thanks for reply.
>
> The required information is mentioned below.
>
> Compiler Used --->
>
> http://launchpad.net/gcc-arm-embedded
>
> Version number ---->
>
> arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.6.2 20110921
> (release) [ARM/embedded-4_6-branch revision 182083]
Yip, this is ARM's Cortex-R & M bare metal toolchain. It doesn't come
directly from Linaro but we've got a good relationship with them.
I'll ping them and see the best place to ask this question.
> The link file is attached with this mail.
I only had a quick read, but you're missing a capture for the
'.text.startup' section in the linker script. You might need
something like:
*(.text.startup)
before the one.o(.text) line or to change the *(.text) capture to
*(.text*). The startup section might need to be at a fixed address.
Please check your chip and toolchain documentation to confirm.
-- Michael
While benchmarking the auto-vectoriser on Libav, I noticed a performance
regression in gcc 4.7 (both FSF and Linaro) compared to gcc 4.6 in the AAC
decoder. I narrowed it down to this function:
static void ps_hybrid_analysis_ileave_c(float (*out)[32][2],
float L[2][38][64],
int i, int len)
{
int j;
for (; i < 64; i++) {
for (j = 0; j < len; j++) {
out[i][j][0] = L[0][j][i];
out[i][j][1] = L[1][j][i];
}
}
}
While gcc 4.6 does not attempt to vectorise this at all, 4.7 goes crazy
with a massive slowdown, about 20x slower than non-vectorised with Linaro
4.7 and much worse with FSF 4.7.
Let me know if you need more information.
--
Mans Rullgard / mru
== Progress ==
* Connect last week.
* Worked through the open issues and open work items related to
performance and we've got a clear list of things that are currently in
flight. Now to keep track of this better.
https://wiki.linaro.org/RamanaRadhakrishnan/Sandbox//RRQ212ConnectNotes
and move this away from the wiki page in a form that we can use to
talk during our regular performance meetings.
* Created blueprints, closed down old issues and reprioritized
issues with Ulrich and others.
* A number of interesting conversations during Connect for a number
of compiler related issues.
* Other sessions that I attended included the Android optimizations
sessions - while there was quite a bit about toolchain performance it
is important that we keep looking out for the performance profiles and
find areas where the toolchain can be improved. However this can't be
done without getting more testcases from other groups. There were a
couple of interesting comments made that skia is CPU bound which would
indicate that the paint function is CPU bound. But why and how ?
Someone should look at reproducing these numbers and see where we get
to in this area. Pointed out that cortex-strings might be good to make
it into bionic ?
* Fixed the vrev off by one error and committed to FSF trunk .
However it couldn't make it in time for FSF 4.7.1 as the merge window
had closed by then.
* Set up my panda board to be identical to what runs on our
validation labs etc.
* This week
* Worked through the merge requests and moved some patches
upstream away from the "toreview" state.
* Landed a few merge requests that were approved but hadn't been
done so. Took care of merging the upstream 4.7 branch.
* Given I only had a few hours back in the office this week I
worked on regenerating arm_neon.h to use __builtin_shuffle with
vrev64, vrev32, vtrn , vzip and vuzp. A follow up patch needs to do
the same for vext but that needs generic support also in
vec_perm_const_ok .Once that is done I think we can safely start
rewriting . It still needs some more testing and polishing up but the
initial results on the testcase from PR48941 is kind of neat. The
result for some of the other testcases that I've looked at also looks
much better than where we were a few weeks back. So all in all nice
progress on that front. However we have to also find a way of getting
these generated at O0 which they don't appear to do so cleanly enough
with this approach.
for one example it does look like this below: Notice those spills
beginning to disappear .... :)
New :
sqrlen4D_16u8:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vabd.u8 q1, q0, q1
vmull.u8 q0, d2, d2
vmull.u8 q8, d3, d3
vuzp.32 q0, q8
vpaddl.u16 q0, q0
vpadal.u16 q0, q8
bx lr
Old :
sqrlen4D_16u8:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
vabd.u8 q1, q0, q1
stmfd sp!, {r4, fp}
add fp, sp, #4
sub sp, sp, #48
add r3, sp, #15
vmull.u8 q0, d2, d2
bic r3, r3, #15
vmull.u8 q8, d3, d3
vuzp.32 q0, q8
vstmia r3, {d0-d1}
vstr d16, [r3, #16]
vstr d17, [r3, #24]
vpaddl.u16 q0, q0
vpadal.u16 q0, q8
sub sp, fp, #4
ldmfd sp!, {r4, fp}
bx lr
* Attended platform / WG sync-up.
== Plans ==
* Cleanup the ml bits of rewiring the intrinsics and try some proper testcases.
* Work on the auto-inc-dec scheduler patches.
* Rework the sched-pressure patch upstream .
* Review the Android benchmarking writeups.
Summary:
* Bug fixes.
* Tune ivopt for code size.
Details:
1. Reproduce lp:1007353 "kernel build fails with 12.04 and 12.05
toolchain released" and workout a patch to fix it; reopen the related
binutils/gas bug http://sourceware.org/bugzilla/show_bug.cgi?id=12698
and propose the patch to it; push the patch to linaro crosstool-ng to
make sure lp:1007353 is fixed for next binary toolchain release.
2. Setup the SPEC build env and reproduce lp: 886124 "using LDR from
literal pool rather than MOVW/MOVT". After cprop1 replaces lo_sum
(high: symbol_ref bloc) (symbol_ref (block)) with a (symbol_ref
(block)), no later optimization can split it. The solution in linaro
4.5 is to add a split (porting from codesourcery) in arm.md. Then
split1 can split the (symbol_ref (block)). The split is:
(define_split
[(set (match_operand:SI 0 "arm_general_register_operand" "")
(match_operand:SI 1 "general_operand" ""))]
"TARGET_32BIT
&& TARGET_USE_MOVT && GET_CODE (operands[1]) == SYMBOL_REF
&& !flag_pic && !target_word_relocations
&& !arm_tls_referenced_p (operands[1])"
[(clobber (const_int 0))]
{
arm_emit_movpair (operands[0], operands[1]);
DONE;
})
3. Tune ivopt for code size. Try to set avg_loop_niter to 1 since loop
iterator number does not impact code size. But test shows there is no
improvement. Need more tuning.
Plans:
* Analyze the failed cases in arm-linux-gnueabihf regression test.
* Tune code size for M0.
Best regards!
-Zhenqiang
Hello Sir/Madam,
I am using MK60FN1M0VLQ12 (COTREX-M4) processor for my development.
I am using float and double data types in my code. When I perform any
mathematical operation on these variables, the processor goes to Hard Fault
Exception.
Earlier I have used GCC 4.5.2 compiler for my compilation
So now I am using Linaro's GNU-GCC Toolchain 4.6.2 for compiling my code
with following command.
arm-none-eabi-gcc -Wall -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mcpu=cortex-m4
-mthumb -Qn -Os -mlong-calls -c main.c -o main.o
But I am getting following error while linking my code
ld: section .text.startup loaded at [00032258,000331cb] overlaps section
.InitializedVariables loaded at [00032258,00032787]
The link file is attached with this mail.
Can you please suggest me some solution for this problem.
Can you also suggest some compiler commands to support float and double data
type using software.
Awaiting for your reply,
Thanks & Regards,
Akash
== GCC ==
* Worked on reimplementing reassociation pass based on
review comments I had received.
* Identified root cause and worked on fix for vectorizer
bug causing unaligned memory accesses (reported by Mans).
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
Hi,
OpenEmbedded-Core/meta-linaro:
* fixed the binary toolchain support on master (still 2012.03)
* fixed armhf support for Linaro GCC 4.6 on master
* backport of Linaro GCC 4.7 r114985
* tested the images using QEMU - no failures
* now the master branch supports building images for ARM, MIPS, PPC,
X86 and X86_64 using the latest (2012.05) releases of Linaro GCC
4.6 or 4.7
* add tags on meta-linaro to easily find the revision for a particular
Linaro GCC
* changed cbuild to pull in the master branches of OE-Core and
meta-linaro
* merged the branch that allows to build OpenEmbedded-Core using cbuild
http://bazaar.launchpad.net/~kwerner/cbuild/oecore/changes/
* updated docs on the wiki
Misc:
* public holiday on Thu, vacation on Fri
* I'll be back on Monday : )
Regards,
Ken
Hi,
GDB for Android:
* Submitted and committed trivial patch to gdbserver which made it
compile again on Android. A patch had been added which made gdbserver
use a MIPS-related constant which Android doesn't provide.
* Compared testsuite results of GDB on Android vs regular Linux.
Unfortunately there's a lot of noise because the GCC 4.4 used by
the Android SDK generates bad debuginfo which confuses GDB and breaks
a lot of tests. Overall, it seems GDB on Android is in a generally
good
shape. Still need to run the testsuite again with an Android based on
a newer compiler to have a better comparison.
* Mozilla has a GDB patch to call gdbarch_addr_bits_remove before
comparing PCs in breakpoint handling which seems like a sensible thing
to do. Still, running the testsuite with and without this patch didn't
make a difference on Android or regular Linux.
* Remotely attended the GDB for Android session at Connect. Prepared
the following page to go with it:
https://wiki.linaro.org/ThiagoBauermann/Sandbox/AndroidGDBConnectSession
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
GDB for Android:
* Created patch to expand the ~ in "set solib-search-path". Despite
doing the right thing in other commands, GDB doesn't understand ~ in
solib-search-path, which made me lose some time in a debugging session
trying to figure out what was going on. Committed upstream.
* Looked into AOSP patch which hardcodes use of fork tracing instead of
thread events. Found out that gdbserver actually already prefers fork
tracing on both Linux and Android (tested on ICS and Linaro 12.04).
This must have been a problem in some earlier version, and the patch
is
unnecessary now.
* Set up a QEMU instance with Linaro Android 12.04. Got dropbear ssh
on it and ran the GDB testsuite remotely on the VM.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
OpenEmbedded-Core/meta-linaro:
* added a default xorg.conf for the qemuarmv7a MACHINE
* necessary because OE-Core master switched from Xfbdev to Xorg
* noticed that hard float with Linaro GCC 4.6 works on denzil but is
broken on master
due to differences on the requested/provided interpreter
* it used to (accidentally?) work when /lib/ld-linux.so.3 was used
even for armhf
* need to check out what loader name OE-Core really wants to use
* worked on getting OE-Core to build with Linaro GCC 4.7
* verified that the recipes for Linaro GCC 4.7 are working for ARM,
MIPS, PPC, X86, X86_64
* all images are working!
* updated the wiki pages
Regards,
Ken
Linaro Connect edition...
RAG:
GREEN: productive Connect, hammered out a KVM TODO list
* As usual, most sessions don't really intersect with KVM/QEMU work,
so the bulk of the benefit of the week was in informal discussions
and hacking sessions. Useful outcomes there:
* Dragged Rusty through some of the more obscure corners of the
ARM architecture, in the course of doing a review of all the
A15 cp15 registers and how KVM should handle them
* Thrashed out a todo list for getting to "initial upstreamable
patchset" for KVM:
https://docs.google.com/document/d/1TSpDKQZ-6u-HH_2BNY_85jDStI2YDhENf5-z8Nb…
* Nailed down a few decisions we'd left hanging for a bit
* A few sessions that seem worth mentioning:
* Enterprise bootloaders
Jon M definitely pushing the idea that servers will want ACPI,
UEFI, etc all to look as consistent and like x86 as possible. This
includes a desire for UEFI in the virtual environment provided by
QEMU/KVM. We've been aware we might want to do that, but there is
definitely some work to do to get UEFI running (probably a combo of
QEMU bugfixes/feature work and patching UEFI). Total work required
hard to estimate because you just have to keep fixing bugs until it
works... (The push for UEFI was repeated in a couple of other
sessions too.)
* v8 discussion
The question of whether there will be a v8 QEMU was raised (again).
There do seem to be enough people interested that we should be able
to collaborate on a user-mode emulator, which I think is a good
outcome. This will obviously depend on release of enough public
info on the architecture.
* KVM performance
Bit of a null session, as it turns out that we aren't really ready
to think about performance. We believe there aren't any obvious
areas requiring optimisation in the current KVM patchset. Virtio is
the only thing to be added later, and this is really just missing
QEMU side rather than needing specific kernel support. We did take
the opportunity to go through our TODO list for KVM functionality;
nobody raised anything we'd missed, so that's good.
-- PMM
The Linaro Toolchain Working Group is pleased to announce the 2012.05
release of the Linaro Toolchain Binaries, a pre-built version of
Linaro GCC and Linaro GDB that runs on generic Linux or Windows and
targets the glibc Linaro Evaluation Build.
Uses include:
* Cross compiling ARM applications from your laptop
* Remote debugging
* Build the Linux kernel for your board
What's included:
* Linaro GCC 2012.05
* Linaro GDB 2012.04
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link
your programs against.
Interesting changes include:
* Updates the system root to Ubuntu Precise
* Switches to the arm-linux-gnueabihf triplet
* Compiles programs for hard float by default
* Includes soft float support for ARMv4T and later systems
* Includes debug symbols for debugging and backtracing the C library
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian
6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation
5.7 and later, and should run on any Linux Standard Base 3.0
compatible distribution. Please see the README about running on
x86_64 hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://launchpad.net/linaro-toolchain-binaries/trunk/2012.05
Need help? Ask a question on https://ask.linaro.org/
Already on Launchpad? Submit a bug at
https://bugs.launchpad.net/linaro-toolchain-binaries
On IRC? See us on #linaro on Freenode.
Other ways that you can contact us or get involved are listed at
https://wiki.linaro.org/GettingInvolved.
Thanks to the change in the schedule the agenda is here.
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-05-28
If there are any topics folks would like to add to this for today
please feel free to do so now given we have a session in under 2
hours.
regards,
Ramana
Progress
* Fixed PR53334 upstream - something that broke eembc builds.
* Usual meetings.
* Work through some of the speed tickets and upstream bugzilla perf
tickets in preparation for connect.
* Prepared for connect. Looked through some open issues and
investigating PR48941 patch. Uli and I had some discussions around the
patches for this and I had an idea later this evening to try out
something with __builtin_shuffle which certainly looks interesting and
is effectively what we came up with . It's probably better to use
__builtin_shuffle rather than inventing something on our own. In the
process found a bug with automatic rev generation from vec_perm
expressions and that should now be fixed.
* Worked through the auto-inc-dec stuff. Still needs some work and
looks unlikely to complete before connect and that's something I need
to keep working through.
* Prepared for connect.
Plans
* Connect next week !
Absences:
28 May - 1 June : Linaro Connect
Committed my core-shifts patch into Linaro GCC.
Checked and posted my (newly rebased) neon-shifts patch upstream for review.
Continued work on my brain-dump of work in progress. Cleaned up, tested
and posted example testcases and before/after compiler output for all my
work-in-progress patches.
Looked at LaunchPad bug #851258. It's a miss-optimization bug that would
take some effort to fix.
Discovered that my lower-subreg build had failed due to Werror. Fixed
the warning, reuploaded the sources, and relaunched the build.
Prepared for travel to Connect.
== GCC ==
* Followed up on review comments on reassociation pass.
* Analyzed performance headroom of Linaro GCC 4.7 compared
to various other compilers and identified several missing
optimisations.
== Misc ==
* Prepared for Linaro Connect Hong Kong.
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
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || ||
== other ==
* preparation for Connect
* wrote up and sent out proposal about handling TrustZone for KVM
* investigated some issues Riku found when testing his packaged
version of KVM (one model issue, one kernel-too-old issue)
* usual upstream maintainer duties
-- PMM
Hi,
OpenEmbedded-Core/meta-linaro:
* cbuild enhancements:
* debugged failures till I noticed cbuild was pulling in the wrong
branch of meta-linaro (now fixed)
* added support for checking the oe-core build prerequisites
* the images are now automatically bootet using qemu
* sizes of the images and package sizes are now recorded
* update to Linaro GCC 4.6 2012.05 (denzil) and Linaro GCC 4.7 2012.05
(master)
* debugged build failure when using Linaro GCC 4.6 in a hard float
configuration
* turns out that OE expects the GCC to respect the
ARCH_FLAGS_FOR_TARGET env variable
to build libgcc and friends properly for the given target
(another missing patch to build the GCC the OE-Core way)
* fix tested and checked in (denzil)
* created/updated wiki pages:
https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/OpenEmbedded-Corehttps://wiki.linaro.org/KenWerner/Sandbox/OpenEmbedded-Core
Regards,
Ken
Hi,
GDB for Android:
* Fixed the PC offset in jmp_buf but the patch still wasn't working.
It turns out that GDB wasn't loading the libc6.so symbols even though
I set both sysroot *and* solib-search-path. Copied libc6.so to GDB's
cwd and the patch worked (will investigate this next week).
Submitted upstream, currently under review.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
GDB for Android:
* Worked on patch which uses the correct offset for finding the PC value
inside the jmp_buf on Android binaries. Things weren't working though,
and in the end it turns out that the value used in AOSP's patch is
wrong.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi Zhenqiang. I've had a look at the difference between testsuite
results on our current softfp Natty builders and the new hard float
Precise builders. The diff and notes is at:
http://people.linaro.org/~michaelh/incoming/hard-float-builder-diff.txt
There's a lot of commonality:
/usr/bin/ld: cannot find {S,g}crt1.o: builder fault. I've fixed this.
sorry, unimplemented: Thumb-1 hard-float VFP ABI errors: tests where
they set the architecture to ARMv5T and use our default Thumb mode.
This causes the compiler to fail as it doesn't support Thumb-1 with
hard float.
arm_iwmmxt_ok5222.c:1:0: sorry, unimplemented: iWMMXt and hardware
floating point
Some are real:
+FAIL: gcc.c-torture/compile/sync-3.c -O0 (test for excess errors)
/tmp/cc3ufndj.s:436: Error: co-processor offset out of range
+FAIL: gcc.dg/pr48335-2.c (test for excess errors)
pr48335-2.c:19:30: internal compiler error: in
expand_expr_addr_expr_1, at expr.c:7527
+FAIL: gcc.dg/pr48335-5.c (test for excess errors)
pr48335-5.c:17:1: error: unrecognizable insn:
(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+bzr114988~zhenqiang-chen~gnueabihf/gcc/gcc-linaro-4.7/gcc/testsuite/gcc.dg/pr48335-5.c:16
-1
(nil))
+FAIL: gcc.dg/torture/stackalign/builtin-apply-2.c -O0 execution test
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
Could you look into the unsupported ones please? I'll fix the crt1
problems and respin the build.
-- Michael
The Precise based hard float auto builders are now online. Every
merge request and commit to gcc-linaro will now be built build both on
a Natty softfp system and a Precise hard float. Let's run this in
parallel for a while before updating the validation lab.
I've also updated the x86 cloud builders from Natty to Precise. A
quick test showed no regressions but I want to run them in parallel
for a bit to be sure.
-- Michael
Progress
* Proposed backport for vfp addressing modes patch.
* Investigated the build issue with EEMBC and have a candidate patch
for upstream trunk. (PR53334)
* Investigated auto-inc-dec sched changes.
* Some upstream patch review.
Plans
* Work on auto-inc-dec sched changes.
* Finish PR53334 patch upstream.
* Work through some of the speed tickets and upstream bugzilla perf
tickets in preparation for connect.
Remerged the GCC 4.7 branch from upstream. I had previously
misunderstood how to resolve a conflict where Uli had committed a
different version of the same patch upstream.
Spun the GCC 4.6 and 4.7 release tarballs and passed them to Michael for
testing.
Continued work on improving code generation for 64-bit and/or/not/xor. I
now have this working to the point where it would be ready to post
upstream .... except that it depends on my other patches that are not
yet committed (or even reviewed) upstream.
Rebased and modified my core-shifts patch following Ramana's code
review. Then regression tested it - no regressions - and committed the
patch upstream. I've also updated the launchpad branch and resubmitted
the merge request with the finalized upstream patch.
Rebased the neon-shifts patch. I'll repost this upstream as soon as I'm
happy it still works correctly.
Worked on a brain-dump of all I have been working on recently. This will
hopefully help others take over my tasks after the contract expires. I
still need to put together all the test-cases and examples that Ramana
requested.
Summary:
* Linaro binary toolchain 2012.05 release.
* Code size benchmark analysis.
Details:
1. Linaro binary toolchain 2012.05 release
* Check-in the patches to support multilib and arm-linux-gnueabihf
in linaro crosstool.
* Update config to 2012.05 release, which will build multilib toolchain:
default option: -mthumb -march=armv7-a -mfloat-api=hard
-mtune=cortex-a9 -mfpu=vfpv3-d16
armv4t option: -marm -march=armv4t -mfloat-api=soft
* Try u-boot build with the armv4t option.
* Add arm-linux-gnueabihf.mpi for windows installer.
* Tests and regression analysis.
2. During code size regression analysis, we find postreload can not
optimize some cases when spilling happens, reassociation for PHI note
might lead to spilling, expand generates inefficient codes which can
not be optimized by later passes and poor code layout introduces more
branch instructions.
Plans:
* Linaro binary toolchain 2012.05 release.
* Investigate other code size regressions in 4.7.
Best regards!
-Zhenqiang
== GCC ==
* Completed implementation 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);
posted to gcc-patches for review.
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
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 ==
* fixed various issues, sent out v2 series, looks good to me
== other ==
* qemu-linaro 2012.05 released
* thinking about how to handle TrustZone in the context of QEMU/KVM
(we're not going to try to do a full emulation, but we need to
define a coherent line for how we support running guests that
are expecting to run as either S or NS PL1/0 kernels)
* had a play with booting UEFI on QEMU -- fails early on trying
to use the TrustZone-only VBAR register
* usual upstream maintainer duties
-- PMM
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
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 ||
== other ==
* cleaned up and refactored QEMU GIC/NVIC code enough to provide
a solid foundation for the in-kernel irqchip support. Posted
the refactoring bits to qemu-devel. This should be enough to
unblock Marc Z.
* qemu-linaro: LP:978694: added patch from Peter Chubb fixing
beagle bootrom FAT12/FAT16 handling
* finished a trivial bit of cleanup of an omap3 ID register patch
I'd had lying around half-done for a while
* investigating a bug reported by Alex Graf where we get a segfault
gtk-query-immodules-2.0 but only if qemu's 'reserve memory space'
feature is being used: this appears to be an interestingly nasty
case where if the guest does mmap(dll); execute code in dll;
munmap(); mmap(dll 2); execute code in dll 2; and the two mmap()s
happened to pick the same address then we will end up using a
stale cached translation from dll 1 when executing dll 2...
-- PMM
== GCC ==
* Completed testing and benchmarking of patch to use vld1/vstd1
instead of vldm/vstdm for vector moves. Saw no regressions but
only minor benefits.
* Checked in patch to fix LP #959242 (GCC PR tree-optimization/52633)
to FSF mainline and 4.7 branch; backports to Linaro GCC 4.7 and 4.6
pending.
* Checked in mainline patch to enable -fsched-pressure by default
on s390.
* Ongoing work on improving end-of-loop value computation.
* 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
Hi Uli,
While looking into something else I ran into these - I wonder how many
of these GCC manages to vectorize ...
http://www.netlib.org/benchmark/livermorec . These look interesting
from a vectorizer kernels point of view.
The other interesting paper of note was this PACT paper on
vectorization benchmarks comparing icc , xlc and GCC which might
provide some interesting hints / reading.
http://polaris.cs.uiuc.edu/~garzaran/doc/pact11.pdf . The appropriate
benchmarks kernels are linked to below.
http://polaris.cs.uiuc.edu/ ̃maleki1/TSVC.tar.gz.
regards,
Ramana
I've put the agenda for Monday's call at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-05-07
which is:
* Review action items from last meeting
* Connect sessions:
* GDB for Android
* GCC performance call - Live!
* KVM performance
* Renderscript
* Android benchmarking
* Dalvik improvements
* Hard float switchover status
* multiarch upstreaming
* Next week is release week
* vld1, EEMBC results, and noise
* twolf result variance
* KVM minimum features
* UP/UP, Ubuntu
* [[MichaelHope/Sandbox/KVMUseCase]]
Feel free to edit,
-- Michael
I've done some minor updates to the instructions for working with
gcc-linaro, bzr, and merge requests at:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips
The interesting changes are using:
* bzr commit --fixes=lp:nnnn to link a branch to a bug number
* bzr branch --hardlink to cut down on branch time and disk usage
* bzr-merge-changelog to automatically merge ChangeLog.linaro
-- Michael
Greetings,
I successfully built BusyBox using the 4.5.2 toolchain. When I try to build BusyBox using the same config with the 4.6.3 toolchain I get the following error:
The Linaro 4.5.2 toolchain was installed in my Ubuntu 11.04 distro using aptitude.
The Linaro 4.6.3 toolchain binaries, downloaded via Launchpad, were installed into my own tools directory.
busybox # make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
scripts/kconfig/conf -s Config.in
can't find file Config.in
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** [include/autoconf.h] Error 2
I get the same error if I try 'make oldconfig' or 'make menuconfig'.
Is there a PATH I need to set? Am I missing a package?
Right now my PATH has following 4.6.3 directories set:
linaro-4.6.3/bin
linaro-4.6.3/arm-linux-gnueabi/libc/usr/include
linaro-4.6.3/arm-linux-gnueabi/libc/lib/arm-linux-gnueabi
linaro-4.6.3/arm-linux-gnueabi/libc/usr/include
Thanks,
Dan
I thought I'd send an update on the SPEC 2000 twolf variance. We're
seeing a high amount of variance in the results for the SPEC 2000
twolf, vpr, and galgel benchmarks. I've run tests on a PandaBoard,
Origen, and IGEPv2 and gotten a coefficent of variance of 0.014,
0.017, and 0.003 which suggests that the problem is Cortex-A9
specific. twolf is hard on the cache so my theory is that it's
something to do with the memory subsystem. I currently have a
PandaBoard running with SMP, heap randomisation, virtual address
randomisation, and the branch predictor off and the CPU down clocked
to the non-overdrive 600 MHz. I'll let this run overnight and see if
the results are tighter.
To solve Andrew's immediate problem, I'm running SPEC on the 64 bit
core register shifts on the OMAP3. The results are tight enough that
we should be able to show any regressions.
-- Michael
I added Ubuntu 12.04 'precise' based sysroots to Jenkins yesterday. They
are built using 'armhf' architecture and available in three flavours:
- alip
- nano
- ubuntu-desktop
So far only -dev ones are present, will work on -dbg ones soon.
We have 'nano' one built and available to fetch at
http://snapshots.linaro.org/precise/images/nano-dev/ - rest will be
built when there will be machine free to do that.
They will also be moved to http://snapshots.linaro.org/precise/sysroots/
to not make people try to boot them ;)
Please take a look do they work as you want and tell me what kind of
changes you would like to have, which images are not needed, which
should be added. Are there any users for -dbg style sysroots?
I did see gcc-4.7 fail to build for an sf/hf multilib configuration. The reason
was that gcc -print-multi-directory didn't print anything for the non-default,
and gcc -print-multi-lib only prints `.'. The reason is that set_multilib_dir
in gcc.c only consults MULTILIB_DEFAULTS (only defined in linux-elf.h), but not
the default configure options in configargs.h. This proposed patch updates
MULTILIB_DEFAULTS depending on the configure options. An alternative approach
would be to update set_multilib_dir and print_multilib_info to lookup the
configure_default_options in configargs.h as well.
Note that this didn't fail to build in gcc-4.6, but I can't see yet what change
did cause the build failure.
Matthias
* Linaro
Continued looking at the lower-subreg problem (that the lowering is only
really intended for 32-bit targets that don't have 64-bit operation).
Without NEON this is only really a problem for "ldrd/strd" 64-bit loads
and stores: the patterns are all (or should be all) written such that
they only access DImode regs via SUBREG, so it all works well. When
adding NEON 64-bit this becomes less clear: many operations must remain
in DImode without SUBREG until after register allocation. The
lower-subreg passes mostly cope with this well enough, but it has some
features that attempt to lower zero_extends, certain shifts, and
pseudo-reg copies, unconditionally. I've been investigating what happens
if I disable the pseudo-reg copy "optimization" in the first
lower-subreg pass. As I expected, in many cases it actually leads to
smaller code (more use of LDRD/STRD) without NEON, and even better
results with NEON. Unfortunately I have found so counter-examples, so
I'm trying to figure out what's going on there: for some reason reload
goes crazy and starts spilling things to the stack, even though I can't
see that more registers are required. More investigation required.
Richard E approved my NEON-immediates patch for upstream. I don't have
time to commit it with proper care this week, so that's delayed to next
week.
* Other
Vacation Monday and Tuesday. Had a fun long weekend in Cornwall with my
family.
Progress
Away last week - nothing to report. Will be in BST + 4:30 timezone
this week.
Plans
* Finish off the VFP addressing modes patch.
* Follow up on iterations idiom patch upstream
* Pursue backporting gnu_unique_object upstream.
* Look at some of the existing blueprints and start discussions around
prioritizing this.
* Investigate some of the SEGVs with h-c partitioning in the future.
Hi Zhenqiang. Ubuntu Precise is now out and has switched to hard
float by default. I want to do the same for the next binaries
release. Here's the work that needs to be done:
* Bring in the new sysroot
* Change the triplet to arm-linux-gnueabihf
* Change GCC's configure so it recognises the new triplet
* Change the default float ABI to hard
We should include a soft float (not softfp) multlib libgcc for those
who use the binary toolchain to build bare metal programs like u-boot
or the kernel. They don't use floating point, but the linker will
complain about mixed calling conventions.
I've updated make-sysroot.sh and spun an experimental sysroot at
http://people.linaro.org/~michaelh/incoming/precise-sysroot-armhf-r0.tar.bz2.
Hopefully we'll use Marcin's ones instead.
Matthias has patches for many of these changes. Let's talk about it
at tonight's meeting.
Could you start on these? I'd like the changes done within two weeks
so we have plenty of time to test.
-- Michael
Summary:
* Linaro binary toolchain 2012.04 release.
* Code size benchmark analysis.
Details:
1. Validate and bug fix for linaro binary toolchain 2012.04 release.
2. Investigate code size regressions in 4.7
Find more regression cases due to loop invariant hoisting, and tests
should we can reduce some codesize with option
-fno-move-loop-invariants. Some regressions are due to
pass_reorder_blocks, which is disabled for -Os in 4.7. For some cases,
ivopt will introduce to more codes and function inline might lead to
more spilling. We also try linaro 2012.04 baremetal build. But there
is a few bytes regression compared with 4.7 trunk.
3. Setup the qemu env following Michael’s instructions
(https://wiki.linaro.org/MichaelHope/Sandbox/QEMUCrossTest) and tests
show it work.
4. Try to build gcc-linaro-2012.04 configured with "--with-fpu=neon
--with-float=hard" based on a precise sysroot
(precise-sysroot-armhf-r0.tar.bz2) from
http://people.linaro.org/~michaelh/incoming
* Linux build is OK without any change.
* Mingw32 build reports error. After removing the code, the build PASS.
[ERROR] .../libc/usr/include/arm-linux-gnueabihf/sys/types.h:117:19:
error: two or more data types in declaration specifiers
Plans:
* Investigate other code size regressions in 4.7.
Planed leaves:
* Labor Day holiday: April 30 and May 1.
Best regards!
-Zhenqiang
Hi,
OpenEmbedded-Core/meta-linaro:
* pushed support for Linaro GCC 4.6.4 2012.04 and for the
2012.03-20120326 binary toolchain
* updated the wiki
* created a branch to support GCC 4.7
* built several images using several GCC 4.7 based toolchains (OE,
linaro 4.7.1, binary toolchain 2012-04)
* minimal images are working
* sato image shows splash screen forever (won't bring up the
matchbox window manager)
* only when using the binary toolchain 2012-04 ? -> needs to be
analyzed
* Qt 4.8 requires small patches (posted and merged into
oe-core/master-next)
Libunwind:
* User reports issues when backtracing through signal frame
* reason: the lib falls back on APCS frame parsing which usually
segfaults on EABI systems
* provided debugging hints and insights on how libunwind handles
signal frames
* posted a reduced testcase
Regards,
Ken
== GCC ==
* Fixed regression (ICE when building EEMBC) with patch to use vld1/vstd1
instead of vldm/vstdm for vector moves. Updated merge request and
restarted testing.
* Implemented patch to fix LP #959242; backported to Linaro GCC 4.7 and
created merge request for regression testing and benchmarking.
* Ongoing discussions on -fsched-pressure; worked on patch to enable it
by default on s390.
* Ongoing work on improving end-of-loop value computation.
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
