- linaro-toolchain - lists.linaro.org

Summary of required work for a Versatile Express QEMU model

by Peter Maydell

I mentioned in the toolchain standup call that I'd done a quick estimate of the work required to support vexpress, so I thought I might as well clean it up a little and post it. This is a quick summary and time estimate for adding Versatile Express support to qemu. The general idea is that most of the components on this board already have QEMU implementations (since they're standard ARM primecells used in versatile/realview), and we can live without the few major components that aren't implemented (maybe we'd need dummy implementations if the kernel prods them on startup.) Components already supported by QEMU: ------------------------------------- A9MPx4 PL050 keyboard, mouse SMCS LAN9118 ethernet PL011 UARTs SP804 timers Components with a near match in QEMU: ------------------------------------- PL111 CLCD -- qemu has a PL110 PL180 MMC card -- qemu has a PL181 -- both cases should either just work or be fairly trivial tweaks Components not supported by QEMU: --------------------------------- PL041 audio compact flash two-wire serial bus (for PCI-express switch config and DVI-I displays) ISP1761 Philips USB controller User switches and LEDs -- vexpress specific, but trivial to do Components where a dummy implementation should be sufficient: ------------------------------------------------------------- PL310 L2 cache controller PL341 dynamic memory controller PL354 static memory bus controller trustzone controllers Other required work: -------------------- The usual knitting for interrupts, clocks, reset etc etc. Summary ------- Assuming we're happy not to worry about support for audio, USB, two-wire serial bus or compact flash, this is about two weeks work to put together, test and get a more-or-less upstreamable patchset from. This would produce a platform hopefully at least as usable as versatile, but with an A9 and 1GB RAM. -- PMM

14 years, 4 months

3
6
0 0

RE: Problems with kernel support for hardware watchpoints

by Ulrich Weigand

"Will Deacon" <will.deacon(a)arm.com> wrote on 02/14/2011 11:30:45 AM: > > - In testing on Versatile Express, I noticed what appears to be SMP > > related bugs in handling regular software breakpoints: occasionally, > > software breakpoints simply are not hit and execution continues as if > > the underlying code had not been changed at all. This symptom > > completely goes away if GDB and the debugged process are forced to > > the same CPU using the affinity feature (e.g. with schedtool). > > I've seen this issue in the past but I thought I'd fixed it. What kernel are > you using and do you have CONFIG_ARM_ERRATA_720789 enabled? I'm using the 2.6.37-1002-linaro-vexpress kernel from the Linaro package of the same name. This does *not* have CONFIG_ARM_ERRATA_720789 enabled (presumably because the mach-vexpress/Kconfig file does not add it?) ... > > My guess, just from seeing those symptoms, would be that when inserting > > a software breakpoint via ptrace, not all i-caches on all CPUs are > > reliably flushed ... Any thoughts on this? > > There was an I-cache aliasing problem in the kernel coupled with a TLB > invalidation hardware bug on the versatile express. I fixed these though > and haven't seen any problems since. Hmm, a TLB flush problem could also explain the symptom (because the write of the breakpoint to the text section causes a copy-on-write operation which installs a new page ...) I'll try rebuilding the kernel with the above config option enabled. > Hmmm, I'll need to have a think about this. What does GDB do if it receives > a SIGTRAP with si_addr set to (potentially) complete nonsense? As an aside, > Cortex-A15 reports the faulting address for a watchpoint correctly, so we > will be able to use multiple watchpoints there. The GDB common core can handle either of the following two indications: A) The (read/write/access) watchpoint at address XXX triggered. B) A write watchpoint may have triggered at some address. In the case of B, GDB will scan all the write breakpoints it is currently tracking and compare the current value at that address with the last value it remembers being present there. Any changes GDB sees will cause it to report the corresponding watchpoint as triggered. As far as the kernel interface is concerned, the important issue that the ARM native target in GDB is able to understand what the kernel reports, so it can in turn report either case A or B to the common core. This means as long as there is some way for GDB to understand the kernel is reporting a write watchpoint hit at an unknown address, everything is fine. This could be done e.g. be reporting a "slot" zero in si_errno to indicate the slot (and then also the address) triggering the watchpoint is unknown ... > > - Finally, I noticed when reading kernel code that under some > > circumstances, the kernel will automatically do a single step to > > get off a watchpoint that was just hit. However, this does not > > happen for user-space watchpoints installed via ptrace, right? > > (Just wanting to confirm; since GDB currently does that single > > step itself -- we don't want *both* kernel and GDB to issue a > > single step each ...) > > If the {break,watch}point has been inserted via ptrace, the kernel will > send a SIGTRAP instead of stepping the instruction. OK, thanks for the confirmation! > > I haven't gotten to looking further into other hardware (IGEP, > > Panda) -- that's next on the list. > > Good stuff, keep me posted if you see any further problems! Sure, will do! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 4 months

2
2
0 0

Announcing the Linaro porting jam

by Steve Langasek

Hello, my fellow ARM aficionados! The Linaro Developer Platform Team is pleased to announce a new initiative to help improve the state of software on ARM: the ARM porting jam. Starting today, February 16th, we will be running a weekly IRC jam on Wednesdays from 1400-1800 UTC to bring developers together to work on all manner of userspace porting bugs, with the aim of fixing portability issues and getting the fixes delivered to our upstreams. An initial porting queue of known issues can be found here: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=arm-porting-queue Interested in making the software in Ubuntu run better on ARM? Stop on by the #linaro channel on irc.linaro.org today! -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek(a)ubuntu.com vorlon(a)debian.org

14 years, 4 months

1
0
0 0

RE: Problems with kernel support for hardware watchpoints

by Ulrich Weigand

"Will Deacon" <will.deacon(a)arm.com> wrote on 02/11/2011 10:13:01 AM: > I don't have a pandaboard, so I'd be interested to see if the code > works there. I developed it using ARM boards, so the versatile express > is a known good target. I've now got it working reliably on on Versatile Express, after fixing a couple of bugs on the GDB side (both in the HW-watchpoint patch, and in common GDB code). The testsuite now passes with no regressions when enabling HW watchpoints, except for two tests that require more than one single watchpoint to be supported. This raises another couple of issues/questions, however: - In testing on Versatile Express, I noticed what appears to be SMP related bugs in handling regular software breakpoints: occasionally, software breakpoints simply are not hit and execution continues as if the underlying code had not been changed at all. This symptom completely goes away if GDB and the debugged process are forced to the same CPU using the affinity feature (e.g. with schedtool). My guess, just from seeing those symptoms, would be that when inserting a software breakpoint via ptrace, not all i-caches on all CPUs are reliably flushed ... Any thoughts on this? - As mentioned above, the kernel currently only supports one single watchpoint to be active at a time, even though hardware might support multiple ones. The reason seems to be that when a watchpoint triggers, the kernel cannot figure out which one it was (if there's more than one choice). This is a bit unfortunate, given that GDB will attempt to insert two or more watchpoints in many interesting cases (e.g. a "watch *p" command will insert *two* low-level watchpoints, one at the address of p, and one at the address where p (currently) points to). In addition, for regular (write) watchpoints, GDB does not actually *require* the underlying hardware/kernel to specify which watchpoint was hit; GDB is able to find out by itself by checking whether the values at any of the currently active locations actually changed. (For read/access type watchpoints, GDB does require that underlying support -- but those are much more rarely used anyway.) Do you see any chance of improving upon the current behaviour? - Finally, I noticed when reading kernel code that under some circumstances, the kernel will automatically do a single step to get off a watchpoint that was just hit. However, this does not happen for user-space watchpoints installed via ptrace, right? (Just wanting to confirm; since GDB currently does that single step itself -- we don't want *both* kernel and GDB to issue a single step each ...) I haven't gotten to looking further into other hardware (IGEP, Panda) -- that's next on the list. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 4 months

2
1
0 0

[ACTIVITY] 7th - 12th February 2011

by Andrew Stubbs

== Linaro GCC 4.5 == Re merged all the patches I've had to back out of Linaro GCC due to various test failures. I've now found all the extra fixes/patches necessary to make them go ... I think. Tested the build and test on ARM and x86_64. == Linaro GCC 4.6 == Continued getting the 4.5 patches forward ported to 4.6. I now have about 4 patches waiting for review upatream, or ready to be posted. Upstream review isn't happening though. This partly due to GCC being in stage 4, but mostly due to Richard Earshaw being on sabatical, and the other maintainers being inactive. I can see that I'm going to have to abandon my hopes of only merging to Linaro GCC once it's been approved upstream, and be content with merging to Linaro once it's posted upstream. Started another test to rebase the Linaro 4.6 branch with the latest from upstream. Once that's done, I think I'll start merging my changes in, and call that our baseline. (There'll still be merges from upstream, but the history will diverge.) ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * Kazu's VFP testcases: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html * Jie's thumb2 testcase fix: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00670.html

14 years, 4 months

1
0
0 0

[ACTIVITY] Jan 31 -- Feb 13

by Chung-Lin Tang

== Week of Jan.31st--Feb.6th == * Vacation, Chinese New Year Holiday. == Last week == * Monday (Feb.7th), last day of vacation. * LP #711819, ICE in push_minipool_fix: this turned out to be a simple case where a memory load alternative was not tagged with the minipool range attributes. Patch sent upstream, awaiting approval. * LP #709453, wrong code generated for NEON. Tracked this down and mostly know how to fix this, but discussion with Ramana brought the issue up that the entire idea of using NEON vmov.i32 for loading VFP constants may not be good for A9, and unclear for A8. We probably should just revert the patch from the Linaro tree for now. * PR46002, IRA internal compiler error with -fira-algorithm=priority. Been looking at this as a part of my background IRA studies. Have a possible patch for this, plus found another assert fail ICE under ARM. Will see if can post upstream this week. == This week == * Continue to look at above unfinished issues, as well as other new ones.

14 years, 4 months

1
0
0 0

[ACTIVITY] Jan 07 - Feb 11

by Ulrich Weigand

== GDB == * Installed 2.6.37 Linaro kernel on IGEP and Versatile Express in order to verify support for HW breakpoints/watchpoints * Tested GDB HW watchpoints patch, fixed several bugs in the patch and core GDB, and got it working reliably on vexpress * Started discussion with Will Deacon (ARM) regarding possible further enhancements to related kernel support Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 4 months

1
0
0 0

[ACTIVITY] 2011-02-11

by David Gilbert

== String routines == * Copied an improvement I'd previously made to memchr (removing a branch using a big IT block) to strlen * Modified benchmark setup to build everything as a library to fairly give everything a PLT overhead. * Pushed optimised memchr and strlen and simple strchr into cortex-strings bzr repo * Patched eglibc to use memchr and strchr code - although currently fighting to get appropriate .changes file == ffi == * Kicked off TSC request for license permissions == bugs == * Built and recreated the qt4-x11 bug, produced all the dumps and boiled it down to a few lines of suspicious RTL for Richard. ** Away next week.

14 years, 4 months

1
0
0 0

[Activity] Jan 31 - Feb 8th

by Ramana Radhakrishnan

== GCC == * Finished testing fix for lp:709329 and got that merged. * Wrote up a plan for GCC performance improvements based on what we discussed at the sprint. * Internal ARM tasks that kept me busy for most of last week and this week. Plans: * still stuck on some ARM internal tasks for next week.

14 years, 4 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Got the STT_GNU_IFUNC work ready to submit. Split out some preparatory patches, including fixes for some general ARM inefficiencies that I noticed this week. Ran the EGLIBC testsuite (including ifunc tests) and they passed. * Discussed ideas for representing permuted vector loads with Ira. I'm still um-ing and ah-ing about the various possible approaches, but I think I understand the constraints a bit more now. * Fixed Qt miscompilation (lp #705689). * Fixed PC-relative load bug in the assembler (lp #716967). == Next week == Holiday! Richard

14 years, 4 months

1
0
0 0

[ACTIVITY] report week 06

by Peter Maydell

RAG: Red: Amber: DATE/QEMU conference still hasn't confirmed I have a place... Green: qemu-linaro first release made! Current Milestones: | Planned | Estimate | Actual | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2011-01-25 | 2011-01-25 | handed off | * maintain-beagle-models: + first qemu-linaro release (2011.02-0) made on time + fixed OMAP3 MMC controller model bug that was causing the kernel to hang when enabling a swapfile; pushed fix to qemu and meego trees + rebased qemu-linaro on new upstream * merge-correctness-fixes + reviewed some softfloat patches from Christophe; testing of the half-precision floating point conversion instructions showed up a number of other bugs which I submitted patches for: http://patchwork.ozlabs.org/patch/82594/ (n/6) + reviewed and tested Christophe's patches for VQMOVUN and VSLI.64/VSRI.64; these have been committed upstream + fix compile failure if !CONFIG_USE_GUEST_BASE http://patchwork.ozlabs.org/patch/82630/ + remove stray #include halfway through source file http://patchwork.ozlabs.org/patch/82661/ + improved vmull.p8 implementation over the meego version, sent upstream: http://patchwork.ozlabs.org/patch/82657/ + upstreamed patch to fix VQDMLSL: http://patchwork.ozlabs.org/patch/82752/ + upstreamed patch fixing thumb-to-arm neon dp insn conversion: http://patchwork.ozlabs.org/patch/82757/ + upstreamed patches fixing Neon VZIP and VUZP * other + did a quick estimate of required effort to do vexpress model (answer: 2 weeks if we don't want audio/USB/compact flash) + usual crop of standing meetings Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 17/18 March: QEMU Users Forum, Grenoble Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver

14 years, 4 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * moved from Ubuntu Maverick to Natty on the PandaBoard * investigation on the LTTng User Space Tracer: https://wiki.linaro.org/KenWerner/Sandbox/LTTng * started to look into latrace: https://wiki.linaro.org/KenWerner/Sandbox/latrace The idea is neat but there are issues in case the users code does dlclose on a shared object. I'll investigate further when time permits. * spent some time on IBM internal process work Regards Ken

14 years, 4 months

1
0
0 0

RE: Problems with kernel support for hardware watchpoints

by Ulrich Weigand

Hi Will, > > - It seems odd that the kernel says it doesn't support the debug > > architecture, but then reports to user space that 1 watchpoint and 6 > > breakpoints are supported ... GDB will never use the watchpoint, because > > the maximum watchpoint size is reported as zero, but GDB will attempt to > > use the breakpoints. Setting a breakpoint will appear to succeed, but then > > the breakpoint just never triggers. The kernel should IMO be more > > consistent in how unsupported configurations are handled ... > > Agreed. This is an artifact of how the ptrace info register is populated. > I'll work on a fix tomorrow so that we don't report any resources when > the architecture is unsupported. Great, thanks! > > - Why is architecture 0x4 not supported? This seems to be the variant of > > the v7 debug architecture with memory-mapped registers. Apparently the > > IGEP only supports this version ... Do you know what the > > Beagle-/Pandaboard and other clones do? What would it take to support this > > architecture variant? Given the widespread use of those boards, it would > > be really nice if we could support hardware debugging on them ... > > The memory-mapped interface is hugely unreliable in real hardware because > you have to calculate the address of the memory-mapped debug registers by > using a base and offset, which are hardcoded in some information registers. > Unfortunately, I've never found a board where these registers have been > programmed correctly so (a) I had nothing to test my code with (b) few people > would be able to use it and (c) there's not really a safe way to go around > poking random areas of memory. Huh, I see. I have no idea whether those information registers contain correct values on IGEP .. > > - Which hardware *is* supported? Can you recommend a board I should be > > using to verify GDB support is working? > > The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported. > The A5 should work (untested) and the A15 will need a bit of hacking to > get it supported. OK. I guess I can try on our Versatile Express. > > Thanks for your help in getting this working! > > No problem. If you find anybody with working memory-mapped debug and some > spare time, I'd be happy to review patches :) Thanks! I'll try and see if I can figure out where the MM area is on the IGEP ... Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 4 months

3
2
0 0

[ACTIVITY] February 6-10

by Revital1 Eres

Hello, * Analyzing DENBench benchmarks. * Running mp3 player on Crotex A9 with gcc-linaro -r99463 using SMS flags (*) gives 21% improvement in execution time compared to using only base flags(**). (*) -fmodulo-sched -fmodulo-sched-allow-regmoves (**) -mcpu=cortex-a9 -mtune=cortex-a9 -mthumb -static --fast-math Thanks, Revital

14 years, 4 months

1
0
0 0

[ACTIVITY] February 6-10

by Ira Rosen

Hi, * regtested vzip/vuzp patch * looked into big-endian build * applied all the required patches and checked that Viterbi gets vectorized giving ~2x performance improvement (compiled with cross-compiler) * looked into vld/vst implementation - mostly discussions with Richard * DenBench analysis: - there are loops that should get vectorized with vzip/vuzp patch, I'll check them next week - sad8_c (hot function from mp4encode) needs reduction SLP (which I implemented several weeks ago), and an ability to jump unknown stride in loop SLP - I am looking into this Ira

14 years, 4 months

1
0
0 0

Re: Problems with kernel support for hardware watchpoints

by Arnd Bergmann

On Wednesday 09 February 2011 20:25:32 Will Deacon wrote: > > - Why is architecture 0x4 not supported? This seems to be the variant of > > the v7 debug architecture with memory-mapped registers. Apparently the > > IGEP only supports this version ... Do you know what the > > Beagle-/Pandaboard and other clones do? What would it take to support this > > architecture variant? Given the widespread use of those boards, it would > > be really nice if we could support hardware debugging on them ... > > The memory-mapped interface is hugely unreliable in real hardware because > you have to calculate the address of the memory-mapped debug registers by > using a base and offset, which are hardcoded in some information registers. > Unfortunately, I've never found a board where these registers have been > programmed correctly so (a) I had nothing to test my code with (b) few people > would be able to use it and (c) there's not really a safe way to go around > poking random areas of memory. So the only problem is that it's board specific? That's something we know how to deal with -- all I/O components have some random board specific address, and we put them in a platform device that is listed in the board file. This should be easy enough to do for another register area, though it means we have to do it separately for each board. > > - Which hardware is supported? Can you recommend a board I should be > > using to verify GDB support is working? > > The simple rule is Cortex-A8 is unsupported and Cortex-A9 is supported. > The A5 should work (untested) and the A15 will need a bit of hacking to > get it supported. Is that because A8 is memory mapped and A9 uses CP14, or is there another problem with A8? Arnd

14 years, 4 months

2
1
0 0

Problems with kernel support for hardware watchpoints

by Ulrich Weigand

Hello Will, I've been trying to get GDB support for hardware watchpoints/breakpoints going. I've ported Matthew's GDB patch to current mainline, and am running this under a 2.6.37-1002-linaro-omap kernel on an IGEPv2 board. However, something seems to be not quite working: I'm seeing this kernel message on boot: hw-breakpoint: debug architecture 0x4 unsupported. and then at runtime, the result of a PTRACE_GETHBPREGS call for register 0 is 0x04000106: debug architecture: 4 watchpoint size: 0 nr. watchpoints: 1 nr. breakpoints: 6 This leads me to a couple of questions: - It seems odd that the kernel says it doesn't support the debug architecture, but then reports to user space that 1 watchpoint and 6 breakpoints are supported ... GDB will never use the watchpoint, because the maximum watchpoint size is reported as zero, but GDB will attempt to use the breakpoints. Setting a breakpoint will appear to succeed, but then the breakpoint just never triggers. The kernel should IMO be more consistent in how unsupported configurations are handled ... - Why is architecture 0x4 not supported? This seems to be the variant of the v7 debug architecture with memory-mapped registers. Apparently the IGEP only supports this version ... Do you know what the Beagle-/Pandaboard and other clones do? What would it take to support this architecture variant? Given the widespread use of those boards, it would be really nice if we could support hardware debugging on them ... - Which hardware *is* supported? Can you recommend a board I should be using to verify GDB support is working? Thanks for your help in getting this working! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 4 months

2
1
0 0

Request for new relocation: R_ARM_IRELATIVE

by Richard Sandiford

Hi, I'm working in the Linaro toolchain team on adding ARM support for GNU indirect functions (STT_GNU_IFUNCs). The indirect function feature requires a new relocation type, which is typically called R_FOO_IRELATIVE. I'd therefore like to propose a new R_ARM_IRELATIVE relocation type for the ARM EABI. This relocation is only used in ET_EXEC and ET_DYN objects. If the object has a PT_DYNAMIC tag, then the relocation may only appear in the DT_REL(A) table; it cannot appear in the DT_JMPREL table. (Note that this is a deliberate divergence from the x86 and x86_64 behaviour, which does allow the IRELATIVE relocation to be used in DT_JMPREL table, but which requires it to be applied at load time, regardless of bind-now vs. lazy semantics. However, the proposed ARM behaviour matches that of other targets like PowerPC.) Static ET_EXEC objects may have R_ARM_IRELATIVE relocations. In this case, the relocations are stored in a relocation table that contains no other type of relocation (not even R_ARM_NONE). The static linker defines two symbols: __rel_iplt_start, which the linker points to the start of this table __rel_iplt_end, which the linker points to the last byte of this table plus one. The two symbols are equal if the executable has no R_ARM_IRELATIVE relocations. It is the executable's responsibility to apply these relocations as appropriate. If the static linker emits a symbol table, then it is not defined whether the linker includes __rel_iplt_start and __rel_iplt_end in that symbol table. The static linker may (or may not) define __rel_iplt_start and __rel_iplt_end in dynamic objects. However, if it does define them, the symbols must refer to part of the DT_REL(A) table, and it is still the dynamic linker's responsibility to apply the relocations. An R_ARM_IRELATIVE relocation applies to all bits of a 4-byte field. There are no alignment restrictions on the field. The relocation value is: call(B(S) + A) where call(X) represents the value of r0 after performing an indirect branch-with-link-and-exchange (BLX) to address X. The dynamic linker must have applied all earlier DT_REL(A) relocations before calling X. It is undefined whether later DT_REL(A) relocations have been applied or not, and X must not make any assumptions about the status of those relocations. If there is an R_ARM_IRELATIVE relocation with symbol S and addend A, then the relocation value: call(B(S) + A) is considered to be a load-time constant. It is possible for an object to have more than one R_ARM_IRELATIVE relocation with the same value of B(S) + A, and in such a case, it is not defined whether the dynamic linker invokes the target function each time, or whether it caches the results of earlier calls. I realise this isn't the cleanest extension in the world. As Alan Modra noted on the binutils list, the choice of __rel_iplt_start and __rel_iplt_end is particularly unfortunate, since the relocations are not specific to "PLTs". However, the GNU extension has been defined this way, so unfortunately there isn't much room for target-specific variation. Thanks, Richard

14 years, 4 months

2
3
0 0

Question about big endian

by Ira Rosen

Hi, I'd like to check vzip/vuzp patch in big endian mode. But when I try to compile with -mbig-endian flag, I get > ~/mainline/bin/bin/gcc -O3 -mfloat-abi=softfp -mfpu=neon neon-vtrnu8.c -mbig-endian /home/irar/mainline/bin/lib/gcc/armv7l-unknown-linux-gnueabi/4.6.0/../../../libgcc_s.so.1: could not read symbols: File in wrong format collect2: ld returned 1 exit status What am I missing? Thanks, Ira

14 years, 4 months

3
6
0 0

Today's standup call

by Michael Hope

Hi there. As discussed on Monday, I've shifted today's standup call an hour earlier to 1700 UTC. See you then! -- Michael

14 years, 4 months

1
0
0 0

Linaro GDB 7.2 2011.02 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.2. Linaro GDB 7.2 2011.02-0 is the third release in the 7.2 series. Based off the latest GDB 7.2, it includes a number of ARM-focused bug fixes and enhancements. Interesting changes include: * Backtracing is more reliable through using the ARM specific exception tables for unwinding * Better supports debugging functions compiled with GCC's -fstack-protector * Multiple testsuite related fixes The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.2-2011.02-0 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- Michael

14 years, 4 months

1
0
0 0

Linaro GCC 4.4 and 4.5 2011.02 released

by Michael Hope

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.4 and Linaro GCC 4.5. Linaro GCC 4.5 is the seventh release in the 4.5 series. Based off the latest GCC 4.5.2, it includes many ARM-focused performance improvements and bug fixes. Interesting changes include: * Improved code generation in the __sync primitives * Better modelling of the Cortex-A9 NEON pipeline * Added a performance improvement that converts a tree of ifs into a switchs * Many bug fixes Linaro GCC 4.4 is the seventh release in the 4.4 series. Based off the latest GCC 4.4.5, it is a maintenance release that fixes one fault found with offsets on NEON loads. The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.5-2011.02-0 https://launchpad.net/gcc-linaro/+milestone/4.4-2011.02-0 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro -- Michael

14 years, 4 months

1
0
0 0

Linaro QEMU 2011.02-0 released

by Peter Maydell

The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2011.02-0. Linaro QEMU 2011.02-0 is the first official release of qemu-linaro. Based off upstream qemu, it includes a number of ARM-focused bug fixes and enhancements. - This initial qemu-linaro release includes all the ARM code generation fixes from the qemu-meego tree; these are mainly Neon related - The OMAP3 support from qemu-meego is also included - Various bugs which prevented newer Linaro snapshots from booting on the beagle model have been fixed - Bugs causing linaro-media-create to print warnings about unimplemented syscalls and ioctls have been fixed Known issues: - There is no support for USB keyboard or mouse, so only a serial console is usable (#708703) - Images built with linaro-media-create's --swap_file option will not boot (#713101) The source tarball is available at: https://launchpad.net/qemu-linaro/+milestone/2011.02 Binary builds of this qemu-linaro release are available for users of Ubuntu. Natty users can find qemu-linaro 2011.02-0 in the Ubuntu archive. Users of Ubuntu 10.04 LTS and Ubuntu 10.10 can find packages in the linaro-maintainers tools ppa: https://launchpad.net/~linaro-maintainers/+archive/tools/ More information on Linaro QEMU is available at: https://launchpad.net/qemu-linaro

14 years, 4 months

1
0
0 0

[ACTIVITY] 31st January - 4th February

by Andrew Stubbs

== Linaro GCC 4.5 == Reviewed, tested and merged all the outstanding patches waiting to go into Linaro GCC 4.5. Michael reported that there was a build failure on i686 and amd64. I attempted to reproduce this but my builds completed successfully - very strange. Eventually I found that I had a corrupted checkout and managed to reproduce the problem - thanks bzr! The problem is in Tom's recent changes to stmt.c, so I informed him and backed out the patches, temporarily. Spun the Linaro GCC 4.4 and 4.5 release tarballs and passed them to Michael Hope for final testing. == GCC 4.6 == Tested a more recent version of GCC 4.6 and pushed it to the bazaar repository. Already out of date by the time testing finished of course, but never mind. The number of test failures is greatly reduced. Started another build/test with an even more up-to-date check-out. Begun work merging the 4.5 patches into 4.6. Pushed 1 patch upstream. Got another ready to go, once I've tested it. == Android == Tried to unpick a large patch I was sent that supposedly added Android support to Linaro GCC 4.5. The patch was suspicious from the start because it had large changes to gcc/ChangeLog that clearly backed out the 4.5.2 release. After comparing it against various sources I concluded that it was a 4.6 snapshot from last May with (at least some of) the Linaro patches forward ported, and the release numbers fudged to look like it was 4.5.2 based. This was not terribly helpful - I can't very well backport that into our 4.5 branch! == Upstream GCC == Upstream patches requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * Kazu's VFP testcases: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html

14 years, 4 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== Last week == * Backported the fixes for lp693502, lp710623 and lp710652 to linaro 4.6 and linaro 4.5. Tested and sent merge requests. * Wrote several more ifunc tests, and fixed the bugs they showed up. Found that ARM generates unnecessary dynamic relocs against GOT entries, so fixed that as a prerequisite. Improved the tracking of STB_LOCAL ifuncs, so that they're treated more like STB_GLOBAL. * Submitted a request for R_ARM_IRELATIVE to be added to the ARM EABI. == This week == * More ifunc. I'm away next week (14th-18th) Richard

14 years, 4 months

1
0
0 0

Extension elimination pass breaks SPU (Fw: spu gcc-4.5 linaro build failure)

by Ulrich Weigand

Hello, Matthias noticed the following ICE when attempting to build the SPU compiler from the Linaro GCC 4.5 sources: ../../../../src-spu/libgcc/../gcc/libgcc2.c: In function '__fixunssfdi': ../../../../src-spu/libgcc/../gcc/libgcc2.c:1344:1: internal compiler error: in spu_expand_mov, at config/spu/spu.c:4575 It turns out that this is due to the new "extension elimination" pass that was recently added in Linaro GCC, as port from the CodeSourcery compiler. This patch has also been proposed, but not yet included upstream. The problem is that this patch seems to frequently introduce instructions that *set* a sub-word lowpart subreg of a register. Now such instructions, according to the docs, are probably valid RTL, but since the effect of the instruction onto the highpart of the register is deliberately left unspecified, they tend to be very infrequently used. Probably because of this, there seem to be parts of the compiler that simply don't handle such instructions correctly. This has been already noticed in the case of the RTL loop optimizers (see discussion here http://gcc.gnu.org/ml/gcc/2010-11/msg00552.html). The failure in the SPU back-end is another instance of the same problem. SPU needs special code to handle subregs (since a "lowpart" SImode subreg of a DImode register is not actually valid on the SPU, because SImode values live in bytes 0..3 while DImode values live in bytes 0..7 of the otherwise big-endian 16-byte SPU registers), and this code simply aborts when given an assignment to a sub-word lowpart subreg. Now, I guess there's two ways forward: either the outcome of the ongoing discussions on gcc-patches is that it is in fact not a good idea to generate such sets, and the EE pass is subsequently rewritten to avoid them; or else, if those instructions are considered valid, I'll have to extend the SPU move expander to handle them. Thoughts? Matthias, if you need a quick workaround for now, I guess you could disable the new pass for SPU by adding a line "flag_ee = 0;" to spu_override_options. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 4 months

6
9
0 0

qemu 2011.02-rc2 test results

by Michael Hope

I've had a go with running the QEMU release candidate. Short story is that it boots to a prompt against the 11.05 alpha2 release so I'm happy. It was a messy road so I've written up my train of though here: https://wiki.linaro.org/MichaelHope/Sandbox/QEMU Note that if you follow the instructions on: https://wiki.linaro.org/Releases/GettingInstallingTesting and turn on a swap file then it halts during boot. -- Michael

14 years, 4 months

3
3
0 0

[ACTIVITY] 2011-02-04

by David Gilbert

== String routines == * After some discussions about IT semantics managed to shave a couple of instructions out of a couple of routines * Got around to trying a suggestion that was made some months ago, that LDM is faster than LDRD on A9's; and indeed it does seem to be in some cases; those cases seem pretty hard to define though - it's no slower than LDRD, so it seems best to avoid LDRD. * Digging around eglibc's build/configure system to see how to add assembler routines to only get used on certain build conditions (i.e. v7 & up) == SPEC == * Compiled lbm -O2 and ran it on our local panda and on Michael's ursa1 - it seems happy (with a drop of swap); so I'd say that confirms the issues I previously had were local to something on canis. That's a bit of a pain since it's the only machine with enough RAM to run the rest of the suite. == Other == * Tested a headless Alpha-2 install on our Beagle C4 - mostly worked * Tested qemu-linaro release on the realview-pbx kernel/nfs setup I had * A simple smoke test for pldw on qemu * Tripped over ltrace not working while trying to profile git's use of memcpy and memcmp; it does some _very_ odd things; it's predominant size of memcpy seems to be 1 byte.

14 years, 4 months

2
1
0 0

OpenOCD support for OMAP4/ PandaBoard

by Nicolas Pitre

I just stumbled across this: http://article.gmane.org/gmane.comp.debugging.openocd.devel/15584 And the mentioned clock issue seems to be fixed here: http://article.gmane.org/gmane.comp.debugging.openocd.devel/15619 This is excellent news, and I think we ought to support this at some point. Nicolas

14 years, 4 months

2
1
0 0

[ACTIVITY] Jan 31 - Feb 04

by Ulrich Weigand

== GDB == * Prepared Linaro GDB 7.2-2011-02.0 release * Committed two patches to implement LP #661253 (Improve backtrace by using ARM exception tables) to mainline and Linaro GDB 7.2 * Provided two follow-on fixes to the patch for LP #616000 (Handle -fstack-protector prologue code); both applied to mainline and Linaro GDB 7.2 * Backported mainline fix for LP #685494 (gdb.xml/tdesc-regs.exp failure) to Linaro GDB 7.2 * Identified root cause of LP #711375 (gdb internal error in inline_frame_this_id trying to debug a qemu target); committed fix to mainline and Linaro GDB 7.2 * Worked on re-implementation of fix for LP #615978 (Failure to software single-step into signal handler) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 4 months

1
0
0 0

[ACTIVITY] Week 2011-2-04

by Mounir Bsaibes

=== Toolchain === * Organized the Weekly Release Meeting Status pages https://wiki.linaro.org/WorkingGroups/ToolChain/Status * Organized the collection of weekly Activity https://wiki.linaro.org/WorkingGroups/KernelConsolidation/ActivityReports * Started to track Linaro events planned and approved attendance https://wiki.linaro.org/Internal/People/MounirBsaibes/ToolchainScratchpad(f… now) * Started to monitor bug handling * Reviewed and tracked blueprints status (burdown charts) * Kernel WG various PM tasks * Power Management WG various PM tasks ==== Plan ==== * Continue investigating importing blueprint and WI's data into OpenProj using OpenProj xml file * map bleuprint/WI's fields to the OpenProj xml fields

14 years, 4 months

1
0
0 0

[ACTIVITY] report week 05

by Peter Maydell

RAG: Red: Amber: DATE/QEMU conference still hasn't confirmed I have a place... Green: qemu-linaro RC2 prerelease uploaded Current Milestones: | Planned | Estimate | Actual | first qemu-linaro release | 2011-02-08 | 2011-02-08 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off | * maintain-beagle-models: + RC1 packaging flushed out some bugs: ++ we include some binary blobs which we're better not distributing: https://bugs.launchpad.net/qemu-linaro/+bug/709965 ++ a couple of array overruns don't compile with our picky armel gcc: https://bugs.launchpad.net/qemu-linaro/+bug/709711 https://bugs.launchpad.net/qemu-linaro/+bug/711272 (both fixes sent and applied upstream) ++ we ought to include a fix for the "swp" in qemu-lock.h: http://patchwork.ozlabs.org/patch/81205/ (patch sent upstream, no comment on it yet) + ...so I have rolled an RC2 tarball with these fixed + investigated why USB keyboard model doesn't work: it turns out that the OMAP host USB model is basically just a stub + some warnings from qemu about bad width accesses are a symptom of a nasty disagreement between gcc and the kernel about getting atomic 32 bit accesses: http://www.spinics.net/lists/arm-kernel/msg113002.html + warnings from qemu about access to a nonexistent i2c register appear to be a kernel bug in the i2c driver for OMAP36xx: https://bugs.edge.launchpad.net/linux-linaro/+bug/645324 + investigated a hang running images built with linaro-media-create's --swap_file option. Still digging but I suspect the Linux driver doesn't cope with an MMC card which can erase in zero time... * merge-correctness-fixes + the usual upstream mailing list monitoring and code review + sent patch for PLI and hint space decoding fixes: http://patchwork.ozlabs.org/patch/81711/ * misc + some non-Linaro time this week; may be more next week + some advance planning of what we might want to do with QEMU in the future Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 17/18 March: QEMU Users Forum, Grenoble Holiday: 22 Apr - 2 May 9-13 May: UDS, Budapest (maybe) ~17-19 August: QEMU/KVM strand at LinuxCon NA, Vancouver

14 years, 4 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * I continued to setup the pandaboad but ran into #708883 - tested vaious various hwpacks and headless images - used different power supplies and several SD cards - built various test kernels from the linux-linaro-natty.git * looked into the crash utility * https://wiki.linaro.org/KenWerner/Sandbox/crash-utility#future%20areas Regards Ken

14 years, 4 months

1
0
0 0

gcc-linaro-4.5+bzr99469 build failure

by Michael Hope

The current revision fails to bootstrap on i686: http://ex.seabright.co.nz/build/gcc-linaro-4.5+bzr99469/logs/i686-lucid-cbu… libtool: compile: /scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc/xgcc -shared-libgcc -B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc -nostdinc++ -L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src -L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs -B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/bin/ -B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/lib/ -isystem /scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/include -isystem /scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc-linaro-4.5/libjava -I./include -I./gcj -I../../../gcc-linaro-4.5/libjava -Iinclude -I../../../gcc-linaro-4.5/libjava/include -I../../../gcc-linaro-4.5/libjava/classpath/include -Iclasspath/include -I../../../gcc-linaro-4.5/libjava/classpath/native/fdlibm -I../../../gcc-linaro-4.5/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../gcc-linaro-4.5/libjava/libltdl -I../../../gcc-linaro-4.5/libjava/libltdl -I../../../gcc-linaro-4.5/libjava/.././libjava/../gcc -I../../../gcc-linaro-4.5/libjava/../zlib -I../../../gcc-linaro-4.5/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\" -DTOOLEXECLIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib\" -DJAVA_HOME=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\" -DBOOT_CLASS_PATH=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/libgcj-4.5.2.jar\" -DJAVA_EXT_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.5.2-11/classmap.db\" -g -O2 -D_GNU_SOURCE -MT exception.lo -MD -MP -MF .deps/exception.Tpo -c ../../../gcc-linaro-4.5/libjava/exception.cc -o exception.o >/dev/null 2>&1 ../../../gcc-linaro-4.5/libjava/prims.cc: In function 'jboolean _Jv_isPrimitiveOrDerived(const Utf8Const*)': ../../../gcc-linaro-4.5/libjava/prims.cc:287:5: internal compiler error: in set_jump_prob, at stmt.c:2211 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. The log is available here: http://builds.linaro.org/toolchain/gcc-linaro-4.5+bzr99469/logs/i686-lucid-… -- Michael

14 years, 4 months

2
4
0 0

do we consider extravagant memory usage a gcc bug?

by Peter Maydell

Trying to build qemu on a beagle board: CC sparc64-linux-user/translate.o cc1: out of memory allocating 26975704 bytes after a total of 70742016 bytes # ls -lh target-sparc/translate.c -rw-r--r-- 1 root root 191K Jan 31 12:05 target-sparc/translate.c ie gcc wants (at least) 100M of RAM trying to compile a 190K sourcefile. (and probably more overall since the board has 500MB RAM total and it hit the out-of-memory condition). This seems a bit excessive to me, but do we consider it enough of a bug to be worth looking into? (I believe this source file has caused compile failures on the buildds too, which have rather more RAM/swap than my beagle.) -- PMM

14 years, 4 months

4
5
0 0

[ACTIVITY] January 30 - February 3

by Revital1 Eres

Hello, Profiling Denbech: * The profiling information on x86 indicate that some benchmarks might need to run longer as helper functions such as t_run_test are reported to be hot. So I've increased the time each benchmark is executed and will continue to experiment with that for the problematic benchmarks until I start to see more reasonable results. * Opened PR711819 after having an ICE running DENbench with trunk (natively built on ARM machine). - I've started to look at an old patch for SMS that was written in 2005 by colleague; Mostafa Hagog; to place the register moves in free slots. Currently, they are placed greedily before each def thats needs them. Thanks, Revital

14 years, 4 months

1
0
0 0

[ACTIVITY] January 30 - February 3

by Ira Rosen

Hi, I continued to work on vect_interleave and vect_extract implementation on NEON: * debugged the compiler to find out what's the problem with neon_vzip/vuzp<mode>_internal * fixed it following Uli's advice * checked how neon_vzip/vuzp<mode>_internal work for intrinsics by writing tests * fixed the patch according to Uli's comments * now fully testing the patch Thanks, Ira

14 years, 4 months

1
0
0 0

Help with define_insn

by Ira Rosen

Hi, I am trying to implement interleave_high/low and extract_even/odd using vzip and vuzp instructions. I am attaching a patch that attempts to do that. It uses already existing neon_vzip<mode>_internal. The problem with it is that it doesn't express the fact that the two outputs of vzip depend on both inputs, which causes wrong code generation in CSE: for (a,b)<- vzip (c,d) and (e,f) <- vzip (g,d) CSE decides that b==f, since on RTL level b and f depend only on d. Here is neon_vzip<mode>_internal: (define_insn "neon_vzip<mode>_internal" [(set (match_operand:VDQW 0 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 1 "s_register_operand" "0")] UNSPEC_VZIP1)) (set (match_operand:VDQW 2 "s_register_operand" "=w") (unspec:VDQW [(match_operand:VDQW 3 "s_register_operand" "2")] UNSPEC_VZIP2))] "TARGET_NEON" "vzip.<V_sz_elem>\t%<V_reg>0, %<V_reg>2" [(set (attr "neon_type") (if_then_else (ne (symbol_ref "<Is_d_reg>") (const_int 0)) (const_string "neon_bp_simple") (const_string "neon_bp_3cycle")))] ) Is there a way to properly mark the dependence? Thanks, Ira

14 years, 4 months

4
8
0 0

qemu-linaro prerelease available

by Peter Maydell

Hi; this is a note to say that we have now produced a prerelease tarball of qemu-linaro. (The first formal qemu-linaro release will happen in sync with other toolchain group releases on 8th Feb.) This prerelease is primarily to pipeclean the release process and to allow work to start on producing Ubuntu and Linaro packages; however it does include a number of useful bugfixes which are required if you want to be able to boot a recent Linaro snapshot on the beagle model. So the enthusiastic might like to build it from source and give it a spin. Like the Linaro kernel trees, the qemu-linaro tree aims to only include patches we are confident will go upstream; at the moment this means the OMAP3 support and ARM correctness fixes from the qemu-meego tree, based on the qemu upstream trunk. You can download the source tarball from: https://launchpad.net/qemu-linaro/+milestone/2011.02 -- Peter Maydell

14 years, 4 months

1
1
0 0

IT block semantic question

by David Gilbert

Hi, What do people understand to be the expected semantics of IT blocks in the cases below, of which there has been some confusion in relation to a recent Qt issue. The code in question had a sequence something like: comparison IT... EQ blahEQ TEQ BEQ The important bits here are that we have an IT EQ block and two special cases: 1) There is a TEQ in the IT block - are all comparisons in the block allowed and do their effects immediately take effect? As far as I can tell this is allowed and any flag changes are used straight away; 2) There is a BEQ at the end of the IT block, as far as I can tell, as long as the destination of the BEQ is close it shouldn't make any difference if the BEQ is included in the IT block or not. Does that match everyone elses understanding? Dave

14 years, 4 months

2
3
0 0

Generating ancilliary sections with gas

by Dave Martin

Hi all, With gas, does anyone know of a way to create a section whose name is based on that of the current section? The specific requirement is to be able to define a generic macro like the example "fixup" below, whose purpose is to record ancilliary data related to some other section. To illustrate: .macro fixup 100\@ : .pushsection fixup<current section name>, "a" .long 100\@b .popsection .endm .text ... fixup .long sym1 ... .section .other, "ax" ... fixup .long sym2 The linux kernel uses a technique just like this for patching SMP kernels at bootup to work on uniprocessor platforms (when CONFIG_SMP_ON_UP is enabled), resulting in code looking something like this: void exit __attribute__ (( __section__ (".text.exit") )) { ... asm( ... FIXUP("something") ... ); } Note that the inline asm may actually come out of a generic header file rather than being explitly written for this invocation. So it may have to be truly generic. Is far as I have been able to determine, it's not possible to generate sections named based on the current section. In practice, the kernel puts all the fixups into a single section. The downside of this is that when sections are selectively discarded at link time (which in general may happen -- for example, Linux discards the "module exit" code for drivers which are built into the kernel and therefore never exit) there is no way to selectively discard the related fixup entries. Currently the only solution is to include all the module exit code in the image and discard it at run-time when the kernel boots. This is obviously wasteful. Attempting to discard that code at like time results in a link error, since fixups refer to the removed sections. Of course, the "fixup" macro could be given an extra parameter to name the containing section, but the macro can then no longer be called in a generic way: all the calls to that macro must be manually (and buggily) maintained to ensure that the referenced section name is correct, some object post-processing must be done before linking, and/or a tool must be created to implement the missing assembler functionality. Unfortunately, such solutions are likely to be too fragile or complex to make it upstream. It's interesting to note that the same problem will apply for any section containing ancilliary data for another section. In particular, it looks like either the ABI or the assembler has had to grow a special-case workaround for this in order to support exception unwind information sections generated by .fnstart ... .fnend in a sane way: the unwind information sections get called .ARM.ex{idx,tab} for .text, and .ARM.ex{idx,tab}<section> for any other section. As a consequence, link-time discarding can handle this information properly, but IMHO this is a bit of a cheat and admits the general need to create sections with names based transparently on those of other sections, without satisfying that need. .popsection is also an example of such a cheat: most other aspects of assmbler state still cannot be saved and restored. In general, it would be useful if gas supported some general reflective abilities: i.e., the ability to query the current assembler state (section, subsection, active instruction set, active macro mode, etc.) and/or the ability to wrap or hook existing pseudo-ops. For example, the above problem would almost certainly solvable using assembler macros (albeit painfully) if wrapper macros could be defined for the section manipulation directives (section, .text, .data, .bss, .pushsection, .popsection, .previous). However, supporting some magic macro parameters reflecting the assembler state would be a lot simpler. As an example of the kind of behaviour I think would be useful, the macro argument qualifier could be extended to allow macros to query the assembler state in a backwards-compatible way; something like: .macro fixup base_section:gas_current_section_name, old_altmacro:gas_macro_mode .altmacro LOCAL fixup_location fixup_location: .pushsection \base_section\().fixup .long 100\@b .popsection \old_altmacro .endm Existing assembler code will continue to work just fine with this approach. Note how this also enables a local label to be generated hygenically, by making it possible to save and restore the macro mode. Otherwise, .altmacro (and hence LOCAL) is hard to use safely, since the initial macro mode is unknown and can't be restored. Any thoughts / comments? Cheers. ---Dave

14 years, 4 months

2
3
0 0

[GCC 5.5 - Help on ERROR] Compilation fails with mfpu=neon

by ShankarGanesh Kandasamy

Hi, Following compilation fails with -O3 -mfpu=neon,(but successful on -O2, -mfpu=neon) for Cortex-A5. Could you please help me out to resolve this error ? ubuntu@tegra:~/$ gcc-4.5 -v -c -o utility.o -DLINUX -DUNIX -DHAS_LONGLONG -DLITTLE_ENDIAN_ARCH -DSPEC_CPU2000 -O3 -mcpu=cortex-a5 -marm -mfpu=neon -mfloat-abi=softfp utility.c Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.5.1/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.1-7ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.5.1 (Ubuntu/Linaro 4.5.1-7ubuntu2) COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'utility.o' '-DLINUX' '-DUNIX' '-DHAS_LONGLONG' '-DLITTLE_ENDIAN_ARCH' '-DSPEC_CPU2000' '-O3' '-mcpu=cortex-a5' '-marm' '-mfpu=neon' '-mfloat-abi=softfp' /usr/lib/gcc/arm-linux-gnueabi/4.5.1/cc1 -quiet -v -DLINUX -DUNIX -DHAS_LONGLONG -DLITTLE_ENDIAN_ARCH -DSPEC_CPU2000 utility.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase utility.c -mcpu=cortex-a5 -marm -mfpu=neon -mfloat-abi=softfp -auxbase-strip utility.o -O3 -version -fstack-protector -o /tmp/ccaZnpsw.s GNU C (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (arm-linux-gnueabi) compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64482 ignoring nonexistent directory "/usr/local/include/arm-linux-gnueabi" ignoring nonexistent directory "/usr/lib/gcc/arm-linux-gnueabi/4.5.1/../../../../arm-linux-gnueabi/include" ignoring nonexistent directory "/usr/include/arm-linux-gnueabi" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include /usr/lib/gcc/arm-linux-gnueabi/4.5.1/include-fixed /usr/include End of search list. GNU C (Ubuntu/Linaro 4.5.1-7ubuntu2) version 4.5.1 (arm-linux-gnueabi) compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 3.0.0-p3, MPC version 0.8.2 GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64482 Compiler executable checksum: 52c4962735600b49ca41dc70631edd04 COLLECT_GCC_OPTIONS='-v' '-c' '-o' 'utility.o' '-DLINUX' '-DUNIX' '-DHAS_LONGLONG' '-DLITTLE_ENDIAN_ARCH' '-DSPEC_CPU2000' '-O3' '-mcpu=cortex-a5' '-marm' '-mfpu=neon' '-mfloat-abi=softfp' as -mcpu=cortex-a5 -mfloat-abi=softfp -mfpu=neon -meabi=5 -o utility.o /tmp/ccaZnpsw.s /tmp/ccaZnpsw.s: Assembler messages: /tmp/ccaZnpsw.s:460: Error: VFP/Neon double precision register expected -- `vmovl.s16 q5,s20' /tmp/ccaZnpsw.s:531: Error: VFP/Neon double precision register expected -- `vmovl.s16 q9,s14' /tmp/ccaZnpsw.s:537: Error: VFP/Neon double precision register expected -- `vmovl.s16 q7,s28' /tmp/ccaZnpsw.s:542: Error: VFP/Neon double precision register expected -- `vmovl.s16 q13,s12' /tmp/ccaZnpsw.s:543: Error: VFP/Neon double precision register expected -- `vmovl.s16 q14,s10' /tmp/ccaZnpsw.s:544: Error: VFP/Neon double precision register expected -- `vmovl.s16 q3,s8' /tmp/ccaZnpsw.s:546: Error: VFP/Neon double precision register expected -- `vmovl.s16 q2,s6' /tmp/ccaZnpsw.s:549: Error: VFP/Neon double precision register expected -- `vmovl.s16 q1,s4' /tmp/ccaZnpsw.s:550: Error: VFP/Neon double precision register expected -- `vmovl.s16 q0,s0' /tmp/ccaZnpsw.s:551: Error: VFP/Neon double precision register expected -- `vmovl.s16 q4,s16' Regards, Shankar -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

14 years, 4 months

1
0
0 0

[ACTIVITY] Jan 24--30

by Chung-Lin Tang

== Last week == * PR47246, VFP index range on Thumb-2. Submitted and committed patch upstream. * Pinged two upstream submissions on gcc-patches, one for PR44557 and the other a patch for LP:689887; still awaiting approval. == This week == * Chinese New Year Holiday, I'll be off until Feb.8th.

14 years, 5 months

1
0
0 0

GCC 4.6 Upgrade Plan

by Andrew Stubbs

Hi All, The GCC 4.6 Upgrade plan can be found here: https://wiki.linaro.org/WorkingGroups/ToolChain/GCCUpgradePlan The plan describes how we should commit "upstream" patches while the FSF trunk is closed, and what we plan to use 4.6 for. Andrew

14 years, 5 months

1
0
0 0

[ACTIVITY] 24th -28th January 2011

by Andrew Stubbs

Created a Google docs spreadsheet to help visualise the benchmark results. The graphs are not very informative yet - too many lines and too much noise. I'm going to have to revisit them. Continued trying to build Android. The toolchains build fine, but Android itself complains about -Werror, and there are a few other real errors too. Considering I was told it built fine with GCC 4.6 and all I needed to do was tweak 4.5 to match, I'm not terribly impressed. I'm sinking too much time into fixing up Android, and I haven't even got to looking at the compiler trouble. Alexander Sack has said he will try to get me to a more appropriate starting place (I think), so I'll see what happens there. Discussed my maddhidi4 patch with Richard E (wearing his GCC ARM maintainer hat). He's not convinced that my change won't make something else produce worse code. I can't prove that it won't either, so I'm going to have to revisit it. Wrote up the GCC 4.6 branch policy and upgrade plan.

14 years, 5 months

1
0
0 0

New phone number for today's call

by Michael Hope

Just a reminder that the dial-in numbers for today's and all future calls has changed. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings for the new list. I'll hang out on IRC just before the meeting to help the lost... -- Michael

14 years, 5 months

1
0
0 0

[ACTIVITY] report week 04

by Peter Maydell

RAG: Red: Amber: Green: qemu-linaro RC0 prerelease uploaded Current Milestones: | Planned | Estimate | Actual | first qemu-linaro release | 2011-01-11 | 2011-01-11 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off | * maintain-beagle-models: + went through diffs between qemu-linaro and qemu-meego to confirm we hadn't dropped any patches by mistake + tested qemu-linaro tree on ubuntu netbook image: boots OK + investigated and fixed qemu bugs caused by new x-loader https://bugs.launchpad.net/qemu-linaro/+bug/704484 and new u-boot: https://bugs.launchpad.net/qemu-linaro/+bug/703094 + made merge requests to meego for a CRIS compile failure and the x-loader bugfix http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/4 http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/5 + Went through the process of doing a qemu-linaro release with a "RC0" prerelease as a pipecleaning exercise and to provide a tarball to slangasek for doing packaging. Download: https://launchpad.net/qemu-linaro/+milestone/2011.02 Release process writeup: https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess * merge-correctness-fixes + the usual upstream mailing list monitoring and code review + tested and sent meego VQ(R)DMULH.s16 fix upstream: http://patchwork.ozlabs.org/patch/80725/ + working on a patch to fix decoding of the preload and hint space Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 17/18 March: QEMU Users Forum, Grenoble Holiday: 22 Apr - 2 May

14 years, 5 months

1
1
0 0

[ACTIVITY] 2011-01-28

by David Gilbert

SPEC Tried to track down what was going on with lbm; it doesn't seem to be repeatable on canis1; I'd previously seen it fail at O1 and work at O0 and tried to chop down the flags between the two; but after adding all the flags back in on top of -O0 it still worked and then I tried -O1 again and it worked. Going to try on another machine, but it might be uninitialised data somewhere. Panda Our panda arrived; it's now happily nestling near our Beagles and running the 0126 headless snapshot (with 0127 hwpack). It seems fine except for rather slow USB and SD IO. Tip: Panda's do absolutely nothing (no LEDs, no serial console activity) unless you put an SD card in with the firmware on. Libffi Wrote the changes for armhf. Tested on arm, armhf, i386, ppc and s390x - all happy. (Not too unsuspectingly variadic calls just work on everything other than armhf without the api change) Mailed Python CType list asking how much of a pain the API change will be and any hints on what might be affected. Awaiting sign off for submission of code. Optimised library routines Looked at benchmarking 'git'; I'd seen previous discussions where it had been pointed out that it spends a lot of time in library routines; and indeed it does spend useful amounts in memchr, memcpy and friends on a simple git diff v2.6.36 v.2.6.37 > /dev/null of the current kernel tree produces a useful ~25second run. One interesting observation is that the variation in the times reported by 'time' - i.e. user, system and real, the variation in user+system is much less than either user or system individually and is quite stable (within ~0.7% over 10 runs). I've just tried preloading my memchr routine in and it does get a consistent 1-1.2% improvement which does look above the nice. Also asked on libc-help list for suggestions as to other benchmarks people actually trust to reflect useful performance increases in core routines as opposed to totally artificial ones. Dave

14 years, 5 months

1
0
0 0

[ACTIVITY] Jan 24 - Jan 28

by Ulrich Weigand

== GCC == * Determined root cause of #Bug 598462 (corrupted profile info with -O[23] -fprofile-use), identified work-around (using -fprofile-correction), and verified on GCC 4.5 and 4.6 == GDB == * Worked on re-implementation of fix for #615978 (Failure to software single-step into signal handler) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 5 months

1
0
0 0

[Activity] Jan 24-28

by Ramana Radhakrishnan

== GCC == * Internal ARM tasks that kept me busy for some time this week. * Reworked the divmodsi4 patch based on comments. Still some test failures that need to be investigated. * Started working on the performance improvement plan for GCC 4.5. * Number of patch reviews upstream. * Looking at A9 memset issue. . * Got an internal bug report about the 4.4 tools from someone using it which had to do with a missing backport. This is now lp:709329. Backported and testing. * Backported a missing upstream patch into GCC 4.5 for bswap patterns. * Wrote up on how to cross-test with qemu and updated that on the Linaro wiki. Comments are welcome. Plans: * Find out the default number of iterations needed for steady state with EEMBC. * Finish testing fix for lp:709329 and get that committed. * Finish off divmodsi4 patch and get it's testing completed and finished. * Submit backport for bswapsi at Os fix (PR44392) for gcc-linaro * Finish the plan for GCC performance improvements based on what we discussed at the sprint. * Away 2-1/2 days next week for an internal engineering conference.

14 years, 5 months

1
0
0 0

[ACTIVITY] Status 2011-01-28

by Richard Sandiford

This week ========= - On other IBM duties until today. Now finished! - Looked at the neon failures that Peter reported. I'm testing patches for the ICE and the "must be a constant" error now. - In the background, I've been trying to pin down the chromium build failure. I can only reproduce it when running under dpkg-buildpackage: if I run the link line manually, it works. This is reminiscent of a problem that Dave saw elsewhere: the linker segfaulted only when run through the normal build system. Next week ========= - Bernd Schmidt has committed our combined patch for #695302. Will backport to our sources. - Submit the neon fixes above. - More on STT_GNU_IFUNC. There are some more tests I want to write. Richard

14 years, 5 months

1
0
0 0

neon intrinsics test cases from ST

by Peter Maydell

Some news from the qemu mailing list that I think might be of interest to gcc folks here: Christophe Lyon from ST has kindly released a large set of test cases of Neon intrinsics: http://gitorious.org/arm-neon-tests/arm-neon-tests (the tests themselves are more aimed at testing qemu, so they just produce output to be compared against a reference generated from running on hardware). However they don't currently compile with gcc (but are ok with armcc). From the README: # The tests currently fail to build with GCC/ARM: # - no support for Neon_Overflow/fpsrc register # - ICE when compiling ref_vldX.c, ref_vldX_lane.c, ref_vstX_lane.c # - fails to compile vst1_lane.c # - missing include files: dspfns.h, armdsp.h Maybe it's worth somebody having a look at this, at least enough to find out whether the ICEs are things we already know about or have perhaps already fixed in linaro gcc? thanks -- PMM

14 years, 5 months

5
4
0 0

[ACTIVITY] January 23-27

by Ira Rosen

Hi, I am working on implementation of interleave_high/low and extract_even/odd for NEON. The pairs of high/low (even/odd) are "magically" united into single vzip (vuzp) instruction in the back end, so there is no need in special support from the tree level. There are still some test failures that I need to solve. Ira

14 years, 5 months

2
2
0 0

Cross testing using qemu.

by Ramana Radhakrishnan

Hi, I've written up a wiki page finally on the cross-testing with qemu here. It's taken me slightly longer than expected as I was playing around with moin-moin syntax. These are based on qemu-0.13.0 which is what I tried when I wrote this up for some testing of a patch that I was playing with. https://wiki.linaro.org/WorkingGroups/ToolChain/CrossTestingQemu Comments are welcome . Ramana

14 years, 5 months

2
2
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * I looked into the perf utility with regard to ARMv7 and raw event support * https://wiki.linaro.org/KenWerner/Sandbox/perf * testsuite fixes for the OpenCL GDB * started to setup the pandaboard (currently the headless snapshot hangs shortly after I got the bash prompt - I'm not sure what's going on here) * On Friday I'll attend a class. Regards Ken

14 years, 5 months

1
0
0 0

[ACTIVITY] January 23-27

by Revital1 Eres

Hello, * Submitted to mainline the patch to model Doloop for ARM (http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01718.html) . The ARM back-end part was reviews by Richard Earnshaw. * Looking into EEMBC/DENbench for opportunities applying Modulo-Scheduling. Based on partial profiling information there are SMSed hot loops. My next step is to generate complete profiling information (including gcov info) and execute the benchmarks on ARM machine. Thanks, Revital

14 years, 5 months

1
0
0 0

Re: Neon Support in kernel

by Dave Martin

Hi Vijay, On Sat, Jan 22, 2011 at 9:59 AM, Vijay Kilari <vijay.kilari(a)gmail.com> wrote: > Hello Dave, > > Thanks for this info. > > I have few more queries after looking at the results of memset on A9 & A8. > I agree that externel bus speed matters in comparision across platforms. > > 1) Why memset is performance is good on A8 than A9?. any justification? I've CC'd the linaro-toolchain list who have been working on this topic and may be able to provide you with more information. Cheers ---Dave

14 years, 5 months

3
2
0 0

2011.01 release failure writeup

by Michael Hope

Hi there. I've had a think and done a write-up on the causes behind the 2011.01 release failure and what should be changed. See: https://wiki.linaro.org/WorkingGroups/ToolChain/Incidents/2011.01-X86_64 The changes involve being more explicit in the release process document and changing the continuous build to give earlier warning. Comments are appreciated. -- Michael

14 years, 5 months

1
0
0 0

Testing a GCC patch for ARM

by Revital1 Eres

Hello, I have a patch for ARM that I want to test and I'm not sure what's the procedure of testing in Linaro nor to where it should be committed. (GCC trunk? it's currently under bug fixes mode only). I appreciate help with that. Thanks, Revital

14 years, 5 months

2
3
0 0

Bug fixes for -Os issues in GCC 4.5.x in Linaro?

by Wolfgang Denk

Hello, could you please provide some comments about the state of "-Os" (optimising for size) in the gcc 4.5.x versions of Linaro's tool chain? It appears there are a number of issues with recent versions of GCC that get triggered when optimising for size, for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45052 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44392 Some other projects like the Linux Foundation driven Poky (resp. Yocto project) capitulated and stopped using -Os, see for example here: http://thread.gmane.org/gmane.linux.embedded.poky/2311/focus=2565 On the other hand, I can see that Linaro even adds improvements for "-Os", see for example here: http://thread.gmane.org/gmane.linux.linaro.toolchain/367 So I wonder what the state of these problems with "-Os" is in the Linaro tool chain? Have these issues been solved, and is "-Os" reliably working with the Linaro tool chain? Thanks in advance. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de The optimum committee has no members. - Norman Augustine

14 years, 5 months

4
3
0 0

toolchain calls moving to new call number?

by Peter Maydell

I assume we're moving the toolchain calls over to the new confcall numbers -- but just to check, are we doing so for this Wednesday's status call? The calendar entry still has the old numbers... -- PMM

14 years, 5 months

2
1
0 0

[Activity] Jan 10-21 2011

by Ramana Radhakrishnan

==GCC== Progress: * Got invited to the Toolchain WG and was at the sprint in Dallas. * Worked on fixing inconsistencies in the A9 scheduler. Now fixed up upstream and submitted merge request for that. * Introduced to other members of the Toolchain WG and had conversations with everyone about what was going on within the Toolchain WG. * Spent some time trying to set up a Pandaboard that I borrowed (Thanks Wookey) but the Panda didn't work. Turns out both the SD cards were broken and or the versions of the boot loader / firmware were broken. * Worked through the patch list with Andrew trying to understand the patches that exist in the backend for the delta between gcc-linaro and upstream. * Did some patch review upstream to help ease the backlog. * Flushed some patches out from my patch queue upstream. * Fixed the scheduler issue upstream and submitted a merge request for it in linaro gcc-4.5 since it really fixes the A9 scheduler. * Some ARM internal tasks with respect to transition into Linaro. * Worked on the divmodsi4 issue and testing my patch with trunk. Pushed my branch into launchpad if someone wants to see the code. Does the right thing for the case we want but won't help with the SPEC2k case really because that's a case with Os. But a good size improvement anyhow and something that will help with divmod cases with 2 variables rather than where a constant is used. * Set up a natty chroot on one of our ve2 boxes which is now running a bootstrap for all languages we are interested in and collecting test results from trunk upstream. * Worked through the new starter guide and still have an issue with accessing wiki.linaro.org Absences: February 1-3:ARM Internal engineering conference.

14 years, 5 months

1
0
0 0

[ACTIVITY] Jan 17 - Jan 21

by Ulrich Weigand

== GCC == * Analyzed root cause of #685352 (libplymouth2_0.8.2-2ubuntu6 and later give ragged splash and text rendering), opened mainline bugzilla PR rtl-optimization/47299 * Submitted backport merge request for the #685352 fix * Successfully completed profiled-bootstrap run on ARM * Investigated profiled pyhton package build problems == GDB == * Forward-ported GDB patch to support ARM hardware watchpoints * Determined root cause of #615978 (Failure to software single-step into signal handler), started discussion of proposed fix * Miscellaneous Launchpad bug maintenance Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 5 months

1
0
0 0

[ACTIVITY] 2011-01-21

by David Gilbert

=A9 Qemu= I've spent most of the week looking at QEmu emulation of SMP A9. The model (of a realview-pbx-a9) doesn't have any working block IO; I spent some time looking at trying to get SD working and got part way, but I fell back to using NFS root. It seems to work OK for basic CPU emulation, and SMP 'works' in the sense that the guest sees multiple CPUs; however QEmu is restricted to only using one host CPU core for multiple guest CPUs, so it's of limited help in debugging SMP code. Video doesn't seem to work either. To get to that point it does need a bunch of patches to QEmu, most of which Peter Maydell already knows of; I've put some notes here : https://wiki.linaro.org/Internal/People/DaveGilbert/QEMUA9SMP Note that the realview-pbx doesn't currently have a Linaro hardware pack; I used a kernel from ARMs website and a 2.6.37 I built myself. =SPEC= SPEC ref got quite a far way through on Canis (with half-duplex ether), however 'lbm' failed when running in ref mode (while having worked in test and train) giving a different output; it takes quite a long time to fail. = Perf = I sent an updated version of my patch for perf's thumb annotation upstream. and apparently we have a Panda on the way. Dave

14 years, 5 months

1
0
0 0

[ACTIVITY] report week 03

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | handed off | first qemu-linaro release | 2011-01-11 | 2011-01-11 | | Historical Milestones: finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | * submitted meego patch upstream to print instruction boundaries in TCG op-level debug dumps: http://patchwork.ozlabs.org/patch/79298/ * reviewed a couple of patches by Christophe Lyon from ST which fix some problems with VMULL and friends (together with a qemu-meego patch in the same area) * lots of rebasing work to get a qemu-linaro tree into shape. Mostly putting together my exploded set of ARM patches from the meego tree with a rebased set of omap patches. I have something which I think is about right but I need to test it. * patches submitted to qemu upstream: + add -version option to qemu-user: http://patchwork.ozlabs.org/patch/79635/ + fix writing default vector address in PL190: http://patchwork.ozlabs.org/patch/79712/ + print instruction boundaries in TCG op-level debug dumps: http://patchwork.ozlabs.org/patch/79298/ Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 17/18 March: QEMU Users Forum, Grenoble Holiday: 22 Apr - 2 May

14 years, 5 months

1
0
0 0

A play with benchmarks

by Michael Hope

I had a few spare cycles this afternoon on my A9 board so I got it to build and run 72 variants of CoreMark with the 2011.01 compiler. The results are here: https://wiki.linaro.org/MichaelHope/Sandbox/CoreMark1 I haven't looked deeply into it and the usual disclaimer about benchmarks applies, but there's some interesting stuff there. The ARM to Thumb-2 drop is more than expected. Tuning for Cortex-A9 generally makes things worse. -- Michael

14 years, 5 months

1
0
0 0

ARMv7-a / Thumb2 etc.

by Ramana Radhakrishnan

Hi, One of the things that came up in yesterday's chat was about ARM vs Thumb2. If some folks are interested in a high level overview that doesn't go into too many details with respect to the ISA that I know a compiler writer will be interested in you could read this presentation unless you've seen it. At the minute the canonical way of figuring out more about Thumb2 is really to read the ARM-ARM. https://wiki.ubuntu.com/Specs/M/ARMGeneralArchitectureOverview?action=Attac… This was a presentation that Dave Rusling gave at the UDS in Belgium last year, it roughly covers the architecture at a high level and talks about Thumb2 vs ARM , why Thumb2 , the evolution of the ARM architecture etc. It's not a lot of detail but quite a high level overview. HTH cheers Ramana

14 years, 5 months

1
0
0 0

[ACTIVITY] January 16-20

by Ira Rosen

Hi, * finished SLP for reduction patch. The loop in DenBench that needs this feature also requires support of load permutation. I am considering to implement that too. I looked for other occasions that need this feature, but only found loops that are not vectorizable. So, I am not sure I'll proceed in this direction. * looked into extract_even/odd and interleave_high/low implementation on ARM as a backup plan for the case we don't have special load/store support on time for the next release. Even though NEON VZIP and VUZP instructions can perform both even and odd (and high and low) computations simultaneously, I don't see how we can express that at the tree level. * looking into ffmpeg * non-Linaro issues Ira

14 years, 5 months

1
0
0 0

Backporting a patch from upstream and bzr workflows.

by Ramana Radhakrishnan

Hi , So rather than manually backporting a patch from upstream "trunk" I decided to try using bzr for this yesterday. Even though this was a slow process and thanks to some help from Michael on IRC last night I think I got it right finally. However I can't get bzr visualize to show me the revision history correctly with the merge from the upstream repository. So what I did was to do the following bzr branch 4.5 new-branch cd new-branch bzr merge -c XXX lp:gcc where XXX is the bzr revision number of the svn commit that I'm tracking upstream. gcc/Changelog merge fails - there is a conflict. Expected because you are merging trunk's gcc/Changelog into a version of the Changelog file in our tree Thus I reverted changes that were brought in by copying in a backup of gcc/Changelog that I had made before the merge bzr resolved gcc/Changelog edit Changelog.linaro Add changelog entry bzr commit bzr push lp:gcc private repository Create merge request upstream. Does this look sensible to people or do folks follow other recipes? cheers Ramana

14 years, 5 months

1
0
0 0

Fwd: RE: [RFC][PATCH] ARM: ptrace: remove single-step emulation code

by Loïc Minier

Hey I think we need to keep an eye on this and be ready to check ltrace if this gets merged Cheers -- Loïc Minier

14 years, 5 months

3
4
0 0

Monday's meeting

by Michael Hope

Hi there. I've cancelled Monday's meeting as the CodeSourcery people are at their annual meeting and others are travelling back from the sprint. Please come to the Wednesday stand up call if you are available. -- Michael

14 years, 5 months

1
0
0 0

[ACTIVITY] 2011-01-14

by David Gilbert

Got a complete run of SPEC Train on Orion board - all working. Kicked off a SPEC ref run - canis1 died. Gathered a full set of 'perf record's for all of SPEC on silverbell; and had a quick look through them; there aren't too many surprises; a few things that might be worth a look at though. (Not as much using libc functions as I hoped). There are some odd bits - chunks of samples landing apparently outside libraries that aren't obvious what's going on. Sent tentative patch for Thumb perf annotate issue (bug 677547) to lkml for comments. Started on libffi variadic fixing. Caught the qemu pbx-a9 testing from PM; got qemu built and getting a handful of lines of output both from a kernel from arm.com's site and a linaro-2.6.37 that I built for it. Dave

14 years, 5 months

1
0
0 0

[ACTIVITY] report week 02

by Peter Maydell

RAG: Red: Amber: Green: issues I wanted to nail at this sprint all handled; a couple of blueprints handed off to other people Milestones: | Planned | Estimate | Actual | finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | | At the Linaro/Ubuntu sprint/rally in Dallas this week * qemu-continuous-integration ** spoke to Paul Larson (in Linaro Validation team) and handed this blueprint off to him (with a clarification of the requirements from qemu's point of view) * maintain-beagle-models ** we've agreed to start doing official "Linaro Qemu" releases which are essentially going to be the meego tree plus point fixes for things. These will be every month with the rest of the toolchain group releases. Ubuntu will also take these releases to replace the current use of the qemu-kvm tree to provide ARM models * verify-a9-pbx-support ** this blueprint has been handed off to David Gilbert * merge-correctness-fixes ** wrote and posted patches: *** to restore IT bits after unexpected exceptions (including fix of Linux usermode bug where it wasn't clearing the IT bits when entering a signal handler) *** to include opcode hex in disassembly of ARM insns *** fixing a compile failure for a previous change when the host linux system didn't have linux/fiemap.h ** I have managed to split the huge "lots of ARM TCG fixes" commit in the meego tree up into 65 more self-contained commits. These now need reordering and possibly some may be recombined. Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Absences: 2011: Holiday 21 Jan, 22 Apr - 2 May.

14 years, 5 months

1
0
0 0

x86_64 bootstrap failure in the 2011.01 release

by Michael Hope

Hi there. Unfortunately the Linaro GCC 4.5 2011.01-0 release has a failure in the x86_64 compiler causing it to fail during the initial build. We're working on triaging the problem at the moment. ARM and i386 targets are not affected. I'll send a new announcement when the problem has been fixed and the replacement 2011.01-1 release is available. -- Michael

14 years, 5 months

2
1
0 0

Linaro GCC 4.4 and 4.5 2011.01-0 released

by Andrew Stubbs

The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.4 and Linaro GCC 4.5. The Linaro Toolchain Working Group is pleased to announce the release of both Linaro GCC 4.4 and Linaro GCC 4.5. Linaro GCC 4.4 is the sixth release in the 4.4 series. Based off the latest GCC 4.4.5, it is a maintenance release that fixes one problem found through use. Linaro GCC 4.5 is the sixth release in the 4.5 series. Based off the official GCC 4.5.2 release, it includes many ARM-focused performance improvements and bug fixes. Interesting changes include: * Improved optimization of multiple load instructions, and multiply-and-accumulate. * -fshrink-wrap optimization for better use of function prologues and epilogues. * plus, various other bug fixes, and minor improvements. The source tarballs are available from: https://launchpad.net/gcc-linaro/+milestone/4.5-2011.01-0 and https://launchpad.net/gcc-linaro/+milestone/4.4-2011.01-0 Downloads are available from the Linaro GCC page on Launchpad: https://launchpad.net/gcc-linaro

14 years, 5 months

1
1
0 0

[ACTIVITY] January 9-13

by Ira Rosen

Hi, * Continued with testing and implementation of reduction support in SLP * Found a major problem in vectorization of if-converted data accesses. Looked into other ways to solve the problem. * Spent some time on non-Linaro vectorization plans * Unsuccessfully tried to make the board work Ira

14 years, 5 months

1
0
0 0

[ACTIVITY] Jan. 3rd -- Jan. 9th

by Yao Qi

== Last Week == * Displaced stepping support for 32-bit Thumb insns are done, unless new bugs are found. Decode writeback for str/ldr in Thumb 32-bit. Fix bugs in supporting LDR/STR/LDRH/STRH in both ARM and Thumb. Test GDB to handle various 32-bit Thumb insns in displaced stepping. Code cleanup and write some new test cases. * One day New Year holiday on Jan. 3rd. == This Week == * Linaro Sprint. * Get patches for Linaro GDB bugs approved on upstreams as many as possible. -- Yao Qi

14 years, 5 months

1
0
0 0

A question about instructions latencies in Crotex-A9

by Revital1 Eres

Hello, While testing SMS on Crotex-A9 I see that the latency of load instruction is 1 cycle when compiling with -mcpu=cortex-a9 -mthumb -mtune=cortex-a9 -O3. Below is a snippet from the SMS dump file showing the DDG, created for the loop in foo function, which depicts the edge between the load of input[i] (insn 181) and the mult instruction (insn 184). [181 -(T,1,0)-> 184] is the true dependence edge created between the two insns; with latency of 1. On Crotex-A8 the latency of the load is 3 as expected. I've read in crotex-a9.md file that loads should have a latency of 4 cycles so I just wanted to check if I should have used other combination of flags for Crotex-A9 or the load latency should indeed be of 1 cycle here. Thanks, Revital int foo (int max, signed short *input, int y) { int i, accum; for (i = 0; i < max; i++) { accum += (signed int) input[i] * (signed int) input[i+y]; } return accum; } The snippet from the DDG: Node num: 2 (insn 181 178 184 13 (set (reg:SI 216 [ D.2019 ]) (zero_extend:SI (mem:HI (plus:SI (reg:SI 319 [ ivtmp.34 ]) (reg:SI 345)) [2 MEM[base: D.2076_257, index: D.2079_226, offset: 0B]+0 S2 A16]))) tmp.c:7 714 {*thumb2_zero_extendhisi2_v6} (nil)) OUT ARCS: [181 -(A,0,1)-> 176] [181 -(T,1,0)-> 184] IN ARCS: [184 -(A,0,1)-> 181] [176 -(T,1,0)-> 181] Node num: 3 (insn 184 181 234 13 (set (reg/v:SI 209 [ accum ]) (plus:SI (mult:SI (sign_extend:SI (subreg/s/u:HI (reg:SI 212 [ D.2013 ]) 0)) (sign_extend:SI (subreg/s/u:HI (reg:SI 216 [ D.2019 ]) 0))) (reg/v:SI 209 [ accum ]))) tmp.c:7 64 {maddhisi4} (expr_list:REG_DEAD (reg:SI 216 [ D.2019 ]) (expr_list:REG_DEAD (reg:SI 212 [ D.2013 ]) (nil))))

14 years, 5 months

2
2
0 0

[ACTIVITY] Jan. 3 -- Jan. 9

by Zach Welch

== Last Week == * Worked to improve libunwind test suite results using new ARM-specific unwinding. Managed to reduce the number of failures, but some tests still fail. * Tested latest ltrace upstream tree and determined that It Is Good. Hopefully, this marks the cusp of a new release that includes my work. == This Week == * Finish up work with libunwind. Update wiki brain dump. -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

14 years, 5 months

1
0
0 0

[ACTIVITY] Jan.3 -- Jan.9

by Chung-Lin Tang

== Last week == * Some discussion about libffi variadic function support. The current proposed design is an additional API function to prepare a new call interface (CIF) structure with the argument number settings for each variadic call site. This IMHO, is slightly less flexible that doing a call-time placement style interface, but should be faster and easier to implement. * Collecting a few cases of ARM/Thumb-2 integration in the GCC ARM backend. * Prepared and traveled to Dallas for the Linaro sprint. == This week == * The Linaro sprint.

14 years, 5 months

1
0
0 0

[ACTIVITY] January 3rd-9th

by Julian Brown

== Linaro GCC == * Continued hacking on (cleaning up, testing) NEON element/structure load/store (etc.) intrinsics-improvement patch. This now passes all the auto-generated neon.exp tests (admittedly only a very weak test for correctness), and the small number of hand-written tests I threw at it, so hopefully we can declare victory soon. (This patch provides huge improvements to generated code for the "fancy" NEON load/store intrinsics and vtbl/vtbx lookup instructions, and hopefully also provides part of the solution for allowing the vectorizer to use the fancy loads/stores also.) == Misc == * Public holiday Monday.

14 years, 5 months

1
0
0 0

[ACTIVITY] January 4th - 9th

by Andrew Stubbs

== GCC == Pulled down new commits from upstream GCC. My test build failed due to a new cross-build configure problem. Found the problem in GCC Bugzilla, and rolled back to the revision before the problem one. Those sources built ok, so I've pushed the changes to Linaro GCC 4.6 branch. It it now updated to 31st December. Discussed cross-build problems with Alexander Sack on IRC. Merged, tested and pushed all the outstanding Launchpad merge requests into GCC 4.4 and 4.5. Merged, tested and pushed all new CS SG++ patches into Linaro GCC 4.5. Merged, tested and pushed GCC 4.5.2 from upstream into Linaro 4.5. Spun releases for both Linaro GCC 4.4 and 4.5. Brought the Linaro patch tracker up to date. == Other == Catch up with lots of email following my two week holiday. Updated some of the CS patch tracker. Travel to Dallas for the Linaro sprint. ------- Next week (10th-14th Jan): Linaro sprint in Dallas Following week (17th-21st Jan): CS annual meeting in Phoenix

14 years, 5 months

1
0
0 0

[ACTIVITY] 2011-01-07

by David Gilbert

Got h264ref working in SPEC; this was another signed-char issue (very difficult one to find - it didn't crash, it just came out with subtly the wrong result); compiling that and sphinx3 with -fsigned-char and they seem happy. With Richard's fix for gromacs that leaves just the zeusmp binary that's too large to run on silverberry; it seems to startup on canis1 (that has more RAM). So that should be a full set; I just need to get the fortran stuff going on canis1. Kicked off discussion on libffi-discuss about variadic calls; people seem OK with the idea of adding it (although unsure exactly how many things really use it - even though there are examples in Python documentation). Also kicked off some of the internal paperwork to contribute code for it. Dave

14 years, 5 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Away Monday, and a fair bit of time on non-Linaro duties. * Looked at Dave's gromacs bug (693502). Turned out to be a reload inheritance problem. Tested a patch. Spent some time coming up with a brute-force testcase that I can submit with the patch. * Found a bug in the x86 and x86_64 ifunc support that would affect ARM too if we weren't careful. Came up with an example testcase and filed the bug upstream: http://sourceware.org/bugzilla/show_bug.cgi?id=12366 It has been fixed by H.J. Lu. I'm wondering about taking a slightly different approach for ARM. * More ifunc work. * Tried again to reproduce the chrome failure, making sure to use DEB_BUILD_HARDENING=1. (I hadn't realised first time round that, in reaction to this bug, debian/rules specifically excluded armel from the automatic DEB_BUILD_HARDENING=1 setting.) The build takes a couple of days on my BeagleBoard. Heh, and just as I wrote that, the build failed with the reported link error. Neat. == Next week == * Finish testing the patch for 693502 and submit it upstream. Backport the patch to our tree once accepted. * Look at the chromium problem. * More ifunc. Richard

14 years, 5 months

1
0
0 0

[ACTIVITY] report week 01

by Peter Maydell

RAG: Red: Amber: Green: qemu git pull request accepted, patches seem to be flowing into qemu upstream more freely now Milestones: | Planned | Estimate | Actual | finish virtio-system | 2010-08-27 | postponed | | finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 | successful ARM qemu pull req | 2010-12-16 | 2010-12-16 | 2010-12-16 | finish qemu-cont-integration | 2010-01-25 | 2010-01-25 | | Bonus extended holiday edition: This report includes a number of things that happened over the Christmas holidays as well as this week (which is a short one, only 3 days). Progress: * merge-correctness-fixes: ** my git pull request for various ARM qemu patches was merged! ** a number of other patches were merged to qemu master: + implement correct NaN propagation rules + rename softfloat float*_is_nan() functions + fix UMAAL (Aurelien's patch, reviewed by me) + VQSHL (reg) patchset ** diagnosed the segfault in https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/604872 and wrote a patchset which fixes it (and related problems): http://patchwork.ozlabs.org/patch/77887/ (n/7) ** wrote and posted a patchset which implements save/restore for the versatile platform (so I didn't have to wait 10 minutes for the test case to reach the segfault) http://patchwork.ozlabs.org/patch/76529/ ** finished and posted a patchset implementing flushing of denormals to zero on input: http://patchwork.ozlabs.org/patch/77798/ (n/3), now committed ** reviewed/tested Aurelien's SMMLA/SMMLS patch (now committed) ** wrote and posted patches which implement the FS_IOC_FIEMAP ioctl (http://patchwork.ozlabs.org/patch/77725/) and the file_sync_range{,2} syscalls (http://patchwork.ozlabs.org/patch/77723/) -- these are used by apt, and so linaro-media-create was generating a lot of warnings from qemu about their lack of implementation ** posted patch to clean up NaN handling in linux-user NWFPE emulation (follow-on from earlier NaN cleanups): http://patchwork.ozlabs.org/patch/77795/ * maintain-beagle-models: ** implemented minimal ARM cp14 debug registers and a random register in the TWL4030 emulation (both needed to get recent Linaro kernels to boot on the beagle model) Submitted merge request upstream: http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/3 Current qemu patch status is tracked here: https://wiki.linaro.org/PeterMaydell/QemuPatchStatus Meetings: toolchain standup, pdsw doughnuts Absences: 2011: Dallas Linaro sprint 9-15 Jan. Holiday 21 Jan, 22 Apr - 2 May.

14 years, 5 months

1
0
0 0

[ACTIVITY] January 2-6

by Ira Rosen

Hi, * implemented reduction support in SLP, I'll check if it helps DenBench next week * helping Sebastian Pop with if-conversion for vectorization improvements (BTW, Sebastian's goal is to vectorize kernels from ffmpeg) * fixed GCC PR47139 Ira

14 years, 5 months

1
0
0 0

GCC Optimizations call minutes

by Andrew Stubbs

Hi All, Thanks for attending the call. I think we had some interesting discussions. I've posted the minutes from the call on the same page as before: https://wiki.linaro.org/AndrewStubbs/Sandbox/GCCoptimizations I'll try to get the audio posted somewhere for anybody that's interested. Andrew

14 years, 5 months

2
1
0 0

GCC 4.6 BZR branch

by Andrew Stubbs

You may have noticed that I have created a new BZR/Launchpad branch for Linaro GCC 4.6: lp:gcc-linaro/4.6 https://code.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6 Up until now, this has not been buildable due to unfixed bugs. However, upstream GCC have now straightened out the problems, so I have pushed a buildable version into the branch. I shall attempt to keep this branch as up-to-date as I can (at least, I will once the holiday season and January travel are over), but I'll only push updates if they build for me, so hopefully the branch should remain fairly stable, at least for our purposes. Note that so far I've only tested build-ability. Right now I'm not making any promises about the quality of the compiler. At some point, we'll want to use this branch to hold our own patches (both those that will never go upstream, and those that are queued for GCC 4.7), so it will diverge from upstream 4.6 a bit. For the moment, it's merely a mirror. Andrew

14 years, 5 months

3
4
0 0

[ACTIVITY] Dec. 27 -- Jan. 2

by Zach Welch

== Last Week == * Got a new ARM-specific unwind test case working, so its integration with libunwind stands a marginally better chance of working (once it's finally finished). * Sent a ping to binutils mailing list about a patch to improve readelf that I had sent in at the beginning of December. Still no response. * Holidays and Vacation == This Week == * Try to finish libunwind integration, as my time with Linaro is nearly over. Update documentation on wiki to reflect current status. * Ping ltrace list about a new release. It seemed so close, then the list went abruptly silent. -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

14 years, 5 months

1
0
0 0

[ACTIVITY] December 13th-January 4th

by Julian Brown

== Linaro GCC == * Continued looking at element/structure load/store intrinsics improvements. Some good initial results: it looks like the plan of using "extra-wide" vectors for returning struct results works fine (at least to a first approximation). Sent off WIP patch (internally to CS only, so far). Incidentally this looks like it'll be a good stepping-stone for the "RTL half" (vs. the "tree half") of the representation of element/structure loads/stores (e.g. vld2/vst2) also. The return type (for loads) and argument type (for stores) of the RTL patterns for such instructions is changed from the current wide-integer representation (OImode, etc.) to a suitable wide vector instead (e.g. V16QImode). This change might help lead to a more meaningful mapping from an equivalent tree form -- though we haven't quite got the whole picture yet, as the middle-end won't want to know about the ARM-specific and non-standard-named patterns for the element/structure loads/stores. (One might imagine a new standard-named RTL expander taking care of that though.) == Vacation == * Vacation Dec 20th-Jan 4th.

14 years, 5 months

1
0
0 0

[ACTIVITY] Dec.27 -- Jan.02

by Chung-Lin Tang

== GCC issues == * PR44557, Thumb-1 ICE, looked at the ARM specific secondary reload parts, as well as some general reload internals context. Concluded that concerns on Thumb-2 about my submitted patch should be unneeded, as the reload_in/out patterns should never be used for Thumb-2. Also looked a bit on how we should upgrade ARM to use TARGET_SECONDARY_RELOAD. * PR45416, ARM code regression. Started working on this again, cleaning up patch to submit. * Had some email discussion with Revital Eres on Swing Modulo Scheduling (SMS) for ARM issues, mainly on how the doloop_end pattern should be done on ARM. * Submitted and committed an obvious small patch for a VFP testsuite case. == This week == * Continue on GCC issues. * Flying to Dallas on Sunday, prepare for trip.

14 years, 5 months

1
0
0 0

[ACTIVITY] December 26-30

by Ira Rosen

Hi, * continued with my attempts to vectorize Viterbi: - finished implementation of conditional store sinking in cselim pass (I did only limited testing). - reconsidered the idea of safe load if-conversion if an adjacent field of the same structure is accessed unconditionally - this may be incorrect. Instead I tried the last, not yet committed, patch by Sebastian Pop that implements if-conversion for such cases of not-safe data accesses. His patch if-converts the loop in Viterbi, however, it also makes the loop not vectorizable - additional work should be done in the data-refs analysis and the vectorizer to make it work. Sebastian is working on the first part, and I'll help him with the vectorizer part if necessary. * analyzed EEMBC DenBench, couldn't find any action items for now. But vld/vst support of strided data accesses should be very useful for these benchmarks. * fixed GCC PR testsuite/47057 * looking into SLP of reduction as in PR 41881. I saw similar patterns several times in DenBench, but I'm not sure that SLP of reduction is enough to vectorize all of these cases. Happy New Year, Ira

14 years, 6 months

1
0
0 0

[ACTIVITY] Dec. 20 -- Dec. 26

by Zach Welch

== Last Week == * Continue with libunwind. Wrote a new unit test for ARM-specific unwinding code to help debug that new code's problems. Almost got it working, which I hope means its integration with libunwind may be nearing completion. == This Week == * Try to finish ARM-specific improvements to libunwind. Famous Last Words. -- Zach Welch CodeSourcery zwelch(a)codesourcery.com (650) 331-3385 x743

14 years, 6 months

1
0
0 0

[ACTIVITY] Dec.20 -- Dec.26

by Chung-Lin Tang

== GCC related == * Launchpad #693686, GCC ARM segfault ICE when building Chromium in V8. Spent some time reproducing; this ICE seems to be in the maverick gcc-4.5, at the vectorizer phase. As the ICE happens in tree-vect-stmts.c:supportable_widening_operation(), I'm suspecting (without further verification yet) this might be due to vmovn not backported? (Linaro 4.5 does has this ported I think) * PR44557, Thumb-1 ICE. Looking further after seeing Richard Earnshaw's comment on my patch. It would be nice if we could upgrade the entire secondary reload bits, looking into this. == This week == * Look into more GCC issues. * Get some backports done.

14 years, 6 months

1
0
0 0

[ACTIVITY] Status Dec. 20th -- Dec. 26th

by Yao Qi

== Linaro GDB == * LP:615972 Get patch approved upstreams. Committed to FSF tree. Propose merge request to Linaro GDB tree. * LP:616003 gdb.mi/mi-var-display.exp failure Discussed in upstreams on how to handle fp in ARM/Thumb mode. Finally work out a one-line patch. Approved and committed to FSF tree. Propose merge request to Linaro GDB tree. Draft another patch to clean up ARM register alias. Pending on upstreams. * LP:616000 Handle -fstack-protector prologue code Revise patch per Joel's comments. Approved, and committed to FSF tree. Draft two patches to handle -fstack-protector prologue code on i386. Sent them out for review. Due to lack of knowledge on i386 prologue generate, not very confident on one of these patches. * LP:615980 Support displaced stepping on Thumb Get my test case to arm displaced stepping approved, and committed to FSF tree. A patch about supporting displace ARM insn in Thumb area is pending upstreams. Tried the 2nd approach since the 1st approach is not acceptable to upstreams reviewers. Without this patch, ARM displaced stepping doesn't work on Linaro. Support another three PC-related 16-bit Thumb insns (adr, ldr, and cbz), and add test cases for them accordingly. Spend some time splitting my big patch into three relatively small patches in order to make them easier to be reviewed. Patches on supporting Thumb 16-bit displaced stepping are sent out upstreams for review. == This Week == * Work from Mon. to Wed. ** Backport some approved upstreams patches to Linaro GDB ** Anything I should do for my pending patches. * Vacation on Thu. and Fri. 3rd Jan. is China public holiday. Back to work on 4th. Jan. -- Yao (齐尧)

14 years, 6 months

1
0
0 0

Re: Linaro gcc ICE bug

by Ulrich Weigand

Khem Raj <raj.khem(a)gmail.com> wrote: > The bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 files > against GCC trunk also happens with linaro gcc 4.5 > My guess is that there is a backported patch from trunk into linaro > 4.5 tree thats causing this ICE > > This ICE does not happen on upstream gcc-4.5 branch Thanks for the bug report! > I havent figured out the commit yet. It looks like the regression was introduced by Bernd Schmidt's patch to improve zero-/sign-extensions (PR 42172), which we did indeed backport to Linaro GCC 4.5. (I've updated the PR 46883 bugzilla with more details.) > Should you need a bug in linaro > bug tracker I will be happy to file one Yes, please do so; this makes it easier to track the problem on the Linaro side. Thanks! Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 6 months

2
1
0 0

[ACTIVITY] Dec 20 - Dec 23

by Ulrich Weigand

== GCC == * Checked in mainline fix for #617384 and submitted backport merge requests (.debug_line is wrong with -fpic) * Submitted backport merge requests for the fix for #662324 (Pointer type information lost in 4.5 debuginfo) * Checked in mainline fix for #693425 and submitted backport merge request (SPU back-end incompatible with extension elimination pass) Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

14 years, 6 months

1
0
0 0

[ACTIVITY] December 20-23

by Ira Rosen

Hi, I was on vacation on Sunday and starting from Tuesday stayed home with a sick child, so I only had a couple of days to work. * vectorization of Viterbi: - continued implementing conditional store sinking in cselim pass - made if-conversion to work on loads of structure fields if other field from the same structure is accessed unconditionally * fixed GCC PR 47001. Ira

14 years, 6 months

1
0
0 0

[ACTIVITY] 2010-12-23

by David Gilbert

Continued looking at SPEC 2006. The two ICEs I mentioned last week are gone on the Natty version of the compiler, however the 4 programs that run and give the wrong results still happen with the Natty version and the latest version from bzr. The 4 failures are: h264ref - still fails on bzr 99447 with -O2 or -O0 sphinx3 - still fails on bzr 99447 with -O2 or -O0 gromacs - still fails on bzr 99447 with -O2 but works with -O1; I've followed this through and detailed it in bug 693502; it looks to me like a post-increment gone wrong (it's split so it's not actually a post increment and the original rather than post inc'd value gets used) zeusmp - this fails to load the binary; it's got a >1GB bss section. Interestingly it gets further on my beagle with less memory but a bit of swap, even though I think it's not really using all of the BSS in the config I'm using. I'm hoping to leave a 'ref' run going over the new year. The canis1 Orion board I was also running Spec on last weekend died during the run and hasn't come back. perf We now have silverberry using the -proposed kernel which has the fixed PERF_EVENT config, and perf seems to work fine. libffi I've started building the page https://wiki.linaro.org/WorkingGroups/ToolChain/FFIusers listing things that use FFI; (generated by a bit of apt wrangling). There are basically 3 sets: a) Apps that just use ffi for something specific b) Languages that then let the users of those languages have varying degrees of freedom in themselves c) Haskell - While some of the packages are actually probably ffi users, I think a lot of these are false dependencies; almost every haskell user seems to gain a dependency on libffi directly. I'm back on the 4th January. Dave

14 years, 6 months

1
0
0 0

[ACTIVITY] December 12 - 16

by Ira Rosen

Hi, I continued looking into EEMBC benchmarks: - telecom fft is not vectorized because unknown number of iterations. It has both non-constant step and its loop bound may overflow. I think, the solution here could be loop versioning, but since versioning increases code size, this kind of optimization can be less beneficial. - telecom viterbi (vectorization potential gain is 4x) requires conditional store sinking and load hoisting to enable if-conversion. I worked on implementation of store sinking this week. Ira

14 years, 6 months

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain