Got SPEC2006 building on Silverbell (VExpress) and Canis1 (Orion). There
are still some issues;
The builds are still going (6 hours so far on a 1GHz A9 for a build and
'test' case), and the Silverbell one has hit an ICE on one of the tests that
looks like 635409,
and also looks like it needs some help getting Perl to work. The build on
Canis has only just started,
but hasn't got Fortran installed.
(The SPEC2006 tools build also failed in the Perl testsuite on sprintf.t and
sprintf2.t which seem to test integer
overflow cases in sprintf % fields)
Added a few of the kernel string/memory routines and bionic routines into my
string/memory graphs and
also ran the tests on the Orion board (similar to other A9 performance - no
surprise).
Wrote up a draft of an email to libffi-dev describing the varargs state; and
as I was doing it realised that
one of the ways didn't quite work and was more messy.
Using rdepends to find all packages using ffi, need to figure out if any
actually care about varargs.
Dave
== GCC ==
* Completed first successful bootstrap and regression test run
of GCC mainline on my IGEPv2 board.
* Worked on implementing fix for #617384
(.debug_line is wrong with -fpic)
* Worked on backporting fix for #662324
(Pointer type information lost in 4.5 debuginfo)
* Analyzed root cause of PR target/46883
(GCC ICE with error: unrecognizable insn)
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
Hi there. I've cancelled the weekly and standup calls for the next
two weeks. The next scheduled call is the standup call on Wednesday
the 5th of January. Please attend if you can as it's our last one
before the sprint.
See you then!
-- Michael
Hi there. The sprint is just around the corner and it's a good time
to think about how we can make best use of the week. I've put some
topics up at:
https://wiki.linaro.org/Events/2011-01-LinaroSprint/ToolChainWG
Please feel free to add to it. Have a think about anything that's
easier to do while everyone is in the same room - things like
discussions, kicking off some work, a bit of pair programming on a
problem, or anything that overlaps with another group or Ubuntu.
-- Michael
RAG:
Red:
Amber:
Green:
Milestones:
| Planned | Estimate | Actual |
finish virtio-system | 2010-08-27 | postponed | |
get valgrind into linaro PPA | 2010-09-15 | 2010-09-28 | 2010-09-28 |
complete a qemu-maemo update | 2010-09-24 | 2010-09-22 | 2010-09-22 |
finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 |
Progress:
* merge-correctness-fixes:
** Submitted patchset upstream to fix NaN propagation to
follow ARM ARM rules rather than x87 semantics:
http://patchwork.ozlabs.org/patch/75742/http://patchwork.ozlabs.org/patch/75743/
* maintain-beagle-models:
** Finished implementation of the OMAP NAND prefetch/postwrite
engine including its DMA support. Patches submitted to the
qemu-maemo upstream tree and merged by Juha:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/1
** Fixed the (cosmetic) bug
https://bugs.launchpad.net/qemu-maemo/+bug/622408
where we were complaining about "Unknown CMD52" when Linux probed
for the presence of SDIO cards. Fix merged into qemu-maemo:
http://meego.gitorious.org/qemu-maemo/qemu/merge_requests/2
* qemu-continuous-integration:
** Discussion with Loic about setting up jobs on his Hudson
instance for testing qemu against snapshots/hwpacks.
* packageselection-arm-n-more-stable-vm-solution-for-arm
** Discussion about Ubuntu moving to using a qemu-maemo based
qemu for ARM purposes. The Ubuntu blueprint is
https://blueprints.launchpad.net/ubuntu/+spec/packageselection-arm-n-more-s…
We need to come to agreement about what parts of this are
going to be done by variously Linaro toolchain, Linaro
foundations and Ubuntu.
** I'm going through doing another rebase-and-package of
the Linaro qemu, and finishing off writing up the notes
on the process:
https://wiki.linaro.org/WorkingGroups/ToolChain/QemuReleaseProcess
Meetings: toolchain, pdsw-tools, pdsw-tools xmas lunch :-)
Issues:
* a number of qemu patches in progress are logjammed behind
the outstanding git pull request
* the dbgsym debug packages for linaro kernels seem to have
vanished:
https://bugs.launchpad.net/linaro-images/+bug/691192
Absences: (complete to end of 2010)
Fri 17 Dec - Tue 4 Jan inclusive.
2011: Dallas Linaro sprint 9-15 Jan. Holiday 22 Apr - 2 May.
Hi,
* I've spent some time for testing the patches that allow the GCC trunk
to bootstrap again on ARM and posted the results to gcc-testresults
* finally tested and posted the patch that optimizes the __sync_*
builtins (#681138) on gcc-patches
* investigated on the state of the crash utility on ARM (or rather its
prerequisites like kexec)
https://wiki.linaro.org/KenWerner/Sandbox/crash-utility
* I'm on holiday now :)
Regards
Ken
Hi,
On Wed, Dec 15, 2010 at 1:44 AM, Michael Hope <michael.hope(a)linaro.org> wrote:
> On Wed, Dec 15, 2010 at 1:05 PM, Steve Langasek
> <steve.langasek(a)linaro.org> wrote:
>> Hi Michael,
>>
>> On Wed, Dec 15, 2010 at 09:29:38AM +1300, Michael Hope wrote:
>>> Hi Steve. I'd like to hand the rest of this over to you if that's OK.
>>
>> Yep, we can take it from here. To be clear, is this an additional change
>> above and beyond what Matthias reports is currently in Ubuntu gcc
>> (http://lists.linaro.org/pipermail/linaro-toolchain/2010-November/000441.html),
>> and if so, in what version of Linaro GCC is it going to become effective?
>> Do we have documentation of what the relevant failure modes caused by this
>> change *look* like, so that we can at least be triaging them appropriately
>> until there's some documentation on how to fix the resulting bugs?
>
> There will be many failures in many packages. The problem is when you
> use conditional suffixes on instructions: previously the compiler
> would insert an implicit instruction before that; now we have to be
> explicit.
>
> The failures are easy to diagnose and fix. The build will fail with a
> message from the assembler along the lines of 'xxx instruction outside
> an IT block'. The fix is to find the inline assembly code, insert the
> appropriate IT instruction, and re-build. The assembler will validate
> the IT instruction against the following conditional instructions so
> the change is quite safe.
Did someone manage to find out which versions of binutils can silently
accept the IT instructions when assembling for ARM?
This affects what advice we should give on how to avoid breaking
upstream with our additions. The safest approach is #ifdefs, but it
will be better for maintenance if we can avoid this, since it will
render the code very messy.
Cheers
---Dave
Hi there. Some of the tr-* blueprints had work items in them and this
was interfering with the tools that the PM guys use. I've created new
engineering blueprints, pulled the work items across into them, and
added the new engineering blueprint as a dependency of the old TR.
Sorry for the blueprint spam. In most cases the new blueprint has the
same name and subject as the TR one, such as the TR:
https://blueprints.launchpad.net/linaro/+spec/tr-toolchain-4.5-in-distros
which is backed by the engineering blueprint:
https://blueprints.launchpad.net/gcc-linaro/+spec/4.5-in-distros
-- Michael
Hi Richard,
Recapping on this earlier conversation:
http://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000030.htmlhttp://lists.linaro.org/pipermail/linaro-toolchain/2010-July/000035.html
Is it worth another attempt to make a case to upstream for supporting
passing -mimplicit-it=thumb by default to gas?
According to my understanding of this issue, my argument would go as follows:
* gcc currently estimates the size of asm blocks, rather than
determining the size accurately.
* gcc cannot guarantee the right answer for asm block size when asm
blocks contain directives etc., however use of directives in asm
blocks is widespread
* gcc cannot guarantee the right answer for asm block size in
Thumb-2. gcc conservatively overestimates the size by assuming that
each statement of the asm block expands to 4 bytes.
* All of Ubuntu lucid and maverick has been built with
-mimplicit-it=thumb passwd by default, with no known build or runtime
failures arising from this (so size issues aside, we have confidence
that the resulting code generation is sound)
* -mimplicit-it=thumb -mthumb makes the asm block size estimation
unsafe: the asm block can exceed the estimated size even in the
absence of directives, which may lead to fixup range errors during
assembly.
* Following the principles already established for Thumb-2 in
general the estimation can be made safe (or, as safe as the
established Thumb-2 behaviour) by raising the assumed maximum
statement expansion size for asm blocks to 6 bytes, since
-mimplicit-it will add as most a single (16-bit) IT instruction to
each statement.
* The vast majority of all asm blocks are small (< 20 instructions,
say), so the overall overestimate in sizes will generally be modest
for any given compilation unit.
* -mimplicit-it is already _required_ by the Linux kernel and
possible other projects.
...so...
* With -mimplicit-it=thumb and a 6-byte asm block statement
expansion size estimate, we have toolchain behaviour which is as
reliable, and as correct, as it is in upstream at present.
* Layout of data in the compiler output will be more optimal in some
cases, and less optimal in other cases, compared with the the current
Thumb-2 behaviour, due to differing asm block size estimates. The
exact behaviour will depend on the distribution of conditional
instructions within asm blocks.
* Taken over a whole compilation unit, the total code size
overestimate (and therefore the impact on object layout) will normally
be modest, due to the small typical size of asm blocks.
* Behaviour for -marm will not be impacted at all.
If gcc currently estimated asm block code size accurately, then I
could understand upstream's objection; but as it stands it seems to me
we wouldn't be making anything worse in practice with the proposed
change; and there is no compatibility impact (other than positive
impact).
Of course, I may have some wrong assumptions here, or there may be
some background I'm not aware of...
Comments?
Cheers
---Dave
== Linaro GCC ==
* Finish testing for big-endian/quad-word patch on mainline, and
send upstream. Not yet reviewed by an ARM maintainer, but Joseph
suggested tweaking DejaGnu's target-supports to better reflect the new
capabilities of the vectorizer in big-endian mode. I've not looked into
that yet.
* Started looking at improving element/structure load/store intrinsics.
Made it so that the structs used for loads/stores are created in the
backend so that the types can be used directly by the builtins, but
discovered that the front-end/middle-end would not play along with that
plan as they are. Thought about ways to fix that.
* Some time spent on other CodeSourcery stuff.
