Hi!
* Finished gcc-4.7 benchmarking:
https://wiki.linaro.org/Internal/ToolChain/Benchmarks/gcc-4.7_benchmarking
Results uploaded to
lp:~linaro-toolchain-wg/linaro-toolchain-benchmarks/private-runs
* Development benchmarks:
Continued the work started at connect.
Got stuck for a while with a problem with the launchpad staging area. I
could no longer log in. Seems the staging area is reset at weekends. The
user credentials has to be given again, but you first have to remove them
manually from the GNOME keyring (or whatever place they are stored).
* Bug triaging:
Triaged these bugs: https://launchpad.net/bugs/926855,
https://launchpad.net/bugs/925991, https://launchpad.net/bugs/924726.
Regards
Åsa
Hi there. I've cancelled the Monday and stand up calls for this week.
Andrew, could you run the standup call on Thursday please? The
moderator details are at:
https://wiki.linaro.org/Internal/ToolChain
-- Michael
* Linaro GCC
Continued work on 64-bit shifts. My patch for shifts in core registers
was rejected because I used conditional-execution before it's safe,
apparently, so I've spent some time looking at the alternatives.
First, conditional move instructions were unsatisfactory - the final
instruction sequence was longer and therefore less efficient.
Second, if_then_else instructions (basically conditional execution
expressed a different way) was to limited - there were no patterns
compatible with "or with shifted input" available in ARM mode, and no
patterns available at all in Thumb mode. I solved that easily enough, of
course, but the result was still unsatisfactory. In Thumb mode the
result was roughly equivalent (conditional-execution is constrained by
IT blocks), but in ARM mode it uses patterns that output two opposing
instructions at once, without allowing for the possibility of scheduling
or other optimization.
Third, I've tried putting in ordinary branches and relying on the
if-conversion pass to transform that to conditional execution. I had not
done this initially, partially because I didn't know how, but mostly
because the original implementation I was trying to replace resulted in
branches in the output code, and I was trying to improve on that.
Anyway, I've now figured out how to do that, and initial testing
suggests that the if-conversion really is working this time. Even if it
doesn't always, the other improvements to the shift sequence should
still give a boost.
My other patch, to do 64-bits shifts in NEON (and fall back to the above
code when register allocation sees fit) has not yet been reviewed.
* Linaro Connect
This week was Linaro Connect week. I could not attend the event in San
Francisco in person this time, so I took part in some of the morning
sessions remotely.
Linaro have switched to using Google Hangouts for the remote
participation, and it went really rather well. In the old system there
was an audio stream to listen to (on a 20 second delay or so, usually),
and an IRC room projected onto a large screen for remote attendees to
respond. The new Hangout system is effectively a simple in-browser
video-conference system that allowed us to not only see the room, but
also respond verbally in real time. The only disadvantage is the
10-person limit, but I never saw any room get near that all week.
I successfully attended several sessions and one regular meeting
remotely by these means. And no jet lag or eating so much!
Hi,
Made the GDB 7.4-2012.02 release:
* Learned about cbuild and how to use its services.
* Prepared a GDB Linaro 7.4-2012.02~rc1 tarball and ran on cbuild.
* Compared test results on ARM and i686 with the ones from 7.3-2011.12.
Investigated new failures, determining that all come from new
testcases added since the last release. One seemed important but
when investigated it turned out to be a bug in the hand-written
debug info for the testcase, which is wrong on ARM. I opened
bug reports on Launchpad for the new failures which are worth being
investigated for future releases. There are no regressions
in 7.4-2012.02 compared to 7.3-2011.12.
* Executed the release process for Linaro GDB.
* Started exploring GDB on Android.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
OpenEmbedded-Core:
* tested the external-toolchain branch from C. Larson
* changes now upstream
* rebased my changes to the current oe-core trunk
* startet to setup a proper external layer at:
git://git.linaro.org/people/kwerner/meta-linaro.git
* got the minimal, sato and Qt image built again
(only two patches required on the oe-core tree)
Misc:
* remotely attended some Linaro Connect sessions
Regards,
Ken
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro GDB 7.4 2012.02.
Linaro GDB 7.4 2012.02 is the first release in the 7.4 series. Based off
the latest GDB 7.4, it includes a number of ARM-focused bug fixes and
enhancements.
Interesting changes include:
* Update to GDB 7.4 code base.
* The "info proc" and "generate-core-file" commands will now also
work on remote targets connected to GDBserver on Linux.
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.4-2012.02
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2012-02.
Linaro QEMU 2012.02 is the latest monthly release of qemu-linaro. Based
off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes
and enhancements.
New in this month's release:
- A simplified A15 model (non-LPAE) which is sufficent to boot a
carefully-configured Linux kernel.
Known issues:
- Graphics do not work for OMAP3 based models (beagle, overo)
with 11.10 Linaro images.
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.02
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
The Linaro Toolchain Working Group is pleased to announce the 2012.02
release of Linaro GCC 4.6 and Linaro GCC 4.5.
Linaro GCC 4.6 2012.02 is the twelfth release in the 4.6 series. Based
off the latest GCC 4.6.2+svn183786, it contains a few bug
fixes and backports Cortex-A7 and Cortex-A15 support from FSF trunk.
Interesting changes include:
* Updates to 4.6.2+svn183786.
* Add initial Cortex-A7 support.
* Backport Cortex-A15 tuning improvements from upstream.
* Backport improvements to 64 bit unsigned comparisons.
Fixes:
* LP: #917967 Backport the fix for PR51799.
* LP: #836588 armel FTBFS with gcc 4.5 org 4.6 O2 and fPIC.
* LP: #879725 ICE in int_mode_for_mode, at stor-layout.c:490.
Linaro GCC 4.5 2012.02 is the eighteenth release in the 4.5 series. Based
off the latest GCC 4.5.3+svn183785, it is a maintenance only release.
Interesting changes include:
* Updates to 4.5.3+svn183785.
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.6-2012.02https://launchpad.net/gcc-linaro/+milestone/4.5-2012.02
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
More information on the features and issues are available from the
release page:
https://launchpad.net/gcc-linaro/4.6/4.6-2012.02https://launchpad.net/gcc-linaro/4.5/4.5-2012.02
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bugs: https://bugs.launchpad.net/gcc-linaro/
Questions? https://ask.linaro.org/
Interested in commercial support? inquire at support at linaro.org
-- Ramana
Hi,
I'm doing some tricks with Linux kernel and I'm dependent on
bootloader atags passing.
On PandaBoard the u-boot is always passing DTF/Atags pointer in r2
register, and I'm kind of depending on it. I need to emulate this
behavior by -initrd qemu's argument. However it seems that
qemu-system-arm zeros the registers on the start, and places atags in
some hardcoded memory address no matter what.
Is this behaviour really OK? Isn't r2 register a proper way to pass
atags on ARM platform? If so, would you merge into mainline a patch
that implement this? I could write it, but I don't want end-users of
my work to have to patch and compile Qemu manually.
Please CC me, I'm not following actively these mailinglists.
Regards,
--
Dawid Ciężarkiewicz
Please take the time to comment on this mockup, would it be useful for you?
what other info you like to see to make your job easier, know what you have
on your plate, your WIs progress, what is next in priority ....
BR,
Mounir
---------- Forwarded message ----------
From: Guilherme Salgado <guilherme.salgado(a)linaro.org>
Date: Wed, Feb 1, 2012 at 9:54 AM
Subject: [RFC] Upcoming work view for individual engineers
To: linaro-dev(a)lists.linaro.org
Hi folks,
We're trying to make status.l.o more useful to engineers and the first
thing we're planning to do is a new page listing the upcoming work
assigned to a given person. I'm attaching a mockup of that view here and
we'd like to know what you think of it... Do you think that would be
useful to you? Is there any other information you'd like to see there,
or maybe a different way to present/group them?
Cheers,
--
Guilherme Salgado <https://launchpad.net/~salgado>
_______________________________________________
linaro-dev mailing list
linaro-dev(a)lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Mounir Bsaibes
Project Manager
Follow Linaro.org:
facebook.com/pages/Linaro/155974581091106http://twitter.com/#!/linaroorghttp://www.linaro.org/linaro-blog <http://www.linaro.org/linaro-blog>
