linaro-toolchain

linaro-toolchain@lists.linaro.org

6 participants
5605 discussions

by Michael Hope

Hi there. The toolchain session blueprints for the summit are now up on Launchpad: https://blueprints.launchpad.net/linaro-toolchain?searchtext=toolchain-o You can check out the schedule here: http://summit.ubuntu.com/uds-o/track/linaro-toolchain/ although it's really only for show at the moment. Expect things to jump around as the constraints kick in. Please go through these blueprints and subscribe yourself to them. You can check your list of blueprints at: https://blueprints.launchpad.net/people/+me?searchtext=toolchain-o -- Michael

14 years, 2 months

"BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

by Barry Song

Hi All, I found Jie has committed a patch "http://sourceware.org/ml/binutils/2010-05/msg00083.html". I am using the newest binary utils(2.21) and encounted the following ASSERT in arm_elf32.c: + if (out_attr[i].i == 0) + { + BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0); My compiling options are as below, ASM_FLAGS := \ -gdwarf-2 \ -mfpu=vfp \ -mfloat-abi=softfp \ -mthumb-interwork C_FLAGS := \ $(ASM_FLAGS) \ -O3 -Wno-all \ -fno-optimize-sibling-calls \ -mlong-calls \ -ffunction-sections \ CPP_FLAGS := \ -fno-rtti \ -fno-exceptions \ LINK_FLAGS := \ --gc-sections -nostdlib \ -L ../stdlib \ -Wl,--as-needed \ -Wl,-no-enum-size-warning \ --cref \ ARFLAGS := \ rcs Can anyone give me any tip about why the assert is triggered? I have reported a bug here: http://sourceware.org/bugzilla/show_bug.cgi?id=12700 But not sure whether it is a bug. -barry

14 years, 2 months

__aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

by Barry Song

Hi All, I am using 2011.3 4.5 linaro GCC(armv7-a vfpv3d16) to compile kernel and modules. I select to compile all codecs as modules: "config SND_SOC_ALL_CODECS tristate "Build all ASoC CODEC drivers" " as M and I2C/SPI too. Then in the kernel dir, run "make" to get both vmlinux and modules, I found snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko will fail due to "__aeabi_uldivmod undefined". If i comment do_div() in these codec drivers, this issue will disappear. But it is strange there are many codecs which use do_div() too, for example: sound/soc/codecs/max98088.c sound/soc/codecs/max9850.c sound/soc/codecs/wm8350.c sound/soc/codecs/wm8400.c sound/soc/codecs/wm8510.c sound/soc/codecs/wm8580.c sound/soc/codecs/wm8753.c sound/soc/codecs/wm8804.c sound/soc/codecs/wm8900.c sound/soc/codecs/wm8904.c sound/soc/codecs/wm8940.c sound/soc/codecs/wm8955.c sound/soc/codecs/wm8960.c sound/soc/codecs/wm8974.c sound/soc/codecs/wm8978.c sound/soc/codecs/wm8985.c sound/soc/codecs/wm8990.c sound/soc/codecs/wm8991.c sound/soc/codecs/wm8993.c sound/soc/codecs/wm8994.c sound/soc/codecs/wm8995.c sound/soc/codecs/wm9081.c but others can pass the compiling except those 3 modules. Is it due to a wrong optimization by gcc? Other information: 1. old tool-chains we are using can pass the compiling of the 3 modules. 2. If i built all codecs into kernel image, these 3 drivers don't report error while compiling. Thanks Barry

14 years, 2 months

Re: [alsa-devel] [PATCH] ASoC: prevent compilers from optimising pll calculation into __aeabi__uldivmod

by Barry Song

2011/4/27 Mark Brown <broonie(a)opensource.wolfsonmicro.com> > > On Wed, Apr 27, 2011 at 04:50:12PM +0800, Barry Song wrote: > > > Marking pll_factors() as noinline or putting asm("" : "+r"(source)); before the > > call to do_div() works around the problem. > > If we do have to do something in the callers rather than in do_div() the > annotation seems substantially more taseful than inserting a random asm > into the code. I agree. for this patch which will not be applied, people can just get information about how to workaround the gcc issue while they have the same problem. google can find there are other people who failed to compile wm8974 module too. eg. http://irclogs.ubuntu.com/2010/03/30/%23ubuntu-arm.txt Andrew Stubbs, Michael Hope in Linaro's toolchain team are working hard on this gcc issue. there have been many update today: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783

14 years, 2 months

-O2 cause optimization issues while va parameters functions

by Barry Song

Hi All, As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the following codes, if we compile it by -O2, it will crash with "segment fault", if we just comment " if(unifi_debug >= level) {", all will be ok. If we don't compile it by -O2, all will be ok too. #include <stdlib.h> #include <stdio.h> #include <stdarg.h> #define DEBUG_BUFFER_SIZE 80 int unifi_debug = 5; void unifi_trace(void* ospriv, int level, const char *fmt, ...) { static char s[DEBUG_BUFFER_SIZE]; va_list args; unsigned int len; if(unifi_debug >= level) { va_start(args, fmt); len = vsnprintf(&(s)[0], (DEBUG_BUFFER_SIZE), fmt, args); va_end(args); if (len >= DEBUG_BUFFER_SIZE) { (s)[DEBUG_BUFFER_SIZE - 2] = '\n'; (s)[DEBUG_BUFFER_SIZE - 1] = 0; } printf("%s", s); } } int main(void) { char *prog = "/usr/sbin/unififw"; unifi_trace(NULL, 1, "start %s\n", prog); return 0; } Thanks Barry

14 years, 2 months

Sessions for the summit

by Michael Hope

Hi there. A first-pass list of summit sessions is up at: https://wiki.linaro.org/MichaelHope/Sandbox/1111Blueprints The next step is to investigate these areas and come up with a basic plan that can be discussed during the summit. I've put your names against the sessions as follows: Andrew: Broad tuning Dave: String routines everywhere Dave: QEMU topic #2 Doug: STM support Ira: Vectoriser and NEON performance Ken: 64 bit sync primitives Ken: Good backtracing Ken: End-developer tools bluesky Michael: Publish benchmarking of the toolchain Michael: Binary builds Michael: Deeper validation Peter: QEMU bluesky Ramana: Thumb-2 performance brainstorm Ramana: GCC backend rework Ulrich: GDB as a cross-debugger Ira and Dave, I know you won't be at the summit but we'll see about being able to call in. Could you all please have a read of the outline, investigate these topics, and draft up a blueprint-style list of work items to achieve it? Record any notes in the sandbox page[5] or in a child page if needed. Larger topics may warrant a specification[1]. I'd like these done by the end of next week. I'd expect to spend up to a day on the topics you already understand and more on broad topics. For reference, the see the draft TRs[2] and spreadsheet [3]. I've added some GDB topics to the spreadsheet that still need to go onto the wiki page. The outlines should touch each of these TRs in some way so let me know if I've missed anything. There's more good information on the process and style at: https://wiki.linaro.org/Process/Blueprints https://wiki.linaro.org/Process/WorkItemsHowto https://wiki.linaro.org/Resources/FAQ Questions? Need more detail? Let me know. -- Michael [1] https://wiki.linaro.org/Process/SpecTemplate [2] https://wiki.linaro.org/Cycles/1111/TechnicalTopics/Toolchain [3] https://spreadsheets.google.com/ccc?key=0Ap7fWLePADFVdHkxYy1INTZmMEd4bkwxSG… [4] there is no 4... [5] https://wiki.linaro.org/MichaelHope/Sandbox/1111Blueprints

14 years, 2 months

[ACTIVITY] 18th - 21st April

by Andrew Stubbs

Merged & tested the outstanding merge requests into Linaro GCC. Spin the Linaro GCC 4.5 and 4.6 releases. Uploaded the tarballs to Michael. Submitted a patch upstream that removed some redundant code that had confused me a introduced a bug into my Thumb2 constants patch. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03756.html This patch is now approved and committed upstream. I'll commit it internally when the rest of my ARM/Thumb constant handling changes are upstream. Worked on addressing RichardE's concerns with my Thumb2 constants patch. Tried to split it into smaller chunks, and rename the constraints. Posted the patches upstream: 1. a small patch upstream to clean up MOWV support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03768.html (Now approved and committed.) 2. ADDW and SUBW support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html 3. Replicated constants for constant splitting. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html Committed upstream Dan's Vector shift test cases patch that was approved last week. Pushed the same patch to Linaro GCC 4.6. ---- Upstream patched requiring review: * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * ARM EABI half-precision functions (reposted 2011-04-14) http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html * ARM Thumb2 addw/subw support. http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html * ARM Thumb2 Replicated constants http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html

14 years, 2 months

Performance meeting agenda for today.

by Ramana Radhakrishnan

Hi, Agenda for today's performance call . Sorry about the last minute posting and I'll put this in the wiki soon enough. 1. Sync-up on what's been happening around the group: a. Coremark regressions. b. Thumb2 constants patch. c. divmodsi4 and vfp register moves. d. DENBench investigations. 2. Planning for the summit and turning some of the ideas into blueprints. 3. AOB. cheers Ramana

14 years, 2 months

[ACTIVITY] Apr.18 -- Apr.24

by Chung-Lin Tang

== Last week == * PR48250, rehaul arm_legitimize_reload_address(). Richard Sandiford caught a bug of mine where I overlooked the valid index range of NEON quad-word load/stores. Quickly whipped up a fix, soon approved and committed upstream. * LP #744754, ICE in NEON struct-mode auto-inc-dec MEMs. Pushed upstream patch for a merge to Linaro 4.5. * PR46888, bit-field insert optimization patch. Resumed investigating, mailed Andrew Pinski for more information on that REG_EQUAL note issue he mentioned on gcc-patches; can't quite reproduce it myself. * CoreMark ARMv6/v7 regressions: posted a patch set to gcc-patches. Still waiting review. * Reported to Bernd and AndrewS on an issue (LP #748138) which seems to be related to the shrink-wrap patch. This ICE does not seem to be avoided by doing -fno-shrink-wrap. * A few tasks related to Linaro-Budapest event travel. == This week == * Do the merge of the new combine patches to Linaro, and test. * LP #689887 is still in progress. * Hope to experiment with a few more optimization ideas.

14 years, 2 months

NEON intrinsics vs. assembly code

by Richard Sandiford

Michael mentioned that some users reported seeing better preformance from RVCT using arm_neon.h then they did when coding directly in assembler. He suggested we try the same thing for GCC. Here's an experiment using the example that Jim Huang posted to the dev list recently: https://wiki.linaro.org/RichardSandiford/Sandbox/IntrinsicsPerformance The summary is that the C version needs to borrow a trick from the assembly code in order to be competitive. If it does that, though, the C code can be faster. I think this is mostly down to scheduling, although I haven't checked in detail yet. Richard

14 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain