== Issues ==
* None.
== Progress ==
* Commit the patch to support S2_<op1>_<Cn>_<Cm>_<op2> system register
in AARCH64 GAS.
* Identify the issue files in parallel build fail (PR57683) and
backport r197467 and r198999 to FSF GCC 4.8.
* Verify Linaro crosstool-ng to make sure Fortran is supported in all builds.
* Try PGO build for ifcombine heuristics. But got "the control flow of
function .. does not match its profile data".
* Investigate loop-invariant heuristics and rtx cost to select
SYMBOL_REF. But tests did not show performance gain.
* Investigate Coremark conditional compare issue in Cortext-M since
the BRANCH_COST is 1.
== Plan ==
* Continue on CCMP.
* Discuss ifcombine heuristics with upstream.
== Planed leaves ==
* Dec 3 & 5: Annual leaves
== Progress ==
- cbuild2 benchmarking
- Done the initial frame work (just with one benchmark) and sent out
for review
- 64bit division for ARMv7-A
- Posted the patch and added target hook documentation required
== Plan ==
- Address zero/extension review comments
- post 64bit divide patch with the required documentation
- investigative bootstrapping issues
- still waiting for h/w access
On 21 November 2013 07:12, Karlsson, Magnus <Magnus.Karlsson(a)lsi.com> wrote:
> Just wondering if somebody could point me to a good document on how the heap
> reclamation algorithm works for memory allocated in a user space program
> using the regular malloc/calloc functions.
Section 7.1.3, whose sub-sections include: "Implementation of malloc()
and free()", "Tools and libraries for malloc debugging", and
"Controlling and monitoring the malloc package", of Michael Kerrisk's
"The Linux Programming Interface" (http://man7.org/tlpi/index.html) is
one of the better reads of which I'm aware. He recommends reading the
man pages for malloc_info, malloc_stats, mallopt, and mallinfo (among
others) for more information.
In the C language, reclamation of allocated memory is usually driven
by the application. When you free() some memory, internal structures
know the size of what was previously allocated at the given location
(i.e. what was given to you by malloc()) and simply release that back
into the heap. There are ways to tweak the allocation of memory.
== This week ==
- This week was mostly spent on coming up to speed on the Linaro
backport process
- Backport 202872 - Merged changes from trunk to Linaro branch
== Next week ==
- Complete backport of 202872
- Begin work on other assigned backports
== Future ==
No concrete plans yet.
---------- Forwarded message ----------
From: Mark Pupilli <mpupilli(a)gmail.com>
Date: 17 November 2013 14:07
Subject: condition_variable_any missing from libstdc
To: linaro-toolchain(a)lists.linaro.org
Hi,
I sent this message a week ago but I don't think I was subscribed to the
list correctly. Apologies if it is repeated (it doesn't show in the
archive).
I have a problem with my cross build of (Linaro GCC 4.8-2013.10). I get the
following runtime linker errors regarding condition_variable_any:
"relocation error: /usr/local/lib/librobolib.so: symbol
_ZNSt22condition_variable_anyC1Ev, version GLIBCXX_3.4.11 not defined in
file libstdc++.so.6 with link time reference"
If I examine my built version of libstdc with readelf I get the following
output:
$ readelf -s ./src/.libs/libstdc++.so.6 | grep condition
10383: 000c58d8 68 FUNC LOCAL DEFAULT 11 _ZNSt15error_conditionC1E
10818: 000c58d8 68 FUNC LOCAL DEFAULT 11 _ZNSt15error_conditionC2E
10837: 000c5944 40 FUNC LOCAL DEFAULT 11 _ZNKSt15error_condition8c
10942: 000c591c 40 FUNC LOCAL DEFAULT 11 _ZNKSt15error_condition5v
Where as with the apt-get installed 4.6 version of the toolchain shows:
$ readelf -s /usr/arm-linux-gnueabi/lib/libstdc++.so.6 | grep condition
777: 000523b1 12 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
929: 000522f1 104 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
1037: 000523b1 12 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
1198: 000522f1 104 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
1686: 00052385 14 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
2166: 00052359 12 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
2438: 00052359 12 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
2685: 00052365 16 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
3186: 00052395 26 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
3448: 00052395 26 FUNC GLOBAL DEFAULT 12
_ZNSt22condition_variable@@GLIBCXX_3.4.11
3643: 00052375 14 FUNC GLOBAL DEFAULT 12
_ZNSt18condition_variable@@GLIBCXX_3.4.11
(Which is still missing anything to do with condition_variable_any, but
given that my native 4.8 compiler doesn't contain this symbol either and my
code builds and runs natively, I assume this is how it should be).
Here is my build's version information:
$ arm-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/mark/arm-linux-gnueabi-4.8.2/libexec/gcc/arm-linux-gnueabi/4.8.2/lto-wrapper
Target: arm-linux-gnueabi
Configured with: ../gcc-linaro-4.8-2013.10/configure
--target=arm-linux-gnueabi --prefix=/home/mark/arm-linux-gnueabi-4.8.2
--with-local-prefix=/home/mark/arm-linux-gnueabi-4.8.2 --disable-nls
--enable-shared --enable-multilib --disable-decimal-float
--enable-languages=c,c++
--with-mpfr-include=/home/mark/gcc-4.8-arm-linux/gcc-build/../gcc-linaro-4.8-2013.10/mpfr/src
--with-mpfr-lib=/home/mark/gcc-4.8-arm-linux/gcc-build/mpfr/src/.libs
--enable-clocale=gnu --enable-threads=posix --enable-__cxa_atexit
--disable-libstdcxx-pch --with-system-zlib
--with-headers=/home/mark/arm-linux-gnueabi-4.8.2/include
--with-libs=/home/mark/arm-linux-gnueabi-4.8.2/lib
--enable-libstdcxx-threads --enable-libstdcxx-time
Thread model: posix
gcc version 4.8.2 20131014 (prerelease) (Linaro GCC 4.8-2013.10)
I configured libstdc++-v3 respectively as follows:
$ ../gcc-linaro-4.8-2013.10/libstdc++-v3/configure --host=arm-linux-gnueabi
--prefix=/home/mark/arm-linux-gnueabi-4.8.2/ --enable-multilib
--enable-shared --disable-nls --disable-libstdcxx-pch
--enable-libstdcxx-threads --enable-libstdcxx-time
I assumed the relevant entries to enable C++11 threading and condition
variables etc would have been --enable-libstdcxx-threads
--enable-libstdcxx-time. I must be missing some other options or have done
something else wrong. Any suggestions?
thanks,
Mark
== Progress ==
* Short week
- Two days off due to a messy implant bloating my face
- Should be better on Monday
* Cambridge LLVM Day, Cambridge University Computer Lab
- Presented the status of the auto-vectorizer in LLVM
* Releasing candidate 1 of LLVM 3.4
- All tests green, running benchmarks
- http://people.linaro.org/~rengolin/llvm/
* Buildbots
- Adding Chromebook self-hosting (fixing MCJIT tests)
- Adding Chromebook test-suite (fixing ClamAV)
- Will turn off the old Chromebook and re-install it for benchmarks
- Will add an Odroid XU in pair with the community one to be added next
week
* Background
- Patch reviews, discussions
* EEMBC rgbcmy implementation requires extensive changes to the compiler
- Will deal with them on the background over the next months
- While checking other EEMBC problems
== Plan ==
* Continue the 3.4 release
* Look at vectorization pragmas
* Look at other EEMBC results
== Progress ==
* Committed a couple of gdb patches
* Debug malloc to a working state, performance improved
* First version of glibc aarch64 ifunc support
* Found a couple of bugs in binutils aarch64 ifunc support
== Issues ==
* Missed two days due to illness
* Power cut and broadband outage on Wednesday afternoon
== Plan ==
* Respin and submit glibc docs patches
* Submit glibc aarch64 ifunc code
--
Will Newton
Toolchain Working Group, Linaro
Hi, All
Under this site
http://releases.linaro.org/13.09/components/toolchain/binaries/,
there are many files released. but do we have any description on the file
naming rules?
Sorry for my simple question, I just want to know what the files are used
for. which one I should select when I need to use toolchain.
Like the files below, I can guess that aarch64 means that it will generate
files run on aarch64 platform, but I can not guess what's the difference
between linux and none, and not know what's the difference between gnu and
elf.
So if you have any wiki/link about the the naming rules or description
about the file,
please share me.
crosstool-ng-linaro-1.13.1-4.8-2013.09-01.tar.bz2
crosstool-ng-linaro-1.13.1-4.8-2013.09.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_runtime.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_src.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64-linux-gnu-4.8-2013.09-20130912_win32.exe
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_runtime.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_src.tar.bz2
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip
gcc-linaro-aarch64-linux-gnu-4.8-2013.09_win32.zip.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64-none-elf-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64-none-elf-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip
gcc-linaro-aarch64-none-elf-4.8-2013.09_win32.zip.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_runtime.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_runtime.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_src.tar.bz2
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip
gcc-linaro-aarch64_be-linux-gnu-4.8-2013.09_win32.zip.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.bz2
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_linux.tar.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip
gcc-linaro-aarch64_be-none-elf-4.8-2013.09-01_win32.zip.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.bz2
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_linux.tar.xz
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip
gcc-linaro-aarch64_be-none-elf-4.8-2013.09_win32.zip.xz
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09-20130912_win32.exe
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.bz2
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_linux.tar.xz
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_src.tar.bz2
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip
gcc-linaro-arm-linux-gnueabihf-4.8-2013.09_win32.zip.xz
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.bz2
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_linux.tar.xz
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_runtime.tar.bz2
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip
gcc-linaro-armeb-linux-gnueabihf-4.8-2013.09_win32.zip.xz
--
Thanks,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-android(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android
linaro-validation(a)lists.linaro.org <linaro-dev(a)lists.linaro.org>
http://lists.linaro.org/pipermail/linaro-validation
Hi toolchain gurus,
I am about to start some projects working with CortexMx devices and am
wondering if anyone has an opinion on which toolchain(s) I should
use/investigate?
Being a fan of Linaro, my first instinct would be to use cbuild2 to
build an arm-none-eabi- toolchain from a 4.8.x tree. But looking
around I can't help notice https://launchpad.net/gcc-arm-embedded.
Does anyone know if gcc-arm-embedded has things the Linaro toolchain
doesn't wrt Cortex M0, M3, and M4 device/instruction support?
Best regards,
Trevor
-------- Original Message --------
Subject: [Bug target/59216] [ARM] negdi*extendsidi regression
Date: Wed, 20 Nov 2013 18:06:14 +0100
From: christophe.lyon at st dot com <gcc-bugzilla(a)gcc.gnu.org>
To: Christophe LYON <christophe.lyon(a)st.com>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59216
--- Comment #2 from christophe.lyon at st dot com ---
Basically, the working code does:
asrs r3, r2, #31
negs r2, r2
sbc.w r3, r3, r3, lsl #1
while the failing one does:
negs r2, r2
asrs r3, r2, #31
--
You are receiving this mail because:
You reported the bug.
