Re: Toolchain Connect sessions

2011-10-27 Thread Michael Hope
On Thu, Oct 27, 2011 at 2:57 AM, Peter Maydell  wrote:
> On 25 October 2011 09:54, Michael Hope  wrote:
>> Hi there.  Connect is just around the corner.  Have a look at:
>>  https://wiki.linaro.org/MichaelHope/Sandbox/Q4.11Plans
>
> (Also, should there be a blueprint for the A15 KVM discussion?)

Hi Peter.  Sorry, time is escaping me.  Could you please log a QEMU
KVM stage one blueprint and perhaps a KVM planning blueprint?

The stage one blueprint should discuss what we need for a first usable
version.  It should be reliable and usable, but doesn't have to be
robust or fast.

The KVM planning/futures could be later in the week and talk about how
Linaro turns KVM into a product including kernel support, hardware
packs, integration in Ubuntu, making it robust, making it fast, and
the server level virtualisation features like migration that might be
needed.

-- Michael

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


[ACTIVITY] October 23-27

2011-10-27 Thread Ira Rosen
Hi,

- Merged to gcc-linaro:
  - widening shifts
  - SLP features: support loads with different offsets and swap
operands if necessary

- Started rewriting SLP analysis to support operations with more than
two operands (towards SLP of conditions)

- Updated NEON presentation following Ramana's suggestions (thanks!)

- Suggested to Ramana to implement vcond with mixed types, created a
blueprint: 
https://blueprints.launchpad.net/gcc-linaro/+spec/vcond-with-mixed-types

- Vectorizer:
   - updated vectorizer's webpage
   - updated vectorizer's wiki page
   - the usual maintenance

- Committed upstream two SLP data-ref analysis improvements: PR 50730
and PR 50819

Ira

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


[ACTIVITY] 24th - 28th October

2011-10-27 Thread Andrew Stubbs

Posted a patch upstream to fix big-endian for generic tuning. This was a
simple omission from my previous patches.

Merged GCC 4.6.2 to Linaro GCC. It's still in testing now, so I'll have
to commit it sometime over the weekend or next week.

Looked at the benchmark results from Spec2000 running on both A8 and A9
systems, with and with NEON, and with various compiler options. Posted
the results in a spreadsheet (visible within Linaro only).

Begun making adjustments to generic tuning and started new spec2k runs
to see if they are beneficial. First, I'm trying A9 prefetch settings on
A8 to see how much damage it does. Next I'll try enabling the A8 NEON
tuning settings on A9 to see what happens there.

Prepared for travel next week.

Vacation Friday

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


Re: [ACTIVITY] WW42

2011-10-27 Thread Michael Hope
On Thu, Oct 27, 2011 at 5:18 PM, Zhenqiang Chen
 wrote:
>>> zlib is used to build binutils, which is built before GCC.
>>> If you install a 32-bit binary toolchain on 64-bit system, you might
>>> have link error. By default, there is no 32-bit zlib on 64-bit system.
>>> You have to  install 32-bit zlib manually.
>>
>> Yip, but both binutils and GCC include a local copy of the zlib source
>> that can be statically linked in during the build.  It might be easier
>> than doing it separetly, especially as zlib is messy to build.
>
> Are you sure?
> I check binutils-2.21 source code. There is no zlib related source
> code like zlib.h. If it has, we should not build zlib separately.

Sorry, I was wrong.  sourceware src/ has zlib.  gcc pulls that in but
binutils doesn't.

>  (3) Currently, the embedded toolchain source packages are released
> as a tarball, which includes gcc, gmp, etc. New scripts are required
> to support it.

 We should check what needs to be done to meet the licenses.  All of
 the tarballs used in building the binary are in .build/taraballs.
>>>
>>> I will add scripts to copy the tarballs to .build/tarballs.
>>
>> From I guess?
>
> The root cause for this gap is that current embedded toolchain release
> creates some source packages from internal git server. And the package
> name is not in standard format: NAME-VERSION.
>
> The script will be a workaround to build and test the embedded toolchain.
>
> I will work with local team to improve the build process for future
> release. All the source packages should get from public links with
> standard format.
>
>> The glibc is more of a concern than the compiler.  RHEL 5 is the
>> earliest version we need to support which is GLIBC 2.5 based.  Ubuntu
>> 8.10 uses GLIBC 2.8 and might turn on other features like hardening or
>> the stack protector which could cause trouble.
>>
>> I think we should build and test the binary under RHEL 5 itself.
>
> Stack protector is the issue on RHEL5.
> For us, we should build and test the binary under RHEL5.

Agreed.

> What do we release: series of toolchains for different versions of
> Linux or just one which can run on most popular linux versions?
> If we only release one binary, what's the preferred build system? And
> we should make sure it can run on different linux systems.

In the requirements spec I said we should support the following:

Redhat Enterprise Linux 5.7
Ubuntu 10.04.3 and 11.05
Fedora 15
Debian 6.0.2
openSUSE 11.4

If we build on the oldest (RHEL 5) then it should work on the more
recent versions.  We'll need to test on all of these for the first
release, but should be able to just test on RHEL and, say, Ubuntu
11.05 for subsequent versions.

The cloud and virtualisation does make this easier.

-- Michael

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