- linaro-toolchain - lists.linaro.org

by Revital1 Eres

Hello, Experiment with aes benchmark from DENbench. Continue my experiments with SMS which includes re-implementing an old patch to insert reg-moves in free slots rather than greedily before the definition as is done in the current implementation. Thanks, Revital

14 years, 7 months

1
0
0 0

[ACTIVITY] March 13-17

by Ira Rosen

Hi, * submitted store sinking patch to mainline * started testing auto-detection of vector size patch * DENBench - some benchmarks are still unstable, I am looking into stable regressions, adjusting and fixing the cost model for them Next week: Sunday and Monday - holidays Ira

14 years, 7 months

1
0
0 0

Versatile Express write-up

by Michael Hope

Here's a end-of-cycle write up for Versatile Express support in QEMU: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMUVersatileExpress Most of it is taken from Peter's page: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress which is the place to go if you want the current state and more detail on the steps involved. While writing this up I had a seamless experience from the first linaro-image-create until seeing the alpha3 greeter come up and wobbling the mouse around. It was awesome. Some ideas for other write-ups at: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs -- Michael

14 years, 7 months

1
0
0 0

RealView PBX write-up

by Michael Hope

Dave did an investigation earlier in the year into Cortex-A9 and RealView PBX support in QEMU. The write-up is available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMURealViewPBX Dave and Peter: could you please review it? I've now closed out the blueprint. I'd like to do similar reports on other outputs and will attack vexpress next. -- Michael

14 years, 7 months

1
0
0 0

Work-item tracking for the "gcc-linaro-tracking" LP project

by Ulrich Weigand

Hi Michael, Andrew, Mounir just pointed out that our non-Ubuntu LP projects (like gcc-linaro, gdb-linaro etc.) are now also included in the LP work-item tracking statistics (http://status.linaro.org/linaro-toolchain-wg.html). This didn't happen in the past due to a Launchpad issue that has now been fixed. This seems to be working out nicely, except for one issue: what about the gcc-linaro-tracking project? I have a couple of bugs that are fixed in Linaro GCC, and are also fixed in mainline GCC, but they still show up as an "in-progress" work-item in the status tracker (there are a whole bunch more of those assigned to Andrew as well). The reason for this is the LP records have an associated gcc-linaro-toolchain project entry, and this is set to "Fix Committed", but not "Fix Released" ... probably because GCC 4.6.0 is not yet released? Now, on the one hand it does make sense to include the -tracking project in the work-item statistics, because they *do* reflect important tasks: namely, to make sure that the changes indeed land in the upstream repository. However, having them all show up as "in progress" until the community makes a new GCC release does not seem very helpful: this is not in our control, and our work is in fact done once the patch is committed upstream. Therefore my suggestion: we should immediately mark -tracking bugs as "Fix Released" (not "Fix Committed"), as soon as the corresponding patch is committed upstream (and thus our work on the problem is completed). Thoughts? Does this make sense? Will this mess up any of the other purposes for which we currently use the -tracking project? 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, 7 months

5
9
0 0

cortex-strings benchmarks

by Michael Hope

Hi Dave. I had a little play with cortex-strings and did some benchmarks on my Tegra 2. Images are attached. I've added two scripts to cortex-strings: scripts/bench-all.sh runs all the routines on all variants and records them scripts/plot.py plots the results from above ploy.py corrects for the benchmark overhead by doing a linear fit to the null 'bounce' results and subtracting this fit. You should be able to a autogen; configure; make; bash scripts/bench-all.sh | tee log.txt; python scripts/plot.py log.txt. I'm sure you have your own favourite tools though. The string routines look good. Lumpy in funny ways though... -- Michael

14 years, 7 months

1
0
0 0

Fwd: Representing interleaving and lane load/stores at the tree level

by Richard Sandiford

[Sorry, forgot to CC: the list] Hi Ira, Thanks for the feedback. On 6 March 2011 09:20, Ira Rosen <IRAR(a)il.ibm.com> wrote: > > So how about the following functions? (Forgive the pascally syntax.) > > > > __builtin_load_lanes (REF : array N*M of X) > > returns array N of vector M of X > > maps to vldN > > in practice, the result would be used in assignments of the form: > > vectorX = ARRAY_REF <result, X> > > > > __builtin_store_lanes (VECTORS : array N of vector M of X) > > returns array N*M of X > > maps to vstN > > in practice, the argument would be populated by assignments ofthe > form: > > vectorX = ARRAY_REF <result, X> > > > > __builtin_load_lane (REF : array N of X, > > VECTORS : array N of vector M of X, > > LANE : integer) > > returns array N of vector M of X > > maps to vldN_lane > > > > __builtin_store_lane (VECTORS : array N of vector M of X, > > LANE : integer) > > returns array N of X > > maps to vstN_lane > > > > How do you distinguish between "multiple structures" and "single structure > to all lanes"? Sorry, I'm not sure I understand the question. Could you give a couple of examples? The idea is that the arrays above really are array types, regardless of the actual type of the thing we're accessing (which might be a larger array than the bounds above say, or which might be an array of structures or a structure of arrays). That should be OK because arrays alias their elements. Richard

14 years, 7 months

3
3
0 0

Linaro GDB patch for natty

by Ulrich Weigand

Hi Matthias, in last week's meeting you raised the question what, if any, code from the Linaro GDB repository could be useful for inclusion into the natty GDB package. I've now reviewed the contents of the repository, and my suggestion would be to use everything in Linaro GDB 7.2, except for this commit (which changes the branding to "Linaro GDB"): revno: 32969 committer: Ulrich Weigand <uweigand(a)de.ibm.com> branch nick: 7.2 timestamp: Wed 2010-09-22 19:18:38 +0200 message: 2010-09-22 Ulrich Weigand <uweigand(a)de.ibm.com> * src-release: Support gdb-linaro packages. gdb/ * version.in: Set to Linaro GDB version number. * configure.ac (PKGVERSION, BUGURL): Refer to Linaro. * configure: Regenerate. gdb/gdbserver/ * configure.ac (PKGVERSION, BUGURL): Refer to Linaro. * configure: Regenerate. gdb/doc/ * configure.ac (PKGVERSION, BUGURL): Refer to Linaro. * configure: Regenerate. (Instead, the branding ought to be set as appropriate for the Ubuntu package. Maybe with an additional reference to Linaro, just as with GCC?) I've created a snapshot of the Linaro GDB 7.2 branch using the command bzr diff --prefix a/:b/ -r32965.. and then manually removed changes to src-release gdb/version.in gdb/configure.ac gdb/configure gdb/gdbserver/configure.ac gdb/gdbserver/configure gdb/doc/configure.ac gdb/doc/configure I've left in the new file ChangeLog.linaro for documentation purposes, but if you prefer this could of course be removed as well. The resulting patch is appended here. (Note that I'd recommend to continue updating the patch from Linaro GDB as further changes make it in.) (See attached file: linaro-gdb.patch) I've then added the patch to the natty GDB package. Since it touches a completely distinct set of files compared to the existing list of patches in the package, it can be added to the series file at any arbitrary point. I've built the resulting compiler on i386, arm, and ppc64, and it strictly improved the test results on all three platforms: i386 without patch: # of expected passes 16161 # of unexpected failures 114 # of expected failures 72 # of untested testcases 9 # of unresolved testcases 1 # of unsupported tests 69 i386 with patch: # of expected passes 16331 # of unexpected failures 24 # of expected failures 72 # of untested testcases 9 # of unresolved testcases 1 # of unsupported tests 69 Fixed test case failures are from: gdb.base/break-interp.exp gdb.base/foll-fork.exp gdb.base/printcmds.exp (These are just test suite cleanups, no actual code changes.) ppc without patch: # of expected passes 15350 # of unexpected failures 74 # of expected failures 53 # of untested testcases 15 # of unresolved testcases 1 # of unsupported tests 63 ppc with patch: # of expected passes 15350 # of unexpected failures 55 # of expected failures 53 # of untested testcases 15 # of unresolved testcases 1 # of unsupported tests 63 Fixed test case failures are from: gdb.base/printcmds.exp gdb.threads/local-watch-wrong-thread.exp gdb.threads/watchthreads.exp (These are just test suite cleanups, no actual code changes.) arm without patch: # of expected passes 15343 # of unexpected failures 270 # of unexpected successes 1 # of expected failures 65 # of untested testcases 11 # of unresolved testcases 2 # of unsupported tests 70 arm with patch: # of expected passes 15686 # of unexpected failures 46 # of unexpected successes 3 # of expected failures 63 # of untested testcases 11 # of unresolved testcases 1 # of unsupported tests 69 Fixed test case failures are from: gdb.base/break-interp.exp gdb.base/corefile.exp gdb.base/foll-fork.exp gdb.base/gcore.exp gdb.base/gdb1555.exp gdb.base/pr11022.exp gdb.base/printcmds.exp gdb.base/recurse.exp gdb.base/relativedebug.exp gdb.base/step-test.exp gdb.base/watch-cond.exp gdb.base/watch-read.exp gdb.base/watch_thread_num.exp gdb.base/watch-vfork.exp gdb.gdb/selftest.exp gdb.mi/gdb792.exp gdb.mi/mi2-syn-frame.exp gdb.mi/mi2-var-display.exp gdb.mi/mi2-watch.exp gdb.mi/mi-syn-frame.exp gdb.mi/mi-var-display.exp gdb.mi/mi-watch.exp gdb.pie/corefile.exp gdb.server/ext-attach.exp gdb.threads/attachstop-mt.exp gdb.threads/attach-stopped.exp gdb.threads/linux-dp.exp gdb.threads/local-watch-wrong-thread.exp gdb.threads/pthread_cond_wait.exp (This represents much of the bug fix work that went into Linaro GDB.) Let me know if there's any further information you need, or anything else I can do to help get the Linaro changes into natty GDB. 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, 7 months

1
0
0 0

[ACTIVITY] 7th - 13th March

by Andrew Stubbs

Merged fixes for several bug into Linaro GCC 4.5. Both from Linaro (Richard, Matthias and Ramana), and from CS (the shrink wrap problems). Continued working on benchmarking the patches I've merged to 4.6. Spent quite some time trying to figure out why EEMBC and the Spec2K weren't working properly. I've got this sorted now. Confirmed that the patch to discourage NEON use for integer operations is still profitable on Cortex-A8. Posted the patch upstream. Merged upstream GCC 4.6 into Linaro GCC 4.6. Booked travel to Budapest for Linaro @ UDS. Followed up on Ramana's questions about the RVCT interoperability patch. Paul Brook helped explain what it was about, and pointed me at the proper section in the proper ARM manual. Continued forward porting patches to 4.6. Mostly I need to convince myself that they still do something useful. I have posted one new patch to upstream - the "Discourage A8 NEON" patch. * Future Absence Away Wednesday 16th to Friday 18th. Away Monday 28th to Friday 1st April. ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * RVCT Interoperability patch http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00059.html * Discourage NEON on A8 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00576.html

14 years, 7 months

1
0
0 0

[ACTIVITY] Mar.07 -- Mar.13

by Chung-Lin Tang

== Last week == * Working on Coremark ARMv6 regressions. Identified a major cause being RTL ifcvt failing on one of the crc routines, due to combine pass failing to optimize a particular sequence, causing the if-conversion estimates to give up on conditional executing (too many insns). The combine pass failed on ARMv6 and above, due to the existence of true zero_extend insns. On ARMv5, the use of two shifts actually allowed combine to phase reduce the shifts one by one, thus producing better code. On ARMv6, combine produced a (xor (and ...) <mask>) which did not match any insn. Analyzed and sent a patch upstream which should work on such XOR cases. Patch is due for upstream commit for 4.7-stage1. (http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00609.html) * Another situation of un-optimized uxth insns still exists; trying to solve this by another combine patch I am currently testing, will send upstream later. == This week == * verify the improvements the above patches should have on Coremark for ARMv6/v7. * Work on sending them to Linaro and SG++ branches. * Other bug issues.

14 years, 7 months

1
0
0 0

[ACTIVITY] Mar 07 - Mar 11

by Ulrich Weigand

== GDB == * Ongoing work on glibc patch to add ARM unwind tables to system call stubs; ran into design problems that look difficult to fix. * As an alternative, started work on a GDB patch to recognize glibc system call assembler stubs via code-scanning; this should allow alloc unwinding in the absence of debug info for current libc code. * Analyzed bug #728216 (GDB fails to get a valid backtrace while debugging a Webkit SIGSEGV) and resolved as invalid; the fault occurs within JIT-generated code where unwinding is impossible. == Misc == * Made travel arrangements for Linaro Summit in Budapest 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, 8 months

1
0
0 0

[ACTIVITY] report week 10

by Peter Maydell

RAG: Red: Amber: Green: another qemu-linaro release out the door on time Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-08 | 2011-03-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 | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | == maintain-beagle-models == * released qemu-linaro 2011-03 * had to do a 2011-03-1 reroll of the tarball on day of release to fix a "versatilepb model crashes on startup" bug found at last minute * Paul Larson is working on having automated test image boots on qemu built from git, so we can catch this much earlier in the cycle == merge-correctness-fixes == * added support to risu for testing of load and store instructions * used this to test a patch which cleans up Thumb load/store decode and makes us UNDEF in the right places * wrote/submitted patch to fix GE bits for signed modulo arithmetic * wrote/submitted patch to get SMUAD/SMLAD Q bit right in an edge case * started on a patchset which will fix various minor qemu Neon bugs detected by test programs from the valgrind source tree == other == * meetings: toolchain, standup, pdsw-tools 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, 8 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, == libunwind == * the patches posted last week are now upstream * continued to study the Exception Handling ABI for the ARM Architecture * looked into the structure of libunwind (lib interdependencies) * documented at: https://wiki.linaro.org/KenWerner/Sandbox/libunwind * The work on the local unwinding appears to be quite complete. If the generic unwind model is used the code assumes the GCC personality routine. We should either check name of the symbol (maybe be difficult) or just call the pers function. I'm in contact with Zach on this. Regards Ken

14 years, 8 months

1
0
0 0

Bad code generation due to shrink-wrap optimisation

by Michael Hope

LP: #731665 is a silent bad code generation bug at least on functions which are empty except for inline assembly: https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/731665 It was introduced in the shrink-wrap patch and is due to using an uninitialised variable. Andrew, can you please address this urgently either in Linaro or CSL. -- Michael

14 years, 8 months

1
0
0 0

[ACTIVITY] 2011-03-10

by David Gilbert

== hard-float == * Updated libffi variadic patch and Sent updated libffi variadic patch to the ffi mailing list. == String routines == * Got a big endian build environment going * Patched up memchr and strlen for big endian; turned out to be a very small change in the end; and tested it on qemu-armeb - note that an older version it didn't work on, but a newer one it did; I'll assume the newer one is correct. * Fixed a couple of build issues in the cortex strings test harness == Other == * Kicked off a SPEC2006 train run on canis using the 2011.03 compilers I'm on holiday tomorrow (Friday) and Monday. Dave

14 years, 8 months

1
0
0 0

[ACTIVITY] March 6-10

by Revital1 Eres

Hello, * Sent the patch to support targets that their doloop part is not decoupled from the rest of the loop's instructions (as is the case for ARM) to @gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00350.html * Continue looking into DENbench benchmarks. Thanks, Revital

14 years, 8 months

1
0
0 0

[ACTIVITY] March 6-10

by Ira Rosen

Hi, * continued working on cost model tuning. I don't see much difference running EEMBC DenBench with and without vectorization enabled (and, therefore, also with and without cost model). Also, I have to say, that the results are not stable and I sometimes get 10% difference just running the same executable two times in a row. * the only benchmark I see consistent degradation 5% with vectorization is DenBench aes, both with GCC trunk and gcc-linaro 4.5. I found one of the responsible loops, if it is not vectorized I see only 1.8% degradation. The problem there is that the loop bound is unknown at compile time, so the vectorizer attempts to vectorize the loop using runtime guards to verify that there are enough iterations to vectorize. The actual number of iterations is 4, so the scalar version of the loop is chosen at the run time, but I guess the guards cause the degradation. I'll continue looking into this next week. * prepared the conditional-store-sink patch (one of the patches that helps to vectorize Telecom Viterbi) for submission to gcc-patches. Ira

14 years, 8 months

1
0
0 0

Linaro QEMU 2011.03-1 released

by Peter Maydell

The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2011.03-1. Linaro QEMU 2011.03-1 is the second release of qemu-linaro. Based off upstream (trunk) qemu, it includes a number of ARM-focused bug fixes and enhancements. This release includes a model of the ARM Versatile Express platform. This is still experimental but may be of use to people who want a model supporting up to 1GB of RAM with graphics and networking. Instructions for getting started with it are on the wiki: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress Other interesting changes include: - The OMAP emulation bug which was causing hangs if Linux tried to enable a swapfile is fixed - The OMAP UART model has been improved; this fixes the problem where kernels using the new omap-hsuart serial drivers stopped serial output halfway through boot. - As usual, various minor correctness fixes and other upstream changes Known issues: - The beagle and beaglexm models do not support USB, so there is no keyboard, mouse or networking (#708703) The only change over the shortlived 2011.03-0 is that the last minute bug #731093 has been fixed (versatilepb models would crash on startup.) The source tarball is available at: https://launchpad.net/qemu-linaro/+milestone/2011.03-1 Binary builds of this qemu-linaro release are being prepared and will be available shortly for users of Ubuntu. When ready, Natty packages of qemu-linaro 2011.03-1 will be in the Ubuntu archive. Packages for users of Ubuntu 10.04 LTS and Ubuntu 10.10 will be 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, 8 months

4
3
0 0

Getting linaro toolchain binaries

by Dave Martin

Hi all, I've had comments that getting hold of binaries for the linaro toolchain can be trick for people unfamiliar with the linaro tools. One reason is that we don't release binaries as such -- but a visitor browsing in through http://www.linaro.org/downloads/ won't discover this, and may waste a lot of time trying to understand launchpad etc. before coming to the conclusion that binaries either aren't available or are not easily findable. On the other hand, the cross toolchain packages are likely to be of interest to such visitors, but aren't obviously advertised -- maybe I'm looking in the wrong place, but if so then new visitors to the linaro pages are likely to look in the wrong place too. Would it make sense to explain the situation more prominently so that visitors know what to expect? Something along the lines of "if you use distro x revision y, these cross-compiler packages are available" and "if you need the tools for some other environment, you need to download the source and build it for yourself". Cheers ---Dave

14 years, 8 months

13
24
0 0

Linaro GDB 7.2 2011-03 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.03-0 is the fourth release in the 7.2 series. Based off the latest GDB 7.2, it includes ARM-focused bug fixes and enhancements. Interesting changes include: * Hardware watchpoint support * Backtracing while in the Linux kernel trampoline frame Hardware watchpoints use the support built into ARM devices to watch for changes in values in memory with little performance impact. A 2.6.37 or later kernel is required. The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.2-2011.03-0 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- Michael

14 years, 8 months

1
0
0 0

[ACTIVITY] 28th February - 5th March

by Andrew Stubbs

Committed Kazu's VFP testcases patch upstream. Merged the latest from upstream GCC 4.6. Merged all the outstanding launchpad merge requests against both GCC 4.5 and 4.6. Spun the 4.5-2011.03-0 and 4.6-2011.03-0 releases. Passed the tarballs to Michael H for final testing. Brought the patch tracker up to date w.r.t. to new merges. Posted one of Dan's patches upstream for review. Decided to drop Julian's A8 alignment patch completely. I had previously discovered it provided no measurable benefit on A8, and now I've found the same for A9 (Pandaboard). There's no real improvement for any combination of -falign-* options in EEMBC. Bernd's "Discourage NEON on A8" patch also doesn't show any value in the benchmark results, but I think I've forward ported it wrong, because it should at least change the binary size, and it doesn't. I need to look into this further. I also decided I don't know enough about ARMv7, so I spent some time reading a few chapters from the ARM A.R.M. ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * RVCT Interoperability patch http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00059.html

14 years, 8 months

1
0
0 0

[ACTIVITY] Feb.28 -- Mar.06

by Chung-Lin Tang

Last week: * Launchpad #711819 / PR47719: ARM minipool ICE. Followed up on discussion with Bernd and Ramana. Later posted discussion results on gcc-patches, where Richard Earnshaw took it over with a final fix. * Coremark ARMv7/v6 regressions: mostly pinpointed the exact cases where RTL simplification fails to optimize away ZERO_EXTEND expressions. Still working on how to enhance it. * TW Public Holiday on Feb.28 (Mon), was off for one day. This week: * Try to turn Coremark regression investigation into code form. * Other GCC issues.

14 years, 8 months

1
0
0 0

Representing interleaving and lane load/stores at the tree level

by Richard Sandiford

I've been spending this week playing around with various representations of the v{ld,st}{1,2,3,4}{,_lane} operations. I agree with Ira that the best representation would be to use built-in functions. One concern in the original discussion was that the optimisers might move the original MEM_REFs away from the call. I don't think that's a problem though. For loads, we can simply treat the whole of the accessed memory as an array, and pass the array by value. If we do that, then the call would just look like: __builtin_load_lanes (MEM_REF[(elem[N] *)ADDR]) (where, despite the C notation, the MEM_REF accesses the whole of elem[N]). It is of course possible in principle for the tree optimisers to replace this MEM_REF with another, equivalent, one, but that's OK semantically. It isn't possible for the optimisers to replace it with something like an SSA name, because arrays can't be stored in gimple registers. __builtin_load_lanes would then be used like this: combined_vectors = __builtin_load_lanes (...); vector1 = ...extract first vector from combined_vectors... vector2 = ...extract second vector from combined_vectors... .... So combined_vectors only exists for load and extract operations. The question then is: what type should it have? (At this point I'm just talking about types, not modes.) The main possibilities seemed to be: 1. an integer type Pros * Gimple registers can store integers. Cons * As Julian points out, GCC doesn't really support integer types that are wider than 2 HOST_WIDE_INTs. It would be good to remove that restriction, but it might be a lot of work, and it isn't something we'd want to take on as part of this project. * We're not really using the type as an integer. * The combination of the integer type and the __builtin_load_lanes array argument wouldn't be enough to determine the correct load operation. __builtin_load_lanes would need something like a vector count (N => vldN) argument as well. 2. a combined vector type Pros * Gimple registers can store vectors. Cons * For vld3, this would mean creating vector types with non-power- of-two vectors. GCC doesn't support those yet, and you get ICEs as soon as you try to use them. (Remember that this is all about types, not modes.) It _might_ be interesting to implement this support, but as above, it would be a lot of work. It also raises some semantic questions, such as: what is the alignment of the new vectors? Which leads to... * The alignment of the type would be strange. E.g. suppose we're loading N*2 uint32_ts into N vectors of 2 elements each. The types and alignments would be: N=2 uint32x4_t, alignment 16 N=3 uint32x6_t, alignment 8 (if we follow the convention for modes) N=4 uint32x8_t, alignment 32 We don't need alignments greater than 8 in our intended use; 16 and 32 are overkill. * We're not really using the type as a single vector, but as a collection of vectors. * The combination of the vector type and the __builtin_load_lanes array argument wouldn't be enough to determine the correct load operation. __builtin_load_lanes would need something like a vector count (N => vldN) argument as well. 3. an array of vectors type Pros * No support for new GCC features (large integers or non-power-of-two vectors) is needed. * The alignment of the type would be taken from the alignment of the individual vectors, which is correct. * It accurately reflects how the loaded value is going to be used. * The type uniquely identifies the correct load operation, without need for additional arguments. (This is minor.) Cons * Gimple registers can't store array values. So I think the only disadvantage of using an array of vectors is that the result can never be a gimple register. But that isn't much of a disadvantage really; the things we care about are the individual vectors, which can of course be treated as gimple registers. I think our tracking of memory values is good enough for combined_vectors to be treated as such (even though, with the back-end changes we talked about earlier, they will actually be stored in RTL registers). So how about the following functions? (Forgive the pascally syntax.) __builtin_load_lanes (REF : array N*M of X) returns array N of vector M of X maps to vldN in practice, the result would be used in assignments of the form: vectorX = ARRAY_REF <result, X> __builtin_store_lanes (VECTORS : array N of vector M of X) returns array N*M of X maps to vstN in practice, the argument would be populated by assignments of the form: vectorX = ARRAY_REF <result, X> __builtin_load_lane (REF : array N of X, VECTORS : array N of vector M of X, LANE : integer) returns array N of vector M of X maps to vldN_lane __builtin_store_lane (VECTORS : array N of vector M of X, LANE : integer) returns array N of X maps to vstN_lane Note that each operation can be expanded independently. The expansion doesn't rely on preceding or following statements. I've hacked up the prototype below as a proof of concept. It includes changes to the C parser to allow these functions to be created in the original source code. This is throw-away code though; it would never be submitted. I've also included a simple test case and the output I get from it. The output looks pretty good; there's not even the stray VMOV that I saw with the intrinsics earlier in the week. (Note that if you'd like to try this yourself, you'll need the patch I posted on Monday as well.) What do you think? Obviously this discussion needs to move to gcc@ at some point, but I wanted to make sure this was vaguely sane first. Richard

14 years, 8 months

2
2
0 0

A question about disabling -gtoggle in bootstrap run

by Revital1 Eres

Hello, I am looking for a way to disable '-gtoggle' flag in the run of stage 2 in bootstrap; when configuring ARM with (*). The flag seems to be applied in stage 2 but not in stage 3 which seems to cause bootstrap failure when testing SMS as in stage 2 SMS fails because of debug_insn caused by -gtoggle disturbing do-loop; while in stage 3 SMS succeeds; resulting in different .o files and bootsrtrap failure. (*) This the configure I used: ../gcc/configure --prefix=/home/eres/mainline/build --enable-checking --enable-languages=c --enable-bootstrap Thanks, Revital

14 years, 8 months

3
8
0 0

[ACTIVITY] Feb 28 - Mar 04

by Ulrich Weigand

== GDB == * Committed fix for the GDB part of #620611 (Unable to backtrace out of vector page 0xffff0000) to mainline and Linaro GDB 7.2. * Ran into GDB crashes due to memory corruption in tests involving multiple inferiors. Tracked down root cause (using valgrind) to long-standing double free bug in GDB terminal state handling code. Committed fix to mainline and Linaro GDB 7.2. * While using valgrind (see above), ran into problems: * ptrace system call is unsupported on ARM * certain variants of the "SUB from SP" Thumb-2 instruction are not handled by the VEX compiler Fixed both problems locally, and was then able to successfully valgrind GDB on ARM. * Created Linaro GDB 7.2-2011.03-0 release. * Worked on glibc patch to add ARM unwind tables to system call stubs; this will help unwinding in the absence of debug info for libc, and in particular fix #684218 (Failures in gdb.base/call-signal-resume.exp) 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, 8 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, == PandaBoard == * upgraded my ARM dev environment from Ubuntu to Linaro snapshot (20110303) * found another kernel bug on the panda (#728565) == libunwind == * resolved build issues on ARM (when using the linaro snapshot) * allows the testsuite to work with linkers that do not pull in indirect shared libs * fix build of the test-static-link test case on ARM * link libunwind-setjmp.so against libunwind-elf * posted some first patches on the libunwind ml * learned about the Exception Handling ABI for the ARM Architecture Regards Ken

14 years, 8 months

1
0
0 0

[Activity] 2011-03-04 week 9

by Ramana Radhakrishnan

Starting back in Linaro land after a gap of 3-4 weeks where I've been away on ARM internal tasks. == GCC == - Setting up a new machine that I received for Linaro work. - Spent some time reviewing upstream patches. Spent some time on the P1 PR47719 upstream to get this fixed . - Starting to read up on the benchmarking report and recreating the environments. - Looked through some of the speed tickets to have a look through and spend some time on it. - Put in a hardware request for a Panda board. == Next Week == - Set up environment properly for some amount of benchmarking. - Look at some of the performance regressions and work on some things that need to be done. - Continue looking at PR47719.

14 years, 8 months

1
0
0 0

[ACTIVITY] 2011-03-04

by David Gilbert

* Investigated and fixed sqlite3 testsuite failure on ARM (bug 725052) * Discussing libffi API changes with maintainer; hopefully he's going to send out his comments today. * Looking at how to upstream the string routine changes * Need to look at big endian testing * Testing QEmu pre-release for Peter; looking very nice. Dave

14 years, 8 months

1
0
0 0

[ACTIVITY] report week 09

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-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 | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | == maintain-beagle-models == * preparation and test for next week's qemu-linaro 2011-03 release * put in a temporary fix for bug 723630 (apt/glibc now try prlimit64 syscall, so silence qemu warnings about not implementing it) * investigated qemu warnings about bad 16 bit writes: this is a kernel bug: https://bugs.launchpad.net/linux-linaro/+bug/727781 == vexpress model == * sent vexpress patches upstream, put into qemu-linaro == merge-correctness-fixes == * more work on performance counter registers: proper cycle counter implementation; now just needs a bit of tidying before upstreaming * ran valgrind's test cases on qemu; added revealed issues to https://blueprints.launchpad.net/qemu-linaro/+spec/merge-correctness-fixes * sent patch fixing broken VMOV s0,s1,r0,r1 implementation * sent patch fixing inverted carry bit on ORNS == other == * meetings: toolchain, standup, architecture q&a, pdsw-tools, team brief 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, 8 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Submitted the fix for the Qt miscompilation upstream. Applied after approval. * Submitted a patch for the Thumb LDR problem that Dave Martin hit. This was rejected. * Ended up spending a few days on the "unreasonable amount of memory while compiling qemu" bug due to unfamiilarity with the DWARF 2 code. I realise the original idea was that I'd just file this upstream, but it was one of those cases where I kept finding out more info for the bug report until the problem became obvious. I've now submitted two patches for this upstream. The first was trivial and is now in. I was asked to add a bit of extra code to the second, which I hope to do next week. * Looked at the MIPS bug that was reported against the Linaro toolchain. This turned out to be a problem in our extension elimination pass. Submitted a merge request for that. * Got confirmation from ARM that we should use relocation number 160 for R_ARM_IRELATIVE, and that it was OK to make the changes public (thanks!). I've now submitted the binutils patches upstream. I'll do the eglibc ones when I get back. == Next week == Holiday! Richard

14 years, 8 months

1
0
0 0

[ACTIVITY] February 27- March 3

by Revital1 Eres

Hello, Testing the patch for SMS to support targets that their doloop part is not decoupled from the rest of the loop's instructions, as SMS currently requires. The testing includes bootstrapping on ARM machines for c language configured w and w\o --with-arch=armv7-a options and using"-O2 -fmodulo-sched -fmodulo-sched-allow-regmoves -fno-auto-inc-dec -funsafe-math-optimizations -mthumb" flags. Thanks, Revital

14 years, 8 months

1
0
0 0

GCC PR43137

by Andrew Stubbs

On Monday, I was asked to find out whether the fix for GCC Bugzilla PR43137 was present in our source base. I can confirm that it is *not* present. Apologies for the delay. Andrew

14 years, 8 months

1
0
0 0

What configuration(s) to test?

by Andrew Stubbs

Hi All, Up until now, I have had no choice but to test toolchain correctness on A8 hardware. It made sense to use the same -mfpu settings as the Linaro/Ubuntu package builds use. This did not match the policy that the interesting platform was A9-NEON, but I didn't have that option. That's changed now - our Panda boards have arrived! Yay! :) But, it seems to me that if I change to using the Pandas for correctness testing (not performance testing) then I won't be testing what Ubuntu will actually use. So what should I test on? I'd rather not double my test load by testing on both, but that is an option .... Any suggestions? Andrew

14 years, 8 months

2
1
0 0

Re: Thumb-2 kernel on imx51/efikamx

by Dave Martin

Hi, On Mon, Feb 28, 2011 at 9:19 PM, Nicolas Pitre <nicolas.pitre(a)linaro.org> wrote: > On Thu, 24 Feb 2011, John Rigby wrote: > >> The resulting kernel builds and boots but some modules have problems: >> >> $ modprobe fat >> fat: unknown relocation: 102 >> FATAL: Error inserting vfat > > A workaround for what appears to be a binutils bug has been merged in > linaro-2.6.38. So the Thumb2 kernel testing may resume on trusted > targets. Thanks for merging it. It's a bit ugly to include turn off compiler optimisations to work around this though, so we might encounter upstream to that patch. In any case, we still need someone to take a look at the possible tools issue -- CC'ing linaro-toolchain in case people aren't aware: https://bugs.launchpad.net/binutils-linaro/+bug/725126 Cheers ---Dave

14 years, 8 months

2
1
0 0

Re: [RFC] Linaro Toolchain for Android and NDK

by Jim Huang

On 25 February 2011 22:28, Alexander Sack <asac(a)linaro.org> wrote: > On Wed, Feb 23, 2011 at 8:28 AM, Jim Huang <jserv(a)0xlab.org> wrote: >> I would like to make a proposal about utilizing Linaro toolchain for >> Android and NDK (Native Development Kit)[1]. Added linaro-toolchai list in Cc. >> ** Motivation >> >> There are some different perspectives between Linaro toolchain and >> Google Android toolchain including technical and >> non-technical considerations. It doesn't really work if we only >> replace prebuilt toolchain with Linaro toolchain because >> of the compatibility of Android system utilities such as ELF >> prelinker. Also, since Android is developed in relatively closed > > I don't have enough background to understand this "ELF prelinker" > stuff. Are you saying that because of the way how android links stuff > we cannot have one code base for gcc that works for both, android and > "normal libc linux"? > Take Bug #707487 for example: https://bugs.launchpad.net/binutils-linaro/+bug/707487 It is evident that Android's system utilities like soslim ("strip" implementation) and apriori ("prelink" implementation) expect the specific output of GNU Toolchain, but it sometimes varies since we would take Linaro's toolchain. >> environment (Google style open source model), a great amount of >> software components are not always verified by different >> toolchain or build configurations. This proposal attempts to > > ack. thats what we want to do. Of course, we cannot really verify what > is going on behind closed walls, but we can continuously build android > with our toolchain and fix issues due that in android public master > and if even that doesn't work we can ensure that our android trees > always work nicely with both, our gcc and android gcc. > Android team is known to work on this field already. > Another thing is to make our toolchain easily consumable (like the NDK > you mention at the bottom); this will increase chances that someone > from google can eventually take a look at what we are doing etc. and > also helps the community to use linaro toolchain to built their > android distributions. Agree. >> establish the compact development flow to enable Linaro >> optimized ARM toolchain to build Android from scratch and verify it >> transparently. Eventually, Android can be the reference >> indicator as Linaro toolchain performance and reliability. >> >> >> ** Brief introduction to Google Android toolchain >> >> Inside Google, there is a dedicated compiler team working on GNU >> Toolchain for various purposes including server-side >> computing, Android, Chrome OS, etc. Google engineers submit patches to >> upstream for public review and maintain the >> toolchain for Android. Along with each Android Open Source Prokect >> (AOSP) release, there is a special branch in korg >> GIT [2] for hosting the GPL'd toolchain source code modified by >> Google. Usually, file "README.google" mentioned the >> summary, but it is not developer friendly because several changes were >> done within one GIT commit. >> >> Please refer to wiki for details: >> https://wiki.linaro.org/Platform/Android/UpstreamToolchain >> > > thats a good wiki page. thanks for the content. If I read the skia > example correctly, we could add a test to our "normal" abrek testsuite > that uses our daily android toolchain and run the skia benchmark? e.g. > we could start doing this benchmarking even without having a > validation solution ready for android targets? > If adb is supposed to work well on target, then you can easily use "bench.py" script mentioned in the above wiki to do several benchmarking. > Please let's talk to Paul how we can get the android toolchain to > /opt/android as part of abrek and lets try to add this to our abrek > testsuites. Until we have daily toolchain builds it would be OK to > download the android toolchain tarball from a fixed place from > people.linaro.org I guess. > Ok! >> ** What's wrong with Android upstream Toolchain? >> >> In my opinion, list as following: >> >> (1) Few information about Google improvement: Sometimes, we have to >> guess something from implicit GIT commitlog >> such as "commit gcc-4.4.3 which is used to build gcc-4.4.3 Android >> toolchain in master"[3]. It is hard to track and get >> verified carefully. > > yes, that feels like a messy situation. Do we know why they don't > commit the changes as individual commits but then in next step > document what they changed? I have no exact idea since I am just an observer regarding Android's GIT tree. Google engineers do send patches to FSF/GNU, but it is not always related to the GIT activities we have seen in korg. You can search the keyword, "submit", in file gcc/gcc-4.4.3/README.google , and you will see some descriptions as following: gcc/cp/cp-lang.c gcc/gimple.c gcc/langhooks-def.h gcc/langhooks.h gcc/langhooks.c gcc/tree-flow.h gcc/tree-ssa-dce.c gcc/testsuite/g++.dg/tree-ssa/vptr_init_dse.C gcc/testsuite/g++.dg/tree-ssa/vptr_init_dse2.C Enhancing dead code elimination to eliminate useless vptr field initialization. Owner: davidxl Status: not submitted gcc/fold-const.c gcc/Makefile.in Fix 2045297 Owner: davidxl Status: Not submitted The information is too few to track for us since the above "Fix 2045297" tends to indicate Google bug database number instead of FSF's. >> (2) Google specific improvements are absent in recent release, only >> enabled months later. For example, Google Compiler >> Team Lead, Dr. Shih-wei Liao, presented the improvements against GNU >> Toolchain in the middle of 2009.[4]. The report >> came with several impressive improvements like FDO (Feedback Directed >> Optimizations) and IPO (Inter-Procedure >> Optimizations). However, only some of them are public to AOSP and be >> integrated late in the middle of 2010 (Android >> Froyo; 2.2). Even FDO was merged in Android Froyo already, but there >> is few documentation and no robust method to verify >> by community members such as Linaro engineers. > > you say that they don't publish the code for lets say the > "gingerbread" toolchain in a timely fashion when they release > gingerbread? Or do they ship a separate "fast" NDK/prebuilt for > partners through secret channels? I have no idea. >> (3) For some reasons, Google tends to deliver stable (old) toolchain >> plus mainline backport. It is a safe and workable approach, >> but sometimes developers would expect to use the latest technologies >> as Linaro aims to bring to the world. >> >> (4) Few readable documentation. For example, Google already open its >> toolchain benchmark suite in early 2010, but there was >> no document specific to such important components. Furthermore, there >> was one file gone in public kog GIT, required by >> automated benchmark process. One year later, Google engineer finally >> put back the one to public. This implies the unusual way >> Google developed and delivered software. >> > > Assuming good faith I would think this might just have been an oversight. > > Do you know if anyone from community pointed this out to google using > official android mailing lists/groups or a bug? > Google engineers sometimes pick up the issues from Google Code: http://code.google.com/p/android/issues/list And, they do discuss on mailing-list: http://developer.android.com/community/ >> ** Linaro's Approach to enable latest technologies >> >> Linaro android team tries to do: >> (1) Document Android toolchain and related utilities in korg GIT as >> possible as we can. > > That's good stuff and I think your wiki page is already a great > contribution in that direction. What we should do though is run this > through google eyes early by using official android mailing lists. > Got it. >> (2) Early adaptation of Linaro toolchain to Android build system and >> verify these output systematically. > > ack. Do you know if those changes would be conflicting with what we do > on "normal" linux side? e.g. do we need to maintain special android > patches or can we merge those into our main trees? > In fact, GCC 4.6 already merges Android specific patches with the help of CodeSourcery. We would initially backport these patches to linaro-gcc-4.5 branch for review. Luse Cheng already did it. However, other parts are not related to Android directly, and they might be too aggressive to generic GCC optimization, that can be the reason why Google didn't submit first. >> (3) Backport Google changes to Linaro GCC and review in public. > > This is really tricky as you said. Here again, we should propose this > on android mailing lists to maybe get feedback from google team and > maybe improve the way we work on that. Untangling a big patch based > just on changelog feels really unefficient. Ok, I got your point. However, what we need is to create workable combination of Linaro kernel + Linaro toolchain for Android integration engineers. Alexander, I need your help to catch the attention of someone at Google. > Also, we have to remember that if we pick changes out of _their_ tree, > we cannot upstream those to fsf because we don't own copyright to > those. Of course, for stuff they already pushed to 4.6 its not a > problem to backport them from fsf trunk. Thanks for notice. >> (4) Improve the deployment and validation flow by means of Linaro >> infrastructure. > > my understanding is this: > > 1. we add support to build android toolchain from linaro branches to > our cloud build service > 2. we do this so that we either produce a full toolchain tarball that > can be installed under /opt/android or a NDK tarball (or both) NDK doesn't need admin permission to install. > 3. we improve our android platform build infrastructure to allow > using latest daily toolchain tarball and then we build android with a) > google toolchain and b) linaro toolchain; in this way we get daily > android builds for both toolchains that can go into the linaro > validation farm and get the typical validation/testing and > benchmarking done. Yes, it would be great. >> (5) Build and test Android system with Linaro tools. Then, figure out >> the regressions caused by Linaro Toolchain and/or >> aggressive optimizations > > right. I think that's covered with the point above, no? The android > builds done with our toolchain would also be available in public, so > you can do whatever you want on top of what we already > test/validate/measure automatically in the validation farm with them. Agree. >> (6) measure performance gain by Linaro tools > > right. for this we need to define a set of open-source benchmarks to > run and ensure that those are supported in our validation framework. > >> The detailed specification in wiki: >> https://wiki.linaro.org/Platform/Android/Specs/LinaroAndroidToolchain >> >> ** Implementation of Linaro toolchain for Android >> >> We started from Android style toolchain build and move to Linaro GCC + >> ARM specific optimizations in mind. The initial work >> can be obtained by wiki: >> https://wiki.linaro.org/Platform/Android/Toolchain >> >> We plan to maintain the following GIT repositories at least: >> * android/toolchain/build.git : Linaro-aware build system. Derived >> from Android toolchain build system, it can handle Linaro-GCC >> and Linaro snapshot/bzr. >> * android/toolchain/gcc-patches.git : Patchset to be applied on top >> of Linaro-GCC release/snapshots > > I think thats fine. however, how do we ensure that we have patches > that always apply to both release/snapshots? do we maintain branches > for gcc-patches.git in case you need two versions of patch X if the > linaro gcc codebase diverged? I might need help from toolchain WG. >> The reference builder script output: >> $ ./linaro-build.sh --help >> --prefix-dir= Specify where to install (default: >> /tmp/android-toolchain-eabi) >> --gcc-src-dir= Specify where linaro gcc source is (in <toolchain>/gcc) >> --apply-gcc-patch=(yes|no) Apply-patch which in >> <toolchain>/gcc-patches directory (default: no) >> >> Current verified combinations: >> * gcc-linaro: 4.5-2011.02-0 >> * binutils: 2.20.1 >> * gmp: 4.2.4 >> * mpfr: 2.4.1 >> >> Only gcc is replaced by gcc-linaro: 4.5-2011.02-0 and others are >> checked out from korg GIT. > > do we need to do something like --gcc-src-dir and -patches for > binutils, gmp and mpfr as well? or would we be only interested in > improving/fixing gcc for now? > I think focusing on linaro-gcc is pretty good. We can follow the original combination of Google. > Waybe we also want to support protocol schemes like git: http: and > bzr+ssh:/lp: for the --gcc-src= argument. this would then > automatically download/branch the source tree from the given location. > What do you think? Agree. >> ** Summary of gcc-patches >> >> "gcc-patches" are used as "backport" from Google changes into Linaro >> gcc base. Here is the summary at present: >> >> 0001-Add-linux-android.patch >> Add linux-android >> >> 0002-Add-support-for-Bionic-C-library.patch >> Add support for Bionic C library >> >> 0003-Support-compilation-for-Android-platform.patch >> Support compilation for Android platform >> >> 0004-Add-multilib-configuration-for-arm-linux-androideabi.patch >> Add multilib configuration for arm-linux-androideabi >> >> 0005-Fix-gthr-posix.h-to-support-Bionic.patch >> Fix gthr-posix.h to support Bionic >> >> 0006-Add-untested-support-for-Bionic-to-libstdc.patch >> Add [untested] support for Bionic to libstdc++ >> >> These patches are taken from Maxim Kuvyrkov of CodeSourcery in gcc-4.6 >> branch. Of course, we can always add changes by >> Google or other Android specific adaptation by this model. > > Can we get a toolchain example tarball done and uploaded to > people.linaro.org? I would like to verify that those work out of the > box with gingerbread and if so, i would like to see those land in the > main toolchain WG branch rather than adding them to our gcc-patches > tree. Yes, I would like to do that later. >> ** Planned improvements over Linaro toolchain for Android >> >> (1) GCC multilib setting >> Default: arm, fpu and thumb. The prebuilt google toolchain use: >> armv5te and mandroid. We should focus on ARMv7. >> (2) HardFP-ABI Support for Android. >> (3) Patch management: Better to get the Android patches into >> Linaro-GCC tree eventually. >> (4) Build system improvement. Don't have to build gmp, mpfr everytime, >> and provide option to build without gdb. >> (5) Enable LTO (Link Time Optimization, introduced since gcc-4.5) in >> Android TARGET_GLOBAL_CFLAGS >> (6) Verify the functionality of FDO (Feedback Directed Optimization) >> and introduce the approaches to integrate. > > I really think those topics should be executed by the toolchain WG > rather than in platform. I am happy that we give them guidance and > support them by providing them with easy to use tools to get their job > done. Also feeding them with topics is great. Please talk to Michael > Hope and ask him how he wants to collect those android toolchain > optimization topic ideas. Could be good input for our 11.11 > requirements gathering process. Agree. >> ** Toward Android NDK >> >> Once Linaro toolchain for Android is ready to use, it is time to >> re-package Android NDK by Linaro toolchain. To do that, extra >> build configuration, sysroot, is required. According to Android >> Release Cycle & Phases[5], the repacked NDK should be verified >> one moth after Android public release. > > That sounds like a great idea. What's the a benefit/difference of > shipping an NDK compared to just shipping a "normal" toolchain binary > tarball for this purpose? NDK consists of some architecture specific helper scripts/headers to indicate the optimization flags and some combinations such as ARMv7 with/without NEON, etc. If we provide NDK directly, users don't have to consider the above integration issues as far as I know. Sincerely, Jim Huang (jserv) Android Team

14 years, 8 months

2
2
0 0

[ACTIVITY] 21st - 26th February

by Andrew Stubbs

Temporarily took over Tech Lead of the Toolchain Working Group while Michael Hope recovers from the Christchurch earthquake. (He's fine, but unable to work.) This didn't actually require any action, in the end. Michael returned to work towards the end of the week. Forward ported, benchmarked, and posted one of Mark Shinwell's NEON patches upstream. Further benchmarking was not possible as the Panda board I was using is located in Christchurch, NZ. Merged and tested the FSF GCC 4.5 branch into Linaro GCC. There were a couple of test regressions in the fortran testsuite, so I've filed bug lp:723086. The other test results were either the same or better. Benchmarked the ARM A8 function/jump alignment patch to see what effect it has in GCC 4.6. Found no measurable improvement in EEMBC. I suggest dropping this patch. Brought the patch tracker up-to-date, and entered tracking tickets for all outstanding patches. Merged FSF trunk to Linaro GCC 4.6. Committed Jie's Thumb2 testcase fix to FSF GCC trunk. Thanks to Ramana for using his new found authority to approve it. Investigated the suitability of several of the patches for forward-porting. Corresponded with Benrd and Julian. ---- 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 * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

14 years, 8 months

1
0
0 0

[ACTIVITY] Feb 21 -- Feb 27

by Chung-Lin Tang

== Last week == * Launchpad #721021 GCC ICE on ARM/XScale: identified as case of upstream PR45177; backported and pushed to Linaro. * Launchpad #709453/CS Issue #7122: Neon vmov 0.0 issues; some progress on my current WIP patch, but tests showed another 3 regressions, still on-going. * Launchpad #711819/GCC PR47719: ICE in push_minipool_fix. Ramana reminded that my patch, which added some pool range attributes, were actually removed earlier by Bernd in the fix for PR43137. Discussed and mostly concluded that we should add them back for now. Will re-submit patch with testcase to gcc-patches this week. * Coremark ARMv7-A regressions: still work in progress. == This week == * TW Public Holiday Feb.28 (Mon). * Ping some of my upstream patch submissions. * Get incompleted issues done. * Coremark regression investigation.

14 years, 8 months

1
0
0 0

GCC M4 DSP support

by Christian ANDERSSON2

Hello Linaro toolchain guys, I have a few questions regarding GCC fully supporting the ARM Cortex M4, I'm especially thinking of the additional DSP instructions and if these are supported and how optimal the code being produced is? Thanks for your support, Best Regards Christian (ST-Ericsson)

14 years, 8 months

2
1
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, == Investigate developer tools == * Finished latrace investigation. == PandaBoard == * The defective PandaBoard that was sent back in December is now repaired and on my desk again. It doesn't show the behaviour of #708883 and works flawlessly so far. :) == libunwind == * Did some debugging of the test-async-sig testcase to get started with libunwind. It will dead-lock if you add "--enable-debug" since libunwind does printfs in this case which are not signal safe. * Sorted out which of Zachs patches are upstream and which are not. * Started to learn about the different unwind methods that libunwind provides on ARM. Regards Ken

14 years, 8 months

1
0
0 0

[ACTIVITY] 2011-02-25

by David Gilbert

== ffi == * Sent variadic patch for libffi to libffi-discuss * Worked through some suggestions from Chung-Lin, need to do some rework == string routines == * memchr & strchr patch sent for inclusion in ubuntu packages * tried sqlite's benchmarks - they don't spend too much time in the C library; although a few % in memcpy, and ~1% in memset (also seem to have found an sqlite test case failure on ARM and filed as bug 725052) == porting jam == * There wasn't much traffic on #linaro during this related to the jam * I closed bug 635850 (fastdep FTBFS) which was already fixed with an explicit fix for ARM in the changelog and bug 492336 (eglibc's tst-eintr1 failing) which seems to work now but it's not clear when it was fixed. * Looking at eglibc's test log there seem to be a bunch of others that are failing and may well be worth investigating. * bug 372121 (qemu/xargs stack/number of arguments limit) seems to work ok, however the reporter did say it was quite a fragile test; that needs more investigation to see whether the original reason has actually been fixed. == misc == * swapping notes with Peter on the PBX SD card investigation Dave

14 years, 8 months

1
0
0 0

[ACTIVITY] report week 08

by Peter Maydell

RAG: Red: Amber: Green: Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-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 | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | == maintain-beagle-models == * rebased qemu-linaro on upstream * checked omap_uart model for any issues with enabling the extended (non-16550A) features which the new Linux drivers need. Sent meego merge request for patchset which turns on the features, and does a little cleanup. Now in meego, qemu-linaro. == merge-correctness-fixes == * reviewed versions 5 and 6 of Christophe's vrecpe/vsqrte patchset; v6 was good and has now been committed * sent a version of "dummy cp14 debug registers" patch upstream; however I've realised it triggers a false positive in the temp-leak debugging code in target-arm/translate.c * wrote/sent a patch which moves this temp-leak debugging code into TCG proper (which I think makes it much simpler and cleaner and avoids the false positives mentioned above) * some work on the cp15 performance counter registers. I now have some code which I think is a fully architecturally valid implementation of an "implements no events" core, except that we don't implement the cycle count register. * started testing/review of Adam's VA-to-PA translation regs patch. In the course of this discovered that qemu unconditionally implements an ARM940 cp15 WFI register which clashes with these; submitted patch to add correct not-for-v6/v7 feature gating. * sent out patch fixing usermode seeks by 32 bit guest on 64 bit host (based on a diagnosis and suggested fix by Eoghan Sherry) * sent patch fixing compile error in vnc code == vexpress model == * sent a patchset for fixing the MMC card detect wiring on PBX upstream; this is needed for vexpress too * finished vexpress cleanup and cross-checking against the docs; I now have a patchset I'm happy to upstream and will post next week == other == * took part in pgp keysigning event with emdebian folks * meetings: toolchain, PDSW-tools 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, 8 months

1
0
0 0

[ACTIVITY] Feb 21 - Feb 25

by Ulrich Weigand

== GDB == * Worked with Will Deacon and the Linaro kernel team to make sure HW watchpoint and Versatile Express errata fixes are included in the upcoming Linaro kernel release. * Committed GDB HW watchpoint patches to mainline, and backport to Linaro GDB. This completes work on the HW watchpoint blueprint. * Worked on fixing the GDB part of #620611 (Unable to backtrace out of vector page 0xffff0000). Posted (two versions of) mainline patch for discussion. * Worked on kernel patch for #615974 (Interrupted system call handling). 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, 8 months

1
0
0 0

[ACTIVITY] Weekly status

by Richard Sandiford

== This week == * Looked at the poor code generated for Neon load/store intrinsics. Looked into the history behind the treatment of VFP registers by CANNOT_CHANGE_MODE_CLASS. Peter confirmed that the restrictions apply only to VFPv1. Wrote a patch to improve the code, which partly overlapped with Julian's. * Looked at how the operations should be represented at the tree level. Experimented with various combinations of tree codes and types to see which felt right. Wrote this up in the message I sent today. == Next week == * More vectorisation. * Submit some queued patches. * Maybe some bug fixing. (I see there's a reload bug just waiting to be claimed by a lucky developer.) On holiday the following week. Richard

14 years, 8 months

1
0
0 0

Re: Unavailable for a bit

by Michael Hope

Services at ex.seabright.co.nz are back up. On Tue, Feb 22, 2011 at 10:06 PM, Michael Hope <michael.hope(a)linaro.org> wrote: > Hi there. We've had an earthquake. Family and friends are fine but i'll be > unavailable for a few days. Services on ex.seabright.co.nz are down. I'll > cancel Wednesdays standup call. > > See you soon, > > -- Michael

14 years, 8 months

1
0
0 0

[ACTIVITY] February 20-24

by Revital1 Eres

Hello, Implemented a patch for SMS to support targets that their doloop part is not decoupled from the rest of the loop's instructions (which is the current assumption of SMS). ARM is an example of such target, where the loop's instructions might use CC reg which is used in the doloop part. Now testing the patch on ARM and other targets that have do-loop. Thanks, Revital

14 years, 8 months

1
0
0 0

[ACTIVITY] February 20-24

by Ira Rosen

Hi, * vectorizer cost model - implemented builtin_vectorization_cost for NEON - added register spilling considerations to the cost model - started testing/tuning on EEMBC Telecom and DenBench (for now I have only two examples for spilling: fdct_int32 mp4encode that shouldn't get vectorized and viterbi that should) * measured vectorization impact on Telecom autcor - it's about 5x (initially I got run time segfault, but the bug is already fixed on GCC trunk, I'll have to check gcc-linaro-4.5 as well) * NEON-vs.non-NEON degradation - started to look at aes. There are 6 loops that get vectorized with 4.6 (due to this patch http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01927.html that allows cond_expr in number of loop iterations expressions) and vzip/vuzp patch, but not with gcc-linaro-4.5. But it doesn't explain the degradation of course. - I don't understand mp4decodepsnr improvement, since I don't see any loops or basic blocks vectorized. Ira

14 years, 8 months

1
0
0 0

Weekly Activity report

by Mounir Bsaibes

Please find the compilation of the weekly activity reports at the following link, if I have missed anyone let me know. https://wiki.linaro.org/WorkingGroups/ToolChain/ActivityReports/2011-02-18 In your report please try to stick to the following format, to help make the report consistant: == Topic == * item 1 * items 2 See https://wiki.linaro.org/Process/Reporting Thanks & Regards, Mounir

14 years, 8 months

1
0
0 0

Improving the code generated for vld and vst intrinsics

by Richard Sandiford

One of the vectorisation discussions from last year was about the poor code GCC generates for vld{2,3,4}_*() and vst{2,3,4}_*(). It forces the result of the loads onto the stack, then loads the individual pieces from there. It does the same thing in reverse for stores. I think there are two major problems here: 1. The result of the vld*() is a record type such as: typedef struct int16x4x3_t { int16x4_t val[3]; } int16x4x3_t; Ideally, we'd like one of these structures to be stored in a pseudo register. However, the ARM port currently limits in-register record types to 64 bits, so something this big is always given BLKmode and stored on the stack. A simple "fix" for this is to increase MAX_FIXED_MODE_SIZE. That would do the right thing for the structures in arm_neon.h, but wouldn't be safe in general. 2. The vld*() returns values as a single integer (such as EI mode), while uses of the value will typically be in a vector mode such as V4SI. CANNOT_CHANGE_MODE_CLASS doesn't allow direct "mode-punning" between the two in VFP_REGS, so this again forces the punning to be done on the stack. The code in question is: /* FPA registers can't do subreg as all values are reformatted to internal precision. VFP registers may only be accessed in the mode they were set. */ #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ ? reg_classes_intersect_p (FPA_REGS, (CLASS)) \ || reg_classes_intersect_p (VFP_REGS, (CLASS)) \ However, the VFP restriction appears to be specific to VFPv1 -- thanks to Peter for the archaeology -- and isn't a problem for v6+. In that case, removing this restriction is an important optimisation. I tried the patch below on the following simple testcase: #include "arm_neon.h" void foo (uint16_t *a) { uint16x4x3_t x, y; x = vld3_u16 (a); y = vld3_u16 (a + 12); x.val[0] = vadd_u16 (x.val[0], y.val[0]); x.val[1] = vadd_u16 (x.val[1], y.val[1]); x.val[2] = vadd_u16 (x.val[2], y.val[2]); vst3_u16 (a, x); } (not necessarily sensible!). Before the patch, -O2 produced: sub sp, sp, #48 add r3, r0, #24 vld3.16 {d16-d18}, [r3] vld3.16 {d20-d22}, [r0] add r3, sp, #24 vstmia sp, {d20-d22} vstmia r3, {d16-d18} fldd d19, [sp, #8] fldd d16, [sp, #0] fldd d17, [sp, #24] fldd d20, [sp, #32] vadd.i16 d18, d16, d17 vadd.i16 d17, d19, d20 fldd d19, [sp, #16] fldd d20, [sp, #40] vadd.i16 d16, d19, d20 fstd d18, [sp, #0] fstd d17, [sp, #8] fstd d16, [sp, #16] vldmia sp, {d16-d18} vst3.16 {d16-d18}, [r0] add sp, sp, #48 bx lr After the patch we get: vld3.16 {d24-d26}, [r0] add r3, r0, #24 vld3.16 {d20-d22}, [r3] vmov q8, q12 @ ti vadd.i16 d17, d17, d21 vadd.i16 d16, d24, d20 vadd.i16 d18, d26, d22 vst3.16 {d16-d18}, [r0] bx lr The VMOV is a bit disappointing, and needs further investigation. The first hunk fixes (2), and I think is correct. The second hunk hacks (1), and isn't suitable in itself. I'll next try to make arm_neon.h use built-in record types that are explicitly EImode, which should remove the need to change MAX_FIXED_MODE_SIZE. Richard Index: gcc/gcc/config/arm/arm.h =================================================================== --- gcc.orig/gcc/config/arm/arm.h +++ gcc/gcc/config/arm/arm.h @@ -1171,10 +1171,12 @@ enum reg_class /* FPA registers can't do subreg as all values are reformatted to internal precision. VFP registers may only be accessed in the mode they were set. */ -#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ - (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ - ? reg_classes_intersect_p (FPA_REGS, (CLASS)) \ - || reg_classes_intersect_p (VFP_REGS, (CLASS)) \ 2+#define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \ + (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \ + ? (reg_classes_intersect_p (FPA_REGS, (CLASS)) \ + || (TARGET_VFP \ + && reg_classes_intersect_p (VFP_REGS, (CLASS)) \ + && arm_fpu_desc->rev == 1)) \ : 0) /* The class value for index registers, and the one for base regs. */ @@ -2458,4 +2460,6 @@ enum arm_builtins instruction. */ #define MAX_LDM_STM_OPS 4 +#define MAX_FIXED_MODE_SIZE GET_MODE_BITSIZE (XImode) + #endif /* ! GCC_ARM_H */

14 years, 8 months

2
4
0 0

Unavailable for a bit

by Michael Hope

Hi there. We've had an earthquake. Family and friends are fine but i'll be unavailable for a few days. Services on ex.seabright.co.nz are down. I'll cancel Wednesdays standup call. See you soon, -- Michael

14 years, 8 months

2
1
0 0

[ACTIVITY] Feb 14 - Feb 17

by Ulrich Weigand

== GDB == * Working with Will Deacon, identified root cause of GDB problems running on Versatile Express in SMP mode, and verified that Errata workaround fixes the problem * Finished testing GDB HW watchpoints patch on vexpress, submitted complete patch set for mainline inclusion * Reviewed Yao's mainline patch to enable displaced stepping in Thumb mode 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, 8 months

2
3
0 0

[ACTIVITY] Feb 14 -- Feb 20

by Chung-Lin Tang

== Last week == * PR46178, PR46002: both upstream issues related to the priority coloring mode of IRA. Both patches submitted, the first already approved and committed. Vladimir M. did mention that the priority algorithm would be removed once his newer "cover class-less" patches goes in during stage1. Anyways, I got more familiar with IRA during the process, and the patches will still be applicable to 4.5/4.6. * PR43872: incorrectly aligned VLAs under ARM. This turned out to be a one-liner fix. Submitted upstream awaiting approval. * Discussed on email/IRC with Revital Eres on SMS and ARM doloop pattern issues. * Launchpad #721021: Linaro GCC ICE under -mtune=xscale. Investigated a bit; did not see ICE immediately, but GCC went into infinite loop (Khem Raj, the reporter, says it runs for a while then ICEs). * Coremark ARMv5TE vs ARMv7-A performance regression: reproduced consistently using our own Tegra boards. Investigated and seem to have found something, will post more detailed findings later. == This week == * Coremark investigation. * More GCC issues.

14 years, 8 months

1
0
0 0

Continuous build results

by Michael Hope

Hi there. I've created a new mailing list for the automated build results of Linaro GCC, Linaro GDB, and (once-weekly) FSF 4.5 and 4.6. You can subscribe by going to: https://launchpad.net/~linaro-toolchain-builds I've subscribed everyone in the toolchain working group. If you'd like to get these emails, go to: https://launchpad.net/people/+me/+editemails and set 'Linaro Toolchain Builds' to 'Preferred address'. Any build failures will also go to linaro-toolchain(a)l.linaro.org. The archive is here: https://lists.launchpad.net/linaro-toolchain-builds/ You can also track the crude state of the build hosts here: http://ex.seabright.co.nz/helpers/scheduler and see things status scroll by on #linaro-cbuild on Freenode. This was kicked off due to the problems with the 2011.01 release. The follow-up is tracked here: https://blueprints.launchpad.net/gcc-linaro/+spec/incident-followup-1 -- Michael

14 years, 8 months

2
2
0 0

[ACTIVITY] 14th - 19th February

by Andrew Stubbs

== GCC == Posted 2 of our 4.5 patches upstream. My latest 4.6 build and test completed, so I've pushed an update to the bzr branch. The branch is now up to mainline state as of the 12th. Merged 3 4.5 patches into Linaro GCC 4.6. Upstream review isn't happening, so I've decided to commit them anyway. The last upload (FSF mainline as of 12th Feb) will therefore become the baseline I'm going to use for Linaro GCC 4.6. Begun benchmarking the questionable patches before forward porting them, using EEMBC. Michael Hope has given me access to one of his A9 Panda boards in New Zealand. This ought to have been straight-forward, but of course it wasn't. It took me a while to convince myself I was getting meaningful results and testing the right thing. Also the A9 seemed to be able to complete the configured iterations in 'zero' time, which fooled me for a while. I think I now have a set up that works. It seems to run very slowly sometimes though - something to do with SSH? ---- 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 * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html

14 years, 8 months

1
0
0 0

[ACTIVITY] report week 07

by Peter Maydell

RAG: Red: Amber: Green: DATE/QEMU conference place confirmed, travel booked Current Milestones: | Planned | Estimate | Actual | qemu-linaro 2011-03 | 2011-03-08 | 2011-03-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 | first qemu-linaro release | 2011-02-08 | 2011-02-08 | 2011-02-08 | * maintain-beagle-models: + implemented missing epoll syscalls for qemu usermode, submitted upstream https://bugs.launchpad.net/qemu-linaro/+bug/644961 + tracked down the problem causing serial console to break: the new Linux driver uses some extra features of the UART which we weren't modelling https://bugs.launchpad.net/qemu-linaro/+bug/714600 * merge-correctness-fixes: + reworked VZIP/VUZP patch as per review comments, resubmitted + reviewed CL's latest shift patches, added fixes of my own for large shift counts and overlapping src/dest regs, submitted a 10 patch rolled up series + reviewed a patch for adding cp15 VA-PA translation ops + reviewed various versions of vrecpe/vsqrte patches from CL * versatile-express model: B Labs kindly made available their Versatile Express board model: https://github.com/bbalban/qemu/commits/universal-branch and I've spent a few days getting it to boot a Linaro kernel, fixing a few bugs and cleaning up the patchset in preparation for upstreaming it. This included discovering a bug in qemu's SD card model which was causing Linux not to be able to detect cards on PL181, and resulting in spurious qemu warnings on omap3: https://bugs.launchpad.net/qemu-linaro/+bug/714606 * other: + ARM architecture Q&A for modelling engineers + booked travel/hotel for QEMU conference * meetings: toolchain, PDSW-tools, PD comms, Linaro-in-ARM network infrastructure, pdsw-doughnuts and 1st birthday celebration, 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, 8 months

1
0
0 0

[ACTIVITY] weekly status

by Ken Werner

Hi, * continued to look into latrace and found an issue in case a dynamic library gets unloaded. Otherwise latrace looks quite good on ARM. https://wiki.linaro.org/KenWerner/Sandbox/latrace * chasing bugs: - After a lot of testing Andy Green has made a big step forward in finding the root cause for the shut-down issue of my PandaBoard. The PMIC is seeing an overcurrent and issues an interrupt that gets ignored by current kernels. Then the PMIC shuts the board down for safety reasons. As a workaround Andy has made a kernel patch for the twl6030 driver that enables all interrupt sources. The kernel will acknowledge the overcurrent reported by the PMIC and the board survives. A patched kernel binary can be found at: https://wiki.linaro.org/KenWerner/Sandbox/708883 - While testing Andys patches on the linaro natty kernels I ran into https://bugs.launchpad.net/bugs/720055 - The flash-kernel utility doesn't work on the PandaBoard because the subarch check expects omap4 instead of omap: https://bugs.launchpad.net/bugs/721147 - Looked into the apr fail (process shared mutex's fail on armel v7). Their mutex functionality can be mappped to various methods, but only pthread is of interest here. The code relies on pthread_mutex_lock and pthread_mutex_trylock which is implemented by the (e)glibc. The c library uses GCCs __sync primitives if eglibc >= 2.12.1-0ubuntu11 and GCC >=4.5. The testprocmutex testcase passes now. https://bugs.launchpad.net/bugs/604753 Regards Ken

14 years, 8 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/16/2011 01:07:09 PM: > > I've now built a kernel with CONFIG_ARM_ERRATA_720789 enabled, and the > > symptoms indeed seem to have disappeared completely ... > > Yup - that's because without it, invalidating a TLB entry for a particular > process isn't broadcast correctly, so you can end up using the old (pre-COW) > mappings if you're running on a different core. OK. So I guess the only remaining questions is: if this hardware needs the errata fix to work properly, shouldn't it be automatically selected by the kernel configure logic? Note that this appears to happen for certain OMAP boards, see arch/arm/mach-omap2/Kconfig: config ARCH_OMAP4 bool "TI OMAP4" default y depends on ARCH_OMAP2PLUS select CPU_V7 select ARM_GIC select PL310_ERRATA_588369 select ARM_ERRATA_720789 <<===== select USB_ARCH_HAS_EHCI But this does not happen for the vexpress; arch/arm/mach-vexpress/Kconfig has only: config ARCH_VEXPRESS_CA9X4 bool "Versatile Express Cortex-A9x4 tile" select CPU_V7 select ARM_GIC 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, 8 months

2
1
0 0

[ACTIVITY] February 13-17

by Revital1 Eres

Hello, * Continue looking into DENbench benchmarks. * While testing SMS I realized that my current implementation of doloop pattern for ARM does not follow SMS's requirement to have the doloop instructions be decoupled from the other loop's instructions. This happens because doloop uses CC register which might be used elsewhere in the loop. I am looking into a solution for that. Thanks, Revital

14 years, 8 months

1
0
0 0

[ACTIVITY] February 13-17

by Ira Rosen

Hi, This week I looked into DENBench: * sad8_c (hot function from mp4encode) needs SLP reduction, but it also contains cond_expr which cannot be vectorized as reduction, so I don't think there is anything I can do here * fdct_int32 (another hot function from mp4encode) now gets vectorized with vzip/vuzp patch, but the vectorization causes performance degradation here because of multiple register spills. I also noticed that vectorizer costs are not set for NEON, i.e., it uses default costs. So, I am now working on costs for NEON and adding registers consideration into vectorizer's cost model. I also did some general vectorization research, checking opportunities of collaboration with GRAPHITE pass and auto-parallelization. Ira

14 years, 8 months

1
0
0 0

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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 8 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 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, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain