== Progress ==
* builtin_bswap16:
* backporting of builtin_bswap16 for ARM to Linaro/4.7: one of the
tests fails. Waiting for Ramana's return to see if he can help me
identify the patch needed from trunk.
* Useless zero extensions: despite Ulrich support I didn't succeed
to rewrite the bswap16 pattern in a way that would avoid
generating useless zero extension. Asking for help on gcc list
shows that it would actually need a complete new optimization
pass, which has already been discussed several times.
* PGO/hot-cold partitioning/Spec2k:
* looking at spec2k build & run system
* Branch reviews: approved Matt's october merges for Linaro-gcc 4.6 and 4.7.
Briefly looked at aarch64-4.7 merge request.
== Next ==
* builtin_bswap16:
* try to complete backport to linaro-gcc 4.7.
* PGO/hot-cold partitioning/Spec2k:
* investigate compiler crash and runtime failures.
* setup Snowball
== Progress ==
* Started Linaro ramp up process.
* Started to look at Crosstool-ng and CBuild
* Fighting against proxy and bazaar configuration
== Next Week ==
* Continue the started tasks.
== Progress ==
* 4.6 and 4.7 start of month merges
* Fixed missing binary files issues whilst doing this.
* 4.7 AArch64 merge into gcc-linaro/4.7
* Completed initial merge
* Admin
* Interviewing
== Next Week ==
* Deputise for Michael
* Do GCC-Linaro releases
* Fix up any issues with 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
Adding linaro-toolchain
On Tue, Oct 02, 2012, Khem Raj wrote:
> On Tue, Oct 2, 2012 at 4:59 PM, Tim Bird <tim.bird(a)am.sony.com> wrote:
> > When I try to build the Linux kernel version 3.6 with the gcc-4.7
> > nightly build Linaro toolchains,
>
> linaro binutils needs to back port
>
> http://sourceware.org/git/?p=binutils.git;a=commit;h=3fd1fadc205bc69410080a…
>
> >
> > $ arm-eabi-gcc --version
> > arm-eabi-gcc (Linaro GCC 4.7-2012.09-1~dev) 4.7.2 20120910 (prerelease)
> > $ arm-eabi-as --version
> > GNU assembler (Linux/GNU Binutils) 2.23.51.0.3.20120918
> >
> > I get a compiler error (actually, assembler error):
> >
> > AS arch/arm/lib/copy_from_user.o
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S: Assembler messages:
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r3,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:100: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:118: Error: selected processor does not support ARM mode `ldralt r3,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:119: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:120: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:121: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:122: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:123: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:124: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:173: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt r9,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:243: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt r9,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:245: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r4,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r5,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r6,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r7,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r8,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt r9,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt ip,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > /a/home/tbird/work/auto-reduce/lto-test/linux-3/arch/arm/lib/copy_template.S:247: Error: selected processor does not support ARM mode `ldralt lr,[r1],#4'
> > make[2]: *** [arch/arm/lib/copy_from_user.o] Error 1
> > make[1]: *** [arch/arm/lib] Error 2
> > make[1]: *** Waiting for unfinished jobs....
> >
> >
> > This appears to be related to the following bug report for binutils:
> > http://sourceware.org/ml/binutils/2012-09/msg00128.html
> >
> > I'm compiling the kernel for PandaBoard
> >
> > Any ideas for work-arounds or fixes for this? Note that the ldralt instruction
> > doesn't actually appear in copy_template.S (maybe it's coming from a macro?)
> > -- Tim
> >
> > =============================
> > Tim Bird
> > Architecture Group Chair, CE Workgroup of the Linux Foundation
> > Senior Staff Engineer, Sony Network Entertainment
> > =============================
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Loïc Minier
== GCC ==
* Implemented patch to prevent lower-subreg pass from splitting
pseudo register moves during first pass. Committed to mainline.
* Updated patch to perform 64-bit integer shifts in NEON registers
to avoid NEON single to NEON double register hazard. Re-started
testing via Launchpad branch neon-shifts-4.7-v3.
* Rebased patch to improve 32-to-64-bit extended from core into
NEON registers, added backport of lower-subreg mainline fix.
New Launchpad branch neon-extendsidi-4.7-v3.
* Tested reload patch to fix aarch64 find_reloads_subreg_address
bug on multiple platforms to prepare for mainline.
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
== Progress ==
* builtin_bswap16:
* patch to catch (x<<8)|<x>>8) committed upstream after confirmation
it was OK by PowerPC guys.
* backporting of builtin_bswap16 for ARM to Linaro/4.7: one of the
tests fails. Trying to isolate the trunk change that would make is
pass.
* useful discussions with Ulrich to investigate if we could avoid
generating useless zero-extensions after rev16. I still need to
experiment.
* PGO/hot-cold partitioning:
* applied info from Matt, I have now a usable Spec2000 setup based
on qemu.
== Next ==
* builtin_bswap16:
* try to avoid useless zero-extensions.
* PGO/hot-cold partitioning:
* investigate runtime failures.
* run on a Snowball board.
== Progress ==
* 4.7 AArch64 merge into gcc-linaro/4.7
* Got Foundation model working
* Ran testsuite - results OK - some obvious infrastructure issues though
* Hot/Cold partitioning in PGO:
* Posted second patch upstream
* Had basic flaw with it pointed out (shame was the flaw fixed the issue)
* Admin
* Interviewing
== Next Week ==
* Start of month branch merges.
* HOT/COLD partitioning for PGO:
* Get two current patches accepted upstream
* Post question upstream about register allocation 'mistakes' I am seeing
* ARM/aarch64-4.7-branch merge into gcc-linaro/4.7.
* Investigate failure in testsuite run
* Check that I am merging the svn branches correctly.
* Participate in sprint
* 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
(two week rollup report since week 38 was a short week for me)
Current Milestones:
|| || Planned || Estimate || Actual ||
|| clean up kvm-qemu cp i/f || 2012-09-20 || 2012-09-20 || ||
|| fake-trustzone || 2012-10-15 || 2012-10-15 || ||
Also planned: general keeping up with kernel changes; upstream patch
review; qemu-linaro releases. May change dates to align with overall
KVM plan for the quarter when that is finalised.
Previous Milestones:
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-20 || 2012-07-20 ||
== other ==
* looked briefly at the result of running the clang static analyzer
over QEMU
* wrote some fixes to totally broken code in the ds1338 model as
result
* reviewed some nice TCG optimisation patches from Aurelien which bump
up performance for ARM guests by 10-15%
* reviewed, bugfixed and committed some patches for the bootwrapper
from Dave Martin
* removed obsolete SMC API support from bootwrapper (lets us knock
the final item off a blueprint)
* implemented the new movcond TCG IR insn in the ARM backend
KVM blueprint progress tracker:
http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr…
-- PMM
Summary:
* Validate and release Linaro binary toolchain 2012.09
* Identify the root cause of dwarf check fail in native build when
enabling shrink-wrap.
Details:
1. Validate and release Linaro binary toolchain 2012.09.
2. Analyze the dwarf check fail in native build when enabling shrink-wrap:
* Root cause: tail calls from simple-return path and normal return
path are optimized as one common tail call.
* To fix it, use simple-return to indicate the one from simple-return
path, which will block the optimization to mix them.
Plans:
* Test shrink-wrap performance.
Planed leaves:
* Sept. 30 - Oct. 7: Mid-Autumn Festival and National Day of China's holiday.
Best regards!
-Zhenqiang
Hi,
I am using Linaro Toolchain for compiling UEFI and I am getting alignment
fault as exception while running UEFI on Origen Board.
When I was using other cross compilers the issue was not there.
The crash report is as follows:
Data Abort Exception PC at 0x4F84DCDC CPSR 0x60000133 nZCveAifT_svc
/home/shiva/workspace/armserver/uefi_origen/edk2/Build/OrigenBoard-Exynos/DEBUG_ARMLINUXGCC/ARM/FatPkg/EnhancedFatDxe/Fat/DEBUG/Fat.dll
loaded at 0x4F84D000 (PE/COFF offset) 0xCDC (ELF or Mach-O offset) 0xA9C
0xF8BD6037 LDRH r6, [sp, #0x37]
R0 0x0000000B R1 0x0000000A R2 0x4FCEEAD8 R3 0x80000000
R4 0x4F836010 R5 0x4F863619 R6 0x00000000 R7 0x4F837F10
R8 0xFFFFFFFF R9 0x00000000 R10 0x00000001 R11 0x00000000
R12 0x00000000 SP 0x4FCEEA20 LR 0x4F84DCDD PC 0x4F84DCDC
DFSR 0x00000001 DFAR 0x4FCEEB17 IFSR 0x0000140B IFAR 0x00910883
Alignment fault: read from 0x4FCEEB17
Instruction Domain fault on Page at 0x00910883
ASSERT
/home/shiva/workspace/armserver/uefi_origen/edk2/ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandler.c(304):
((BOOLEAN)(0==1))
--
Thanks and Regards,
Shiva.
Interested in working with us on improving the performance of Linux on
ARM? We’re looking for motivated engineers to work in our toolchain
team on compiler technology, developer tools, and low level
performance libraries. You will use your specialised knowledge to work
in the open, work upstream, and make ARM flavoured improvements to a
range of tools that are fundamental to making the latest mobile and
server products.
We’re currently looking for:
* GCC developers
* Developer tools engineers, especially on the GNU tools like binutils and GDB
* ARM performance engineers, to work on a range of low level libraries
We’re a distributed team. Working from the home office is an option.
Please see the careers page on our website for more information and
how to contact us.
-- Michael
== GCC ==
* Committed patch to use vld1.64/vst1.64 instead of vldm/vstm
to GCC mainline and Linaro GCC 4.7
* Committed patch to use vld1/vst1 to implement vec_set/vec_extract
to GCC mainline and Linaro GCC 4.7
* Posted patch to perform 64-bit integer shifts in NEON registers
for mainline inclusion. Started to address review comments.
* Rebased patch to improve 32-to-64-bit extends from core
into NEON registers; ran into lower-subreg regression.
* Worked on implementing fix for lower-subreg regression.
* Handed over (Richard's) auto-inc-dec patches to Matt.
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.09
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.09
* 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.
Interesting changes include:
* gdbserver is stripped.
* gdbtui is replaced by "gdb --tui"
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.09
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.
Summary
* Prepare Linaro binary toolchain 2012.09 release
* Fix lp:1036170/pr50970
Details:
1. Prepare Linaro binary toolchain 2012.09 release
* Update linaro gcc and gdb to 2012.09 release
* Workaround gdb lsb build issue.
* Strip gdbserver.
* Smoke tests.
2. Merge shrink-wrap patch to lp:gcc for cbuild test. But dwarf checks
fail when building fortan related codes at stage 2.
3. Identify the root cause of lp:1036170/pr50970 and work out a patch to fix it.
Plans:
* Linaro binary toolchain 2012.09 release.
* Fix shrink-wrap build fail issues.
Planed leaves:
* Sept. 30 - Oct. 7: Mid-Autumn Festival and National Day of China's holiday.
Best regards!
-Zhenqiang
== Progress ==
* Discussed big-endian patches for vext tests: careful review of the
specification is required and this patch might actually expose GCC
bugs in big-endian/Neon.
* builtin_bswap16:
* Posted 2 implementations of the generic patch for
(x<<8)|(x>>8). The 2nd one looks OK, but I was asked to make some
checks on powerPC, which are on-going.
* backporting it to Linaro/4.7. On-going: merged obvious patches but
one test does not produce the same code as on trunk.
* validations in cbuild in with GCC configured for thumb and hard FP
showed that some bswap16 tests fail because they force armv6,
which leads to unsupported thumb1 configuration. Proposed
testsuite modification to make this easier, under discussion with
Matt & Richard.
== Next ==
* builtin_bswap16:
* check powerPC results and have the patch accepted upstream.
* measure probable regression in libav when using the builtin
instead of an asm().
* complete backport in Linaro/4.7.
* PGO/hot-cold partitioning: start working on this blueprint.
== Progress ==
* Fixed
https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/1029454
* After investigating further found that this was actually an issue
already fixed in FSF upstream
* 4.7 AArch64 merge into gcc-linaro/4.7
* Did an initial merge of upstream ARM/aarch64-4.7-branch into gcc-linaro/4.7
* So far it hasn't broken other platforms
* Investigated getting FastModels working for me
* Hot/Cold partitioning in PGO:
* Tidied up current patches ready for reposting upstream
* Handed current status to Christophe
== Next Week ==
* HOT/COLD partitioning for PGO:
* Complete hand-over to Christophe
* Get two current patches accepted upstream
* Post question upstream about register allocation 'mistakes' I am seeing
* ARM/aarch64-4.7-branch merge into gcc-linaro/4.7.
* Get a test run of aarch64 targetted compiler complete
* Confirm no code generation changes for other back-ends
* symbol_ref splitting
* Test code alignment hypothesis
* Test v2 patch.
* Admin
* Several interviews
== Future ==
* Look at Cards for Vectorization, PGO and LTO with Michael.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Current Milestones:
|| || Planned || Estimate || Actual ||
|| clean up kvm-qemu cp i/f || 2012-09-20 || 2012-09-20 || ||
|| fake-trustzone || 2012-10-15 || 2012-10-15 || ||
Also planned: general keeping up with kernel changes; upstream patch
review; qemu-linaro releases. May change dates to align with overall
KVM plan for the quarter when that is finalised.
Previous Milestones:
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-20 || 2012-07-20 ||
== track-kvm-abi-changes ==
* folded in Christoffer's interrupt ABI changes
* updated to new ONE_REG ABI for register accesses
* QEMU now in sync with the kernel patchset Christoffer has just sent to alkml
== other ==
* qemu-linaro 2012.09 released
* various meetings/status calls
KVM blueprint progress tracker:
http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr…
Summary
* Workaround the unwind issue for shrink-wrap
* Verify Linaro tickets.
Details:
1. Debugging the failed cases for shrink-wrap. To workaround the
unwind issue, update arm_expand_epilogue to generate return not
simple_return when sp is changed.
2. Setup Linaro toolchain and verify 8 tickets:
*Linaro gcc:
lp:1036170: Function pointer dereferenced twice. It is ARM special bug
which is confirmed in 4.6, 4.7 and FSF trunk only on ARM.
lp:1048709: wrong assembler, out of range vldr instruction. Confirmed
in Linaro 4.6. Can not reproduce it in 4.7 or FSF 4.6.
lp:1014658: It is c++11 related issue in 4.6.
lp:944572: It is a gcc general issue.
lp:972503 and lp:1039401 can not be reproduced.
* Linaro binary toolchain:
lp:1046718: confirmed and fixed it.
lP:1049498: invalid
Plans:
* Prepare Linaro binary toolchain 2012.09 release.
* Performance test for shrink-wrap.
* Follow-up the tickets.
Best regards!
-Zhenqiang
== Progress ==
* Committed patch to fix 3 testcases in big-endian after upstream comments.
* Updated patch to make vext tests support big-endian after upstream comments.
* builtin_bswap16:
* Committed implementation for ARM.
* Investigating testsuite regressions caused by my patch to catch
(x<<8)|(x>>8)
== Next ==
* Continue with bswap16 support.
== Progress ==
* Started looking at
https://bugs.launchpad.net/ubuntu/+source/gcc-4.6/+bug/1029454
* Confirmed the failure
* Unfortunately the git bisect I thought would find the fix didn't
* Hot/Cold partitioning in PGO:
* Some further investigations
* Talked to Uli about one failure - he gave me some further pointers
* Admin
* Some interviewing
== Next Week ==
* Continue looking at 1029454: cselim tree optimizer generates incorrect code
* Start looking at merging the ARM public 4.7 GCC branch into gcc-linaro/4.7
* Hot/Cold Partitioning:
* Investigate remaining silent code-gen faults and non-termination
issue in SPEC
* If failures are fixed start profiledbootstraps and tests on the
central boards.
* 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
== GDB ==
* Created and published Linaro GDB 7.5 release.
== GCC ==
* Posted patch to use vld1.64/vst1.64 instead of vldm/vstm
for mainline inclusion.
* Posted patch to use vld1/vst1 to implement vec_set/vec_extract
with scalar operand residing in memory.
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 GDB 7.5.
Linaro GDB 7.5 2012.09 is the first release in the 7.5 series.
***NOTE*** Linaro GDB 7.5 2012.09 is identical to the FSF GDB 7.5 release,
except for the change in version number and Linaro branding, since all
Linaro GDB features were already accepted upstream and are included in
the FSF release as-is. Future releases in the Linaro GDB 7.5 series may
include additional ARM-focused bug fixes and enhancements.
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.5-2012.09
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro QEMU 2012.09.
Linaro QEMU 2012.09 is the latest monthly release of qemu-linaro. Based
off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes
and enhancements.
There are no major changes in this month's release, but it has
been updated to be based on upstream's recent 1.2.0 release.
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.09
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
The Linaro Toolchain Working Group is pleased to announce the 2012.09
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.09 is the sixth release in the 4.7 series. Based
off the latest GCC 4.7.1+svn191123 release, it includes ARM-focused
performance improvements and bug fixes.
Interesting changes include:
* Updates to GCC 4.7.1+svn191123
* Adds support for the NEON vext instruction when shuffling
* Backports improvements to scheduling transfers between VFP and core registers
* Backports support for the UBFX instruction on certain bit extract idioms
Fixes:
* PR54252 ICE with too wide alignment assertion on vectorised code
* PR54212 ICE due to generating a predicated NEON vdup instruction
Linaro GCC 4.6 2012.09 is the nineteenth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn191000 release, this is the sixth
release after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn191000
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.09https://launchpad.net/gcc-linaro/+milestone/4.6-2012.09
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.09
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
Summary:
* Test shrink-wrap code
Details:
1. Add simple_return support in function thumb2_expand_return for
shrink-wrap. Here is the make check status
* One new fail is due to code size increase. We'd disable it when
optimizing function for size on THUMB2.
* Other new fails is due to dwarf info. Root cause is ICE at function
maybe_record_trace_start
gcc_checking_assert (cfi_row_equal_p (cur_row, ti->beg_row));
Here is the failed code segment:
tst ... L1
push {r4}
...
ldr r4, ...
L1:
bx lr // common simple return from two branches.
Here are the results for cur_row and ti->beg_row of trace starting at L1:
{cfa = {offset = 0, base_offset = 0, reg = 13, indirect = 0, in_use =
0}, cfa_cfi = 0x0, reg_save = 0x0}
{cfa = {offset = 4, base_offset = 0, reg = 13, indirect = 0, in_use =
0}, cfa_cfi = 0x0, reg_save = 0x7ffff726ab70}
Try gcc-linaro-4.5-2011.03. It does not generate the common bx lr.
test L1
push {r4}
...
pop {r4}
bx lr
L1:
bx lr
There is similar bug about it. But the fix is useless for us:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50833
Plans:
* Continue shrink-wrap task.
Best regards!
-Zhenqiang
== Progress ==
* Neon vext support for builtin_shuffle:
* Committed vext patch upstream, as well as a small cleanup patch.
* Merged vext support into gcc-linaro/4.7 branch.
* Posted upstream a follow-up patch to make vext tests support
big-endian.
Filed PR 54517: wrong code generation in big-endian with inline in
these tests.
* Updated patch to fix 3 testcases in big-endian after upstream comments.
* Implement builtin_bswap16:
* Posted upstream a patch to implement bswap16. Discussion on-going,
to have less duplication between arm and thumb patterns.
* Investigating how to make GCC catch the (x<<8)|(x>>8) construct
(where x is unsigned short) and map it to rev16, like
builtin_bswap16.
== Next ==
* Continue with bswap16 support.
Current Milestones:
|| || Planned || Estimate || Actual ||
|| clean up kvm-qemu cp i/f || 2012-09-20 || 2012-09-20 || ||
|| fake-trustzone || 2012-10-15 || 2012-10-15 || ||
Also planned: general keeping up with kernel changes; upstream patch
review; qemu-linaro releases. May change dates to align with overall
KVM plan for the quarter when that is finalised.
Previous Milestones:
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-20 || 2012-07-20 ||
== track-kvm-abi-changes ==
* merged in Christoffer's patches altering the IRQ delivery ABI
== other ==
* resent some patches as qemu trunk has reopened after 1.2 release
* misc upstream review work
* prep for qemu-linaro 2012.09 release
* AFDS (annual review) season again
KVM blueprint progress tracker:
http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr…
-- PMM
== Progress ==
* Started looking at symbol_ref splitting benchmark results
* One big regression ~18%
* Started to investigate whether code alignment was the problem as before
* Hot/Cold partitioning in PGO:
* https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-…
* Sent fixes so far upstream
* Spent most of the week looking at a Silent Code Gen fault in reload.
* Admin
* Some interviewing
== Next Week ==
* symbol_ref splitting
* Test code alignment hypothesis
* Test v2 patch.
* Hot/Cold Partitioning:
* Investigate remaining silent code-gen faults and non-termination
issue in SPEC
* If failures are fixed start profiledbootstraps and tests on the
central boards.
== Future ==
* Look at Cards for Vectorization, PGO and LTO with Michael.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
All,
I have run into a(nother) problem with reload with
-freorder-blocks-and-partition.
Attached is my WIP patch (some of this has been sent up to gcc-patches
for review), and also the profile information (tarred up) I have
gathered in the train session
I get a segfault when executing crafty, which seems to come from
incorrect code generation in iterate.c.
The following shows some of the RTL dump after IRA
(insn 3087 1471 3088 163 (clobber (reg:DI 682 [ D.7985 ])) -1
(nil))
(insn 3088 3087 3085 163 (set (subreg:SI (reg:DI 682 [ D.7985 ]) 0)
(sign_extend:SI (mem/c:QI (reg/f:SI 1417) [0
transposition_id+0 S1 A8]))) 735 {*thumb2_extendqisi_v6}
(expr_list:REG_DEAD (reg/f:SI 1417)
(nil)))
...
(insn 3089 1477 1478 163 (set (subreg:SI (reg:DI 682 [ D.7985 ]) 4)
(ashiftrt:SI (subreg:SI (reg:DI 682 [ D.7985 ]) 0)
(const_int 31 [0x1f]))) 130 {*arm_shiftsi3}
(nil))
...
(insn 2898 2622 2899 203 (set (reg:SI 1677)
(mem/u/c:SI (symbol_ref/u:SI ("*.LC60") [flags 0x2]) [2 S4
A32])) 635 {*thumb2_movsi_vfp}
(insn_list:REG_LABEL_OPERAND 1525 (expr_list:REG_EQUIV (label_ref:SI 1525)
(nil))))
(insn 2899 2898 3491 203 (set (reg:SI 1678)
(ior:SI (reg:SI 1677)
(const_int 1 [0x1]))) 98 {*iorsi3_insn}
(expr_list:REG_DEAD (reg:SI 1677)
(nil)))
(insn 3491 2899 3492 203 (set (reg:DI 1734 [orig:682 D.7985 ] [682])
(reg:DI 682 [ D.7985 ])) 636 {*movdi_vfp}
(nil))
...
(jump_insn 2900 3499 2625 203 (set (pc)
(reg:SI 1678)) 727 {*thumb2_indirect_jump}
(expr_list:REG_DEAD (reg:SI 1678)
(expr_list:REG_CROSSING_JUMP (nil)
(nil))))
...
Insns 2898, 2899, and 2900 form the standard Thumb-2 indirect jump
sequence. Insn 3491 is a move that has been generated as part of
emit_moves in IRA for the loop it belongs to (effectively copying r682
into r1734).
Now despite thinking that r1678 is live throughout insn 3491 after
reload this part of the RTL dump looks like
(insn 2898 2622 2899 212 (set (reg:SI 4 r4 [1677])
(mem/u/c:SI (symbol_ref/u:SI ("*.LC60") [flags 0x2]) [2 S4
A32])) 635 {*thumb2_movsi_vfp}
(insn_list:REG_LABEL_OPERAND 1525 (expr_list:REG_EQUIV (label_ref:SI 1525)
(nil))))
(insn 2899 2898 3491 212 (set (reg:SI 4 r4 [1678])
(ior:SI (reg:SI 4 r4 [1677])
(const_int 1 [0x1]))) 98 {*iorsi3_insn}
(nil))
(insn 3491 2899 3493 212 (set (reg:DI 4 r4 [orig:682 D.7985 ] [682])
(mem/c:DI (plus:SI (reg/f:SI 13 sp)
(const_int 24 [0x18])) [9 %sfp+-672 S8 A64])) 636 {*movdi_vfp}
(nil))
...
(jump_insn 2900 3497 2625 212 (set (pc)
(reg:SI 4 r4 [1678])) 727 {*thumb2_indirect_jump}
(expr_list:REG_CROSSING_JUMP (nil)
(nil)))
That is all of r682, r1678, and r1734 have been assigned to hard
register r4. This is incorrect - as insn 2900 wants to be using r1678
from insn 2899.
Looking at the logs it seems to me that r1734 because its original is
r682 and that is assigned r4.
The reload dump says the following about the liveness of the registers
for various insns:
insn=3087, live_throughout: ..., dead_or_set: 682
insn=3088, live_throughout: ..., dead_or_set: 682
insn=3089, live_throughout: ..., dead_or_set: 682
insn=2898, live_throughout: ..., 682, ..., dead_or_set: 1677
insn=2899, live_throughout: ..., 682, ..., dead_or_set: 1677, 1678
insn=3491, live_throughout: ..., 682, 1678, ..., dead_or_set: 1734
insn=2900, live_throughout: ..., 682, 1734, ..., dead_or_set: 1678
This suggests to me that the compiler should know assigning the same
hard-register to r682 and r1678 is incorrect as they have overlapping
live-ranges, and are not duplicates of each other.
The compiler is configured as follows:
Target: arm-none-linux-gnueabi
Configured with:
/work/sources/gcc-fsf-enable-hot-cold-partitioning/configure
--target=arm-none-linux-gnueabi
--prefix=/work/builds/gcc-fsf-enable-hot-cold-partitioning-arm-none-linux-gnueabi/tools
--with-sysroot=/work/builds/gcc-fsf-enable-hot-cold-partitioning-arm-none-linux-gnueabi/sysroot
--disable-libssp --disable-libgomp --disable-libmudflap
--enable-languages=c,c++,fortran --with-cpu=cortex-a9 --with-fpu=neon
--with-float=softfp --enable-build-with-cxx : (reconfigured)
/work/sources/gcc-fsf-enable-hot-cold-partitioning/configure
--target=arm-none-linux-gnueabi
--prefix=/work/builds/gcc-fsf-enable-hot-cold-partitioning-arm-none-linux-gnueabi/tools
--with-sysroot=/work/builds/gcc-fsf-enable-hot-cold-partitioning-arm-none-linux-gnueabi/sysroot
--disable-libssp --disable-libgomp --disable-libmudflap
--enable-languages=c,c++,fortran --with-cpu=cortex-a9 --with-fpu=neon
--with-float=softfp --enable-build-with-cxx
Thread model: posix
gcc version 4.8.0 20120821 (experimental) (GCC)
The gcc command line looks like:
./xgcc -B`pwd` -march=armv7-a -mtune=cortex-a9 -mthumb -mfpu=neon
-mvectorize-with-neon-quad -mfloat-abi=softfp
-fprofile-use=.../186.crafty -freorder-blocks-and-partition
-fno-common -fdump-noaddr -O3 -dp -save-temps iterate.c -o iterate.o
Does anyone have any hints as to where I should go looking?
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
First I am trying to learn and am in no way an expert.
I have searched and searched for a walkthrough on how to compile LKMs for my
pandaboard ES. My target is the pandaboard running Linaro 12.08. I am using
Linaro toolchain binary 12.08. My confusion comes from me not knowing where
the kernel sources are (really how to get them) and the target libraries. I
guess what I expect is the target's rootfs with kernel source to be
somewhere on my Ubuntu Host so I can link to them.
I have tried the following make file configs. But obviously, I don't have
the correct path for KERNDIR as I don't know if it even exists on my host.
And the second make file seems like a native compile.
My previous experience with buildroot:
KERNDIR=/opt/buildroot/build_arm/linux-2.6.20.7/
export CROSS_COMPILE=arm-linux-
export ARCH=arm
obj-m += pwr_led.o
all:
make -C $(KERNDIR) M=$(PWD) modules
clean:
make -C $(KERNDIR) M=$(PWD) clean
Web examples:
obj-m = foo.o
KVERSION = $(shell uname -r)
all:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(KVERSION)/build M=$(PWD) clean
Could you please set my head straight by pointing me to a webpage or briefly
walking through the steps?
Thanks,
Todd
Assaf,
Just to let you know that linaro-toolchain-dev(a)lists.launchpad.net is
a closed list, a better place for this question is
linaro-toolchain(a)lists.linaro.org.
On 3 September 2012 11:41, Assaf Hoffman <hoffman(a)marvell.com> wrote:
> Hi,
>
> Where can I find Linaro toolchain manuals?
The manuals are distributed as *.info files, as per FSF GCC. These
are found in .../share/info/ under wherever you installed your
toolchain.
One way to view these is to run info as follows:
info -f .../share/info/gcc.info
> I’m looking for Linaro supported optimization flag list.
>
> Is it a super set of FSF GCC?
Linaro GCC 4.X supports all the options of FSF GCC 4.X, it may also
support options that were added in later versions of FSF GCC if the
appropriate functionality has been backported. The info files will
document these new options.
Unfortunately, I do not have an easy to read list of these options (if
indeed there are any), so I can't provide you with any further
pointers at the moment.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Summary:
* Release Linaro binary toolchain 2012.08
* Start shrink-wrap task
Details:
1. Validate and release Linaro binary toolchain 2012.08.
2. Start shrink-wrap task
https://launchpad.net/gcc-linaro/+spec/shrink-wrapping:
* Learn the background from the mail-list discussion:
http://old.nabble.com/Shrink-wrapping%3A-Introduction-to31220423.html
* Build X86/MIPS trunk toolchain to check the changes.
* Try to apply ARM backend related patches. It can get correct
result for several small cases. But lots of new fails in gcc
make-check. "pop_multiple_with_writeback_and_return" is not handled
correctly.
Plans:
* Continue the shrink-warp work.
Best regards!
-Zhenqiang
(Short week: 4 days, bank holiday)
Current Milestones:
|| || Planned || Estimate || Actual ||
|| clean up kvm-qemu cp i/f || 2012-09-20 || 2012-09-20 || ||
|| fake-trustzone || 2012-10-15 || 2012-10-15 || ||
Also planned: general keeping up with kernel changes; upstream patch
review; qemu-linaro releases. May change dates to align with overall
KVM plan for the quarter when that is finalised.
Previous Milestones:
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-20 || 2012-07-20 ||
== track-kvm-abi-changes ==
* working through design of how we do sync of register state between
QEMU and the kernel and how we handle migration (the two turn out
to be related and I now have a nice looking design that resolves
both of these at once)
* both the interrupt injection ABI and the coprocessor access
ABI are changing (again!)
== other ==
* fixed an embarrassing bug which made qemu-system-arm segfault
on 32 bit hosts; luckily spotted just in time for QEMU 1.2 release
* AFDS (annual review) season again
KVM blueprint progress tracker:
http://ex.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&pr…
-- PMM
== Progress ==
* Bank Holiday on Monday
* Got symbol_ref split benchmarking going
* Hot/Cold partitioning in PGO:
* https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-…
* Investigated and fixed all compile-time failures in SPEC
* Investigated and fixed a silent code-gen fault in SPEC
== Next Week ==
* Look at symbol_ref split benchmarking results
* Hot/Cold Partitioning:
* Investigate remaining silent code-gen faults and non-termination
issue in SPEC
* If failures are fixed start profiledbootstraps and tests on the
central boards.
== Future ==
* Look at Cards for Vectorization, PGO and LTO with Michael.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
== Progress ==
* Validation of my vext patch in big-endian mode proved that proper
support would be non-trivial.
Spent a lot of time writing a self-testing executable test, which
works in both big and little endian modes.
Posted an updated patch which makes no optimization in big-endian.
After discussion with Ramana, I will post a 2nd patch which improves
the testing in big-endian mode.
* In the process, wrote a patch to fix 3 other testcases which used to
fail in big-endian mode.
* Received no answer from the original contributor of bswap16 support patch.
== Next ==
* Have my vext patch accepted on trunk.
* Continue with bswap16 support.
(Short week: 3 days)
Current Milestones:
|| || Planned || Estimate || Actual ||
|| clean up kvm-qemu cp i/f || 2012-09-20 || 2012-09-20 || ||
|| fake-trustzone || 2012-10-15 || 2012-10-15 || ||
Also planned: general keeping up with kernel changes; upstream patch
review; qemu-linaro releases. May change dates to align with overall
KVM plan for the quarter when that is finalised.
Previous Milestones:
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-20 || 2012-07-20 ||
== clean-up-kvm-patches ==
* patches as they stand look good; currently blocked waiting
for changes to go into kernel side
== track-kvm-abi-changes ==
* thinking about some interesting corner cases in accessing
cp15 state via KVM, notably how userspace should get at the
cache ID registers, which are exposed by hardware as a "select"
and "read value of selected register" cp15 register pair.
Consensus seems to be that the kernel should deal with converting
this into a simple interface that userspace can use to just
read all the ID register state at once.
== other ==
* fixed breakage in ARM TCG host support (recent changes had failed
to account for the ABI requirement that 64 bit arguments to functions
must be passed in even-odd register pairs)
* KVM bootwrapper: pushed 64-bit-addresses-in-dtb patch to main repo;
reviewed patch from Guodong Xu adding uInitrd support
KVM blueprint progress tracker:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
-- PMM
The Linaro Toolchain Working Group is pleased to announce the 2012.08
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.08
* 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:
* Enable threaded gold linker in Linux package
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.08
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.
Summary:
* Identify the root cause of performance regression for the "split2" patch.
* Validate Linaro binary toolchain prerelease.
Details:
1. Identify the root cause of performance regression for the "split2" patch.
* Code alignment is the root cause for the performance regression
(Michael reproduced it with "__attribute__ ((aligned(16)))").
* "build-id" section is the root cause of result difference from
cbuild test (the additional section makes the function address
different).
* Workout a small case to show the impact of code alignment on performance.
2. Linaro binary toolchain 2012.08 prerelease validation. All tests pass.
Absence:
* Annual leave: Aug. 24.
Plans:
* Linaro binary toolchain 2012.08 release.
* Start shink-wrap work.
Best regards!
-Zhenqiang
== Progress ==
* Fixed problems with my patch for "constant vec permute operation for
the vext instruction" blue-print, validated in cbuild.
* Ported it to trunk and submitted for review. R.Earnshaw requested
validation on big-endian. I need to upgrade my qemu to have it
supported.
* Compiled my Neon intrinsics testsuite with LLVM (version 3.2 trunk 160543).
It compiles at O0/O1/O2/O3, but only O0 produces the expected results.
Errors include: vset_lane, vld3, and vld4.
* Started looking a bswap16 support
== Next ==
* Have my "constant vec permute operation for the vext instruction"
patch accepted on trunk
* Continue with bswap16 support.
== Progress ==
* Follow up from 2012.08 Toolchain release
* Updated Wiki pages
* Start working on symbol_ref split benchmarking.
* Backport to PR54212 done upstream to 4.6 and 4.7
* Started picking up Hot/Cold partitioning in PGO blueprint:
* https://blueprints.launchpad.net/gcc-linaro/+spec/hot-cold-partitioning-in-…
* Got SPEC running locally and I think I have reproduced Ramana's failures.
== Next Week ==
* Bank Holiday on Monday
* Investiagte SPEC failures in Hot/Cold PGO
* Get symbol_ref benchmarking going properly
== Future ==
* Look at Cards for Vectorization, PGO and LTO with Michael.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
(cc'd to linaro-toolchain to archive)
Hi Matt. I've had a look at the manual builds you tried to spawn.
Here's what I did to run cbuild locally to test it:
* cd linaro
* bzr branch lp:cbuild
* cd cbuild/slaves
* cp -a example `hostname`
* cd `hostname`
* make -f ../../lib/build.mk final/gcc-4.8+svn190558.stamp
I'm not proud of the whole 'slaves/$hostname' setup, but it is what it is.
Results are in $version, such as gcc-4.8+svn190558. The build tree is
in $version/gcc/default/build. Nuke using rm -rf final results
$version. See lib/common.mk and override the email address etc in
local.mk to stop build results going out You should put a proxy in
$http_proxy or ~/.wgetrc to reduce the download cost. Please add to
the cbuild README.
A nit: we use the Debian versioning scheme so the version should be
4.8~svn190558, i.e. a SVN checkout leading up to 4.8. Compare with
4.7+svn1234, which is a SVN checkout of the 4.7 branch.
The tarballs look generally good. I've spawned them into the a9hf
queue as that's what we benchmark on. Note that they're low priority
due to not having 'linaro' in the name.
-- Michael
Zhenqiang's been working on the later split 2 patch which causes more
constants to be built using a movw/movt instead of a constant pool
load. There was an unexpected ~10 % regression in one benchmark which
seems to be due to function alignment. I think we've tracked down the
reason but not the action.
Compared to the baseline, the split2 branch took 113 % of the time to
run, i.e. 13 % longer. Adding an explicit 16 byte alignment to the
function changed this to 97 % of the time, i.e. 3 % faster. The
reason Zhenqiang and I got different results was the build-id. He
used the binary build scripts to make the cross compiler, which turn
on the build ID, which added an extra 20 bytes ahead of .text, which
happened to align the function to 16 bytes. cbuild doesn't use the
build-id (although it should) which happened to align the function to
an 8 byte boundary.
The disassembly is identical so I assume the regression is cache or
fast loop related. I'm not sure what to do, so let's talk about this
at the next performance call.
-- Michael
All,
I have updated the minutes from today's Performance Call here:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-08-21
The following are the actions from the meeting:
* michaelh to folow-up and ping Mans on getting a hold of his benchmark runs
* michaelh to investigate regression with movw/movt patch by hand
* mgrettondann to run current symbol ref splitting patch over SPEC
against FSF trunk
* michaelh to point mgrettondann to existing cards
* michaelh and mgrettondann to start writing card for PGO work
* mgrettondann to pick up Hot/Cold Partitioning patch from ramana,
cross-test against SPEC for correctness, and then do a benchmarking
run
* ramana to create a Blueprint for min-idion in middle-end and
update Todo list with link
* mgrettondann to update todo list with changes in 2012.08 release.
* zchen to work on shrink-wrapping
* clyon to update his vext patch
The next meeting is on 4 September and a proposed Agenda is here:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-09-04
Please add any items you wish to discuss to the agenda.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
On 18 August 2012 12:06, Ramana Radhakrishnan
<ramana.radhakrishnan(a)linaro.org> wrote:
> This should have been fixed by this patch . I'm a bit surprised that
> we are seeing these failures still ?
>
> ../ports/sysdeps/unix/sysv/linux/arm/ldsodefs.h:41:0: warning:
> "MORE_ELF_HEADER_DATA" redefined [enabled by default]
>
> http://permalink.gmane.org/gmane.comp.lib.glibc.ports/1428
>
> which should have made it back to eglibc 2.16 ?
Well, that's embarrassing. The eglibc script is used to both build
eglibc and to use a fixed eglibc to test GCC. The latter was winning
so every snapshot build was actually building eglibc 2.12.
Fixed and testing,
-- Michael
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-20 || 2012-07-20 ||
||clean-up-kvm-patches || || || ||
||track-kvm-abi-changes || || || ||
||fake-trustzone || || || ||
== clean-up-kvm-patches ==
* started on driving "read/write cp15 regs from kernel" from the existing
QEMU hashtable of cp regs it knows about. First cut seems to work,
but needs more testing and also qemu's ARMCPRegInfo struct needs to
provide raw_read/write methods which bypass access permission and
similar checks.
== other ==
* shepherded various things into upstream QEMU for 1.2 release freeze:
arm-devs patch queue, linux-user patches, some minor stuff
* qemu-linaro 2012.08 released
* travel booked for Connect/ELC-E/KVM Forum; rest is blocked on
the Connect conference hotel discount rate/booking info appearing
KVM blueprint progress tracker:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
-- PMM
The Linaro Toolchain Working Group is pleased to announce the 2012.08
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.08 is the fifth release in the 4.7 series. Based
off the latest GCC 4.7.1+svn189992 release, it includes many
ARM-focused performance improvements and bug fixes.
Interesting changes include:
* Updates to GCC 4.7.1+svn189992
* An ABI fix for vectors with the wrong layout
* Backports improvements to the NEON vdup instruction with immediates
* Backports a fix to performance regressions in partial redundancy
elimination at high optimisation
* Backports faster 64 bit core register adds with immediates
A bug has been fixed in GCC's implementation of the AAPCS rules for
the layout of vectors that could lead to wrong code being generated.
Vectors larger than 8 bytes in size are now by default aligned to an
8-byte boundary. This is an ABI change: code that makes explicit use
of vector types may be incompatible with binary objects built with
older versions of GCC. Auto-vectorized code is not affected by this
change.
Fixes:
* LP: #1020601 Strange behaviour with __builtin_unreachable()
* PR38785 huge performance regression on EEMBC bitmnp01
* PR53447 missed optimization of 64bit ALU operation with small constant
Linaro GCC 4.6 2012.08 is the eighteenth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn189991 release, this is the fifth
release after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn189991
* An ABI fix for vectors with the wrong layout
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.08https://launchpad.net/gcc-linaro/+milestone/4.6-2012.08
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.08
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
== Progress ==
* Out of office Friday 17
* Attended Virtual Connect sessions:
* Vectorization
* PGO/LTO: provided benchmarking results on Webkit computed in ST last
year.
* At last managed to have bzr working
* Prepared a patch for "constant vec permute operation for the vext
instruction" blue-print, based on linaro-gcc/4.7
* Some pending internal work
== Next week ==
* Out of office Monday 20
* Check reviews for my patch to have it accepted.
Hi Matt. I've fleshed out the Etherpad for the PGO and LTO session at:
http://pad.linaro.org/GzRj35tXFt
It's a topic list that needs some specifics. Could you make sure we
have basic answers to any correctness or performance questions?
Ramana, could you add the specifics from the performance call? I
can't seem to find the right meeting in the logs.
-- Michael