== GCC related ==
* Launchpad #693686, GCC ARM segfault ICE when building Chromium in V8.
Spent some time reproducing; this ICE seems to be in the maverick
gcc-4.5, at the vectorizer phase. As the ICE happens in
tree-vect-stmts.c:supportable_widening_operation(), I'm suspecting
(without further verification yet) this might be due to vmovn not
backported? (Linaro 4.5 does has this ported I think)
* PR44557, Thumb-1 ICE. Looking further after seeing Richard Earnshaw's
comment on my patch. It would be nice if we could upgrade the entire
secondary reload bits, looking into this.
== This week ==
* Look into more GCC issues.
* Get some backports done.
== Linaro GDB ==
* LP:615972
Get patch approved upstreams. Committed to FSF tree. Propose merge
request to Linaro GDB tree.
* LP:616003 gdb.mi/mi-var-display.exp failure
Discussed in upstreams on how to handle fp in ARM/Thumb mode. Finally
work out a one-line patch. Approved and committed to FSF tree. Propose
merge request to Linaro GDB tree.
Draft another patch to clean up ARM register alias. Pending on upstreams.
* LP:616000 Handle -fstack-protector prologue code
Revise patch per Joel's comments. Approved, and committed to FSF tree.
Draft two patches to handle -fstack-protector prologue code on i386.
Sent them out for review. Due to lack of knowledge on i386 prologue
generate, not very confident on one of these patches.
* LP:615980 Support displaced stepping on Thumb
Get my test case to arm displaced stepping approved, and committed to
FSF tree.
A patch about supporting displace ARM insn in Thumb area is pending
upstreams. Tried the 2nd approach since the 1st approach is not
acceptable to upstreams reviewers. Without this patch, ARM displaced
stepping doesn't work on Linaro.
Support another three PC-related 16-bit Thumb insns (adr, ldr, and
cbz), and add test cases for them accordingly.
Spend some time splitting my big patch into three relatively small
patches in order to make them easier to be reviewed. Patches on
supporting Thumb 16-bit displaced stepping are sent out upstreams for
review.
== This Week ==
* Work from Mon. to Wed.
** Backport some approved upstreams patches to Linaro GDB
** Anything I should do for my pending patches.
* Vacation on Thu. and Fri. 3rd Jan. is China public holiday. Back to
work on 4th. Jan.
--
Yao (齐尧)
Khem Raj <raj.khem(a)gmail.com> wrote:
> The bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46883 files
> against GCC trunk also happens with linaro gcc 4.5
> My guess is that there is a backported patch from trunk into linaro
> 4.5 tree thats causing this ICE
>
> This ICE does not happen on upstream gcc-4.5 branch
Thanks for the bug report!
> I havent figured out the commit yet.
It looks like the regression was introduced by Bernd Schmidt's
patch to improve zero-/sign-extensions (PR 42172), which we
did indeed backport to Linaro GCC 4.5. (I've updated the
PR 46883 bugzilla with more details.)
> Should you need a bug in linaro
> bug tracker I will be happy to file one
Yes, please do so; this makes it easier to track the problem
on the Linaro side. Thanks!
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
== GCC ==
* Checked in mainline fix for #617384 and submitted backport merge
requests (.debug_line is wrong with -fpic)
* Submitted backport merge requests for the fix for #662324
(Pointer type information lost in 4.5 debuginfo)
* Checked in mainline fix for #693425 and submitted backport merge
request (SPU back-end incompatible with extension elimination pass)
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand | Phone: +49-7031/16-3727
STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E.
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi,
I was on vacation on Sunday and starting from Tuesday stayed home with
a sick child, so I only had a couple of days to work.
* vectorization of Viterbi:
- continued implementing conditional store sinking in cselim pass
- made if-conversion to work on loads of structure fields if other
field from the same structure is accessed unconditionally
* fixed GCC PR 47001.
Ira
Continued looking at SPEC 2006.
The two ICEs I mentioned last week are gone on the Natty version of the
compiler, however the 4 programs that run and give the wrong
results still happen with the Natty version and the latest version from bzr.
The 4 failures are:
h264ref - still fails on bzr 99447 with -O2 or -O0
sphinx3 - still fails on bzr 99447 with -O2 or -O0
gromacs - still fails on bzr 99447 with -O2 but works with -O1; I've
followed this through and detailed it in bug 693502; it looks to me like
a post-increment gone wrong (it's split so it's not
actually a post increment and the original rather than post inc'd value gets
used)
zeusmp - this fails to load the binary; it's got a >1GB bss section.
Interestingly it gets further on my beagle with less memory but a bit of
swap,
even though I think it's not really using all of the BSS
in the config I'm using.
I'm hoping to leave a 'ref' run going over the new year.
The canis1 Orion board I was also running Spec on last weekend died during
the run and hasn't come back.
perf
We now have silverberry using the -proposed kernel which has the fixed
PERF_EVENT config, and perf seems to work fine.
libffi
I've started building the page
https://wiki.linaro.org/WorkingGroups/ToolChain/FFIusers listing things
that use FFI; (generated by a bit of apt wrangling).
There are basically 3 sets:
a) Apps that just use ffi for something specific
b) Languages that then let the users of those languages have varying
degrees of freedom in themselves
c) Haskell - While some of the packages are actually probably ffi
users, I think a lot of these are false dependencies; almost every haskell
user seems
to gain a dependency on libffi directly.
I'm back on the 4th January.
Dave
Hi,
I continued looking into EEMBC benchmarks:
- telecom fft is not vectorized because unknown number of iterations.
It has both non-constant step and its loop bound may overflow. I
think, the solution here could be loop versioning, but since
versioning increases code size, this kind of optimization can be less
beneficial.
- telecom viterbi (vectorization potential gain is 4x) requires
conditional store sinking and load hoisting to enable if-conversion. I
worked on implementation of store sinking this week.
Ira
Ulrich Weigand/Germany/IBM wrote on 12/20/2010 06:01:21 PM:
> Mark Mitchell <mark(a)codesourcery.com> wrote:
> > On 12/20/2010 8:35 AM, Ulrich Weigand wrote:
> > > 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?
> >
> > I haven't participated in the upstream discussion -- I'm way behind on
> > that list :-( :-( -- but I think such sets should be considered valid.
>
> OK, I'll have a look at fixing the SPU back-end then.
I've now fixed this problem in the back-end upstream:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01694.html
I've also created a back-port to Linaro GCC 4.5 and proposed the
branch for merge; you can find the details at:
https://bugs.launchpad.net/gcc-linaro/4.5/+bug/693425
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
== Last Week ==
* Continued working on ARM unwinding in libunwind. Produced a draft
write-up of my progress in the event that I don't finish this work
before being swapped out of Linaro.
* (Re-)submitted patches to fix ltrace test suite. Hopefully, these will
be the last changes before the new release.
== This Week ==
* Continue working on libunwind.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
Hi,
We would like to build Android with the Linaro tool chain. Do any of you
know what kind of work will be needed to adapt Linaro gcc to Android?
Regards,
Patrik
== GCC related ==
* CS Issue #10201 / PR46883, unrecognizable insn ICE when compiling
Samba. Fixed this by changing the predicates of two split patterns.
Patch reviewed in CS internally and upstream, committed upstream, will
backport to SG++ and Linaro soon.
* LP:641397/PR46888: bitfield insert optimization. Andrew Pinski found a
testcase that escapes the CSE patch gets handled by combine, and also
found another bug with REG_EQUIV notes. Only looked at this minimally
last week, will really work on this later.
* LP:687406/PR46865, -save-temps creating different code. Backported and
bzr-pushed the upstream fix by Jakub Jelinek.
* PR45416, ARM code regression. Mostly can generate what I wanted by
now, under ARM and x86, although patch is still not in a submittable state.
* VFP index patch. Uncommitted GCC patch of mine from last year; added
Thumb-2 bits and corrected some things in the testcase. Committed upstream.
== This week ==
* Really get January travel stuff nailed.
* Upstream patch review is probably going to start getting
slow/suspended this week. Will probably do some study stuff on larger
projects.
* Continue to look at GCC issues.
== Linaro GDB ==
* LP:615972 Different output of 'info register' w/ and wo/ corefile.
Understands gcore impl in gdb. Two patches are reviewed in upstreams.
One is approved by Dan, and the other is still be reviewed.
Evaluate the two approaches for NEON registers in corefile. Resume the
discussion on kernel support for dumping NEON registers. Need a
decision with kernel side, but no progress on it.
* LP:685494 Revise patch per Pedro's suggestion. Waiting for someone
to approve it.
* LP:685702 Get it approved for FSF GDB 7.2 branch. Committed to both
FSF 7.2 branch and Linaro tree.
* LP:616003 gdb.mi/mi-var-display.exp failure
GDB always assumes $fp is r11, even code is in thumb mode. Current GDB
infrastructure can't handle mapping the same alias to two different
registers. Proposed a new gdbarch took for this in upstreams, in order
to increase the flexibility of GDB. No reply yet.
* LP:616001 gdb.mi/mi-var-cmd.exp failure
Ulrich pointed out it is caused by stack randomization. Confirmed this
by setting "kernel.randomize_va_space" to zero. Figure out why this
case passes on x86, because it is more restricted to turn on stack
randomization on x86.
* LP:615980 Support displaced stepping on Thumb
Understands displaced stepping in GDB/ARM. Find a bug when GDB tries to
execute ARM instruction in copy area, which is in Thumb mode (copy area
starts from "_start + 4", and it is compiled in Thumb mode in Ubuntu).
The fix is an one-line patch, which doesn't update status register when
writing PC in displaced stepping.
Write a test case for arm displaced stepping. Write code in ARM asm
directly for the first time, which is very helpful to remember ARM asm
instructions.
Read ARM ARM and decode 16-bit thumb instructions in GDB for displaced
stepping. It doesn't work so far because breakpoint instruction after
instructions in copy area is still hard-coded to ARM breakpoint insn.
== Misc ==
* Linaro GCC optimization meeting.
== This Week ==
* LP:615980 Support displaced stepping on Thumb
Send my fix and test case to upstreams for review.
Make displaced stepping work on 16-bit instruction.
* Ping other GDB patches.
--
Yao (齐尧)
Mark Mitchell wrote:
> > If Profile Guiding could spot that a particular callsite to say strlen()
> > was often associated with strings
> > of at least 'n' characters we could call a different implementation.
>
> I don't believe this is possible current profile-guided optimization,
> but certainly it could be done.
It looks to me like a case of value profiling, see tree-profile.c, for
the various "stringops" optimizations. Unless I misunderstand David's
idea here or missing something else, it seems that this kind of
optimization should fit in the existing infrastructure without too much
effort.
Ciao!
Steven
Does anyone have any experience of what can be profiled in the profiled
guided optimisations?
One of the problems with some of the string routines is that you can write
pretty neat fast routines that
work well for long strings - but most of the calls actually pass short
strings and the overhead of the
fast routine means that for most cases you are slower than you would have
been with a simple routine.
If Profile Guiding could spot that a particular callsite to say strlen() was
often associated with strings
of at least 'n' characters we could call a different implementation.
Dave
* Linaro GCC
lp:686381: C++ link failure on ARM
Reproduced the bug and posted my findings to the bug report - user error.
Changed the way the Linaro GCC version numbers are handled. Hopefully
the new system should be less distasteful to Matthias. Updated the GCC
release procedure document to match.
Organised and chaired a meeting to discuss GCC optimization
opportunities for ARM. It was well attended, and I think we had some
useful discussion. Spend quite some time preparing beforehand, and
writing it up afterwards. Next step is to come up with some actual plans
to implement something. I imagine we can discuss this at the sprint in
Dallas next month. See
https://wiki.linaro.org/AndrewStubbs/Sandbox/GCCoptimizations
* Upstream GCC
My upstream patch to fix ARM smlabb has been approved and committed to
GCC 4.6 (mainline). Only another three patches need approval now!
Continued testing upstream GCC 4.6 with both cross and native builds. It
appears to be in a buildable state now, with no extra patches required.
I've updated the Linaro GCC 4.6 branch with the buildable state.
* Other
Updated my ESTA, and added my security details to the airline bookings.
------
Future availability
20th Dec .. 3rd Jan - Vacation/Holiday
4th Jan .. 8th Jan - Business as usual
9th Jan .. 14th Jan - Linaro Sprint, Dallas
15th Jan .. 21st Jan - CodeSourcery/Mentor Annual Meeting, Scottsdale
24th Jan onwards - normal service restored!
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.
