linaro-toolchain

linaro-toolchain@lists.linaro.org

11 participants
5659 discussions

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.

13 years

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

by 남관우

13 years

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

by 남관우

13 years

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

13 years

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

13 years

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

by 남관우

13 years

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

13 years

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

13 years

[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.

13 years

[ACTIVITY] report week 45

by Peter Maydell

* Attended LinuxCon Europe / ELC-Europe / QEMU Summit / KVM Forum (an overlapping set of conferences across a week in Barcelona) LCE/ELC: brief summary of interesting sessions (I've only listed ones which seem most relevant to ARM just to keep the length of this report down): * "Devicetree and its stumbling blocks" -- a view from a kernel developer perspective of some of the issues with doing platform data to dt conversions: (a) dt is supposedly OS independent and an external ABI, implying more need for cleanliness and long term supportable interfaces. (b) conversions imply a need to generalise bindings to be usable across many devices (c) what do we do about configuration / policy choices? My take is that the kernel folks are tying themselves in knots to try to preserve the (somewhat fictional in practice) idea that any kernel will work with any older device tree blob and they'd find it easier if they declared an amnesty for breaking changes before some deadline date... * Developing and testing industrial hardware with QEMU Rather than developing/testing sw against expensive/limited availability hw, use a model -- easier automation, ability to simulate error conditions, etc. If your hardware is basically a PCI card in an x86 box QEMU's fairly easy to use for this. * UEFI Secure Boot A summary of the current status of UEFI Secure Boot: it's mandatory for Win8 hardware; Linux implication is that we need to be able to maintain simple "out of box boot off distro CD"; optionally, if we have end-to-end signed binaries we have access to environments which will end up mandating it (read: government). Fortunately people have come together to tackle this and it looks like we're in good shape. http://mjg59.dreamwidth.org/18945.html is a good summary. * Kernel report by Jonathon Corbet ARM featured fairly prominently in this stats-driven roundup: 64-bit ARM support was first listed bullet point for 3.7 features Pointed out that Linaro and other embedded-ARM kernel contributions are notably up, ARM mess has been cleaned up. KVM Forum: * Concurrency in QEMU Plans for splitting QEMU's "big lock" into finer grained mutexes; should improve I/O scalability for KVM guests and realtime guest latency. However some tricky locking design issues to be solved. I am as usual sticking my oar in occasionally to remind people that the world is not solely x86-and-PCI... * qtest A summary of QEMU's new qtest framework, how it works and how to write tests. We're going to start insisting on test cases for new patches, so I need to write some basic tests for a few ARM devices so I know how it works :-) * ARM Virtualization for the Masses Christoffer Dall's talk introducing the ARM virt. extensions and KVM work. Well received, various questions afterwards (some elements of "why doesn't this work the way the x86 stuff does", also lots of "does this work on the Samsung/Google Chromebook" :-)) QEMU Summit: * This was an invite-only afternoon with perhaps 20 or so of the main QEMU contributors; broadly focused on "process" issues like release management, patch flow and security bug handling. Productive session; minutes should be available on the QEMU mailing list shortly. This is likely to be repeated next year. Informal discussions (IME the most important and worthwhile part): * virtio related : ran through current status of virtio-mmio patches with Anthony Liguori and Alex Graf, confirmed what changes we need to make and what the next steps with this should be. Some enthusiasm for getting this patchset in in the early part of the QEMU 1.4 release if we can. I'm really happy that we've unblocked this bit of work which had stalled slightly trying to figure out the right approach. Long term we will probably end up using virtio-pci on ARM but this is really dependent on hardware with good PCI support appearing. * SystemC : the upstream community is not currently interested in SystemC support, but there is some work on the QEMU core which would be a useful cleanup for QEMU itself and also useful for the SystemC folk. I'm hopeful that this might help to bring people working with QEMU in SystemC closer to the "QEMU upstream" community and mailing list, but it will be a gradual process both socially and technically if it does happen. * an informal enquiry about whether system emulation of virt. mode in ARM was planned or how much work it would be * in-kernel-irqchip: common ABI cross architecture the current ABI is a bit x86-specific, useful discussion about what POWER/S390/ARM would need. There will probably be some more ioctls coming along but the good news is that what the KVM ARM patches have currently fits into the proposals with only a very trivial tweak; we can add support for the new ioctls later if they are useful for us. -- PMM

13 years

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain