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.
