Hi All,
I've created a new wiki page to track our upstream merge process.
https://wiki.linaro.org/WorkingGroups/ToolChain/GCC4.4UpstreamPatches
I'll add the new patches (using the script) periodically, for now, but
maybe it could go on a cron job somewhere in future.
The idea is that people write useful thing in this page manually, as and
when state changes. If we don't do something like this, we'll lose track
of what's submitted, and what isn't.
Thanks
Andrew
Hi, all,
I notice that linaro-gcc is a native compiler on ARM, when I go through
linaro gcc bugs on launchpad. When we fix bugs, shall we configure gcc
as a native compiler on ARM directly, or configure gcc as a cross
compiler on i386 box? Former needs extra hardware boards, while latter
needs some cross compiling setting. I'd like to know how do you do that?
Hi there. The notes from today's stand up call are available at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2010-07-14
A copy follows.
One thing I forgot is the upcoming sprint. Please add what you'll be
working on to https://wiki.linaro.org/Internal/Events/2010-07-PlatformSprint/ToolChainWG
- it's great for networking as it helps those interested in similar
areas to track you down.
== Attendees ==
* Andrew Stubbs
* David Rusling
* Michael Hope
* Richard Earnshaw
* Ulrich Weigand
* Yao Qi
* Juilan Brown
== Minutes ==
* Andrew has been working on the release. A power failure last night
interrupted the test suite. MLH noted that Matthias has started his
own build/test process. Andrew will hold off re-running the tests
* Richard has been getting involved in the ABI discussions, which
seem to be winding down from ARM's point of view
* Ulrich has been backporting the testsuite fixes. Next task is
looking at gdb. He has run the test suite on gdb 7.2 and found more
failures than expected.
* Yao is continuing on the CSL 4.4 to 4.5 patch set. The process is
still ongoing. MLH offered to help with any Ubuntu specific packaging
problems partly due to being close in timezones.
The next stand up meeting is on Friday the 16th.
-- Michael
I've expanded the notes on using bzr for toolchain development here:
https://wiki.linaro.org/WorkingGroups/ToolChain/BzrTips
It's now much more step-by-step and includes notes on how long
operations take and how big they end up on disk or the network.
-- Michael
Hey
Matthias kicked an armel rebuild of Ubuntu main with a gcc-4.4 + Linaro
diff package. The rebuild copy-archive is visible at:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707
The failed logs are at:
https://launchpad.net/ubuntu/+archive/test-rebuild-20100707/+builds?build_t…
@Steve, you had offered help in reviewing the i386/amd64 rebuilds in
the past (and I think Michael Hope was working on these); I would very
much take help in reviewing the armel issues. Is this something the
Foundations team could help with?
I'd like to discuss organizing this review a bit.
* First, we need to make sure we don't review the same build logs
multiple times; the rebuild isn't over and builds are going to
continue showing up; Matthias told me new build logs will show up at
the top, so we only need to note the last package we reviewed.
* We need some place tracking the build logs which we skipped (for
which we didn't file a bug) and/or note last reviewed package; I
propose to note this down in a wiki page.
* For now, we should skip openjdk / java related issues; openjdk needs
some bug fixing before we can consider using it on armel. Such
issues should be documented along other instructions in the
aforementioned wiki page.
* I think we should skip packages which FTBFS on x86. Do we actually
compare build logs before classifying these?
* We should file bugs with some standard tags, perhaps linaro + armel?
* I would like us to develop helpers to analyze build-logs; perhaps
Lucas Nussbaum has something since he manages to analyze the grid5000
rebuild logs decently. Ideally, these tools would also allow
assigning build log reviews to people, leaving comments and such.
Comments welcome!
Cheers,
--
Loïc Minier
Hi there. What's the appropriate format for a ChangeLog entry when
closing out a issue, or when merging in a change from another branch?
My best guess was:
2010-07-12 Michael Hope <michael.hope(a)linaro.org>
lp:602171
* gcc.target/i386/pr9771-1.c: Merge r159776 from FSF GCC into the
Linaro branch.
* gcc.target/arm/frame-pointer-1.c: Likewise.
Original entry:
2010-05-24 Paul Brook <paul(a)codesourcery.com>
* gengtype-lex.l: Add HARD_REG_SET.
* expr.c (expand_expr_real_1): Record writes to hard registers.
* function.c (rtl_data): Add asm_clobbers.
* ira.c (compute_regs_asm_clobbered): Use crtl->asm_clobbers.
(ira_setup_eliminable_regset): Remove regs_asm_clobbered.
Use crtl->asm_clobbers.
Note that the change was already present but the test cases hadn't
been updated.
In this case I back-ported Subversion revision 159776 from the FSF GCC
into the Linaro branch to fix a Launchpad ticket that was assigned
against me. Paul Brook did the original work. The note at the bottom
is due to most of the fix already existing in the Linaro branch.
-- Michael
