== Blueprints ==
Initial Current Actual
fix-gcc-multiarch-testing 31 Dec 2012 31 Jan 2013
== Progress ==
* Short week, working Weds-Fri
* Admin
* Welcomed Renato to the team, and discussions with him about LLVM
* Initial project setup for llvm-linaro.
* Finished putting current set of card drafts into Jira
* Did GCC merges
* Backport of Thumb literal pool issues to 4.7.
== Next week ==
* Prepare Cortex Strings release
* Ensure GCC backports are up to date.
* Merge reviewing week.
* Catch up on outstanding cards.
== Future ==
* Run HOT/COLD partitioning benchmarks
* Analyse ARM results
* On x86_64 to see what the actual benefit we could get
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
--
Matthew Gretton-Dann
Toolchain Working Group, Linaro
Hi all!
I use the arm-linux-gnueabihf-ct-ng.config in gcc-linaro-arm-linux-gnueabihf-4.7-2012.12-20121214_win32.zip to rebuild linaro-toolchain,but failured with the fellow messages:
[INFO ] Performing some trivial sanity checks
[INFO ] Build started 20130104.110952
[INFO ] Building environment variables
[WARN ] Directory '/home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/tarballs' does not exist.
[WARN ] Will not save downloaded tarballs to local storage.
[EXTRA] Preparing working directories
[EXTRA] Installing user-supplied crosstool-NG configuration
[EXTRA] =================================================================
[EXTRA] Dumping internal crosstool-NG configuration
[EXTRA] Building a toolchain for:
[EXTRA] build = i686-pc-linux-gnu
[EXTRA] host = i586-mingw32msvc
[EXTRA] target = arm-linux-gnueabihf
[EXTRA] Dumping internal crosstool-NG configuration: done in 0.26s (at 00:04)
........
[EXTRA] Saving state to restart at step 'binutils'...
[INFO ] =================================================================
[INFO ] Installing binutils
[EXTRA] Configuring binutils
[EXTRA] Building binutils
[ERROR] /home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/src/binutils-2.22/gold/arm.cc:2173: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:4971
[ERROR] make[5]: *** [arm.o] Error 1
[ERROR] make[4]: *** [all-recursive] Error 1
[ERROR] make[3]: *** [all] Error 2
[ERROR] make[2]: *** [all-gold] Error 2
[ERROR] make[1]: *** [all] Error 2
[ERROR]
[ERROR] >>
[ERROR] >> Error happened in: main[scripts/crosstool-NG.sh]
[ERROR] >>
[ERROR] >> For more info on this error, look at the file: 'build.log'
[ERROR] >> There is a list of known issues, some with workarounds, in:
[ERROR] >> 'share/doc/ct-ng-linaro-1.13.1-4.7-2012.12-20121214/B - Known issues.txt'
[ERROR]
[ERROR] Build failed in step 'Extracting and patching toolchain components'
[ERROR]
[ERROR] (elapsed: 57:51.80)
make: *** [build] 错误 2
And in build.log:
..........
[ALL ] /home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/src/binutils-2.22/gold/arm.cc:11999: instantiated from here
[ERROR] /home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/src/binutils-2.22/gold/arm.cc:2173: internal compiler error: in make_rtl_for_nonlocal_decl, at cp/decl.c:4971
[ALL ] Please submit a full bug report,
[ALL ] with preprocessed source if appropriate.
[ALL ] See <URL:http://www.mingw.org/bugs.shtml> for instructions.
[ERROR] make[5]: *** [arm.o] Error 1
[ALL ] make[5]: *** Waiting for unfinished jobs....
[ALL ] mv -f .deps/powerpc.Tpo .deps/powerpc.Po
[ALL ] make[5]: Leaving directory `/home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/arm-linux-gnueabihf/build/build-binutils/gold'
[ERROR] make[4]: *** [all-recursive] Error 1
[ALL ] make[4]: Leaving directory `/home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/arm-linux-gnueabihf/build/build-binutils/gold'
[ERROR] make[3]: *** [all] Error 2
[ALL ] make[3]: Leaving directory `/home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/arm-linux-gnueabihf/build/build-binutils/gold'
[ERROR] make[2]: *** [all-gold] Error 2
[ALL ] make[2]: Leaving directory `/home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/arm-linux-gnueabihf/build/build-binutils'
[ERROR] make[1]: *** [all] Error 2
[ALL ] make[1]: Leaving directory `/home/ljc/ct-ng/crosstool-ng-linaro-1.13.1-4.7-2012.12-20121214/mybuild/.build/arm-linux-gnueabihf/build/build-binutils'
[ERROR]
[ERROR] >>
[ERROR] >> Error happened in: main[scripts/crosstool-NG.sh]
[ERROR] >>
[ERROR] >> For more info on this error, look at the file: 'build.log'
[ERROR] >> There is a list of known issues, some with workarounds, in:
[ERROR] >> 'share/doc/ct-ng-linaro-1.13.1-4.7-2012.12-20121214/B - Known issues.txt'
[ERROR]
[ERROR] Build failed in step 'Extracting and patching toolchain components'
[ERROR]
[ERROR] (elapsed: 57:51.80)
Has anybody met this problem too?
Dear All,
When doing prelink I got following error.
/a.out
/a.out: R_ARM_TLS_DTPMOD32 reloc in executable?
Gcc version 4.6
I have following question:
1. What this relocation do. ?
2. Is it problem in tool chain ?
3. Are we need to fix this in Prelink utils
Thanks
Hi,
The following code fails to build with OE Aarch64 toolchain with
current kernel headers. While ugly, the code is a reduced testcase
from fuse build failure (
https://bugs.launchpad.net/linaro-oe/+bug/1087757 ) and the same fuse
code compiles on all other architectures. Before I send a workaround
for upstream, I'd like to know how we can end up with different
definitions for int64_t when that happens on no other architectures -
something wrong with the generic kernel headers?
Testcase:
#include <sys/types.h>
#define __s64 int64_t
#include <signal.h>
int main(int argc, char **argv)
{
int64_t x=4;
return x;
}
Failure:
/data/oe/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/aarch64-oe-linux/aarch64-oe-linux-gcc
-save-temps --sysroot=/data/oe/build/tmp-eglibc/sysroots/genericarmv8
-o test test.c
In file included from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm-generic/types.h:7:0,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm/types.h:1,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/linux/types.h:4,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm/sigcontext.h:19,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/bits/sigcontext.h:27,
from
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/signal.h:338,
from test.c:4:
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/asm-generic/int-ll64.h:29:44:
error: conflicting types for 'int64_t'
In file included from test.c:2:0:
/data/oe/build/tmp-eglibc/sysroots/genericarmv8/usr/include/sys/types.h:197:13:
note: previous declaration of 'int64_t' was here
Summary:
* Follow-up shrink-up and branch cost related work.
* Investigate "MSR FPEXC, r2" assemble fail issues.
Details:
1. RM toolchain related work.
2. Investigate "MSR FPEXC, r2" assemble fail issues.
* According to Reference Manual, should use VMSR/VMRS to access
FPEXC register other than MSR/MRS.
* Binutils 2.23.1 or later had enhanced VMRS/VMSR to accept FPEXC register.
3. Rebase and test the shrink-wrap patches.
4. Read codes about impact of branch-cost.
Plan:
* Follow up the shrink-wrap and branch cost related work.
Planed leaves:
* Jan. 1-3, 2013
Best Regards!
-Zhenqiang
Hi all!
I'm rebuildding linaro-toolchain with ct-ng,I expect use the configure file in linaro-toolchain-binaries ,but I can't read the options in it's arm-linux-gnueabihf-ct-ng.config.
How I can do?
Thanks!
== Progress ==
* 64-bits ops in Neon: re-posted patch after a bit of cleanup
requested by upstream.
Investigated Fortran regression: confirmed unrelated to this
patched, and fixed upstream.
* disable-peeling: launched jobs under cbuild to perform initial benchmarking
* builtin_bswap16 backport to linaro-4.7: almost OK, missing some
pending validation results.
* cbuild: investigated some reporting problems which were slowing down
the branch review process.
== Next ==
* handle 64-bits bitops in Neon feedback from upstream if any
* finish builtin_bswap16 backport
* benchmark with vectorizer cost model enabled with its default configuration
== Future ==
Back on January 7th, after the end of the world.
== Blueprints ==
Initial Current Actual
initial-aarch64-backport 31 Oct 2012 31 Dec 2012 21 Dec 2012
aarch64-baremetal-testing 31 Oct 2012 31 Dec 2012 21 Dec 2012
backport-fma-intrinsic 31 Dec 2012 Brice
fused-multiply-add-support 31 Dec 2012 Brice
gcc-investigate-lra-for-arm 31 Dec 2012 Brice
fix-gcc-multiarch-testing 31 Dec 2012 31 Jan 2013
== Progress ==
* Admin
* Interviewing
* Welcomed Brice Dobry to the working group
* Started inputting cards into cards.linaro.org
* Discussions about KVM
* Discussions about Toolchain/Platform interactions
* initial-aarch64-backport and aarch64-baremetal-testing
* Finished documentation
== Next (working) week ==
* Admin
* Finish loading card drafts into Jira.
* Welcome Renato to working group.
* Do monthly GCC merges
* Prepare Cortex Strings release
* Ensure GCC backports are up to date.
== Future ==
* Run HOT/COLD partitioning benchmarks
* Analyse ARM results
* On x86_64 to see what the actual benefit we could get
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
On 21 December 2012 09:54, Yvan Roux <yvan.roux(a)linaro.org> wrote:
> Matt, do you have something particular in mind to put in a shared and versioned .bzrignore file ?
> My understanding of its usage is that it is more a user side configuration of the archive.
> (Maybe we could chat about this topic on another channel)
Yes this conversation should probably be conducted elsewhere :-) -
moved to linaro-toolchain.
If you look at upstream SVN GCC and do svn propget svn:ignore you get
a long list of files that SVN is set up to ignore. And whilst there
isn't a .gitignore other upstream projects which have git mirrors do
put a .gitignore in place (see GDB for instance).
I think having a .bzrignore which is a copy of the svn:ignore set up
(and the defaults that SVN ignores but aren't on bzr's list) would be
valid in the repo. Although as I said in the original thread - let's
do this when we branch 4.8 and not to the historic branches.
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
The Linaro Toolchain Working Group is pleased to announce the 2012.12
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.12
* Linaro GDB 7.5 2012.12
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link
your programs against.
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian
6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation
5.7 and later, and should run on any Linux Standard Base 3.0
compatible distribution. Please see the README about running on
x86_64 hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://launchpad.net/linaro-toolchain-binaries/trunk/2012.12
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.
