== Progress ==
* Turn off 64-bits bitops in Neon: initial implementation under
benchmarking.
Currently it modifies the handling of: add, sub, and, or, xor, shifts,
not. In some case the generated code is quite larger, so it will careful
benchmarking.
* Started looking at "disable peeling" blue-print. Reading GCC source code
to get more familiar with that area.
* Internal support
== Blueprints ==
Initial Current Actual
initial-aarch64-backport 31 Oct 2012 30 Nov 2012
aarch64-baremetal-testing 31 Oct 2012 30 Nov 2012
fix-gcc-multiarch-testing 31 Dec 2012 31 Dec 2012
backport-fma-intrinsic 31 Dec 2012 31 Dec 2012
fused-multiply-add-support 31 Dec 2012 31 Dec 2012
gcc-investigate-lra-for-arm 31 Dec 2012 31 Dec 2012
== Progress ==
* Admin
* Interviewing
* Investigate patches for literal pool layout bug
* Took longer than expected as the 'simple' fix is wrong due to GCC not
knowing how large instructions actually are.
* Patch posted upstream
* Post triplet backport patches upstream
* Other bug issues
* Including an issue running SPEC2K on x86 with recent trunk
== Next Week ==
* Run HOT/COLD partitioning benchmarks
* Analyse ARM results
* On x86_64 to see what the actual benefit we could get
* initial-aarch64-backport & aarch64-baremetal-testing
* Finish documentation
* gcc-investigate-lra-for-arm
* Analyse benchmarks
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
== Future ==
* backport-fma-intrinsic & fused-multiply-add-support
* Backport patches once fix-gcc-multiarch-testing has been done.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Hi,
I try ARM, MIPS, PowerPC and X86 on povray benchmark. No one can
shrink-wrap function Ray_In_Bound.
Here is:
bool Ray_In_Bound (RAY *Ray, OBJECT *Bounding_Object)
{
...
for (Bound = Bounding_Object; Bound != NULL; Bound = Bound->Sibling)
{...}
return (true);
}
For ARM O2/O3, "Bound" is allocated to "r6" during ira. So there is copy
r6 = r1 before
testing Bound != NULL
The copy (using r6) blocks the shrink-wrap optimization since r6
should be saved. Need enhance shrink-wrap to handle this case.
Overall, for povray benchmark,
54 functions are shrink-wrapped for ARM;
59 functions are shrink-wrapped for X86;
25 functions are shrink-wrapped for MIPS;
26 functions are shrink-wrapped for PowerPC.
Thanks!
-Zhenqiang
On 15 November 2012 01:58, 남관우 <kw46.nam(a)samsung.com> wrote:
>
> Hi,
>
>
>
> As your guide, i tried to build again.
>
>
>
> without : -mapcs -fno-common -fstack-protector --param==ssp=buffer-size=4
>
>
> and -fPIC instead of -fpic
>
>
>
> But it is failed with same the message. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03)
>
>
>
> Thank you,
>
> Kwanwoo Nam.
>
>
>
> ------- Original Message -------
>
> Sender : 남관우<kw46.nam(a)samsung.com> S4(선임)/선임/SLP개발그룹(무선)/삼성전자
>
> Date : 2012-11-14 21:45 (GMT+09:00)
>
> Title : Re: Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)
>
>
>
> Hi,
>
>
>
> Here is our LDFLAGS.
>
> -Wl,--rpath=/usr/lib -Wl,--as-needed
>
>
>
> And i try to build with your guide.
>
> without : -mapcs -fno-common
> and -fPIC instead of -fpic
>
>
>
> But it is failed with same the message. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03)
Ta. I'm afraid we don't have enough information to solve this.
Could you please send a full build log and we can go from there.
gzipped on a public server is best.
-- Michael
== Blueprints ==
Initial Current Actual
initial-aarch64-backport 31 Oct 2012 30 Nov 2012
aarch64-baremetal-testing 31 Oct 2012 30 Nov 2012
fix-gcc-multiarch-testing 31 Dec 2012 31 Dec 2012
backport-fma-intrinsic 31 Dec 2012 31 Dec 2012
fused-multiply-add-support 31 Dec 2012 31 Dec 2012
gcc-investigate-lra-for-arm 31 Dec 2012 31 Dec 2012
== Progress ==
* Admin
* Interviewing
* Hand over prep with Michael
* Release Week
* Made 2012.11 releases of gcc-linaro 4.6 and 4.7.
* LEG interations:
* Investigated CILK+ and how much work to port to AArch64.
* HOT/COLD partitioning
* Ran benchmarks on ARM
* LRA
* Ran x86-64 benchmarks
== Next Week ==
* Investigate patches for literal pool layout bug
* Post triplet backport patches upstream
* Run HOT/COLD partitioning benchmarks
* Analyse ARM results
* On x86_64 to see what the actual benefit we could get
* initial-aarch64-backport & aarch64-baremetal-testing
* Finish documentation
* gcc-investigate-lra-for-arm
* Analyse benchmarks
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
== Future ==
* backport-fma-intrinsic & fused-multiply-add-support
* Backport patches once fix-gcc-multiarch-testing has been done.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
== Progress ==
* Infrastructure:
- Managed to have my laptop re-installed by IT with a native Ubuntu 12.04,
(as a beta tester).
- Re-setup my working environment.
* GCC release process familiarization.
* Boehm GC AArch64 support:
- Resume libatomic-ops work.
* Some internal support
== Next ==
* Continue on the Boehm GC AArch64 support.
== Progress ==
* Started working on "Turn off 64 bits Bitops in Neon in GCC" blueprint.
* branch review for aarch64-4.7 merge.
A lot of time wasted due network instability making it difficult to
checkout a GCC branch from launchpad/bzr.
* Internal support for infrastructure problems.
* Resumed discussions with our internal IT and Christian Bejram to try to
decrease our constraints.
The Linaro Toolchain Working Group is pleased to announce the 2012.11
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.11 is the eigth release in the 4.7 series. Based
off the latest GCC 4.7.2+svn193200 release, it includes ARM-focused
performance improvements and bug fixes.
Interesting changes include:
* Updates to GCC 4.7.2+svn193200
* Also includes arm/aarch64-4.7-branch up to svn revision 193328.
Fixes:
* LP #1065122
* LP #1065559
* LP #1067760
Linaro GCC 4.6 2012.11 is the 21st release in the 4.6 series. Based
off the latest GCC 4.6.3+svn193199 release, this is the eigth release
after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn193199
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.11https://launchpad.net/gcc-linaro/+milestone/4.6-2012.11
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 pages:
https://launchpad.net/gcc-linaro/4.7/4.7-2012.11https://launchpad.net/gcc-linaro/4.6/4.6-2012.11
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
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Hi,
I've encountered a case where gcc produces a broken program: a branch that should never be taken is taken, and wrong values are written to memory (and printed out).
The code is fairly ordinary and small. It can be seen here: http://pastebin.com/0Hspz8mw
This happens when -funroll-loops flag is used in conjunction with -O2 or -O3. It doesn't seem to happen when it is used with -O1.
Another few things that influences the program flow from from incorrect to correct run (gives expected outpus) are:
- Adding/removing printf's inside the inner loop
- Changing the order of the expressions in the "if" clause. i.e. from this:
if ((y < mu) || (y >= H - md) ||
(x < ml) || (x >= W - mr))
to this:
if ((x < ml) || (y >= H - md) ||
(y < mu) || (x >= W - mr))
- Assigning ml inside f() to the same value (3) it's getting from the function arguments.
All of these shouldn't change how the program behaves but it does.
I compiled this with two different compilers/environments:
1. g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, running on 3.2.1-42-linaro-lt-mx6 (native compilation on the ARM board)
Compilation command:
g++ -march=armv7-a -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O3 -std=c++0x -funroll-loops -o test_bug_sa_loops_linaro test_bug.cxx
2. arm-fsl-linux-gnueabi-g++ (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) 4.6.2 20110630 (prerelease)
Running on a freescale LTIB built linux (3.0.15-1359-g1b64ead)
Compilation command:
arm-fsl-linux-gnueabi-g++ -march=armv7-a -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O3 -std=c++0x -funroll-loops -o test_bug_sa_loops test_bug.cxx
In all the variations I tried it seems that -funroll-loops is critical for this problem to appear.
I'd be glad to hear some comments on this.
Mickey.
This mail was sent via Mail-SeCure system.
On 10 November 2012 05:11, "Frank Müller" <franky1976(a)gmx.net> wrote:
> Michael Hope <michael.hope(a)linaro.org>:
>> My suspicion is that we/crosstool-NG enable extra features like
>> Graphite or GCC is built with a different level of checking. If you
>
> I suspected Graphite as well and removed it in my own builds without noticable difference.
>
>> have the time, could you check the flags passed to GCCs configure?
>> You can do this on Ubuntu using:
>>
>> apt-get build-dep gcc
>> apt-get source gcc
>> dpkg-buildpackage -uc -us -b
>>
>> and compare the configure line with the one in crosstool-NG's build.log.
>
> Isn't this the same as gcc -v? I've posted the lines at http://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002913.html
Good point. There's nothing obvious in the list. Ubuntu explicitly
adds --enable-checking=release but it's the default for release
branches like ours.
I can reproduce the slowdown in a smaller testcase. Compiling pcre
with -O3 -mfpu=neon -march=armv7-a -mtune=cortex-a8 takes 18.8 s for
the Ubuntu Precise 4.6 compiler, 17.8 s for the Ubuntu Quantal 4.7
compiler, and 41.2 s for the Linaro 4.7 2012.10 build. I've logged
LP: #1077739 to track. I'll spin a --enable-checking=release build
just to check.
> The above lines do not work for me, the last line misses a changelog file:
>
> # dpkg-buildpackage -uc -us -b
> tail: cannot open `debian/changelog' for reading: No such file or directory
> dpkg-buildpackage: error: tail of debian/changelog gave error exit status 1
Yip, you need to change to the just-extracted source directory first.
-- Michael
On 14 November 2012 00:48, 남관우 <kw46.nam(a)samsung.com> wrote:
>
> Hi,
>
>
>
> First, our CFLAGS is here.
>
>
>
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wl,--as-needed
> -fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mfpu=vfpv3-d16 -mfloat-abi=hard -mthumb -Wa,-mimplicit-it=thumb
> -mapcs -mno-sched-prolog -mabi=aapcs-linux -Uarm -fno-common -fpic
>
>
>
> It was occurred with the message. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03)
>
>
>
> Second,
>
> -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wl,--as-needed
> -fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mfpu=vfpv3-d16 -mfloat-abi=hard -mthumb -Wa,-mimplicit-it=thumb
> -mapcs -mno-sched-prolog -fno-common -fpic
>
>
>
> It was occurred too. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03)
Hi there. I don't know the cause but I'm suspicious of a few things.
Could you try the following builds?
The most likely:
* Without -mapcs
* Without -fstack-protector --param=ssp-buffer-size=4
Less likely:
* Without -fno-common
* With -fPIC instead of -fpic (should make no difference on ARM)
Could you also send through the linker command line? It would be
great to get a full log up on pastebin or similar.
-- Michael
Hi Michael,
Recently I tested the linaro toolchain gcc-4.6 version and try to
build our codes.
it's okay to compile the codes, but when launching the binary it
occures following messages.
/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03
I tested it both "hard float" and "soft float". the result is same.
do you have any clues?
Test environment:
toolchain: gcc-4.6.4 (2012.10 version) soft float option.
Thank you,
Kyungmin Park
hi,
I use beaglebone ,and the CPU is AM3359 from TI
can I use the linaro toolchain to the u-Boot linux kernel and android files?if I can ,which tool chain you suggest you use.
other question, your android realese file also can use my CPU(AM3359),Can I build image and download to my SD and run it?
thanks for your reply.
zhangzhangwei
2012-11-09
== Progress ==
* Watched some Connect sessions (ARMv8, GCC performance)
* AArch64 GDB support testing and backport investigation:
- Activities blocked until patches with the pthread interface update
are ready.
* Boehm GC AArch64 support:
- Read documentation on the garbage collector and ARMv8.
- Asked for advices to the maintainers.
- Started to port the libatomic_ops.
== Next ==
* Continue on the Boehm GC AArch64 support.
* Attended LinuxCon Europe / ELC-Europe / QEMU Summit / KVM Forum
(an overlapping set of conferences across a week in Barcelona)
LCE/ELC: brief summary of interesting sessions (I've only listed
ones which seem most relevant to ARM just to keep the length of this
report down):
* "Devicetree and its stumbling blocks" -- a view from a kernel
developer perspective of some of the issues with doing platform
data to dt conversions: (a) dt is supposedly OS independent and
an external ABI, implying more need for cleanliness and long term
supportable interfaces. (b) conversions imply a need to generalise
bindings to be usable across many devices (c) what do we do about
configuration / policy choices?
My take is that the kernel folks are tying themselves in knots
to try to preserve the (somewhat fictional in practice) idea that
any kernel will work with any older device tree blob and they'd
find it easier if they declared an amnesty for breaking changes
before some deadline date...
* Developing and testing industrial hardware with QEMU
Rather than developing/testing sw against expensive/limited
availability hw, use a model -- easier automation, ability to
simulate error conditions, etc. If your hardware is basically
a PCI card in an x86 box QEMU's fairly easy to use for this.
* UEFI Secure Boot
A summary of the current status of UEFI Secure Boot: it's mandatory
for Win8 hardware; Linux implication is that we need to be able to
maintain simple "out of box boot off distro CD"; optionally, if we
have end-to-end signed binaries we have access to environments which
will end up mandating it (read: government). Fortunately people
have come together to tackle this and it looks like we're in good shape.
http://mjg59.dreamwidth.org/18945.html is a good summary.
* Kernel report by Jonathon Corbet
ARM featured fairly prominently in this stats-driven roundup:
64-bit ARM support was first listed bullet point for 3.7 features
Pointed out that Linaro and other embedded-ARM kernel contributions
are notably up, ARM mess has been cleaned up.
KVM Forum:
* Concurrency in QEMU
Plans for splitting QEMU's "big lock" into finer grained mutexes;
should improve I/O scalability for KVM guests and realtime guest
latency. However some tricky locking design issues to be solved.
I am as usual sticking my oar in occasionally to remind people that
the world is not solely x86-and-PCI...
* qtest
A summary of QEMU's new qtest framework, how it works and how to
write tests. We're going to start insisting on test cases for new
patches, so I need to write some basic tests for a few ARM devices
so I know how it works :-)
* ARM Virtualization for the Masses
Christoffer Dall's talk introducing the ARM virt. extensions and KVM
work. Well received, various questions afterwards (some elements of
"why doesn't this work the way the x86 stuff does", also lots of
"does this work on the Samsung/Google Chromebook" :-))
QEMU Summit:
* This was an invite-only afternoon with perhaps 20 or so of the
main QEMU contributors; broadly focused on "process" issues like
release management, patch flow and security bug handling. Productive
session; minutes should be available on the QEMU mailing list shortly.
This is likely to be repeated next year.
Informal discussions (IME the most important and worthwhile part):
* virtio related : ran through current status of virtio-mmio patches
with Anthony Liguori and Alex Graf, confirmed what changes we need
to make and what the next steps with this should be. Some enthusiasm
for getting this patchset in in the early part of the QEMU 1.4
release if we can. I'm really happy that we've unblocked this bit of
work which had stalled slightly trying to figure out the right approach.
Long term we will probably end up using virtio-pci on ARM but this
is really dependent on hardware with good PCI support appearing.
* SystemC : the upstream community is not currently interested in
SystemC support, but there is some work on the QEMU core which would
be a useful cleanup for QEMU itself and also useful for the SystemC
folk. I'm hopeful that this might help to bring people working with
QEMU in SystemC closer to the "QEMU upstream" community and mailing
list, but it will be a gradual process both socially and technically
if it does happen.
* an informal enquiry about whether system emulation of virt. mode
in ARM was planned or how much work it would be
* in-kernel-irqchip: common ABI cross architecture
the current ABI is a bit x86-specific, useful discussion about
what POWER/S390/ARM would need. There will probably be some more
ioctls coming along but the good news is that what the KVM ARM
patches have currently fits into the proposals with only a very
trivial tweak; we can add support for the new ioctls later if
they are useful for us.
-- PMM
== Blueprints ==
Initial Current Actual
initial-aarch64-backport 31 Oct 2012 30 Nov 2012
aarch64-baremetal-testing 31 Oct 2012 30 Nov 2012
fix-gcc-multiarch-testing 31 Dec 2012 31 Dec 2012
backport-fma-intrinsic 31 Dec 2012 31 Dec 2012
fused-multiply-add-support 31 Dec 2012 31 Dec 2012
gcc-investigate-lra-for-arm 31 Dec 2012 31 Dec 2012
== Progress ==
* Returned from Connect and followed up.
* Updated performance blueprints for next iteration
* Backporting Doko's triplet patches to 4.7
* Patches ready except for problems building Ada
* HOT/COLD partitioning
* Rebuilt with TBB/TBH disabled always
* Started investigated LRA for ARM
== Next Week ==
* Post triplet backport patches upstream
* Run HOT/COLD partitioning benchmarks
* On ARM to see if TBB/TBH is making the difference previously seen
* On x86_64 to see what the actual benefit we could get
* initial-aarch64-backport & aarch64-baremetal-testing
* Finish documentation
* gcc-investigate-lra-for-arm
* Benchmark on x86_64 to see what the benfit could be.
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
== Future ==
* backport-fma-intrinsic & fused-multiply-add-support
* Backport patches once fix-gcc-multiarch-testing has been done.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Dear all,
we have an ARM Cortex-A8 board where we are running our application. I am in charge of maintaining the Linux on it and the toolchain/SDK setup. So far we've been running Poky/OpenEmbedded and using the cross compiler that came about during the compilation.
For easier maintenance, we are now switching to Linaro. The image is set up and I can compile, however I notice a peculiar fact: the binary distribution of Linaro's gcc (https://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc…) has a significantly larger compilation speed than a version of arm-linux-gnueabihf-gcc that is shipping with Ubuntu. In our particular case, using Ubuntu's version it takes less than 6 minutes to compile our software, but 10 minutes when we use Linaro's version. The makefiles and source are exactly the same, only the compiler is different. I also tried an older version (4.6) of Linaro's gcc to match the Ubuntu one (tested the 12.04 shipped version), with no significant difference.
Compiler flags for the system are -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard
Running with -ftime-report, most of the additional time seems to be spent in the parser. Adding -fno-graphite-identity -fno-graphite for Linaro's gcc did not make a difference.
I believe I tried to use crosstool-ng to make my own version, but I don't remember the results as this was over 7 weeks ago. I also did not have a chance to compare performance of the binaries. I do notice a difference in compilation sizes (4.8 MB for Ubuntu's 4.6 version, 4.1 MB for Linaro's 4.7 versions - can't test anything other right now).
I would like to use Linaro's gcc as the crosscompiler for our project, as it is an easy setup. Repackaging Ubuntu's version is an option, though (some of the team do not use Ubuntu, plus I'd like everybody to use EXACTLY the same version of the crosscompiler). So there is no real "problem" for me, per se, but I am extremely curious as to what is going on here. It seems that Linaro's gcc has additional patches or maybe just different default settings that cause additional time to be spent in the parser. It would be interesting to know what exactly this is and whether/how it can be disabled in those cases where time of compilation is more important than e.g. performance gain.
TIA for replying.
Best
Frank
* Attended Linaro Connect; notable sessions:
+ Ubuntu plans for QEMU for Ringtail release
= upstream qemu has merged qemu-kvm back in so
Ubuntu will switch to qemu from qemu-kvm for x86
= also makes sense now to use upstream qemu for all archs
(following Debian) rather than using qemu-linaro for non-x86:
reasons for using q-l in Ubuntu now mostly fixed (ie upstream
ARM support no longer dire). Ubuntu will carry omap3 patches
to avoid dropping that feature in the changeover
= makes sense for Linaro too as we now have an automated
package-to-PPA setup for people who need bleeding-edge and
also will want Ubuntu to transition to a more stably released
and supported QEMU codebase to use for KVM-on-ARM-servers
+ KVM Testing plans
= worked through a list of things that would be nice to test;
useful feedback from people in the session about what matters.
Missing: specific commitment by anybody to write tests :-)
+ various informal discussions about possibilities for v8 QEMU
* this week: at LinuxCon Europe / ELC-Europe / KVM-Forum / QEMU Summit
-- PMM
Hi toolchain people,
I've gone through and massaged our meetings and 1-on-1s to handle the
recent daylight savings changes. Most meetings now start at 9:15 am GMT
and 1-on-1s are packed before them if possible.
Let me know if I should massage them further,
-- Michael
== Progress ==
* Attended Linaro Connect
* Worked out focus for performance in next iteration:
* Cortex-A15
* Other discussions on:
* Transitioning from cbuild->LAVA
* ARMv8 GNU Tools support
* big.LITTLE Toolchain tuning
== Next Week ==
* Backport Doko's configury changes for arm-none-linux-gnueabihf support
* Remerge HOT/COLD partitioning to test like for like (TBB generation)
* Benchmark LRA vs Reload on x86 and x86-64
* Write up strawman for non-multitest testing in GCC
== Future ==
* Decide whether the effort to develop HOT/COLD partitioning is worth it.
* Support LRA on ARM.
* Attend Connect in Hong Kong...
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Dear All,
We have ARM cross compiler, and building our code. we got below error.
we have GCC Linaro 4.6.4.
arm-linux-gnueabi/bin/ld: DIV usage mismatch between
/home/Release/libasm.a(Blt32_Neon.o) and /home/Release/liblayer.so
arm-linux-gnueabi/bin/ld: failed to merge target specific data of file
/home/Release/libasm.a(Blt32_Neon.o)
is it related to below link ?
http://sourceware.org/ml/binutils/2012-03/msg00211.html
thanks
Hi,
here's some patches for gcc-linaro to make it work with
--host=arm-linux-androideabi
They're the quick and dirty thing to do and look like they could have
been written by Microsoft, needed something working in time for
Connect ;)
gcc-4.7-android-workarounds.patch: Workarounds for things that go
wrong, but where the true cause is yet to be determined (e.g. why
would configure think we have fread_unlocked and friends when we
don't?)
gcc-4.7-libitm-android.patch: Workaround for Bionic not knowing Elf32_auxv_t
gcc-4.7-no-unneeded-multilib.patch: Get the multilib config in sync
with regular Linux
gcc-4.7-stlport.patch: Use stlport instead of libstdc++ (yes, this
sucks - but it's what Android decided to do). Still needs to link
libstdc++ because Bionic contains a libstdc++.so (but it's more like a
libsupc++ - no STL there, but needed for stlport to work).
ttyl
bero
== Progress ==
* HOT/COLD partitioning for PGO
* Initial look at results
* Patch Tracking & Backporting
* Testing Doko's configury changes for arm-none-linux-gnueabihf support
* Connect Prep
* LRA Investigations
* Sign/zero extension II
== Next Week ==
* Linaro Connect
== Future ==
* Attend Connect
* HOT/COLD partitioning for PGO:
* Get two current patches accepted upstream
* Post question upstream about register allocation 'mistakes' I am seeing
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Summary:
* Validate and release Linaro binary toolchain 2012.10
* Test
Details:
1. Release Linaro binary toolchain 2012.10
* Fix windows installer issue due to version format change.
* Validate and release Linaro binary toolchain 2012.10.
2. Identify the root cause of PR 54902 (lp:1065559), and Richard
Biener fixed it.
3. Enable SPEC2006 test. Testing is ongoing.
Planed Leaves:
* Nov. 5-7: Off site teambuilding event.
* Nov. 9, 12-13: Annual leaves
Plans:
* Performance test for shrink-wrap.
Best regards!
-Zhenqiang
== track-kvm-abi-changes ==
* updated qemu patches to match Christoffer's v13 tree, committed
all fixes suggested in previous round of code review, rebased
and sent RFC v3 of the QEMU KVM/ARM support patches
== other ==
* rebased qemu-linaro on master; found and fixed a bug which
meant that beagle models crashed when the kernel tried to touch
the USB-OHCI device
* submitted some minor QEMU cleanup patches (last lot of stuff
before softfreeze next week, I expect)
* usual upstream review/etc
* started to look at virtio-mmio patches
* prep for Linaro Connect next week
KVM blueprint progress tracker:
http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr…
-- PMM
== Progress ==
* Aarch64 GDB support testing:
- Ran the GDB testsuite via gdbserver on x86
- Made a board file to run against the model
- Tried debugging a simple hello world via gdbserver:
It fails while loading the image, because of a mismatch between
kernel and GDB ptrace interface.
* Aarch64 GDB backport investigation:
- Backported to the Linaro GDB 7.5 release.
- Discussed with ARM people the ptrace issue.
== Next ==
* On vacation.
The Linaro Toolchain Working Group is pleased to announce the 2012.10
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.10
* Linaro GDB 7.5 2012.09
* 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.
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.10
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.
Hi All,
I wanted to see the difference in objdump of an application where I can
make the difference between the VFPV3 and VFPV4 support. I tried enabling
the flag -mfpu=vfpv3 and -mfpu=vfpv4 for ARM Cortex A15 toolchain in my
test code but cannot see the difference in two objdumps.
According to my survey, the fused multiply and accumulate is the only
instruction that can create the difference in two. Can any one provide the
sample test code for the same? Precisely, I wish to see the difference in
performance for vfpv3 and vfpv4.
Looking forward to your reply.
Thanks and Regards,
Jubi
Summary:
* Linaro bug analysis
* Validation
Details:
1. Linaro bug analysis:
* lp:1065122: Triaged. A fix patch was committed to 4.7 and trunk.
* lp:1065559: Confirmed. Need more investigation to find the root cause.
* lP:1065509: Can not reproduce it with the latest Linaro toolchain.
* lp:1066095: Investigate and invalid it since the reporter can not
reproduce it now.
2. Bug fix and smoke test for Linaro binary toolchain 2012.10 release.
3. Clean up shrink-wrap related patches and send to Linaro mail-list for review.
Plans:
* Linaro binary toolchain 2012.10 release.
* Shrink-wrap performance test.
Planed leave:
* Oct. 26
Best regards!
-Zhenqiang
== Progress ==
* Read wikis on OpenEmbedded and FastModel
* Aarch64 GDB support testing :
- Managed to run OE rootfs and kernel under FastModel
- Configured the ssh/scp access to the model
* Aarch64 GDB backport investigation :
- Discussed with ARM the port and plans
- Identified upstream patches
== Next ==
* Continue on Aarch64 GDB.
Short week (two days):
== other ==
* implemented QEMU patches to track and tell the kernel where the
various bits of the VGIC should be mapped in the address space;
however these seem to cause the host kernel to Oops...
* added a log message category for "guest just did something that's
probably a bug in the guest", so we can use it instead of random
printf/aborting QEMU
* generate inline code for Neon 64 bit negate and 32 bit abs,
rather than calling helper functions
* updated and resent new versions of some minor cleanup patches
which had got lost/obsoleted by QEMU internals changes
KVM blueprint progress tracker:
http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr…
-- PMM
== Progress ==
* HOT/COLD partitioning for PGO
* Submitted merge request for current changes so that we can
benchmark and see how much benefit we can actually expect
* Patch Tracking & Backporting
* Backported Uli's fix for insn splitting at -O0 to 4.7
* Started backporting Doko's configury changes for
arm-none-linux-gnueabihf support
* Connect Prep
* Started investigating LRA
* Admin
* Interviewing
== Next Week ==
* Prepare for Connect
* Investigate zero/sign extension
* Investigate LRA
* Investigate Conditional Comparison benefits
* AArch64
* Document processes
== Future ==
* Attend Connect
* HOT/COLD partitioning for PGO:
* Get two current patches accepted upstream
* Post question upstream about register allocation 'mistakes' I am seeing
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Hi Ramana,
The attached file is a reference patch to add more dwarf/unwind info
in epilogue. Please help to review.
Without the patch, dwarf check fail for the following cases when
enabling shrink-wrap:
tst ... L1 //simple_return
push ...
...
pop ... //.cfa_offset is not 0
L1:
bx lr //common simple_return
Thanks!
-Zhenqiang
== other ==
* upstream patch review
* target-arm pull request
* reviewed/committed some boot wrapper patches from Tixy to init the CCI
* rebased various qemu kvm-related patches on current upstream master,
sent out RFC v2 for review (matching kernel -v12 patches); this is
getting some useful review feedback
* added check for 'does KVM support vfp-d32' rather than just
assuming it on the QEMU side
* discussed API for userspace to tell KVM the base address of the
VGIC with Avi, Christoffer [todo: write QEMU patches to go with
C's proposed kernel patches]
KVM blueprint progress tracker:
http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr…
-- PMM
Summary:
* Test shrink-wrap.
* Identify the root cause of dwarf check fail when enabling shrink-wrap.
Details:
1. Test shrink-wrap on PandaBoard with Precise
* Bootstrap is OK
* No make check regression
* No performance change for SPEC2000 INT.
2. Identify the root case for dwarf check fail on ARM, while they are
OK on X86 and MIPS when enabling shrink-wrap.
* "push" related INSNs are set as RTX_FRAME_RELATED_P in prologue; but
not all "pop" related INSNs are set as RTX_FRAME_RELATED_P.
* Prologue uses REG_FRAME_RELATED_EXPR notes to tell the dwarf backend
SP is adjusted; but no such kind of notes in epilogue.
* In addition, dwarf info for INSNs to adjust SP are not handled
correctly in epilogue.
Plans:
* Verify shrink-wrap related bugs
* Prepare Linaro binary toolchain 2012.10 release
Best regards!
-Zhenqiang
The Linaro Toolchain Working Group is pleased to announce the 2012.10
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.10 is the seventh release in the 4.7 series. Based
off the latest GCC 4.7.2+svn191881 release, it includes ARM-focused
performance improvements and bug fixes.
Interesting changes include:
* Updates to GCC 4.7.2+svn191881
* Backport changes to use VLD1 for Neon quad loads.
Fixes:
* LP 1053348: Missing binary files
Linaro GCC 4.6 2012.10 is the twentieth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn191880 release, this is the seventh
release after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn191880
* A fix to LP #1029454
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.10https://launchpad.net/gcc-linaro/+milestone/4.6-2012.10
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 pages:
https://launchpad.net/gcc-linaro/4.7/4.7-2012.10https://launchpad.net/gcc-linaro/4.6/4.6-2012.10
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
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
== Progress ==
* Completed Linaro ramp up process.
* Obtained my SSH security exception
* Crosstool-ng :
- Repoduced the aarch64 builds (bare and linux)
- Updated gcc to Linaro 2012.10 and submitted the merge request.
* Cbuild autobuilder :
- Not able to spawn a job on seabright (lack of permission)
== Misc ==
* One day off.
== Progress ==
* builtin_bswap16:
* Backported missing patch from thunk to Linaro/4.7. One test still
failing in the hard-float + thumb configuration because it forces
armv6 and results in a unsupported configuration: vfp-1 + hard-float.
Resumed discussion about a fix I proposed 3 weeks ago.
* PGO/hot-cold partitioning/Spec2k:
* read doc about spec2k
* started looking at 254.gap causing an ICE.
* started studying qemu traces about 175.vpr crashing when compiled
using profiling info. Cold code returns from a function using a
clobbered lr value.
== Next ==
* builtin_bswap16:
* complete backport to linaro-gcc 4.7.
* PGO/hot-cold partitioning/Spec2k:
* investigate compiler crash and runtime failures.
== Progress ==
* Deputising for Michael
* 4.6 and 4.7 2012.10 releases
* Included extra AArch64 merge into gcc-lianro/4.7
* AArch64 support
* Did another merge
* Starting another one.
* HOT/COLD partitioning for PGO
* PINGed If/Then/Else block conversion patch
* Started reworking postreload-gcse.c patch
* Ran into issues with vanilla gcc-linaro/4.7 not being able to
build for 'arm-none-linux-gnueabihf' without some configury magic
* Admin
* Interviewing
== Next Week ==
* Do another AArch64 merge.
* HOT/COLD partitioning for PGO:
* Get two current patches accepted upstream
* Post question upstream about register allocation 'mistakes' I am seeing
* symbol_ref splitting
* Test code alignment hypothesis
* Test v2 patch.
== Future ==
* Look at Cards for Vectorization, PGO and LTO with Michael.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Hi Guys,
I just found an issue in kernel code and thought we must have a
compilation warning for such cases.
Submitted a bug here:
https://bugs.launchpad.net/gcc-linaro/+bug/1064218
Problem description:
-------------------------
When we have following declaration:
struct foo {
char array[5];
....
};
And have a definition like:
struct foo foo_abc = {
.array = "12345",
};
Problem here is: size of array is 5 bytes and so we can actually add a
string with four characters only to it, as '\0' will take
an additional space.
But with my definition of foo_abc.. i had 5 characters + '\0'... that
will make it 6 and that will overflow the array..
What will actually happen here?
- compiler will not add '\0' at all?
-or it will go outside of boundaries of array?
--
viresh
On 5 October 2012 12:10, Rob Herring <robherring2(a)gmail.com> wrote:
> I've been scratching my head with a "scheduling while atomic" bug I
> started seeing on 3.6. I can easily reproduce this problem when doing a
> wget on my system. It ultimately seems to be a combination of factors.
> The "scheduling while atomic" bug is triggered in do_alignment which
> gets triggered by this code in net/ipv4/af_inet.c, line 1356:
>
> id = ntohl(*(__be32 *)&iph->id);
> flush = (u16)((ntohl(*(__be32 *)iph) ^ skb_gro_len(skb)) | (id ^ IP_DF));
> id >>= 16;
>
> This code compiles into this using "gcc version 4.6.3 (Ubuntu/Linaro
> 4.6.3-1ubuntu5)":
>
> c02ac020: e8920840 ldm r2, {r6, fp}
> c02ac024: e6bfbf3b rev fp, fp
> c02ac028: e6bf6f36 rev r6, r6
> c02ac02c: e22bc901 eor ip, fp, #16384 ; 0x4000
> c02ac030: e0266008 eor r6, r6, r8
> c02ac034: e18c6006 orr r6, ip, r6
>
> which generates alignment faults on the ldm. These are silent until this
> commit is applied:
Hi Rob. I assume that iph is something like:
struct foo {
u32 x;
char id[8];
};
struct foo *iph;
GCC merged the two adjacent loads of x and id into one ldm. This is
an ARM specific optimisation done in load_multiple_sequence() and
enabled with -fpeephole2.
I think the assembly is correct - GCC knows that iph is aligned and
knows the offsets of both x and id. Happy to be corrected if I'm
wrong, but I think the assembly is valid given the C code.
-- Michael