[ACTIVITY] December 6th-12th

2010-12-14 Thread Julian Brown 
== 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.

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Re: RFC: -mimplicit-it and GCC upstream

2010-12-14 Thread Dave Martin 
Hi,

On Tue, Dec 14, 2010 at 3:24 AM, Michael Hope  wrote:
> On Mon, Nov 22, 2010 at 11:35 PM, Dave Martin  wrote:
>> On Wed, Nov 17, 2010 at 11:22 AM, Dave Martin  wrote:
>>> On Wed, Nov 17, 2010 at 2:53 AM, Michael Hope  
>>> wrote:
 In general the product should move forward and drop work-arounds like
 -mimplicit-it.  We (the greater ARM community) should fix these
 package problems as they are found.  Here's a bunch of quick-fire
>
> Just to finish this thread off, the following decisions were made:
>  * -mimplicit-it will not be passed to the assembler by default
>  * Linaro as a whole and Linaro Foundations in particular will fix any
> problems upstream as found

Just to add to this, we need to work with the Ubuntu guys to ensure
that all problems caused by this compiler change are tracked.

I've seen a few bugs going past where the Ubuntu maintainers quickly
"fix" the affected package by building with -marm.  This is OK for
getting the package building in the short term, but we need to be
careful to ensure these problems aren't forgotten about.

Secondly, the people maintaining the affected upstream projects may
not be builing for Thumb-2 regularly-- this means that packages may
break again due to upstream maintenance.  In rare cases, maintenance
changes which cause incorrect execution in Thumb-2 might not cause
build failures.  We need to be vigilant about this, and accompany
changes pushed upstream with comments advising how to avoid this.

I expect the most practical approach is to write up advice on the wiki
or somewhere, and refer developers to it, especially linaro and
ubuntu-arm guys.  I can have a go at drafting that, but it may not
happen until January...

Cheers
---Dave

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Blueprint changes

2010-12-14 Thread Michael Hope 
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

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain