Hi all,
Right now, it's impossible to merge from lp:gcc/4.7 to
lp:gcc-linaro/4.7. This is due to a BZR bug of some kind, so hopefully
we won't have to work around it for too much longer.
According to the nice folks at #bzr, here's how to do the same merge
manually:
bzr branch lp:gcc-linaro/4.7
cd gcc-linaro
bzr log | less
# find the last merge revision (it should be clear from the message)
# grab the *SVN* revision number
bzr log --show-ids lp:gcc/4.7 | less
# search for the *SVN* revision number
# (it should appear on the end of a "revision-id" line, not "parent")
# grab the corresponding *BZR* revision number ("revno")
bzr diff -r <bzr-revno> lp:gcc/4.7 > ../patch
patch -p0 -i ../patch
# resolve conflicts, rejected hunks, etc.
bzr add --file-ids-from lp:gcc/4.7
# if it's doing the right thing you'll get messages like:
# "adding <file> w/ file id from <file>"
# if it just says "adding file" then you got something wrong
# edit Changelog.linaro, as usual
bzr ci
bzr push lp:~.........gcc-linaro/merge-from....
After all that, a future "bzr merge" should just work (once the bug has
been fixed).
Anyway, I doubt there's anybody else needs to know this: I've just
posted it in case I get hit by a bus before next month.
Andrew
== GCC ==
* GCC PR 53636 fix caused regression on powerpc64 and sparc64;
committed fix upstream and to Linaro GCC 4.7.
* Backported GCC PR 53636 fix --including regression fix--
to Linaro GCC 4.6.
* Reworked Andrew's neon-shifts branch to reliably use NEON
for "left shift by register"; fix typo in "left shift by 1";
overall simplification of implementation. Tests restarted.
== GDB ==
* Investigated remaining GDB/Android work; reviewed card.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || 2012-06-24 ||
||a15-lpae-support || 2012-07-13 || 2012-07-13 || ||
||clean-up-kvm-patches || || || ||
||track-kvm-abi-changes || || || ||
||fake-trustzone || || || ||
The blueprints clean-up-kvm-patches and track-kvm-abi-changes include
dependencies on kernel side work which makes it hard to set a date;
however I'm hoping to get them either done or mostly done within the
next two months.
== cp15-rework ==
* patches were committed to master, blueprint complete
== a15-lpae-support ==
* worked on a set of patches to lay groundwork for this: mostly
this is extending the size of QEMU's 'target physical address'
type to 64 bits for ARM (potentially a small perf hit for the
32 bit only ARM cores; benchmarking still to be done)
* wrote patches to implement all the various pieces of LPAE,
confirmed that Linux with LPAE enabled boots, sent patches to list
* started looking into whether there are any bits of LAVA that make
sense to use for QEMU benchmarking
== other ==
* fixed a missing Makefile line that meant qemu-linaro wouldn't build
on ARM targets with KVM enabled
* reviewed a pile of outstanding patches (including SDHCI, i.MX31)
and am now caught up with the post-holiday backlog
KVM blueprint progress tracker:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
-- PMM
Hello,
I tried codesourcy
arm-2012.03-57-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2, and get
below err infos.
Error: selected processor does not support ARM mode `sdiv R2,R0,R1'
Error: selected processor does not support ARM mode `udiv R2,R0,R1'
Does it mean this toolchain version don't support both instructions? and
which toolchain can support them?
Thanks a lot!
Xiao
== GCC ==
* GCC PR 53636 fix caused regression on powerpc64 and sparc64;
investigated, determined root cause, and implemented fix.
== GDB ==
* Took over remaining GDB/Android work from Thiago.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
The Linaro Toolchain Working Group is pleased to announce the 2012.06
release of the Linaro Toolchain Binaries, a pre-built version of
Linaro GCC and Linaro GDB that runs on generic Linux or Windows and
targets the glibc Linaro Evaluation Build.
Uses include:
* Cross compiling ARM applications from your laptop
* Remote debugging
* Build the Linux kernel for your board
What's included:
* Linaro GCC 4.7 2012.06
* Linaro GDB 7.4 2012.06
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link
your programs against.
Interesting changes include:
* Refine the system root
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian
6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation
5.7 and later, and should run on any Linux Standard Base 3.0
compatible distribution. Please see the README about running on
x86_64 hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://launchpad.net/linaro-toolchain-binaries/trunk/2012.06
Need help? Ask a question on https://ask.linaro.org/
Already on Launchpad? Submit a bug at
https://bugs.launchpad.net/linaro-toolchain-binaries
On IRC? See us on #linaro on Freenode.
Other ways that you can contact us or get involved are listed at
https://wiki.linaro.org/GettingInvolved.
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-06-23 || ||
||clean-up-kvm-patches || || || ||
||track-kvm-abi-changes || || || ||
||fake-trustzone || || || ||
||a15-lpae-support || || || ||
(dates to come next week)
== cp15-rework ==
* sent out pull request including these patches, so it should get
committed to master in the next few days
== a15-lpae-support ==
* started on getting ARM qemu to work with 64 bit physaddrs
(first stage mostly a tedious code audit)
== other ==
* email catchup following holiday
* rebased various trees, sent out pullreqs for outstanding ARM
QEMU patches
Michael H has set up a web page which tracks progress on KVM related
blueprints here:
http://apus.seabright.co.nz/helpers/backlog?group_by=topic&colour_by=state&…
This includes QEMU blueprints related to KVM.
-- PMM
I've gone through and checked the 64 bit operation improvements that
Andrew has made to GCC. For everything but the Cortex-A8, GCC uses
the NEON unit for 64 bit operations and Andrew's improvements mean we
can stay on NEON for longer without having an expensive transfer back
and forth to the core registers.
The results are here:
https://wiki.linaro.org/MichaelHope/Sandbox/64BitOperations
Once we've fixed the shift-left-by-n pattern I'll turn this into an
Outputs[1] page.
Benchmark results have been sent to the linaro-toolchain-benchmarks list.
-- Michael
Hi,
OpenEmbedded-Core/meta-linaro:
* updated OE-Core cbuild to pick up a recent snapshot of meta-linaro
* verified the release candidate of the Linaro binary toolchain 12.06
* prepared meta linaro for the upcoming release of our binary toolchain
* started on a linaro-qemu recipe but didn't finish it
misc:
* boot Linaro Android using QEMU:
https://wiki.linaro.org/KenWerner/Sandbox/AndroidQEMU
Regards,
Ken
== Progress ==
* Tried a number of testcases for the shuffles . Needed to add
support to the C++ frontend for the __builtin_shuffle support.
Fortunately there existed a patch - I tested it and it looked good.
Committed upstream. However the original author had some concerns
whether it would work in C++ or not but we shall see. The OP is
concerned that it might break C++11 and constexpr which need to be
looked at .
* Briefly investigated a regression with Linaro GCC 4.6 with Neon
intrinsics. It looks like my patch to allow LTO to proceed has had
some fall out . We really need some good tests in the GCC testsuite
for intrinsics.
* Looked at the Android documents and commented.
* Some upstream patch review.
== Plans ==
* Follow on the C++11 issues with the __builtin_shuffle patch if any.
* Commit the __builtin_shuffle variation of the neon intrinsics
patch into FSF 4.8. The improvements obtained are real and nice
atleast for the testcases that we could see after finishing up the
testcases.
* There is some follow-up work which should tie in nicely with costs
rework - lower-subreg ends up splitting things a bit badly in some
cases with vld4 style intrinsics and for V4SF copies. So it's better
we try to get the costs right. I suspect this might be harming us in a
few cases with auto-vectorized code as well. Especially where we
vectorize with the large vldn instructions.
* Investigate the 4.6 regression with Neon intrinsics.
* Auto-inc-dec scheduler work.
Hi,
I'm trying to build some shared libraries with the Linaro Android
toolchain.
For all of my libraries I get the following errors from the linker:
|BlaBla.cpp.o: requires unsupported dynamic reloc R_ARM_REL32; recompile with -fPIC
/home/dev/android/android_linaro_toolchain/libexec/gcc/arm-linux-androideabi/4.7.1/real-ld: error: hidden symbol '__dso_handle' is not defined locally
|
I'm using -fPIC in the compiler's flags so I'm not sure why the linker
is complaining.
The |__dso_handle| error is supposed to have been fixed in the NDKr6. I
tried the
Linaro 4.7.1(2012.05) toolchain, the one available for download, one of
the daily
builds from Linaro of the same toolchain(the one from Friday last week)
and I also
rebuilt entirely the toolchain from source but with the same results. I
found a bug
report in the
launchpad(https://bugs.launchpad.net/igloocommunity/+bug/1000200)
which pretty much describes exactly the same problem but unfortunately
none of the
observations made there helped(I do have -fPIC in the compilation flags,
I do not
have any assembly source and I rebuilt the toolchain from source).
Does anyone have any hints on how to fix or overcome the problem?
Thanks,
Marius
== GCC ==
* Fixed vectorizer bug causing unaligned memory accesses
(LP 1010826 / GCC PR 53636); checked in to GCC mainline
and Linaro GCC 4.7. Backports to FSF 4.7 and Linaro
GCC 4.6 are under way.
* Investigated vectorizer performance regression reported
by Mans; main problem seems to be lack of use of the
vectorizer cost model by default on ARM, but other
aspects of the vectorized code could be improved as well.
* Created blueprint to tune vectorizer cost mode on ARM
and enable it by default.
* Ongoing work on reassociation pass.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro QEMU 2012-06.
Linaro QEMU 2012.06 is the latest release of qemu-linaro. Based off
upstream qemu, it includes a number of ARM-focused bug fixes and
enhancements.
There are no major changes with this release, though it has been updated
to the latest (1.1.0) qemu.
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.06
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
We talked at Connect about finishing up the cortex-strings work by
upstreaming them into Bionic, Newlib, and GLIBC. I've written up one
of our standard 'Output' pages:
https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/CortexStrings
with a summary of what we did, what else exists, benchmark results,
and next steps. This can be used to justify the routines to the
different upstreams.
The Android guys are going to upstream these to Bionic. I need a
volunteer to do Newlib and GLIBC.
One surprise was that the Newlib plain C routines are very good on
strings - probably due to a good end of string detector.
-- Michael
Hi,
OpenEmbedded-Core/meta-linaro:
* worked on building oe-core+meta-linaro using the 2012.05 release of
the binary toolchain
* minimal sysroot contains libraries that reference the old
ld-linux.so.3 loader
* created #1011671
* otherwise works fine for oe-core+meta-linaro
* setup the build env on tcserver01
* verified the 2012.06 RC of linaro GCC 4.7 and 4.6
* 4.7 looks good
* 4.6 has ICE when building Qt -mfpu=neon
* reduced testcase available at bug #1013209
* updated meta-linaro (master) to pull in version 2012.06 of Linaro
GCC 4.6/4.7
Regards,
Ken
Hello,
I am wondering if there is support for gettext in the linaro toolchain?
How can I check it if it should work or not?
I can compile and link the "setlocale()" and "bindtextdomain()" and
"textdomain()" functions, however, the translation doesn't work.
Best regards
Tom,
--
*Tom Deblauwe*
*R&D Engineer*
Traficon International N.V.
Vlamingstraat 19
B-8560 Wevelgem
Belgium
Tel.: +32 (0)56 37.22.00
Fax: +32 (0)56 37.21.96
URL: www.traficon.com <http://www.traficon.com>
I noticed this bug upstream about C++11 and C++98 ABI
incompatibilities , in case someone is using the C++11 features,
please be aware that there is an ABI bug lurking.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53646
Ramana
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro GDB 7.4 2012.06.
Linaro GDB 7.4 2012.06 is the third release in the 7.4 series. Based off
the latest GDB 7.4.1, it includes a number of bug fixes.
Interesting changes include:
* GDB now expands tildes in solib-search-path entries.
* Updated to the GDB 7.4.1 code base.
https://launchpad.net/gdb-linaro/+milestone/7.4-2012.06
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
The Linaro Toolchain Working Group is pleased to announce the 2012.06
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.06 is the third release in the 4.7 series. Based
off the latest GCC 4.7.0+svn188038 release, it includes performance
improvements especially around 64 bit operations.
Interesting changes include:
* Updates to GCC 4.7.0+svn188038
* Adds multilib support for use in the binary builds
* Improves performance of 64 bit shifts in core registers
Fixes:
* LP: #949805 GCC doesn't by default use %gnu_unique_object
* LP: #990530 internal compiler error: in convert, at lto/lto-lang.c:1292
* An off-by-one error in vrev
Linaro GCC 4.6 2012.06 is the sixteenth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn188320 release, this is the third
release after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn188320
* Uses the new /lib/ld-linux-armhf.so.3 loader for hard float binaries
Fixes:
* LP: #949805 GCC doesn't by default use %gnu_unique_object
* LP: #990530 internal compiler error: in convert, at lto/lto-lang.c:1292
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.06https://launchpad.net/gcc-linaro/+milestone/4.6-2012.06
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
More information on the features and issues are available from the
release page:
https://launchpad.net/gcc-linaro/4.7/4.7-2012.06
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bugs: https://bugs.launchpad.net/gcc-linaro/
Questions? https://ask.linaro.org/
Interested in commercial support? Inquire at support(a)linaro.org
-- Michael
On 12 June 2012 18:53, Akash D <akashd(a)renuelectronics.com> wrote:
> Hello Michael,
>
> Thanks for reply.
>
> The required information is mentioned below.
>
> Compiler Used --->
>
> http://launchpad.net/gcc-arm-embedded
>
> Version number ---->
>
> arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.6.2 20110921
> (release) [ARM/embedded-4_6-branch revision 182083]
Yip, this is ARM's Cortex-R & M bare metal toolchain. It doesn't come
directly from Linaro but we've got a good relationship with them.
I'll ping them and see the best place to ask this question.
> The link file is attached with this mail.
I only had a quick read, but you're missing a capture for the
'.text.startup' section in the linker script. You might need
something like:
*(.text.startup)
before the one.o(.text) line or to change the *(.text) capture to
*(.text*). The startup section might need to be at a fixed address.
Please check your chip and toolchain documentation to confirm.
-- Michael
While benchmarking the auto-vectoriser on Libav, I noticed a performance
regression in gcc 4.7 (both FSF and Linaro) compared to gcc 4.6 in the AAC
decoder. I narrowed it down to this function:
static void ps_hybrid_analysis_ileave_c(float (*out)[32][2],
float L[2][38][64],
int i, int len)
{
int j;
for (; i < 64; i++) {
for (j = 0; j < len; j++) {
out[i][j][0] = L[0][j][i];
out[i][j][1] = L[1][j][i];
}
}
}
While gcc 4.6 does not attempt to vectorise this at all, 4.7 goes crazy
with a massive slowdown, about 20x slower than non-vectorised with Linaro
4.7 and much worse with FSF 4.7.
Let me know if you need more information.
--
Mans Rullgard / mru
== Progress ==
* Connect last week.
* Worked through the open issues and open work items related to
performance and we've got a clear list of things that are currently in
flight. Now to keep track of this better.
https://wiki.linaro.org/RamanaRadhakrishnan/Sandbox//RRQ212ConnectNotes
and move this away from the wiki page in a form that we can use to
talk during our regular performance meetings.
* Created blueprints, closed down old issues and reprioritized
issues with Ulrich and others.
* A number of interesting conversations during Connect for a number
of compiler related issues.
* Other sessions that I attended included the Android optimizations
sessions - while there was quite a bit about toolchain performance it
is important that we keep looking out for the performance profiles and
find areas where the toolchain can be improved. However this can't be
done without getting more testcases from other groups. There were a
couple of interesting comments made that skia is CPU bound which would
indicate that the paint function is CPU bound. But why and how ?
Someone should look at reproducing these numbers and see where we get
to in this area. Pointed out that cortex-strings might be good to make
it into bionic ?
* Fixed the vrev off by one error and committed to FSF trunk .
However it couldn't make it in time for FSF 4.7.1 as the merge window
had closed by then.
* Set up my panda board to be identical to what runs on our
validation labs etc.
* This week
* Worked through the merge requests and moved some patches
upstream away from the "toreview" state.
* Landed a few merge requests that were approved but hadn't been
done so. Took care of merging the upstream 4.7 branch.
* Given I only had a few hours back in the office this week I
worked on regenerating arm_neon.h to use __builtin_shuffle with
vrev64, vrev32, vtrn , vzip and vuzp. A follow up patch needs to do
the same for vext but that needs generic support also in
vec_perm_const_ok .Once that is done I think we can safely start
rewriting . It still needs some more testing and polishing up but the
initial results on the testcase from PR48941 is kind of neat. The
result for some of the other testcases that I've looked at also looks
much better than where we were a few weeks back. So all in all nice
progress on that front. However we have to also find a way of getting
these generated at O0 which they don't appear to do so cleanly enough
with this approach.
for one example it does look like this below: Notice those spills
beginning to disappear .... :)
New :
sqrlen4D_16u8:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vabd.u8 q1, q0, q1
vmull.u8 q0, d2, d2
vmull.u8 q8, d3, d3
vuzp.32 q0, q8
vpaddl.u16 q0, q0
vpadal.u16 q0, q8
bx lr
Old :
sqrlen4D_16u8:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
vabd.u8 q1, q0, q1
stmfd sp!, {r4, fp}
add fp, sp, #4
sub sp, sp, #48
add r3, sp, #15
vmull.u8 q0, d2, d2
bic r3, r3, #15
vmull.u8 q8, d3, d3
vuzp.32 q0, q8
vstmia r3, {d0-d1}
vstr d16, [r3, #16]
vstr d17, [r3, #24]
vpaddl.u16 q0, q0
vpadal.u16 q0, q8
sub sp, fp, #4
ldmfd sp!, {r4, fp}
bx lr
* Attended platform / WG sync-up.
== Plans ==
* Cleanup the ml bits of rewiring the intrinsics and try some proper testcases.
* Work on the auto-inc-dec scheduler patches.
* Rework the sched-pressure patch upstream .
* Review the Android benchmarking writeups.
Summary:
* Bug fixes.
* Tune ivopt for code size.
Details:
1. Reproduce lp:1007353 "kernel build fails with 12.04 and 12.05
toolchain released" and workout a patch to fix it; reopen the related
binutils/gas bug http://sourceware.org/bugzilla/show_bug.cgi?id=12698
and propose the patch to it; push the patch to linaro crosstool-ng to
make sure lp:1007353 is fixed for next binary toolchain release.
2. Setup the SPEC build env and reproduce lp: 886124 "using LDR from
literal pool rather than MOVW/MOVT". After cprop1 replaces lo_sum
(high: symbol_ref bloc) (symbol_ref (block)) with a (symbol_ref
(block)), no later optimization can split it. The solution in linaro
4.5 is to add a split (porting from codesourcery) in arm.md. Then
split1 can split the (symbol_ref (block)). The split is:
(define_split
[(set (match_operand:SI 0 "arm_general_register_operand" "")
(match_operand:SI 1 "general_operand" ""))]
"TARGET_32BIT
&& TARGET_USE_MOVT && GET_CODE (operands[1]) == SYMBOL_REF
&& !flag_pic && !target_word_relocations
&& !arm_tls_referenced_p (operands[1])"
[(clobber (const_int 0))]
{
arm_emit_movpair (operands[0], operands[1]);
DONE;
})
3. Tune ivopt for code size. Try to set avg_loop_niter to 1 since loop
iterator number does not impact code size. But test shows there is no
improvement. Need more tuning.
Plans:
* Analyze the failed cases in arm-linux-gnueabihf regression test.
* Tune code size for M0.
Best regards!
-Zhenqiang
Hello Sir/Madam,
I am using MK60FN1M0VLQ12 (COTREX-M4) processor for my development.
I am using float and double data types in my code. When I perform any
mathematical operation on these variables, the processor goes to Hard Fault
Exception.
Earlier I have used GCC 4.5.2 compiler for my compilation
So now I am using Linaro's GNU-GCC Toolchain 4.6.2 for compiling my code
with following command.
arm-none-eabi-gcc -Wall -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -mcpu=cortex-m4
-mthumb -Qn -Os -mlong-calls -c main.c -o main.o
But I am getting following error while linking my code
ld: section .text.startup loaded at [00032258,000331cb] overlaps section
.InitializedVariables loaded at [00032258,00032787]
The link file is attached with this mail.
Can you please suggest me some solution for this problem.
Can you also suggest some compiler commands to support float and double data
type using software.
Awaiting for your reply,
Thanks & Regards,
Akash
