linaro-toolchain November 2012

linaro-toolchain@lists.linaro.org

16 participants
37 discussions

[ANNOUNCE] Linaro GCC 4.7 and Linaro GCC 4.6 2012.11 released

by Matthew Gretton-Dann

The Linaro Toolchain Working Group is pleased to announce the 2012.11 release of both Linaro GCC 4.7 and Linaro GCC 4.6. Linaro GCC 4.7 2012.11 is the eigth release in the 4.7 series. Based off the latest GCC 4.7.2+svn193200 release, it includes ARM-focused performance improvements and bug fixes. Interesting changes include: * Updates to GCC 4.7.2+svn193200 * Also includes arm/aarch64-4.7-branch up to svn revision 193328. Fixes: * LP #1065122 * LP #1065559 * LP #1067760 Linaro GCC 4.6 2012.11 is the 21st release in the 4.6 series. Based off the latest GCC 4.6.3+svn193199 release, this is the eigth release after entering maintenance. Interesting changes include: * Updates to 4.6.3+svn193199 The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.7-2012.11 https://launchpad.net/gcc-linaro/+milestone/4.6-2012.11 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 pages: https://launchpad.net/gcc-linaro/4.7/4.7-2012.11 https://launchpad.net/gcc-linaro/4.6/4.6-2012.11 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 -- Matthew Gretton-Dann Linaro Toolchain Working Group matthew.gretton-dann(a)linaro.org

11 years, 11 months

Getting a broken program when the -funroll-loops flag is set (gcc linaro arm)

by Mickey Iluz

Hi, I've encountered a case where gcc produces a broken program: a branch that should never be taken is taken, and wrong values are written to memory (and printed out). The code is fairly ordinary and small. It can be seen here: http://pastebin.com/0Hspz8mw This happens when -funroll-loops flag is used in conjunction with -O2 or -O3. It doesn't seem to happen when it is used with -O1. Another few things that influences the program flow from from incorrect to correct run (gives expected outpus) are: - Adding/removing printf's inside the inner loop - Changing the order of the expressions in the "if" clause. i.e. from this: if ((y < mu) || (y >= H - md) || (x < ml) || (x >= W - mr)) to this: if ((x < ml) || (y >= H - md) || (y < mu) || (x >= W - mr)) - Assigning ml inside f() to the same value (3) it's getting from the function arguments. All of these shouldn't change how the program behaves but it does. I compiled this with two different compilers/environments: 1. g++ (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3, running on 3.2.1-42-linaro-lt-mx6 (native compilation on the ARM board) Compilation command: g++ -march=armv7-a -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O3 -std=c++0x -funroll-loops -o test_bug_sa_loops_linaro test_bug.cxx 2. arm-fsl-linux-gnueabi-g++ (Freescale MAD -- Linaro 2011.07 -- Built at 2011/08/10 09:20) 4.6.2 20110630 (prerelease) Running on a freescale LTIB built linux (3.0.15-1359-g1b64ead) Compilation command: arm-fsl-linux-gnueabi-g++ -march=armv7-a -mfpu=neon -mfloat-abi=hard -mtune=cortex-a9 -O3 -std=c++0x -funroll-loops -o test_bug_sa_loops test_bug.cxx In all the variations I tried it seems that -funroll-loops is critical for this problem to appear. I'd be glad to hear some comments on this. Mickey. This mail was sent via Mail-SeCure system.

11 years, 11 months

Fwd: Re: Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by 남관우

11 years, 11 months

Re: Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by 남관우

11 years, 11 months

Re: Compilation speed of Linaro's gcc compared to e.g. Ubuntu's version

by Michael Hope

On 10 November 2012 05:11, "Frank Müller" <franky1976(a)gmx.net> wrote: > Michael Hope <michael.hope(a)linaro.org>: >> My suspicion is that we/crosstool-NG enable extra features like >> Graphite or GCC is built with a different level of checking. If you > > I suspected Graphite as well and removed it in my own builds without noticable difference. > >> have the time, could you check the flags passed to GCCs configure? >> You can do this on Ubuntu using: >> >> apt-get build-dep gcc >> apt-get source gcc >> dpkg-buildpackage -uc -us -b >> >> and compare the configure line with the one in crosstool-NG's build.log. > > Isn't this the same as gcc -v? I've posted the lines at http://lists.linaro.org/pipermail/linaro-toolchain/2012-October/002913.html Good point. There's nothing obvious in the list. Ubuntu explicitly adds --enable-checking=release but it's the default for release branches like ours. I can reproduce the slowdown in a smaller testcase. Compiling pcre with -O3 -mfpu=neon -march=armv7-a -mtune=cortex-a8 takes 18.8 s for the Ubuntu Precise 4.6 compiler, 17.8 s for the Ubuntu Quantal 4.7 compiler, and 41.2 s for the Linaro 4.7 2012.10 build. I've logged LP: #1077739 to track. I'll spin a --enable-checking=release build just to check. > The above lines do not work for me, the last line misses a changelog file: > > # dpkg-buildpackage -uc -us -b > tail: cannot open `debian/changelog' for reading: No such file or directory > dpkg-buildpackage: error: tail of debian/changelog gave error exit status 1 Yip, you need to change to the just-extracted source directory first. -- Michael

11 years, 11 months

Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by Michael Hope

On 14 November 2012 00:48, 남관우 <kw46.nam(a)samsung.com> wrote: > > Hi, > > > > First, our CFLAGS is here. > > > > -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wl,--as-needed > -fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mfpu=vfpv3-d16 -mfloat-abi=hard -mthumb -Wa,-mimplicit-it=thumb > -mapcs -mno-sched-prolog -mabi=aapcs-linux -Uarm -fno-common -fpic > > > > It was occurred with the message. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03) > > > > Second, > > -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Wl,--as-needed > -fmessage-length=0 -march=armv7-a -mtune=cortex-a8 -mfpu=vfpv3-d16 -mfloat-abi=hard -mthumb -Wa,-mimplicit-it=thumb > -mapcs -mno-sched-prolog -fno-common -fpic > > > > It was occurred too. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03) Hi there. I don't know the cause but I'm suspicious of a few things. Could you try the following builds? The most likely: * Without -mapcs * Without -fstack-protector --param=ssp-buffer-size=4 Less likely: * Without -fno-common * With -fPIC instead of -fpic (should make no difference on ARM) Could you also send through the linker command line? It would be great to get a full log up on pastebin or similar. -- Michael

11 years, 11 months

Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by 남관우

11 years, 11 months

unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)

by Kyungmin Park

Hi Michael, Recently I tested the linaro toolchain gcc-4.6 version and try to build our codes. it's okay to compile the codes, but when launching the binary it occures following messages. /usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03 I tested it both "hard float" and "soft float". the result is same. do you have any clues? Test environment: toolchain: gcc-4.6.4 (2012.10 version) soft float option. Thank you, Kyungmin Park

11 years, 11 months

linaro toolchain

by zhangzhangwei

hi, I use beaglebone ,and the CPU is AM3359 from TI can I use the linaro toolchain to the u-Boot linux kernel and android files?if I can ,which tool chain you suggest you use. other question, your android realese file also can use my CPU(AM3359),Can I build image and download to my SD and run it? thanks for your reply. zhangzhangwei 2012-11-09

11 years, 11 months

[ACTIVITY] 5 - 9 November

by Yvan Roux

== Progress == * Watched some Connect sessions (ARMv8, GCC performance) * AArch64 GDB support testing and backport investigation: - Activities blocked until patches with the pthread interface update are ready. * Boehm GC AArch64 support: - Read documentation on the garbage collector and ARMv8. - Asked for advices to the maintainers. - Started to port the libatomic_ops. == Next == * Continue on the Boehm GC AArch64 support.

11 years, 11 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain November 2012