[ACTIVITY] January 4th - 9th

[Andrew Stubbs]

== GCC ==

Pulled down new commits from upstream GCC. My test build failed due to a 
new cross-build configure problem. Found the problem in GCC Bugzilla, 
and rolled back to the revision before the problem one. Those sources 
built ok, so I've pushed the changes to Linaro GCC 4.6 branch. It it now 
updated to 31st December.


Discussed cross-build problems with Alexander Sack on IRC.

Merged, tested and pushed all the outstanding Launchpad merge requests 
into GCC 4.4 and 4.5.


Merged, tested and pushed all new CS SG++ patches into Linaro GCC 4.5.

Merged, tested and pushed GCC 4.5.2 from upstream into Linaro 4.5.

Spun releases for both Linaro GCC 4.4 and 4.5.

Brought the Linaro patch tracker up to date.

== Other ==

Catch up with lots of email following my two week holiday.

Updated some of the CS patch tracker.

Travel to Dallas for the Linaro sprint.


---
Next week (10th-14th Jan):
 Linaro sprint in Dallas

Following week (17th-21st Jan):
 CS annual meeting in Phoenix

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

Linaro GCC 4.4 and 4.5 2011.01-0 released

[Andrew Stubbs]

The Linaro Toolchain Working Group is pleased to announce the release
of both Linaro GCC 4.4 and Linaro GCC 4.5.

The Linaro Toolchain Working Group is pleased to announce the release of 
both Linaro GCC 4.4 and Linaro GCC 4.5.


Linaro GCC 4.4 is the sixth release in the 4.4 series. Based off the 
latest GCC 4.4.5, it is a maintenance release that fixes one problem 
found through use.


Linaro GCC 4.5 is the sixth release in the 4.5 series. Based off the 
official GCC 4.5.2 release, it includes many ARM-focused performance 
improvements and bug fixes.


Interesting changes include:
 * Improved optimization of multiple load instructions, and 
multiply-and-accumulate.
 * -fshrink-wrap optimization for better use of function prologues and 
epilogues.

 * plus, various other bug fixes, and minor improvements.

The source tarballs are available from:
 https://launchpad.net/gcc-linaro/+milestone/4.5-2011.01-0
and
 https://launchpad.net/gcc-linaro/+milestone/4.4-2011.01-0

Downloads are available from the Linaro GCC page on Launchpad:
 https://launchpad.net/gcc-linaro


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

Linaro GCC 4.5 2011.01-1 released

[Andrew Stubbs]

The previous Linaro GCC 4.5 release, 4.5-2011.01-0, suffered from a 
build failure on x86_64, and PowerPC. ARM and x86 (32) were not 
apparently affected, but users might like to upgrade to be on the safe side.


A bug fix toolchain, 4.5-2011.01-1 has now been released:
  https://launchpad.net/gcc-linaro/4.5/4.5-2011.01-1

The -fshrink-wrap optimization and multiple load improvements have been 
temporarily withdrawn.


This update refers to the GCC 4.5-based tools - the 4.4-based tools are 
unaffected.


We apologise for the inconvenience.

On 11/01/11 11:13, Andrew Stubbs wrote:

The Linaro Toolchain Working Group is pleased to announce the release
of both Linaro GCC 4.4 and Linaro GCC 4.5.

The Linaro Toolchain Working Group is pleased to announce the release of
both Linaro GCC 4.4 and Linaro GCC 4.5.

Linaro GCC 4.4 is the sixth release in the 4.4 series. Based off the
latest GCC 4.4.5, it is a maintenance release that fixes one problem
found through use.

Linaro GCC 4.5 is the sixth release in the 4.5 series. Based off the
official GCC 4.5.2 release, it includes many ARM-focused performance
improvements and bug fixes.

Interesting changes include:
* Improved optimization of multiple load instructions, and
multiply-and-accumulate.
* -fshrink-wrap optimization for better use of function prologues and
epilogues.
* plus, various other bug fixes, and minor improvements.

The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.5-2011.01-0
and
https://launchpad.net/gcc-linaro/+milestone/4.4-2011.01-0

Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro


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



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

Re: x86_64 bootstrap failure in the 2011.01 release

[Andrew Stubbs]

The new release is now available here:
  https://launchpad.net/gcc-linaro/4.5/4.5-2011.01-1

On 12/01/11 10:36, Michael Hope wrote:

Hi there.  Unfortunately the Linaro GCC 4.5 2011.01-0 release has a
failure in the x86_64 compiler causing it to fail during the initial
build.  We're working on triaging the problem at the moment.

ARM and i386 targets are not affected.  I'll send a new announcement
when the problem has been fixed and the replacement 2011.01-1 release
is available.

-- Michael

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



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

[ACTIVITY] 24th -28th January 2011

[Andrew Stubbs]

Created a Google docs spreadsheet to help visualise the benchmark 
results. The graphs are not very informative yet - too many lines and 
too much noise. I'm going to have to revisit them.


Continued trying to build Android. The toolchains build fine, but 
Android itself complains about -Werror, and there are a few other real 
errors too. Considering I was told it built fine with GCC 4.6 and all I 
needed to do was tweak 4.5 to match, I'm not terribly impressed. I'm 
sinking too much time into fixing up Android, and I haven't even got to 
looking at the compiler trouble. Alexander Sack has said he will try to 
get me to a more appropriate starting place (I think), so I'll see what 
happens there.


Discussed my maddhidi4 patch with Richard E (wearing his GCC ARM 
maintainer hat). He's not convinced that my change won't make something 
else produce worse code. I can't prove that it won't either, so I'm 
going to have to revisit it.


Wrote up the GCC 4.6 branch policy and upgrade plan.

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

GCC 4.6 Upgrade Plan

[Andrew Stubbs]

Hi All,

The GCC 4.6 Upgrade plan can be found here:
 https://wiki.linaro.org/WorkingGroups/ToolChain/GCCUpgradePlan

The plan describes how we should commit "upstream" patches while the FSF 
trunk is closed, and what we plan to use 4.6 for.


Andrew

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

Re: gcc-linaro-4.5+bzr99469 build failure

[Andrew Stubbs]

I can't reproduce this failure.

I did the build using am i686-natty chroot, but with an amd64 bit 
kernel, if that makes a difference.


I did it with default configure options, so I'm going to try again with 
the same options you did and see what happens.


Andrew

On 03/02/11 01:17, Michael Hope wrote:

The current revision fails to bootstrap on i686:

http://ex.seabright.co.nz/build/gcc-linaro-4.5+bzr99469/logs/i686-lucid-cbuild45-scorpius-i686r1/gcc-build.txt
libtool: compile:
/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc/xgcc
-shared-libgcc 
-B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/./gcc
-nostdinc++ 
-L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src
-L/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/build/i686-pc-linux-gnu/libstdc++-v3/src/.libs
-B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/bin/
-B/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/lib/
-isystem 
/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/include
-isystem 
/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/i686-pc-linux-gnu/sys-include
-DHAVE_CONFIG_H -I. -I../../../gcc-linaro-4.5/libjava -I./include
-I./gcj -I../../../gcc-linaro-4.5/libjava -Iinclude
-I../../../gcc-linaro-4.5/libjava/include
-I../../../gcc-linaro-4.5/libjava/classpath/include
-Iclasspath/include
-I../../../gcc-linaro-4.5/libjava/classpath/native/fdlibm
-I../../../gcc-linaro-4.5/libjava/../boehm-gc/include
-I../boehm-gc/include -I../../../gcc-linaro-4.5/libjava/libltdl
-I../../../gcc-linaro-4.5/libjava/libltdl
-I../../../gcc-linaro-4.5/libjava/.././libjava/../gcc
-I../../../gcc-linaro-4.5/libjava/../zlib
-I../../../gcc-linaro-4.5/libjava/../libffi/include
-I../libffi/include -fno-rtti -fnon-call-exceptions
-fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64
-ffloat-store -fomit-frame-pointer -Usun -Wextra -Wall -D_GNU_SOURCE
-DPREFIX=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\"
-DTOOLEXECLIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib\"
-DJAVA_HOME=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install\"
-DBOOT_CLASS_PATH=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/libgcj-4.5.2.jar\"
-DJAVA_EXT_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/ext\"
-DGCJ_ENDORSED_DIRS=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/share/java/gcj-endorsed\"
-DGCJ_VERSIONED_LIBDIR=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11\"
-DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\"
-DLIBGCJ_DEFAULT_DATABASE=\"/scratch/cbuild/slave/slaves/scorpius/gcc-linaro-4.5+bzr99469/install/lib/gcj-4.5.2-11/classmap.db\"
-DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.5.2-11/classmap.db\" -g
-O2 -D_GNU_SOURCE -MT exception.lo -MD -MP -MF .deps/exception.Tpo -c
../../../gcc-linaro-4.5/libjava/exception.cc -o exception.o>/dev/null
2>&1
../../../gcc-linaro-4.5/libjava/prims.cc: In function 'jboolean
_Jv_isPrimitiveOrDerived(const Utf8Const*)':
../../../gcc-linaro-4.5/libjava/prims.cc:287:5: internal compiler
error: in set_jump_prob, at stmt.c:2211
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

The log is available here:
  
http://builds.linaro.org/toolchain/gcc-linaro-4.5+bzr99469/logs/i686-lucid-cbuild45-scorpius-i686r1/gcc-build.txt

-- Michael

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



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

Re: gcc-linaro-4.5+bzr99469 build failure

[Andrew Stubbs]

On 04/02/11 01:18, Michael Hope wrote:

On Fri, Feb 4, 2011 at 5:59 AM, Andrew Stubbs  wrote:

>  I can't reproduce this failure.
>
>  I did the build using am i686-natty chroot, but with an amd64 bit kernel, if
>  that makes a difference.
>
>  I did it with default configure options, so I'm going to try again with the
>  same options you did and see what happens.

I can reproduce this from a clean checkout:


OK, my checkout was broken. I hate bzr 

Anyway, the problem was caused by r99469 itself, so I've reverted that 
and started a new test build. If that succeeds I'll push up the 
reversion, and start the release process.


Andrew

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

[ACTIVITY] 31st January - 4th February

[Andrew Stubbs]

== Linaro GCC 4.5 ==

Reviewed, tested and merged all the outstanding patches waiting to go 
into Linaro GCC 4.5. Michael reported that there was a build failure on 
i686 and amd64. I attempted to reproduce this but my builds completed 
successfully - very strange. Eventually I found that I had a corrupted 
checkout and managed to reproduce the problem - thanks bzr! The problem 
is in Tom's recent changes to stmt.c, so I informed him and backed out 
the patches, temporarily.


Spun the Linaro GCC 4.4 and 4.5 release tarballs and passed them to 
Michael Hope for final testing.


== GCC 4.6 ==

Tested a more recent version of GCC 4.6 and pushed it to the bazaar 
repository. Already out of date by the time testing finished of course, 
but never mind. The number of test failures is greatly reduced. Started 
another build/test with an even more up-to-date check-out.


Begun work merging the 4.5 patches into 4.6. Pushed 1 patch upstream. 
Got another ready to go, once I've tested it.


== Android ==

Tried to unpick a large patch I was sent that supposedly added Android 
support to Linaro GCC 4.5. The patch was suspicious from the start 
because it had large changes to gcc/ChangeLog that clearly backed out 
the 4.5.2 release. After comparing it against various sources I 
concluded that it was a 4.6 snapshot from last May with (at least some 
of) the Linaro patches forward ported, and the release numbers fudged to 
look like it was 4.5.2 based. This was not terribly helpful - I can't 
very well backport that into our 4.5 branch!


== Upstream GCC ==

Upstream patches requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* Kazu's VFP testcases:
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html


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

Re: Question about big endian

[Andrew Stubbs]

On 08/02/11 07:33, Ira Rosen wrote:

It certainly helps to understand that I don't want to try that fancy
both-endians build ;)
Is separate big-endian build Really Hard as well?


Yes and no.

It's easy to configure for big endian:
  /configure --target=armbe-linux-gnueabi" .

The hard part is that you'll probably find you need a big endian C 
library, and that means the usual circular compiler<->library dependencies.


Andrew

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

[ACTIVITY] 7th - 12th February 2011

[Andrew Stubbs]

== Linaro GCC 4.5 ==

Re merged all the patches I've had to back out of Linaro GCC due to 
various test failures. I've now found all the extra fixes/patches 
necessary to make them go ... I think. Tested the build and test on ARM 
and x86_64.


== Linaro GCC 4.6 ==

Continued getting the 4.5 patches forward ported to 4.6. I now have 
about 4 patches waiting for review upatream, or ready to be posted. 
Upstream review isn't happening though. This partly due to GCC being in 
stage 4, but mostly due to Richard Earshaw being on sabatical, and the 
other maintainers being inactive. I can see that I'm going to have to 
abandon my hopes of only merging to Linaro GCC once it's been approved 
upstream, and be content with merging to Linaro once it's posted upstream.


Started another test to rebase the Linaro 4.6 branch with the latest 
from upstream. Once that's done, I think I'll start merging my changes 
in, and call that our baseline. (There'll still be merges from upstream, 
but the history will diverge.)




Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* Kazu's VFP testcases:
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html
* Jie's thumb2 testcase fix:
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00670.html

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

[ACTIVITY] 14th - 19th February

[Andrew Stubbs]

== GCC ==

Posted 2 of our 4.5 patches upstream.

My latest 4.6 build and test completed, so I've pushed an update to the 
bzr branch. The branch is now up to mainline state as of the 12th.


Merged 3 4.5 patches into Linaro GCC 4.6. Upstream review isn't 
happening, so I've decided to commit them anyway. The last upload (FSF 
mainline as of 12th Feb) will therefore become the baseline I'm going to 
use for Linaro GCC 4.6.


Begun benchmarking the questionable patches before forward porting them, 
using EEMBC. Michael Hope has given me access to one of his A9 Panda 
boards in New Zealand. This ought to have been straight-forward, but of 
course it wasn't. It took me a while to convince myself I was getting 
meaningful results and testing the right thing. Also the A9 seemed to be 
able to complete the configured iterations in 'zero' time, which fooled 
me for a while. I think I now have a set up that works. It seems to run 
very slowly sometimes though - something to do with SSH?





Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* Kazu's VFP testcases:
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html
* Jie's thumb2 testcase fix:
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00670.html
* ARM EABI half-precision functions
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html

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

Re: Unavailable for a bit

[Andrew Stubbs]

Hi All,

Stephen Doel called me this morning to assure me that Michael is ok, and 
to ask me take over his role as Tech Lead until he is back in action.


I don't imagine that there'll be much to do - you all have your tasks 
and know what you're doing, but I'll be here if you need anything. My 
number is on the Linaro EngineeringTeamContacts wiki page. I'll also be 
on Mumble and IRC, and email, of course.


Michael has cancelled the stand-up call tomorrow, but if anybody has 
anything they wish to discuss, I'm sure it can be un-cancelled.


Best wishes to Michael. I hope this hasn't affected you too badly.

Andrew


On 22/02/11 09:12, Michael Hope wrote:

Hi there. We've had an earthquake. Family and friends are fine but i'll
be unavailable for a few days. Services on ex.seabright.co.nz
 are down. I'll cancel Wednesdays standup call.

See you soon,

-- Michael



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



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

[ACTIVITY] 21st - 26th February

[Andrew Stubbs]

Temporarily took over Tech Lead of the Toolchain Working Group while 
Michael Hope recovers from the Christchurch earthquake. (He's fine, but 
unable to work.) This didn't actually require any action, in the end. 
Michael returned to work towards the end of the week.


Forward ported, benchmarked, and posted one of Mark Shinwell's NEON 
patches upstream.


Further benchmarking was not possible as the Panda board I was using is 
located in Christchurch, NZ.


Merged and tested the FSF GCC 4.5 branch into Linaro GCC. There were a 
couple of test regressions in the fortran testsuite, so I've filed bug 
lp:723086. The other test results were either the same or better.


Benchmarked the ARM A8 function/jump alignment patch to see what effect 
it has in GCC 4.6. Found no measurable improvement in EEMBC. I suggest 
dropping this patch.


Brought the patch tracker up-to-date, and entered tracking tickets for 
all outstanding patches.


Merged FSF trunk to Linaro GCC 4.6.

Committed Jie's Thumb2 testcase fix to FSF GCC trunk. Thanks to Ramana 
for using his new found authority to approve it.


Investigated the suitability of several of the patches for 
forward-porting. Corresponded with Benrd and Julian.





Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* Kazu's VFP testcases:
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00128.html
* ARM EABI half-precision functions
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

Re: [RFC] Linaro Toolchain for Android and NDK

[Andrew Stubbs]

On 01/03/11 07:00, Jim Huang wrote:

I think thats fine. however, how do we ensure that we have patches
>  that always apply to both release/snapshots? do we maintain branches
>  for gcc-patches.git in case you need two versions of patch X if the
>  linaro gcc codebase diverged?

I might need help from toolchain WG.


I aim to have Android support in Linaro GCC soon, but I lack the ability 
to test it. In fact, I have wanted to have Android support in both 
February's and March's release, but it isn't going to happen now.


I did build a Linaro GCC with the Android patches installed, and it did 
appear to build a lot of the Android tree, but the Android build is 
broken. There are problems with -Werror, but even when you work around 
those, it still won't build. :(


When somebody gives me a properly patched Android tree, that will build 
out-of-the-box with GCC 4.6, then I will be unblocked, and Linaro GCC 
will have Android support shortly afterwards. :)


Andrew

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

What configuration(s) to test?

[Andrew Stubbs]

Hi All,

Up until now, I have had no choice but to test toolchain correctness on 
A8 hardware. It made sense to use the same -mfpu settings as the 
Linaro/Ubuntu package builds use. This did not match the policy that the 
interesting platform was A9-NEON, but I didn't have that option.


That's changed now - our Panda boards have arrived! Yay! :)

But, it seems to me that if I change to using the Pandas for correctness 
testing (not performance testing) then I won't be testing what Ubuntu 
will actually use.


So what should I test on?

I'd rather not double my test load by testing on both, but that is an 
option 


Any suggestions?

Andrew

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

Re: Getting linaro toolchain binaries

[Andrew Stubbs]

On 02/03/11 17:52, Nicolas Pitre wrote:

Building a cross-compiler is already a challenge in itself.  Would be
better to build a version that can be installed anywhere like the
CodeSourcery releases and offer that as a tar download.


Binaries that can be run anywhere are challenging. You either have to 
static link (and even then you need to be careful what syscalls you 
use), or you have to build them against some ancient libraries, and 
static link the less ubiquitous dependencies (such as mpfr, ppl, etc.).


Andrew

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

Re: Getting linaro toolchain binaries

[Andrew Stubbs]

On 02/03/11 22:51, Nicolas Pitre wrote:

On Wed, 2 Mar 2011, Andrew Stubbs wrote:

Binaries that can be run anywhere are challenging. You either have to static
link (and even then you need to be careful what syscalls you use), or you have
to build them against some ancient libraries, and static link the less
ubiquitous dependencies (such as mpfr, ppl, etc.).


Sure.  But we have some evidence with the CS releases that this is
reasonably possible, right?


True, but CodeSourcery have some quite involved infrastructure in place 
to achieve that.


Of course, I have access to that, and I could probably get something 
built quite quickly.


I'm not sure about the QA & support implications though?

Andrew

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

Re: Getting linaro toolchain binaries

[Andrew Stubbs]

On 02/03/11 18:09, Matthias Klose wrote:

On 02.03.2011 19:02, Andrew Stubbs wrote:

On 02/03/11 17:52, Nicolas Pitre wrote:

Building a cross-compiler is already a challenge in itself.  Would be
better to build a version that can be installed anywhere like the
CodeSourcery releases and offer that as a tar download.


Binaries that can be run anywhere are challenging. You either have to static
link (and even then you need to be careful what syscalls you use), or you have
to build them against some ancient libraries, and static link the less
ubiquitous dependencies (such as mpfr, ppl, etc.).


I didn't try this, so I don't know if it's feasible.

  - build packages in a PPA, say, for an "old" release, e.g. hardy,
including mpfr, ppl, and other dependencies.
  - unpack a set of deb's with dpkg -x
  - relocate to /usr/local, or /opt/linaro. The toolchain itself
should be relocatable
  - pack a tarball.

Again, not tried, but this way you would end up with exactly the same binaries
that you provide in a PPA.


Well, that process is fine for Debian/Ubuntu users, but not-so-good for 
Suse/Redhat/Centos/Fedora/Arch/etc. I think it would be better if they 
worked anywhere (including Windows).


The toolchain *is* relocatable, but you need to be careful about the 
search paths and such. By default GCC will search for binaries and 
libraries relative to itself first, then in the location it was 
configured to be installed, and then in the standard places (IIRC, 
ICBW). Whatever, there can be a few interesting gotchas if you aren't 
careful.


Andrew

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

Re: Getting linaro toolchain binaries

[Andrew Stubbs]

On 03/03/11 09:47, Andrew Stubbs wrote:

Sure.  But we have some evidence with the CS releases that this is
reasonably possible, right?


True, but CodeSourcery have some quite involved infrastructure in place
to achieve that.

Of course, I have access to that, and I could probably get something
built quite quickly.


It turns out there are some big issues with this idea. I don't think 
it's going to happen easily.


Andrew

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

GCC PR43137

[Andrew Stubbs]

On Monday, I was asked to find out whether the fix for GCC Bugzilla 
PR43137 was present in our source base.


I can confirm that it is *not* present.

Apologies for the delay.

Andrew

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

[ACTIVITY] 28th February - 5th March

[Andrew Stubbs]

Committed Kazu's VFP testcases patch upstream.

Merged the latest from upstream GCC 4.6.

Merged all the outstanding launchpad merge requests against both GCC 4.5 
and 4.6.


Spun the 4.5-2011.03-0 and 4.6-2011.03-0 releases. Passed the tarballs 
to Michael H for final testing.


Brought the patch tracker up to date w.r.t. to new merges.

Posted one of Dan's patches upstream for review.

Decided to drop Julian's A8 alignment patch completely. I had previously 
discovered it provided no measurable benefit on A8, and now I've found 
the same for A9 (Pandaboard). There's no real improvement for any 
combination of -falign-* options in EEMBC.


Bernd's "Discourage NEON on A8" patch also doesn't show any value in the 
benchmark results, but I think I've forward ported it wrong, because it 
should at least change the binary size, and it doesn't. I need to look 
into this further.


I also decided I don't know enough about ARMv7, so I spent some time 
reading a few chapters from the ARM A.R.M.





Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* ARM EABI half-precision functions
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* RVCT Interoperability patch
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00059.html

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

Re: Work-item tracking for the "gcc-linaro-tracking" LP project

[Andrew Stubbs]

On 08/03/11 19:59, Ulrich Weigand wrote:


Hi Michael, Andrew,

Mounir just pointed out that our non-Ubuntu LP projects (like gcc-linaro,
gdb-linaro etc.) are now also included in the LP work-item tracking
statistics (http://status.linaro.org/linaro-toolchain-wg.html).   This
didn't happen in the past due to a Launchpad issue that has now been fixed.


Yay! :)


This seems to be working out nicely, except for one issue:  what about the
gcc-linaro-tracking project?   I have a couple of bugs that are fixed in
Linaro GCC, and are also fixed in mainline GCC, but they still show up as
an "in-progress" work-item in the status tracker (there are a whole bunch
more of those assigned to Andrew as well).  The reason for this is the LP
records have an associated gcc-linaro-toolchain project entry, and this is
set to "Fix Committed", but not "Fix Released" ... probably because GCC
4.6.0 is not yet released?

Now, on the one hand it does make sense to include the -tracking project in
the work-item statistics, because they *do* reflect important tasks:
namely, to make sure that the changes indeed land in the upstream
repository.   However, having them all show up as "in progress" until the
community makes a new GCC release does not seem very helpful: this is not
in our control, and our work is in fact done once the patch is committed
upstream.


There's another problem: the patches that we have decided not to push 
upstream at all are marked "Won't Fix", and the work items are showing 
as "Postponed". It would be better if they were shown as "Done" - as in, 
I've considered the patch and decided what to do with it, so it's done, 
but no fix has been either committed, or released.


Does anybody know what happens if I say it's "Invalid"? I'll flip one 
over, and see what happens.



Therefore my suggestion: we should immediately mark -tracking bugs as "Fix
Released" (not "Fix Committed"), as soon as the corresponding patch is
committed upstream (and thus our work on the problem is completed).

Thoughts?   Does this make sense?  Will this mess up any of the other
purposes for which we currently use the -tracking project?


Well, I rather liked the distinction, on an aesthetic level, but I don't 
see that there was any real advantage. I mean, the release number is 
given in the milestone, and we know whether that number has been 
released, or not, so the information has been encoded there. You could 
certainly argue that the patch has indeed been released to the public at 
large.


If nobody objects in the next day or two, I say we do it. The task 
tracker is quite useful, and it's all certain managers will look at, so 
it is of some commercial interest to those of us who don't work for 
member companies.


Michael, I think the patch tracker ought to be adjusted to give a 
different message for released, and somehow flag bugs that are in the 
unhelpful "Fix committed" state. (Maybe we should do something about 
"Won't fix" too.)


Andrew

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

Re: Work-item tracking for the "gcc-linaro-tracking" LP project

[Andrew Stubbs]

On 11/03/11 22:54, Mounir Bsaibes wrote:



On Wed, Mar 9, 2011 at 3:31 PM, James Westby mailto:james.wes...@linaro.org>> wrote:

On Wed, 9 Mar 2011 14:31:57 -0600, Mounir Bsaibes
mailto:mounir.bsai...@linaro.org>> wrote:
 > Copying James  to  check whether there was a reason for mapping
Won't fix to
 > Postponed. If there is no compelling reason, maybe it is an easy
change to
 > map it to Done instead.

It is an easy change.

I believe that this is done due to the way that series-targeted bugs
work in LP.

When you target a bug to a series, say "gcc-4.4", you can remove that
targeting by marking the bug "Won't Fix". That is presumably why this is
there.


I'm wary of changing it without understanding that interaction better
though.

James,  are you going to check on that and make a decision, whether it
is ok to change the mapping?

  For the other issue: bugs in gcc-linaro-tracking showing as in
progress work items. Can we exclude the gcc-linaro-tracking from the
status, if we decide to?


I specifically want to include gcc-linaro-tracking items. That's why I 
added them.


Andrew

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

[ACTIVITY] 7th - 13th March

[Andrew Stubbs]

Merged fixes for several bug into Linaro GCC 4.5. Both from Linaro 
(Richard, Matthias and Ramana), and from CS (the shrink wrap problems).


Continued working on benchmarking the patches I've merged to 4.6. Spent 
quite some time trying to figure out why EEMBC and the Spec2K weren't 
working properly. I've got this sorted now.


Confirmed that the patch to discourage NEON use for integer operations 
is still profitable on Cortex-A8. Posted the patch upstream.


Merged upstream GCC 4.6 into Linaro GCC 4.6.

Booked travel to Budapest for Linaro @ UDS.

Followed up on Ramana's questions about the RVCT interoperability patch. 
Paul Brook helped explain what it was about, and pointed me at the 
proper section in the proper ARM manual.


Continued forward porting patches to 4.6. Mostly I need to convince 
myself that they still do something useful. I have posted one new patch 
to upstream - the "Discourage A8 NEON" patch.




* Future Absence

Away Wednesday 16th to Friday 18th.

Away Monday 28th to Friday 1st April.




Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* ARM EABI half-precision functions
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* RVCT Interoperability patch
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00059.html
* Discourage NEON on A8
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00576.html

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

Re: Work-item tracking for the "gcc-linaro-tracking" LP project

[Andrew Stubbs]

On 13/03/11 22:28, Michael Hope wrote:

I specifically want to include gcc-linaro-tracking items. That's why I added
them.


Hi Andrew.  What is your goal here?  I'm concerned as
status.linaro.org counts each tracking ticket as a work item and this
inflates the amount of work recorded.  I've assumed that the
upstreaming work is rolled into the original work item or bug report
which is already tracked.


Simply that I seemed to be spending all my time on one work item, so I 
thought I would break it down a bit. This also gives me some indication 
how far through the task I am.


It's unfortunate that the ticket status isn't really what we're after 
here - i.e. the blueprint status depends on the local 4.6 branch, but 
the ticket status depends on the upstream status. I had intended that 
these two would correlate quite closely, but events have conspired 
against me.


Andrew

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

[ACTIVITY] 21st - 25th March

[Andrew Stubbs]

* Linaro GCC

Tested and merged both the latest Linaro merge requests, and various bug 
fixes to the Shrink Wrap optimization from CS, into Linaro GCC 4.5.


Merged and tested from FSF GCC 4.6.

Richard and Ramana have approved some of my upstream patches! I just 
need to wait for stage one so I can commit them upstream. I'll commit 
them internally when I get time to do the final integration test.


Continued benchmarking GCC 4.6 with the patches merged from GCC 4.5. 
Decided to discard a couple of extra patches since they don't appear to 
be of any value.




* Other

On leave Wednesday to Friday playing daddy. :)



* Future Absence

Away Monday 28th to Friday 1st April.




Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* ARM EABI half-precision functions
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

Re: [ACTIVITY] 14th - 18th March

[Andrew Stubbs]

Subject dates corrected 

On 21/03/11 10:55, Andrew Stubbs wrote:

* Linaro GCC

Tested and merged both the latest Linaro merge requests, and various bug
fixes to the Shrink Wrap optimization from CS, into Linaro GCC 4.5.

Merged and tested from FSF GCC 4.6.

Richard and Ramana have approved some of my upstream patches! I just
need to wait for stage one so I can commit them upstream. I'll commit
them internally when I get time to do the final integration test.

Continued benchmarking GCC 4.6 with the patches merged from GCC 4.5.
Decided to discard a couple of extra patches since they don't appear to
be of any value.



* Other

On leave Wednesday to Friday playing daddy. :)



* Future Absence

Away Monday 28th to Friday 1st April.




Upstream patched requiring review:
* Thumb2 constants:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* ARM EABI half-precision functions
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html
* NEON scheduling patch
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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



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

Re: can linaro toolchain compile ARM earlier than Cortex A8?

[Andrew Stubbs]

On 24/03/11 03:09, Michael Hope wrote:

Hi Barry.  GCC can be switched at runtime by supplying -march=* and/or
-mcpu=* flags to the compiler, just as you have done below.  The
'--with-arch=*' lines you see below set what GCC compiles to by
default.


While that is true, but the libraries that come with the compiler are 
probably still inappropriate for older architectures.


The short answer is that, no, the Linaro *binary* releases will not 
support -march=armv5.


However, you can build your own compiler from the Linaro sources, and 
then build the libraries you need to match, and you can have v5 support. 
This is not a straightforward process. :(


If you'd prefer not to build your own tools, may I recommend 
CodeSourcery's Sourcery G++ Lite for ARM GNU/Linux:


   http://www.codesourcery.com/sgpp/lite/arm

That compiler defaults to ARMv5TE. If that's too new, the toolchain also 
contains prebuilt libraries for ARMv4T (-march=armv4t) and those should 
be compatible. Although it is not the Linaro compiler, it is somewhat 
similar, and programs you build should be compatible with Ubuntu. 
(Disclosure: I work for CodeSourcery).


Hope that helps

Andrew

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

Re: can linaro toolchain compile ARM earlier than Cortex A8?

[Andrew Stubbs]

On 24/03/11 11:05, Imre Kaloz wrote:

On Thu, 24 Mar 2011 11:36:17 +0100, Andrew Stubbs
 wrote:

However, you can build your own compiler from the Linaro sources, and
then build the libraries you need to match, and you can have v5 support.
This is not a straightforward process. :(


You can always use the OpenWrt buildroot to easily build a custom
Linaro-based crosscompiler, just make sure you select the right libc for
your needs (we use uClibc by default) and a target similar to yours.


Or OpenEmbedded or CrossTool / CrossTool-NG.

Andrew

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

Re: Linaro 4.5.2 v. CodeSourcery 4.5.1

[Andrew Stubbs]

On 25/03/11 21:48, Diane Holt wrote:

I hope you don't mind me sending you mail, but I'm a bit stuck...I've
been told I need the Linaro 4.5.2 toolchain because it has some "neon
optimizations" that the CS 4.5.1 doesn't have.


In general, you'd be better addressing these questions on the Linaro 
Toolchain mailing list: linaro-toolchain@lists.linaro.org (I've copied 
it in).


Not least because I'm on vacation for the next week. :)

> Unfortunately, the Linaro

4.5.2 that's available for download (already built) won't work in my
Scratchbox environment, since it was compiled against a glibc that's too
new. The CS 4.5.1 works fine -- but I'm not allowed to use it, because
of the neon stuff.


The CS and Linaro compilers are really very similar, but CodeSourcery 
has not made a release since the autumn, so Linaro will have some extra 
features.



Do you know whether CS actually does have (or will have) the same neon
optimizations Linaro has?


It depends which optimizations you are referring to? The existing CS 
release had the latest improvements at the time it was released, and I 
believe that the upcoming release will probably be very similar to 
Linaro (at least, with respect to ARMv7 - there'll be many differences 
for other architecture variants), but I'm not promising that.


Sorry if that's a bit vague, but I the contents of the next CS release 
is still not finalised.



If it doesn't (and won't), then I'm going to have to build the Linaro
one from source. Unfortunately, I've not been able to find any detailed
information on how to go about doing that. Do you know if that's
documented anywhere?


Are you talking about building native compiler, or a cross-compiler? The 
former is very simple (provided you have all the dependencies), while 
the latter is more involved.


Here's the recipe to build a native compiler:

   tar xf gcc-linaro.tar.bz2
   mkdir objdir
   cd objdir
   ../gcc-linaro../configure --prefix= 
   make bootstrap
   make install

You can copy the configure  from another compiler using 'gcc -v' 
and './configure --help' in the source tree should tell you what they mean.


If you want to build a cross compiler, I suggest you look at crosstool 
or crosstool-ng, or OpenEmbedded. Building cross-toolchains is non-trivial.


Hope that helps.

Andrew

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

[ACTIVITY] 21st - 26th March

[Andrew Stubbs]

Committed Dan's RVCT interoperation patch, both upstream and to Linaro 
GCC 4.6.


Adjusted Benrd's "Discourage NEON on Cortex-A8" patch following Richard 
Earnshaw's comments, and reposted upstream. The new version was 
approved, and committed. I've also submitted a merge proposal to Linaro 
GCC 4.6.


Dropped Tom's patch for marking smalls strings read-only. This 
optimization seems to have no visible effect for ARM in GCC 4.6. I'll 
leave it it to Tom to forward-port, if it's still meaningful for MIPS.


Julian has committed the patch for lp:675347, so I've submitted merge 
requests to both Linaro GCC 4.5 and 4.6.


Bernd has posted the shrink wrapping patches upstream. I've posted this 
info in all the relevant Linaro tracking tickets.


Talked Revital Eres through the Bazaar/Launchpad merge request system.

Tried to understand why GCC 4.6 does not use multiply-and-accumulate 
efficiently, when used with 64-bit values. It seems that the compiler 
sometimes uses (subreg:SI (reg:DI ...)) and sometimes just uses a plain 
(reg:SI ..) and those don't combine to give useful patterns, but I 
haven't got to the bottom of it yet.


Tested an FSF GCC 4.6 snapshot from the 23rd. All well, so I've merged 
it to the Linaro GCC 4.6 branch.




* Future Absence

Away Monday 28th to Friday 1st April.




Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* ARM EABI half-precision functions
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* ARM Thumb2 Spill Likely tweak
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

Re: Linaro toolchain integration with ChromiumOS build

[Andrew Stubbs]

On 01/04/11 06:46, PANKAJ KUMAR DUBEY wrote:

a) gcc-4.4.3.tar.bz2: It is main gcc source code.
b) gcc-4.4.3-patches-1.2.tar.bz2: It seems like some patches after code
release.


The Linaro tarball should replace both of these.


c) gcc-4.4.3-uclibc-patches-1.0.tar.bz2: Not having idea about this. On
google found that
uClibc (aka µClibc/ pronounced yew-see-lib-see) is a C library for
developing embedded Linux systems.
No idea why this is reuquired? Or if it is mandatory for a gcc
compilation or Chromium OS?


I'm sure you *could* run ChromiumOS with Glibc, rather than uClibc, but 
there probably wouldn't be much point (unless uClibc lacks support for 
your platform?)


I suggest you try to apply these patches. If they fit, then you're 
probably ok. If they don't fit, it might be that they're not necessary 
in our toolchain.


If they don't fit, and you find the compiler output doesn't work 
correctly with uClibc, then that's a more tricky problem. :(



d) gcc-4.4.3-piepatches-v0.4.1.tar.bz2 |
e) gcc-4.4.3-specs-0.1.8.tar.bz2 | These two (d) and (e) are getting
used as part of hardened tool-chain.


You could simply try to apply these patches. If they fit, then they'll 
probably work. But I expect you can just omit them. I have not looked 
inside, but hardening patches usually make the compiler more picky 
and/or produce more paranoid output, but don't affect the user 
interface. If that's true then the build system probably won't notice if 
they're not there.



So my question to Linaro toolchain team:
I) Do we have same kind of uClibc patch available for Linaro-gcc? If yes
how to get that?


No, we do not, but Linaro GCC 4.4 is based on CodeSourcery G++, and that 
does support uClibc on some targets, so it might just work.



II) Since ChromiumOS toolchain is tightly bound with build system, and
ChromiumOS default profile is using "hardened" USE flag and hence using
"hardened toolchain", it needs another two patches one is "PIE" and
another "SPECS", as shown above.
Does Linaro-GCC supports this "hardened" feature? If yes how we can get
correct versions of these (PIE and SPECS) two parts.


No, but as I said above, just omitting the hardening features might be 
ok. Alternatively, Ubuntu GCC applies hardening patches on top of Linaro 
GCC, so you might like to look there.


Hope that helps

Andrew

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

Re: Linaro 4.5.2 v. CodeSourcery 4.5.1

[Andrew Stubbs]

On 05/04/11 03:07, Diane Holt wrote:

Nope -- all those files came with the CodeSourcery 4.4.1
(arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2) -- I
just don't know what CS built them from. (I suppose if I can't find out
how to build them myself I could try just snagging them from my 4.4.1
toolchain and seeing if they work in this 4.5.2 linaro one...)


Michael already replied to this, but just to be clear ...

The CS Linux toolchains consist of GNU Binutils (as, ld, nm, objdump, 
etc.), GCC, GLIBC (and/or uClibc), GDB, and a few other useful 
utilities, all bundled up into one install.


Most of the utilities you mentioned do indeed come from Glibc, not GCC, 
and should be included with your Glibc provider - in this case 
Scratchbox. A few of them may come from other places; 'gdbserver' comes 
from GDB, for example.


Andrew

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

[ACTIVITY] 4th - 9th April

[Andrew Stubbs]

The test results for the patch for lp:675347 on GCC 4.6 came back clean, 
so I merged it to Linaro GCC 4.6.


The test results for lp:675347 on 4.5 had problems though, but they 
might be unrelated to the patch. The test results for the "discourage 
NEON on A8" patch had similar failures, and that's a 4.6 testsuite.


Richard Earnshaw approved the Thumb register allocation patch. I've 
committed it upstream, and updated the patch trackers. It was already on 
the Linaro 4.6 branch.


Now that GCC 4.6 is released, switched all the Linaro tracking tickets 
from 'Fix committed' to 'Fix released'.


Merged from FSF 4.5 to Linaro 4.5 and submitted the patch for test. The 
tests came back clean, so I pushed it to the 4.5 branch. (Yay for 
Michael's new test service!)


Merged more patches from SG++ to Linaro. Or, at least considered them 
for merge. Mostly I decided that they were not appropriate for Linaro, 
at least, not just yet. I have yet to push these patches to Launchpad.


Reviewed Richard Sandiford's patch for LP:714921.

Retried the Android build with a view to integrating Android support in 
Linaro GCC 4.5 (4.6 should already support it). Eventually, after 
downloading many different git repositories and branches, and maxing out 
the memory on my machine a few times, I managed a successful build using 
the toolchain the Android team are using. I then backported Maxim's 
patches to Linaro GCC 4.5, and built and tested that, and got another 
successful Android build. I've pushed the patched toolchain to Launchpad 
at lp:~ams-codesourcery/gcc-linaro/android for testing. All being well, 
I'll merge Android support into the 4.5 trunk in time for the next release.





Upstream patched requiring review:
* Thumb2 constants:
  http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html
* ARM EABI half-precision functions
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

[ACTIVITY] 11th -15th April

[Andrew Stubbs]

Reviewed and approved Revital's do-loop patch, and Ira's store sinking 
patch. More precisely, I reviewed the test results from Michael's test 
system, and cast my eye over the patch to look for anything obvious. I 
don't pretend to know exactly what they do.


Attended Ramana's thumb2 optimization discussion.

Continued work on merging useful patches from CodeSourcery. Pushed the 
new patch set to Launchpad for testing in Michael's system.


Pointed Bernd at lp:758082 - another probable shrink-wrap failure. Bernd 
responded with a new patch, and asked me to test it. I've pushed it to 
Launchpad and created a merge request.


Posted an old patch of Dan's upstream:
 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03144.html

Pinged my thumb2 constants patch upstream. Richard E responded with some 
issues to address. I'll need to change the names of the constraints, at 
least.


At Ramana's request, tested the NEON scheduling patch with SPEC2000. 
Encountered trouble with time-outs. Fixed those and retested.


Posted an updated version of my EABI half-precision patch:
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html

Merged my backport of Julian's -fstrict-volatile-bitfields bug fix into 
Linaro GCC.


The testing of the Android patches came back with a few test 
differences, but they appear to be unrelated to the patch, so are 
probably environmental. I've merged the changes to Linaro GCC.


[Also spent most of Friday working on internal CS tasks.]




Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* NEON test cases
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03144.html
* ARM EABI half-precision functions (reposted)
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html

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

[ACTIVITY] 18th - 21st April

[Andrew Stubbs]

Merged & tested the outstanding merge requests into Linaro GCC.

Spin the Linaro GCC 4.5 and 4.6 releases. Uploaded the tarballs to Michael.

Submitted a patch upstream that removed some redundant code that had 
confused me a introduced a bug into my Thumb2 constants patch.

 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03756.html
This patch is now approved and committed upstream. I'll commit it 
internally when the rest of my ARM/Thumb constant handling changes are 
upstream.


Worked on addressing RichardE's concerns with my Thumb2 constants patch. 
Tried to split it into smaller chunks, and rename the constraints. 
Posted the patches upstream:

 1. a small patch upstream to clean up MOWV support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03768.html
  (Now approved and committed.)
 2. ADDW and SUBW support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html
 3. Replicated constants for constant splitting.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html

Committed upstream Dan's Vector shift test cases patch that was approved 
last week. Pushed the same patch to Linaro GCC 4.6.




Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* ARM EABI half-precision functions (reposted 2011-04-14)
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03210.html
* ARM Thumb2 addw/subw support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html
* ARM Thumb2 Replicated constants
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html

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

Re: Sessions for the summit

[Andrew Stubbs]

On 20/04/11 04:37, Michael Hope wrote:

I've put your names against the sessions as follows:

Andrew:  Broad tuning


I've added some work-items to the wiki page.

Please let me know if this is sufficient.

Thanks

Andrew

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

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Andrew Stubbs]

On 26/04/11 03:39, Nicolas Pitre wrote:

But I digress.  This is just to say that gcc shouldn't pull
__aeabi_uldivmod in this case because:


There isn't a library call (or instruction) for a straight 'mod' 
operation, so GCC always has to use 'divmod', no exceptions.


In any case, optimization of a div and a mod into a single call is 
problematic, at best, so it's unlikely that's happening. See GCC PR43721.


Andrew

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

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Andrew Stubbs]

On 27/04/11 09:44, Barry Song wrote:

Thanks. I am totally thinking it is a gcc bug not an optimization
feature. in fact, __aeabi_uldivmod is never called as seen by objdump.
It only exists in symbol reference list.


Your code contains "Nmod = target % source" so the only reason divmod 
wouldn't get called is if it got optimized away somehow.


If that were the case then it would be a compiler bug somehow, but when 
I build the test case in Michael's bug report it looks like 
__aeabi_uidivmod does get called, AFAICT.


I don't see any reference to __aeabi_uldivmod so you must have different 
compiler or testcase?


Andrew

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

Re: -O2 cause optimization issues while va parameters functions

[Andrew Stubbs]

On 27/04/11 10:08, Barry Song wrote:

Hi All,

As i have frequently said, we are using 2011.3 4.5 linaro gcc. For the
following codes, if we compile it by -O2, it will crash with "segment
fault", if we just comment " if(unifi_debug>= level) {", all will be
ok.
If we don't compile it by -O2, all will be ok too.


Sorry, are you saying that the compiler crashes, or are you saying that 
the output binary crashes at runtime?


Andrew

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

Re: -O2 cause optimization issues while va parameters functions

[Andrew Stubbs]

On 27/04/11 10:23, Barry Song wrote:

the target binary got crash while running on armv7 board, not gcc :-)


I suspect I know what the problem is here.

Can you try again with -fno-shrink-wrap, please?

Andrew

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

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Andrew Stubbs]

On 27/04/11 10:22, Barry Song wrote:

__aeabi_u*l*divmod has never existed in asm codes after objdump the
target ko.
__aeabi_u*l*divmod only exists in refrence list. the list means what
symbols are depent by this module. So we got a link error. but in
fact, the module doesn't need link this symbol since it never call
__aeabi_u*l*divmod in asm level.


Can you compile with --save-temps and look in the .s file.

If it's never mentioned in there then it's not a compiler bug (at least, 
not with this testcase) - the reference is coming from elsewhere.


We should be able to narrow things down, at least.

Andrew

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

Re: __aeabi_uldivmod undefined for sound/soc/codecs/snd-soc-wm8974.ko, snd-soc-wm8940.ko and snd-soc-wm8510.ko

[Andrew Stubbs]

On 27/04/11 10:57, Michael Hope wrote:

Hi Andrew.  I uploaded the wrong preprocessed source to the GCC
bugzilla entry.  It included the __attribute__((noinline)) workaround
which hides the problem.


OK, I've now reproduced the problem and reduced the test case.

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48783

Andrew

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

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Andrew Stubbs]

On 28/04/11 02:30, Barry Song wrote:

I am using the newest binary utils(2.21) and encounted the following ASSERT in
arm_elf32.c:
+ if (out_attr[i].i == 0)
+   {
+ BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0);


[...]


But not sure whether it is a bug.


I should say that it is a bug because asserts are there to catch bugs. 
If it were checking the input were valid then it would give a diagnostic 
message. That said, it may be that the bug *is* that a diagnostic should 
be used instead of an assert. :)


In this case 'i' will be 'Tag_FP_arch', so the code is saying that if 
Tag_FP_arch is not set, then set that and set Tag_ABI_HardFP_use at the 
same time. Since this is the only place Tag_ABI_HardFP_use is ever set, 
it should not be possible to have it set without Tag_FP_arch also being 
set, so if the assert triggers then something is broken.


So, the question is, what is setting the tags this way? Assuming the 
code is ok, the only other way it could happen is in a malformed input file.


Now, the reason this is an assert, and not a diagnostic, is probably 
because the tags are not considered "user input". Yes, the user can set 
them via assembler directives, but the assembler is supposed to make 
sure they are valid before creating the object file.


Could you please run the broken link again with "-Wl,-t" (trace) and 
record all the input files the linker uses, and check what attributes 
(tags) are set on those files using "readelf -A".


I suspect that you may have a mal-formed binary on your system (possibly 
created by an older version of binutils).


Andrew

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

Re: "BFD_ASSERT (out_attr[Tag_ABI_HardFP_use].i == 0) " assert

[Andrew Stubbs]

On 28/04/11 09:59, Barry Song wrote:

my other two mails explain what happened, in fact link input file is simple:


There must be more than one input file to the link, otherwise I believe 
you wouldn't see this problem. We need to find out what the other ones are.



ASSERT found just because we are using -nostdlib flag since we don't
call any library. This flag changed out_attr[Tag_FP_arch] to 0, which
is generically 4 for linaro new toolchain by watching a normal
compile/link process.


The -nostdlib flag only changes the list of libraries that will be 
linked. It shouldn't change any attributes directly.


Here's how a link should work, if I understand it correctly:

1. The linker creates an empty output file (conceptually). This file 
will have all attributes set to default settings (i.e. zero).


2. Each input file is then merged into the output file in turn. New 
sections are added, or existing ones appended to, and the symbol tables 
and such are built incrementally. At each step, the attributes are 
merged from the input file to the output file.


For the first input file, the attribute merge is basically just a copy. 
Both Tag_FP_arch and Tag_ABI_HardFP_use should be zero in the (empty) 
output file, so we should not be able to hit this condition.


For the second input file, the attribute merge is more complicated. For 
each attribute the result will be either be the union, or the 
intersection of the two attributes, or else it will throw an error.


So, it should be that this can't happen, but clearly it does, so 
something is broken, but I can't tell what without reproducing it, or at 
least seeing what inputs you're dealing with.


So, please help me figure out what the full set of input files are and I 
see if I can work from there.


Thanks

Andrew

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

[ACTIVITY] 26th -28th April

[Andrew Stubbs]

My MOVW patch from last week left an unused variable that killed -Werror 
builds, so I posted a new patch to fix it.

 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg04141.html
Ramana approved that in record time, so I've committed it.

Tom has committed Mark Shinwell's BRANCH_COST patch upstream, so I have 
backported it to Linaro GCC 4.6.


Maxim has committed his compound conditionals patch upstream, so I've 
backported that to Linaro GCC 4.6 also.


Reviewed what other patches are queued for forward porting to 4.6/7, 
hoping that other's might have picked some of them off, and found no 
other progress just yet.


Reduced the test case for GCC PR48783. For some reason it is retaining 
".global" directives for symbols that have been optimized away, which 
leads to link errors in the kernel build.


Tried to find out why the "discourage neon in A8" patch has caused test 
failures. I'm still not sure - I've asked Michael Hope to rerun the 
tests in case it's just random.


Reposted the EABI half-precision patch with the extra bits Joseph says 
it needed in the version scripts.

  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg04251.html

Looked at the linking problem reported by Barry Song on the 
linaro-toolchain list.



* Other

Public holidays on Monday and Friday.


* Future

I will be attending UDS in Budapest from 8th - 14th May. I shall 
continue to read my email, but will not be attending any calls.




Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* ARM Thumb2 addw/subw support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html
* ARM Thumb2 Replicated constants
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03883.html
* ARM EABI half-precision function names (reposted 2011-04-27).
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg04251.html

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

Pushing to diverged branches

[Andrew Stubbs]

Hi all,

We seem to have had an accident!

This morning I merged one of my patches to lp:gcc-linaro/4.6, and this 
afternoon I got an email from Launchpad notifying me that a mystery 
revision had been deleted.


It seems that Richard has somehow overwritten my change with his. 
Luckily I've spotted it and will fix it now, but it could very easily 
have got lost.


I'm not sure what's happened here, but I'm pretty sure bzr does not just 
do this silently. I thought you needed to specify --overwrite to do this 
on purpose, but perhaps there's a bzr bug here?


Anyway, could everyone please be very careful when they do bzr push to 
the release branches.


Thanks

Andrew

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

Re: Pushing to diverged branches

[Andrew Stubbs]

OK, I think I've got to the bottom of this now, with a bit of help from 
the people at #bzr.


What Richard must have done is merged lp:gcc-linaro/4.6 *to* his 
development branch, and then pushed that branch with --overwrite, thus 
rewriting history. :(


I've now changed the configuration of the branch such that it shouldn't 
be permitted any more. It should only permit revisions to be appended 
from now on.


I also changed 4.4 and 4.5 branches likewise.

Andrew


On 04/05/11 16:55, Andrew Stubbs wrote:

Hi all,

We seem to have had an accident!

This morning I merged one of my patches to lp:gcc-linaro/4.6, and this
afternoon I got an email from Launchpad notifying me that a mystery
revision had been deleted.

It seems that Richard has somehow overwritten my change with his.
Luckily I've spotted it and will fix it now, but it could very easily
have got lost.

I'm not sure what's happened here, but I'm pretty sure bzr does not just
do this silently. I thought you needed to specify --overwrite to do this
on purpose, but perhaps there's a bzr bug here?

Anyway, could everyone please be very careful when they do bzr push to
the release branches.

Thanks

Andrew

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



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

Re: Pushing to diverged branches

[Andrew Stubbs]

On 04/05/11 17:48, Andrew Stubbs wrote:

What Richard must have done is merged lp:gcc-linaro/4.6 *to* his
development branch, and then pushed that branch with --overwrite, thus
rewriting history. :(


Just to be clear, here's the correct way to do a merge:

[assuming you want to reuse an existing branch]
bzr pull --overwrite lp:gcc-linaro/4.6
bzr merge lp:.whatever.
[...resolve-conflicts]
bzr resolve
bzr commit
bzr push lp:gcc-linaro/4.6

In other words, please merge *from* development branches *to* release 
branches.


Thanks

Andrew

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

Re: Pushing to diverged branches

[Andrew Stubbs]

On 05/05/11 08:43, Richard Sandiford wrote:

Anyway, the bzr help page seemed to suggest that merging in the new
4.6 revision was the Right Thing to do.  I'm afraid that, once again,
it felt so natural to resolve push conflicts this way that I didn't even
question the assumption.  I did the merge, and as expected, there was
only one new commit: your change from yesterday.  So I committed the
merge and pushed again.  bzr was happy this time.  I didn't need any
special options to push.  Perhaps if I had, overdue alarm bells might
finally have rung.


OK, so if I understand correctly, the merge was done correctly, but then 
the push didn't work. So far so good.


But then, merging from 4.6 to synchronize the branches somehow convinced 
bzr that it was ok to push without --overwrite, even though that would 
rewrite history. Yuck, that's horrible!


So the end result is that the source tree is indistinguishable from what 
it would have been, but the bzr log is totally screwed up. :(



Once again, I'm sorry for the screw-up.  I should have been more
circumspect.


Who knew bzr could even do this?! :(

Anyway, I've set the branches to append only mode, so hopefully this 
kind of 'smart' feature is defeated.


BTW, there is a bzr plugin named 'rewrite' that adds a 'rebase' command 
that works better in the case of diverged branches. It's slow as hell 
though.


Andrew

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

Re: Pushing to diverged branches

[Andrew Stubbs]

On 05/05/11 09:32, Richard Sandiford wrote:

But just to be clear, in the kind of situation where person A has pushed
a new revision while person B was doing a merge, what should person B do
when the push fails?  Should they undo the local merge, pull, then merge
again?  Or is there a better way?  Do you mean that:


>  BTW, there is a bzr plugin named 'rewrite' that adds a 'rebase' command
>  that works better in the case of diverged branches. It's slow as hell
>  though.

this is the right thing to do instead?


Yes, with the rewrite plugin you can just do:

bzr rebase
[while conflict]
  [...fix conflict...]
  bzr rebase-continue
bzr push

However, I have to say that doing it manually might be faster (if you 
don't have many commits) and you don't need the plugin:


bzr pull --overwrite/* wipe local changes */
bzr merge 
[...fix conflicts...]
bzr commit
bzr push

Andrew

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

Re: Pushing to diverged branches

[Andrew Stubbs]

On 05/05/11 15:42, Martin Pool wrote:

I'd like to know more about the case where it's slow, because we have
fixed up some of the other performance issues that were biting Linaro.
  Could you tell me more, or if you like file a bug at
  saying what you're running on what
branches and what speed it is?


Last time I used it, I took 
lp:~ams-codesourcery/gcc-linaro/cs-merge-20110413, and rebased it to 
lp:gcc-linaro. This took at least an hour to run, possibly 2-3 hours, I 
don't recall - I got bored and went to do something else.


Note that some of the revisions on cs-merge-20110413 have now been 
committed to lp:gcc-linaro, so to repeat the experiment you'll need to 
only rebase as far as r99496, I think. It's actually only 3 revisions 
difference, I think.


The GCC source tree is huge, and has a long history, so doing just about 
anything with it in BZR takes a while, and consumes a lot of memory. 
I've not tried using git with the full GCC history, but I have tried it 
with even larger sourcebases (GCC, binutils, GDB, etc. all combined into 
one repo), and I can say it was much quicker, although still gives 
enough time to read a few emails.


Andrew

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

Re: Pushing to diverged branches

[Andrew Stubbs]

On 05/05/11 16:22, Martin Pool wrote:

I filed  to track
this.  I think it will have been improved a fair bit by John's recent
work on huge-tree workingtree performance work (which sped up some
things like revert 8x) but there's probably more to do.  That work is
in bzr 2.4beta, which you can get from eg ppa:bzr/daily.


I certainly have witnessed revert being very slow.

In fact, I'd say it feels quicker to run "bzr st" and then do "bzr 
revert" naming individual files. Maybe that's illusory, but it's 
certainly quicker to revert individual files if you already have the 
list to hand. Of course, that doesn't revert merge notes, so it's 
perhaps not exactly the same.


Uncommit is another command that seems unreasonably slow. It really 
shouldn't be that hard to do a "patch -R" and update some metadata 
somewhere, but clearly there's a lot more to it than that!


Andrew

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

Re: Pushing to diverged branches

[Andrew Stubbs]

On 06/05/11 07:11, John Arbash Meinel wrote:

In 2.4b? most commands that took>3min in my testing dropped into the
<30s range because of improved ordering while walking the inventory.
There are still a few more that can be improved a bit further.


Any idea when these improvements are likely to hit the PPA stable release?

I can try out other versions on my local machine, but I won't get it on 
the build server until it's officially stable.


Thanks

Andrew

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

Fwd: Linaro forums replaced by "Ask Linaro"

[Andrew Stubbs]

There's already a couple of tools-related questions on here. We should 
probably make sure we monitor it regularly.


This isn't to hard, once you're signed up, you can mark certain topics 
as 'interesting' and then you'll get email notifications when there's a 
post.


Andrew

 Original Message 
Subject: Linaro forums replaced by "Ask Linaro"
Date: Fri, 06 May 2011 15:58:53 +0200
From: Michael Opdenacker 
Organization: Linaro
To: everyone 

Greetings,

We are pleased to announce the replacement of our forums by a new "Ask
Linaro" service.

Better than forums, we expect this service to bring more questions and
answers, and incite people to join the Linaro community by sharing their
experience.

We count on your participation.

See http://ask.linaro.org/

Cheers,

Michael.

--
Michael Opdenacker - Community Manager
Linaro, http://linaro.org
Cell: +33 621 604 642
IRC: 'opm' in #linaro on irc.freenode.net


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

[ACTIVITY] 3th - 6th May

[Andrew Stubbs]

Worked on the ARM 16 -> 64-bit multiply-and-accumulate problem. Bernd 
kindly provided a prototype patch to help. I've tried to understand what 
needs to be done, but I didn't have enough time to get to the bottom of 
it. So far, I think I know why the existing code doesn't work, and I 
think I have a way forward. It does appear that the real problem ought 
to be solved in the tree optimizers, though.


Committed the FSF GCC 4.5.3 merge to the Linaro 4.5 branch. Testing did 
not show any trouble.


Matthias requested an additional 4.5 merge to pick up a new bug fix, so 
I've done the merge, and submitted the merge request for testing.


Committed Maxim's compound conditionals optimization patch - a merge 
from Linaro GCC 4.5.


There was some confusion caused by the lp:gcc-linaro/4.6 branch history 
accidentally getting re-written. After some discussion on #bzr I managed 
to figure out what happened, posted a warning to linaro-toolchain 
mailing list, and changed the branch configuration to prevent it 
happening again.


Committed Mark Shinwell's BRANCH_COST patch to Linaro GCC 4.6 - another 
merge from GCC 4.5.


Merged from FSF GCC 4.6 to Linaro 4.6 and submitted the patch for testing.

Richard Earnshaw approved my recent Thumb2 constants patch, but only if 
I modify it slightly. I've begun work on the changes, but I still need 
to test them. I won't be able to commit them until the ADDW/SUBW patch 
has been approved.


Ramana has reviewed my EABI half-precision function names patch, and 
discovered that the return types are wrong. I have no idea how this 
happened - the changes are deliberate so they must have been based on 
something, but I no longer have the same documents I had when I did the 
work, and it clearly doesn't match my current ones. In any case, the 
changes make no practical difference as function return values are 
always as wide a register anyway.




* Other

Public holiday on Monday.



* Next week

I will be attending UDS in Budapest from 8th - 14th May. I shall 
continue to read my email, but will not be attending any calls.





Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* ARM Thumb2 addw/subw support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html

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

[ACTIVITY] 9th - 13th May

[Andrew Stubbs]

Spent the whole week attending Linaro@UDS. Any other activity this week 
is squeezed into the space between (interesting) sessions.


Finished making the suggested changes to my Thumb2 constants patch, and 
posted it back upstream. This is pre-approved, but can't be committed 
until after the addw/subw patch.

   http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg05195.html

Merged all my outstanding approved merge requests to the release 
branches in time for next week's release.




Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* ARM Thumb2 addw/subw support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html

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

[ACTIVITY] 16th - 20th May

[Andrew Stubbs]

Posted a new patch for 16 -> 64 bit multiply and accumulate:
 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg05794.html
Pushed the same patch to a Launchpad branch for testing.

Pinged my addw/subw patch as a review didn't seem forthcoming.

Worked on a canonical form for HImode to DImode multiple-and-accumulate. 
The problem isn't too hard to fix, but it's hard to do it in a nice way.


Attended Nathan S's reorg call. Followed up by talking to Nathan F about 
what he's been working on with Wind River. Read up on the Wiki.


Looked at why the ARM smlal{tb,bt,tt} instructions are not generated. 
I've added the proper patterns, but combine doesn't match them, and I've 
run out of time this week to check why.





Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* ARM Thumb2 addw/subw support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html
* Multiply and accumulate:
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg05794.html

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

[ACTIVITY] 23rd - 27th May

[Andrew Stubbs]

Posted a new patch for canonicalization of widening multiplies. This was 
rejected, so I submitted another one. And another  and another. 
Finally I have one that nobody has complained about ... yet, but still 
nobody has approved it either.

  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg06546.html

Add support for SMLALTB/SMLALTT/SMLATB/SMLATT to the machine 
description. This depends on the canonicalization patch working. Posted 
this upstream also.

  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg06692.html

[I had to spend quite a bit of time on internal CodeSourcery work this 
week, hence the shorter than usual status report. Normal service will 
resume shortly.]





Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* ARM Thumb2 addw/subw support.
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg03783.html
* Multiply and accumulate:
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg06546.html
* SMLALTB/SMLALTT/SMLATB/SMLATT
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg06692.html

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

[ACTIVITY] 30th May - 5th June.

[Andrew Stubbs]

Public Holiday on Monday.

Learned that Linaro are reducing their funding to just one CodeSourcery 
engineer, myself. Spoke to Chung-Lin to break the news and reassign him 
to other work. Chung-Lin will now be working on MIPS16 Eglibc porting.


Pinged my ADDW/SUBW patch, again. Ramana finally reviewed it, so I've 
addresses his concerns and reposted. The corrected patch was approved, 
so I've set it to test before committing.


Continued work on widening multiplies tree optimizations in GCC. Bernd 
made it sound quite easy, but changing the type of some operations means 
quite a lot of tweaking and reworking in the rest of the compiler expand 
routines. In particular, the widening stuff needs to be broken out of 
expand_binop, and recast.


Merged, tested and committed the latest patches from FSF 4.5.

Merged, tested and committed the latest patches from FSF 4.6.

Richard Earnshaw approved my widening multiply RTL patch, so I've set 
that to test in the Linaro test system.


Richard also approved my SMLALTB/SMLALTT patch. Set that testing also.

Responded to a question on ask.linaro.org.




Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

[ACTIVITY] 6th - 10th June

[Andrew Stubbs]

My testing for the widening multiplies patches came back clean. I've 
committed it upstream, and merged it to Linaro GCC 4.6.


The testing for my Thumb2 constants patches failed (bootstrap failure on 
ARM), so can't commit that right away. The failure is a SIGSEGV in the 
stage 2 compiler building it's own libgcc. This is going to be tricky to 
pin down!


Continued work on widening operations in the GCC middle-end. I now have 
it doing all the arbitrary width widening operations that I want. I've 
tested that it didn't do the wrong thing for just about all permutations 
of input and output types, but I've yet to do anything like a bootstrap 
test or anything. There's still quite a lot more work to do in tidying 
it up.




Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

[ACTIVITY] 13th - 18th June

[Andrew Stubbs]

Chaired the Toolchain Working group call. Michael H was unavailable (but 
OK) following yet another earthquake in Christchurch.


Continued working on my widening multiplies patches. I did think for a 
while there must be a logic flaw because it's using the wrong sized 
inputs to instructions, but on closer inspection that was taken care of 
in the RTL transformations. The changes I already had seem good in all 
the test cases I could generate. I've also identified a number of 
additional optimization opportunities, so I've been tweaking the patch 
for those.


Continued trying to figure out why my Thumb2 constants patches break the 
native bootstrap build. The stage2 compiler enters an infinite loop, but 
I couldn't easily identify why, as yet.


Backported Julian's unaligned access patches to a Linaro test branch.




Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

Re: GCC cross compilation help: [cannot compute suffix of object files]

[Andrew Stubbs]

You need to see config.log for more details. There'll be more than one
config.log, but probably only one will have this error message. Grep for it.

Once you have the relevant log snippet, we might be able to help you
decipher it.

Andrew

On 22/06/11 10:23, mins@globalunichip.com wrote:
> Hello,
> I tried to build the gcc-linaro cross compiler tool on the x86_64 
> ubuntu-10.04 machine.
> The build and host machine is the x86_64 ubuntu-10.04, the target is 
> arm-eabi.
> But failed and got the following error messages:
> -
> checking host system type... arm-unknown-eabi
> checking for arm-eabi-ar... arm-eabi-ar
> checking for arm-eabi-lipo... arm-eabi-lipo
> checking for arm-eabi-nm... /home/minslin/ET0001A/build-gcc/./gcc/nm
> checking for arm-eabi-ranlib... arm-eabi-ranlib
> checking for arm-eabi-strip... arm-eabi-strip
> checking whether ln -s works... yes
> checking for arm-eabi-gcc... /home/minslin/ET0001A/build-gcc/./gcc/xgcc 
> -B/home/minslin/ET0001A/build-gcc/./gcc/ 
> -B/home/minslin/linaro-gcc/arm-eabi/bin/ 
> -B/home/minslin/linaro-gcc/arm-eabi/lib/ -isystem 
> /home/minslin/linaro-gcc/arm-eabi/include -isystem 
> /home/minslin/linaro-gcc/arm-eabi/sys-include
> checking for suffix of object files... configure: error: in 
> `/home/minslin/ET0001A/build-gcc/arm-eabi/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> See `config.log' for more details.
> make[1]: *** [configure-target-libgcc] Error 1
> make[1]: Leaving directory `/home/minslin/ET0001A/build-gcc'
> make: *** [all] Error 2
> -
> 
> The configure options I used were:
> -
> ../gcc-linaro-4.5-2011.06-0/configure --target=arm-eabi 
> --enable-languages=c,c++ --enable-shared 
> --prefix=/home/minslin/linaro-gcc --with-gmp=/home/minslin/gmp 
> --with-mpfr=/home/minslin/mpfr --with-mpc=/home/minslin/mpc
> -
> 
> I downloaded and built the GMP, MPFR and MPC packages. The versions I 
> used are:
> gmp-5.0.2
> mpfr-3.0.1
> mpc-0.8.2
> 
> Please help me solving this problem.
> Thanks.
> 
> Best regards,
> 
> Min-Shong Lin (林敏雄)
> Engineering Division
> Global UniChip Corp. (創意電子)
> EMAIL : mins@globalunichip.com
> TEL : +886-3-5646600 ext. 6937
> 
> - Email Confidentiality Notice 
> --
> If you are not the intended recipient for this CONFIDENTIAL E-mail, 
> please delete it immediately without keeping or distributing any copy 
> and notify the sender.
> --
>  
> 
> 
> 
> 
> ___
> linaro-toolchain mailing list
> linaro-toolchain@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-toolchain


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

[ACTIVITY] 20th - 24th June

[Andrew Stubbs]

Continued work on widening multiplies. Finally got a point where I have 
something I'm happy to post upstream! Posted here:

http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08720.html

Richard Guenther reviewed one of the patches, and found a flaw, so I've 
been working on addresssing that.


Booked hotel for August sprint.



Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* Widening Multiplies 1/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08721.html
* Widening Multiplies 2/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08723.html
* Widening Multiplies 3/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08724.html
* Widening Multiplies 4/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08725.html
* Widening Multiplies 5/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08726.html
* Widening Multiplies 6/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08727.html
* Widening Multiplies 7/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08728.html

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

[ACTIVITY] 27th June - 1st July

[Andrew Stubbs]

Worked on updates to the widening multiplies patches following upstream 
review. This was never going to be as easy as it first looked, so I've 
spent much of the week trying to figure out how make annoying type casts 
go away.


Merged both FSF GCC 4.5 and 4.6 to Linaro GCC. Pushed the new tree to 
Launchpad for testing.





Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* Widening Multiplies 1/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08721.html
* Widening Multiplies 2/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08723.html
* Widening Multiplies 3/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08724.html
* Widening Multiplies 4/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08725.html
* Widening Multiplies 5/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08726.html
* Widening Multiplies 6/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08727.html
* Widening Multiplies 7/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08728.html

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

[ACTIVITY] 4th - 8th July

[Andrew Stubbs]

Completed the merge of FSF GCC 4.5 & 4.6 to Linaro GCC. There were a few 
extra test failure in the i686 testing for both toolchains, but x86_64 
and arm were clean, so it seems likely to be an environmental issue (in 
particular, some of the failures were linker crashes).


Posted an update to my widening multiplies patch 3. This one hopefully 
addressed the issues found by Richard Guenther. Also tested an posted 
updates to my other patches that had their context changed.


Richard picked more holes in my patch, and also reviewed patches 4, 5 
and 6. 4 & 5 only have minor issues so far, and 6 has actually been 
approved! :)


Rewrote patch 3 yet again following review. Richard has now modified the 
VRP pass to make the widening pass's job simpler, so I don't need it to 
do as much. Also rebaslined the whole patch set; Bernd's recent patch 
has introduced some conflicts.


Found (some of?) the bugs that broke my thumb2 constants patch. Pushed 
the updated patch to Launchpad for testing.


Updated a lot of the patch tracker data.

Half day Thursday.



Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* Widening Multiplies 1/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08721.html
* Widening Multiplies 2/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08723.html
* Widening Multiplies 3/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08724.html
* Widening Multiplies 4/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08725.html
* Widening Multiplies 5/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08726.html
* Widening Multiplies 7/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08728.html

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

[ACTIVITY] 11th - 17th July

[Andrew Stubbs]

Continued responding to review comments on my widening multiply patches. 
Wrote large parts of most of the patches to fix bugs and tidy them up. 
The result is that all but patch 1 are now approved. Pushed the patches 
to Launchpad for final testing.


Monitored the test status of my thumb2 constants patch, but it still 
hasn't returned any results. It seems Michael has been having some 
problems with his systems.


Went back to looking at merging patches to 4.6. It's only really the 
hard ones left. Many are blocked on work that needs to be done by 
somebody else. Pinged Tom and Bernd to find out the status of their ones 
- all are stuck on the back burner.





Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html
* Widening Multiplies 1/7
  http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg08721.html

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

Appologies

[Andrew Stubbs]

Hi All,

Apologies for missing the stand-up call today.

I've been having technical difficulties at my end. :(

I think they're resolved now ... maybe.

Andrew

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

[ACTIVITY] 18th - 22nd July

[Andrew Stubbs]

Spun release tarballs for Linaro GCC 4.5 and 4.6. Sent them to Michael 
Hope and Matthias Klose.


Testing for my widening multiplies patches revealed a bug when the 
accumulate value had a different type. The problem is easily fixed, so 
I've created a patch, submitted it, and now it's approved upstream.


Same again, this time with a bug involving constant integers. Again, 
easily fixed, submitted, and approved.


Nobody had reviewed the first patch in my series - Richard Guenther had 
reviewed all the others, but wasn't happy to review the expand pass. So, 
I asked newly crowned RTL Maintainer Richard Sandiford to review it, but 
apparently it's the wrong bit of the back-end, so I asked Bernd instead. 
Bernd kindly reviewed and approved it, so now the whole series is ready 
to commit if only my test comes back clean.


Continued trying to figure out why my thumb2 constants patch is broken. 
So far, no further progress. It might be that Michael's build system is 
confused, but it's looking likely to be a real bug.





Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

[ACTIVITY] 25th - 31st July

[Andrew Stubbs]

Continued work on widening multiplied. I've identified another cause for 
the bootstrap failure, and submitted the new version for testing.


Continued trying to find out how my thumb2 constants patches are broken. 
This is taking ages due to the time it takes to turn around a bootstrap 
build on my IGEP board.


Tried to get the CS Panda boards to work again. They'll do the bootstrap 
builds much faster (if still not quickly), but are no longer very well. 
All my attempts to bring them back up remotely have failed. I've 
discovered that the device the serial console on one was connected to 
has been relocated to the new Mentor Graphics board lab, so this might 
explain some of it 


Chaired the Monday and Thursday meetings in Michael's absence.

Travelled to the Linaro Connect event in Cambourne, near Cambridge.


Other:

More machine trouble. I keep thinking I have the display issues solved, 
and then it starts up with all the windows displayed double sized, but 
requiring mouse clicks in the correct location  typically this 
happened just when I needed access to the pin number for the Monday 
meeting. This hasn't happened since Monday, so hopefully it's now ironed 
out ... this sort of thing does not happen with Windows. :(





Upstream patched requiring review:
* NEON scheduling patch
  http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html

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

GCC 4.6 merge

[Andrew Stubbs]

Hi all,

I'm having real trouble here :(

I just can't seem to get bzr to work! I've tried to branch 
gcc-linaro/4.6 again and again, and it just won't. My other machine 
refuses to do the merge from lp:gcc/4.6, presumable because the bzr on 
there is too old.


I'm stuck. Can anybody else do the merge from upstream?

I'm going to keep trying.

Andrew

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

[ACTIVITY] 8th - 12th August.

[Andrew Stubbs]

* GCC

Continued tracking down problems in my various broken patches. Fixed one 
bug, investigated two more. Re-submitted the widening multiplies for 
testing, and this time it returned with no problems. Yay, I can now 
check it in next week.


Merged from upstream GCC 4.5. The launchpad import bug still exists 
(although should not for much longer) so I had to ask on #launchpad to 
get the imports done. Submitted the merged branch for testing.


Tried to merge GCC 4.6 similarly, but failed. Bzr just refused to play 
ball, which was very frustrating. Michael Hope has now done the merge 
instead.



* Other

On leave Wednesday and Friday.

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

Re: Basic libav profiling

[Andrew Stubbs]

On 18/08/11 06:56, Ira Rosen wrote:

How can I tell the vectoriser that a input is a multiple of something?

Unfortunately, I don't think you can.


I think you can do something like this:

void multiple(struct image * __restrict dst, struct image * __restrict
src, int h)
{
   if (h & 0xf)
 __gcc_unreachable ();

   for (int i = 0; i < h; i++) {
   dst->d[i] = A*src->d[i] + B*src->d[i+1];
   }
}

[Just off the top of my head - you'd have to check the syntax for 
gcc_unreachable.]


That should allow the value range propagation to do the right thing 
whilst inserting no real code, but whether that's properly hooked into 
vectorization I have no idea?


Andrew

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

Re: Is the Linaro toolchain useful on x86/x86_64?

[Andrew Stubbs]

On 17/08/11 12:38, Christian Robottom Reis wrote:

On Wed, Aug 17, 2011 at 04:09:21AM -0700, Bernhard Rosenkranzer wrote:

is the Linaro toolchain (esp. gcc) useful on x86/x86_64, or is an
attempt to use the Linaro toolchain with such a target just asking for
trouble?


Isn't this exactly what Ubuntu do for all their releases (from when we
started producing a gcc-linaro)?


I believe Linaro GCC is used as the basis for the Ubuntu system compiler 
on x86, amd64, armel, and ppc.


However, they do apply some additional patches, so we can't make any 
promises that the results will be the same. That said, most of their 
patches are customization and hardening, and they do report any bugs 
they find to us, so the extra patches shouldn't be that important.


Andrew

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

[ACTIVITY] 15th - 19th August

[Andrew Stubbs]

* GCC

Completed merging GCC 4.5 from FSF to Linaro.

Spun release tarballs for Linaro GCC 4.5 and 4.6. Uploaded them to 
Michael's server, and kicked off the test builds remotely.


Submitted expenses for Linaro Connect.

Finally (!) committed my widening multiplies patches to FSF. :)

Continued trying to figure out what's wrong with my thumb2 constants 
patches. I think I have identified a possible flaw, but I'm having 
trouble reproducing the problem as I have been unable to pin down a 
specific constant/expression combination that makes it through all the 
other optimizations intact, and triggers the problem. I've not run out 
of idea yet though ...



* Other

On leave all day Wednesday.

Prepared for the big CodeSourcery to Mentor switch-over by moving all my 
work-in-progress data over to the new servers.



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

Re: GCC 4.6 merge

[Andrew Stubbs]

On 15/08/11 02:02, Martin Pool wrote:

On 13 August 2011 17:31, Andrew Stubbs  wrote:

Hi all,

I'm having real trouble here :(

I just can't seem to get bzr to work! I've tried to branch gcc-linaro/4.6
again and again, and it just won't. My other machine refuses to do the merge
from lp:gcc/4.6, presumable because the bzr on there is too old.

I'm stuck. Can anybody else do the merge from upstream?


Are you getting an error?  If so, please let me know, or file a bug,
or ask in #bzr.


Hi Martin,

I can't reproduce either problem at the moment.

The machine with the old bzr has just been retired (finally), so 
hopefully that's a moot problem. In any case, it was an old one, so not 
your problem.


The problem branching to my local machine has also gone away. For a 
couple of days it just wouldn't work, but now I can't make it not work. 
There's been no software update (as far as I know) so I presume the 
problem was something else. (It could have been the power management on 
my wireless card? When I first tried it the machine was doing nothing 
else, but when I've tried it since I've been actively using it.)


Anyway, thanks for the offer.

Andrew

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

Re: how to properly enable multilib builds?

[Andrew Stubbs]

On 22/08/11 11:33, Matthias Klose wrote:

If I understand the code correctly, this comes from the hard setting of
MULTILIB_DEFAULTS in the arm target. If you look at mips, you see

#ifndef MULTILIB_DEFAULTS
#define MULTILIB_DEFAULTS \
 { MULTILIB_ENDIAN_DEFAULT, MULTILIB_ISA_DEFAULT, MULTILIB_ABI_DEFAULT }
#endif

which records the proper selected defaults.

Should something similiar be done for arm?


We seem to have no problem build a compiler that defaults to thumb by 
using --with-mode=thumb. How does that work?


Andrew

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

Re: how to properly enable multilib builds?

[Andrew Stubbs]

On 22/08/11 11:33, Matthias Klose wrote:

the current gcc-4.6 packages build for both softfp and hard, so that the armel
and (not yet existing) armhf packages can be installed together in the system.
To enable multilib, I currently use the rather complicated arm-multilib.diff,
which works, but doesn't seem to be correct. With the much simpler arm-ml2.diff,
the directory for the default multilib is not resolved to . (as done for e.g.
amd64).


Ok, I *think* I see the problem: you're not supposed to list the default 
library as a multilib.


Try this:

--8<>8--
ifeq ($(with_float),hard)
MULTILIB_OPTIONS= mfloat-abi=softfp
MULTILIB_DIRNAMES   = sf

else
MULTILIB_OPTIONS= mfloat-abi=hard
MULTILIB_DIRNAMES   = hf

endif
--8<>8--

Andrew

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

[ACTIVITY] 22nd - 27th August

[Andrew Stubbs]

Booked hotel and travel for Linaro Connect in Orlando.

Fixed a couple of bugs in my thumb2 constants patch and retested. The 
test results came back clean, so I've committed it upstream.


Bernd claimed he has found some test failures that might be caused by my 
patch, but I couldn't reproduce them at first. I've now got the failure, 
but I've not yet investigated the cause. Next week ...


Committed my widening multiplies patches to Linaro GCC, after first 
convincing Richard Sandiford that it wasn't totally bonkers.


Started work on ARM GCC tuning options:
 * Submitted a patch for -m{arch,cpu,tune}=native
   http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg14225.html
 * Submitted a patch for -m{arch,cpu,tune}=generic-armv7-a
   http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg14231.html

Joseph found an issue with those patches, but that was easily resolved 
and I've reposted both.



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

Re: GCC trunk fails to build

[Andrew Stubbs]

On 29/08/11 21:22, Michael Hope wrote:

See:
  http://builds.linaro.org/toolchain/gcc-4.7~svn178154

The problem is -Werror triggering on:

../../../gcc-4.7~/gcc/config/arm/arm.c: In function 'int
optimal_immediate_sequence_1(rtx_code, long long unsigned int,
four_ints*, int)':
../../../gcc-4.7~/gcc/config/arm/arm.c:2690:46: error: comparison
between signed and unsigned integer expressions [-Werror=sign-compare]


Oh, that's my patch. :(

I'll fix it.

Andrew

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

Csmith

[Andrew Stubbs]

Do we know anything about "Csmith"?

Maybe we should try it?

Andrew

 Original Message 
Subject: Re: [PATCH][ARM] pr50193: ICE on a | (b << negative-constant)
Date: Thu, 1 Sep 2011 13:21:38 + (UTC)
From: Joseph S. Myers 
To: Andrew Stubbs 
CC: gcc-patc...@gcc.gnu.org, patc...@linaro.org
Newsgroups: gmane.comp.gcc.patches
References: <4e5f6b5f.2020...@codesourcery.com>

On Thu, 1 Sep 2011, Andrew Stubbs wrote:


This patch fixes the problem by merely checking that the constant is positive.
I've confirmed that values larger than the mode-size are not a problem because
the compiler optimizes those away earlier, even at -O0.


Do you mean that you have observed for some testcases that they get
optimized away - or do you have reasons (if so, please state them) to
believe that any possible path through the compiler that would result in a
larger constant here (possibly as a result of constant propagation and
other optimizations) will always result in it being optimized away as
well?  If it's just observation it would be better to put the complete
check in here.

Quite of few of the Csmith-generated bug reports from John Regehr have
involved constants appearing in unexpected places as a result of
transformations in the compiler.  It would probably be a good idea for
someone to try using Csmith to find ARM compiler bugs (both ICEs and
wrong-code); pretty much all the bugs reported have been testing on x86
and x86_64, so it's likely there are quite a few bugs in the ARM back end
that could be found that way.

--
Joseph S. Myers
jos...@codesourcery.com


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

[ACTIVITY] 29th - August - 3rd September

[Andrew Stubbs]

* Linaro GCC

Fixed up, committed and posted two bug fixes to my thumb2 constants 
patches, found by other people running FSF trunk.


Analysed bug lp:836401 / pr50193, developed a fix, and posted it both 
upstream and to launchpad for testing. The launchpad tests have come 
back clean, and the patch is approved, but upstream have not approved it 
yet.


Posted a query to linaro-dev mailing list asking for ARM CPU ID register 
numbers, and got lots back. Entered these into the patch, and begun some 
test builds. I will post the new verion upstream, if all's well, next week.


Started looking at an optimization I discussed with Richard Earnshaw in 
Cambourne, in which GCC attempts to synthesize constants more 
efficiently by reusing constant values already in registers. I've made a 
start, but not much more to say just yet.




* Other

- Public holiday Monday.
- Half day leave on Wednesday.
- Internal train session

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

[ACTIVITY] 5th - 11th September

[Andrew Stubbs]

Merged both GCC 4.5 and 4.6 from FSF to Linaro. Matthias requested that 
I avoid a particular upstream 4.6 commit, so I selected the revision 
before that as the merge point. The problem was then fixes upstream, and 
another fix was desirable, so I've redone the merge from the branch head.


Another widening-multiplies bug was reported to me (I logged it as 
pr50318/lp843775), so I've fixed that and committed the fix upstream, 
and filed a merge request on Launchpad.


Finished fixing the bugs in my thumb2 constants optimizations, and 
backported the new patches to Linaro GCC 4.6. Pushed the updated stuff 
to Launchpad for testing.


Richard Sandiford found a flaw in my patch for pr50193/lp836401, so I've 
done another version of that and posted it upstream. Ramana didn't like 
that version. I've started again trying to fix it a different way, but I 
don't have it working just yet.


Continued work on my new constant reuse patch. I have it detecting many 
constant expressions, and calculating the values for some of them. Once 
it does that sufficiently well, the next step is to track what constants 
are available where, I then I'll be in a position to find optimization 
opportunities. At the moment, 'sufficiently well' could just mean 
MOVW/MOVT pairs, as those are the most common


Tried to get the CS Panda Boards up and running again after the move. No 
success. Ricardo is on the case. I'm still using the boards located at 
Canonical.


Andrew

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

Implicit-it upstream discussion.

[Andrew Stubbs]

Hi Michael,

Here's the gcc-patches@ discussion you asked for:

http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01339.html
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01351.html
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01353.html
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01354.html
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01355.html
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01356.html
http://gcc.gnu.org/ml/gcc-patches/2010-07/msg01357.html

Andrew

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

[ACTIVITY] 12th - 17th September

[Andrew Stubbs]

* Linaro GCC

Spun 4.5 and 4.6 2011.09 GCC release tarballs. Uploaded them to 
Michael's server, and kicked off the tests.


Continued work on my new constant optimization experiments. I now have 
it tracking all the constants and am looking at how to detect the 
optimization opportunities. So far it only calculates how exprensive it 
would be to generate a value by adding to an existing constant, which is 
a start at least. I'm having difficulties detecting whether changing an 
insn will make it's parent (dependency-wise) obsolete, or not (and 
therefore whether to count its costs - there's no problem for 
instructions that overwrite an entire register, but ones that write to 
portions of registers (such as MOVT) make more complex dependency 
chains, and the def-use chains don't seem to be sorted into the order of 
use.



* Other

Half day vacation on Thursday.

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

[ACTIVITY] 26th - 30th September

[Andrew Stubbs]

* Vacation

Monday, Tuesday, and Wednesday.



* GCC

Continued work on my constant reuse optimizations. Disappointingly, I've 
found that there are very few optimization opportunities in EEMBC 
(ARM/Thumb V7-A), although it's not difficult to write testcases that 
the optimization could improve. I also discovered that the data-flow 
chains don't work exactly how I thought (with respect to if-then-else 
cases) so I need to do a little more work.


Pinged the native tuning patches; they're still waiting for upstream review.

Still can't get the generic tuning work done as the CodeSourcery panda 
boards appear to be still offline.


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

[ACTIVITY] 3rd - 7th October

[Andrew Stubbs]

Continued work on my constant reuse optimizations. Not too much this 
week though. I've now fixed some issues with the ARM size-costs code 
that was causing it to wildly over-estimate the cost of a MOVT 
instruction. I'll have to post this upstream sometime soon.


Took another look at the shift-amount bug. Discussed the issue with Paul 
Brook. I've now fixed the original bug, and fixed the new bug introduced 
by Paul's original fix, and committed that upstream. I still need to 
backport it to Linaro GCC though, and the latent bug that Richard S 
spotted is still being analysed.


Did a merge from FSF 4.5 & 4.6 to Linaro, and pushed them the Launchpad 
branches for testing.


Begun work benchmarking different setups for the generic tuning patches. 
I had a lot of trouble trying to set up SPEC2000 though. Hopefully these 
issues are now resolved, with some help from Michael, and I have 
established some baseline figures on both A8 and A9 to work from.


No progress on native tuning. I'm still waiting for upstream review.

In other news: Mentor's contract with Linaro has now been extended for 
another 6 months. :)


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

How to install an ARM cross compiler

[Andrew Stubbs]

Saw this, thought it might be interesting if we want to point people at 
it something in future 


http://playterm.org/r/install-an-arm-cross-compiler-1316950150

Maybe we could record some more detailed stuff ourselves?

Andrew

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

[ACTIVITY] 10th - 14th October

[Andrew Stubbs]

Completed the 4.5 and 4.6 FSF to Linaro merges.

Spun the Linaro GCC release tarballs, uploaded them to the test farm, 
and set off the test builds.


Continued looking at the constant reuse optimization. This time I've 
build GCC itself with the new pass to see how many optimization 
opportunities there are. This shook out a lot more small bugs, which was 
useful.


Backported my negative-shifts patch to Linaro 4.6, pushed it to 
Launchpad for testing, and then committed it to 4.6 once in was approved.


Experimented with running SPEC2K on A8 and A9 boards in order to 
establish a baseline for the generic tuning tweaks. A short test doesn't 
give much clue as to what can be achieved, and a long test takes way too 
long. The problem is also complicated by the benchmarks where the A8 
tuning works better on A9 than A9 tuning does. :S


Received a bug report (GCC bugzilla 50717) for my widening multiplies 
patches. Analysed the problem, developed a patch, and posted it to 
gcc-patches.


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

[ACTIVITY] 17th - 21st October

[Andrew Stubbs]

Continued looking at my constant reuse optimization. I've identified a 
couple of hundred optimization opportunities in the whole of gcc itself, 
which is fewer than I had hoped. There are almost no opportunities when 
compiling for size as constants are always loaded from a constant pool 
in that case (I'm not sure why that's the case, given that this isn't 
any more space efficient than movw+movt, unless it can share the 
constant in more than one place).


Backported my -mtune=native patch to Linaro GCC.

Backported my generic tuning patch to Linaro GCC.

Backported my pr50717 patch to Linaro, and pushed to Launchpad for testing.

Analysed my benchmark results I made to aid generic tuning. 
Disappointingly the A8/A9 tuning is not as beneficial as one would like. 
In fact, the existing generic tuning patch (which was supposed to be a 
framework only) is actually quite competitive and gives better 
performance in some cases.


Set more benchmarks running, this time with NEON enabled. That's about 
36 hour's worth on A9, and more like 90 hours on my A8 (obviously, 
there's some difference in the clock speeds there).


Discovered that my native tuning code won't compile with a C++ compiler 
(GCC Bugzilla PR50809). Tested and committed a fix upstream.


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

[ACTIVITY] 24th - 28th October

[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

LAVA recipe

[Andrew Stubbs]

Hi All,

This is a brain dump of what I learned about running LAVA today.

Dave will probably find a place for this in the Validation wiki, but 
I'll pass it round in the meantime.


Hope it helps

Andrew
1. Get permission to schedule tests on validation.linaro.org:

  Click "sign in" at top right of the website, select launchpad.net
  log in option, ensure that your name, username, and email address are
  checked, and sign in. Then, contact the validation team, and ask them
  to add the correct permissions to your account.

2. Install the lava client tools:

  sudo add-apt-repository ppa:linaro-validation/ppa
  sudo apt-get update
  sudo apt-get install lava-scheduler-tool lava-dashboard-tool

3. Create an Authorization Token on validation.linaro.org:

  Click "API"
  -> "Tokens"
  -> "create" (on right)
  -> "Create Token"
  -> "Toggle"

  A long token string should be displayed.

4. Install the token on you machine:

  lava-tool auth-add https://use...@validation.linaro.org/lava-server/RPC2/

5. Create a personal test stream to store your test results:

  This may not be necessary if you wish to post your results to one of the
  existing streams on validation.linaro.org.

  lava-dashboard-tool make-stream \
   --dashboard-url http://validation.linaro.org/lava-server/RPC2/ \
   /anonymous/USERNAME/

6. Create a job file:

  This example just runs the 'stream' basic test which is built into lava-test.

  You need to select suitable rootfs and hwpack tar files. It's easiest to
  select some from releases.linaro.org or snapshots.linaro.org. Beware that
  not all images work - you can get a clue about recent images from the
  validation.linaro.org home page.

---jobfile1.json-
{
  "job_name": "foo",
  "device_type": "panda",
  "timeout": 18000,
  "actions": [
{
  "command": "deploy_linaro_image",
  "parameters":
{
  "rootfs": "ROOTFS-URL-HERE",
  "hwpack": "HWPACK-URL-HERE"
}
},
{
  "command": "lava_test_install",
  "parameters":
{
"tests": ["stream"]
}
},
{
  "command": "boot_linaro_image"
},
{
  "command": "lava_test_run",
  "parameters":
{
  "test_name": "stream"
}
},
{
  "command": "submit_results",
  "parameters":
{
  "server": "http://validation.linaro.org/lava-server/RPC2/";,
  "stream": "/anonymous/USERNAME/"
}
}
  ]
}
--

7. Submit the test to the LAVA scheduler

  lava-tool submit-job \
https://use...@validation.linaro.org/lava-server/RPC2/ \
jobfile1.json 



==

If you want to run a custom test not pre-installed with lava-test,
i.e. an "Out-of-Tree Test", this can be done too.

1. Wrap up your testsuite in a tar file with a simple script

  This can look like whatever you like, it just needs to do the right
  thing when invoked.

2. Post your testfile to a public place.

  people.linaro.org is a good place.

3. Create a "Test Definition File".

  This gives what commands need to be executed to install and launch
  your test file.

  So, for example, this installs bzr, downloads and untars a file,
  runs a script, and uses the standard regex for recognising PASS
  or FAIL lines:

--simple-oot-test.json--
{
"format": "Lava-Test Test Definition 1.0",
"test_id": "mwhudson-dummy",
"install": {
"deps": ["bzr"]
"url": http://people.linaro.org/...";
"steps": ["bzr branch ", "tar xf "],
},
"run": {
"steps": ["mytestdir/go-script some parameters"]
},
"parse": {
"native": true
}
}


4. Create a job file.

  This is exactly the same as the job file above, but references the
  definition file:

--jobfile2.json--
{
  "job_name": "foo",
  "device_type": "panda",
  "timeout": 18000,
  "actions": [
{
  "command": "deploy_linaro_image",
  "parameters":
{
  "rootfs": "ROOTFS_URL_HERE",
  "hwpack": "HWPACK_URL_HERE"
}
},
{
  "command": "lava_test_install",
  "parameters":
{
"tests": ["my-out-of-tree-test"],
"register": ["http://people.linaro.org//simple-oot-test.json";]
}
},
{
  "command": "boot_linaro_image"
},
{
  "command": "lava_test_run",
  "parameters":
{
  "test_name": "my-out-of-tree-test"
}
},
{
  "command": "submit_results",
  "parameters":
{
  "server": "http://validation.linaro.org/lava-server/RPC2/";,
  "stream": "/anonymous/USERNAME/"
}
}
  ]
}


5. Submit the job, as before.

  lava-tool submit-job \
   https://use...@validation.linaro.org/lava-server

Re: LAVA recipe

[Andrew Stubbs]

On 03/11/11 18:08, Andrew Stubbs wrote:

5. Create a personal test stream to store your test results:

   This may not be necessary if you wish to post your results to one of the
   existing streams on validation.linaro.org.

   lava-dashboard-tool make-stream \
--dashboard-url http://validation.linaro.org/lava-server/RPC2/  \
/anonymous/USERNAME/


An "anonymous" stream may have a personal name, but is open to anybody 
for both read and write (IIUC).


Other types of stream:

* User writeable, public readable

  lava-dashboard-tool make-stream \
   --dashboard-url \
   https://use...@validation.linaro.org/lava-server/RPC2/ \
   /public/personal/USERID/


* User readable/writeable only

  lava-dashboard-tool make-stream \
   --dashboard-url \
   https://use...@validation.linaro.org/lava-server/RPC2/ \
   /private/personal/USERID/

(Note the https, not http, and user id in the URLs. The trailing '/' on 
the stream name is also required.)


I think there are also /private/group/... stream types (or will be)?

---

The important thing for us is that tests submitted to /private/personal 
streams will be invisible to other users and are suitable for benchmark 
results. :)


BUT the jobs *will* be visible in the scheduler (for the moment) so we 
have to be careful that no confidential information leaks into the json 
file or the serial port output. Basically we have to redirect the 
results into a file on the target.


I have yet to find out how to scan the results from the private file, 
but I'm told it's possible. I'll post it here when I found out ...


Andrew

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

[ACTIVITY] 4th -11th November

[Andrew Stubbs]

Spun Linaro GCC 4.6 release tarball, uploaded it to Michael's server, 
and launched the testing.


Continued work on constant reuse optimization. I've now eliminated some 
more false positives caused by inconsistent rtx_cost results. It turns 
out the pass also fixes up inefficient constants generated by 
arm_split_constants, which is nice.


Set yet more spec benchmark runs going as part of the generic tuning 
investigation.




Other:

Half day Monday to recover from the weekend's travel.

Half day on internal Mentor activities.

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

Re: Output miscompare in 175.vpr

[Andrew Stubbs]

On 16/11/11 22:03, Michael Hope wrote:

Hi there.  The 4.6-2011.10 release causes an output miscompare failure
in 175.vpr from SPEC 2000.  The fault didn't exist in 2011.09 and has
cleared in 2011.11.

Does this ring a bell with anyone?  Andrew, could it be related to
your widening multiplies fix?


As far as I can see, there were no widening-multiplies related changes 
between 2011.09 and 2011.10, so no, I don't think so.


Andrew

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

[ACTIVITY] 14th - 18th November

[Andrew Stubbs]

Continued looking at constant reuse optimizations, as a background task. 
I've fiddled with the costs a bit more to remove false positives.


Continued benchmarking different generic tuning ideas. With each test 
run taking most of a day this is slow going.


Took Michael's rootfs that is used for all the toolchain testing and 
benchmarking, unpacked it, and repacked it so that it is compatible with 
"linaro-media-create", then tested that I could use it to run tests on 
LAVA successfully. I was hoping to use this for extra benchmarking 
bandwidth, but there's a permissions problem in the LAVA website 
software that means it's not yet possible to post private results to the 
system, so no proprietary benchmarks yet. I can still continue 
pipe-cleaning my process, and maybe run some benchmarks without actually 
reporting the results (or perhaps posting them somewhere write-only).


Begun work on adding GCC support for 64-bit shifts with NEON. This is 
not quite as simple as it ought to be because a) it's inefficient to 
move a value to NEON registers just to do a shift, so it needs to detect 
where the value is, and b) right shifts are encoded as left shift by a 
negative amount, and negative shift amounts are normally considered 
undefined behaviour.


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

Re: [ACTIVITY] 14th - 18th November

[Andrew Stubbs]

On Mon 21 Nov 2011 21:26:03 GMT, Michael Hope wrote:

Took Michael's rootfs that is used for all the toolchain testing and
benchmarking, unpacked it, and repacked it so that it is compatible with
"linaro-media-create", then tested that I could use it to run tests on LAVA
successfully. I was hoping to use this for extra benchmarking bandwidth, but
there's a permissions problem in the LAVA website software that means it's
not yet possible to post private results to the system, so no proprietary
benchmarks yet. I can still continue pipe-cleaning my process, and maybe run
some benchmarks without actually reporting the results (or perhaps posting
them somewhere write-only).


We can rsync them to the validation machine as a step and only post a
summary, such as the number of regressions or improvements, to LAVA.


Yeah, I've investigated pushing the private results to 
people.linaro.org, but to do so would require exposing an encryption 
key, and p.l.o does not permit use of .ssh/authorized_keys so I can't 
create a restricted one for the purpose. I could upload them to my home 
server, but that doesn't help anyone else. I could set something up to 
receive write-only file drops on p.l.o with a non-standard port number 
(if there's no firewall), but it might be harder to encrypt it, though 
that might not matter.



Begun work on adding GCC support for 64-bit shifts with NEON. This is not
quite as simple as it ought to be because a) it's inefficient to move a
value to NEON registers just to do a shift, so it needs to detect where the
value is


Is this true for all 64 bit operations?  What do the other operations
currently do?


Basically, the neon 64-bit integer ops all provide two options: one for 
neon mode; and one for core-regs mode (that calls the normal 32-bit 
splitter). The decision which is used is essentially random - there's a 
marker on the fallback alternatives that slightly disparages that option 
(all else being equal), but it really just depends on where the register 
allocator happens to find room for a DImode value. Once the first 
register has been allocated, the patterns will tend to force the 
allocator to continue to use that mode for the rest of the algorithm, 
until it hits something that isn't provided or implemented by neon.


I've found that DImode values that come from function parameters will 
almost never use neon - they're already allocated in core-regs, so it 
always prefers that option.


DImode values loaded from memory also tend to be loaded to core-regs in 
small test cases. I intend to try a few cases where core-regs are less 
available to see what happens then, but maybe we can do something to 
alter the allocation algorithm when neon is available.


BTW, is hard float mode, are 64-bit integers passed in core-regs still? 
I expect so, since hard-float doesn't imply neon, but it would probably 
be a bonus if they were passed in neon registers.



and b) right shifts are encoded as left shift by a negative
amount, and negative shift amounts are normally considered undefined
behaviour.


But the behaviour is defined for NEON, and this only appears at the
assembly level - you implement a right shift by constant as the left
shift by negative constant in the assembly.


I'm not talking about shifts by constants, this is shifts by variable. 
True, GCC is probably more forgiving in that case because it's less able 
to reason about them, but if some value range propagation pass can 
determine that it's negative (now or in future) you never know what 
might happen.


Andrew

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

[ACTIVITY] 21st - 25th November

[Andrew Stubbs]

Worked on adding support for 64-bit NEON integer shifts. I have this 
working now, although I'm still not very happy about how the register 
allocator chooses which mode to use - it prefers core-registers if the 
values start or end in core-regs, even though moving to values to NEON 
registers might be more efficient (general 64-bit shifts in core 
registers require several instructions). I've also had to mark the CC 
register clobbered in all cases, even though it only gets clobbered in 
some of them, which might be necessary, but isn't very satisfactory.


The NEON shifts work showed that 32->64 bit extends could be done better 
also. This hasn't been a great problem up to now, but the shift amount 
(in particular) is typically a 32-bit value and yet needs to be 
zero-extended to 64-bit for NEON's purposes. Right now, GCC prefers to 
extend the value in core-registers, and then copy it to NEON. This 
works, but burns another core-register - a scarce commodity - so I think 
it would be better to copy it first, and then extend it after. NEON has 
instructions for this, so I'm investigating how to get the compiler to 
do it (this is all strictly post-combine, so the usual options are out, 
and the register allocator has to be allowed to do it the old way in the 
case where core-regs really are the best option, so it's tricky).


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

[ACTIVITY] 28th November - 2nd December

[Andrew Stubbs]

* Linaro GCC

Continued work on 64-bit shift / extend / etc. in NEON. I have posted an 
RFC to the gcc-patches list in the hope of getting some feedback on how 
best to fix this. No response yet. Hopefully some of the Linaro guys are 
at least looking at it ...


Merged FSF GCC 4.5 and 4.6 into the Linaro GCC release branches prior to 
the release next week.


Set more benchmarking work running in my ongoing investigation into 
generic tuning.


Did a dry run of the extra release testing Michael normally does. It 
failed. Michael says he's fixed it now, but I know how to do my bit, so 
fingers crossed.




* Other

Experienced some IT/connectivity outages within Mentor. Resolved now.

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