-fremove-local-statics optimization

As already discussed with Loic, CodeSourcery have a GCC patch that implements a new optimization: -fremove-local-statics. Essentially, it transforms code like this: int foo (void) { static int a = 1; return a; } into this: int foo (void) { int a = 1; return a; } Admittedly, if the c

Re: -fremove-local-statics optimization

On 29/07/10 17:23, Andrew Stubbs wrote: > This patch was originally submitted, by RedHat, to gcc-patches here: > http://gcc.gnu.org/ml/gcc-patches/2008-07/subjects.html#00982 Joseph points out, the patch we have in our tree is not actually the same one posted in the link above. Our patc

Ubuntu Lucid running from SD card on IGEPv2

Hi all, These are approximate instructions for installing Lucid on an IGEPv2. It uses the kernel recommended on the IGEP site because this supports the SD card. I'm sure an ubuntu kernel will be fine later. At the end, you will have an SD card that will boot the IGEPv2 board with no external i

Re: Ubuntu Lucid running from SD card on IGEPv2

On 30/07/10 11:51, Loïc Minier wrote: > On Fri, Jul 30, 2010, Andrew Stubbs wrote: > I had put Julian's instruction at >https://wiki.linaro.org/Boards/Igep > > perhaps you can extend that proposing an alternate install? OK, it&

Re: Multiarch paths and toolchain implications

On 31/07/10 19:01, Ulrich Weigand wrote: > I've finally completed a first of draft the write-up of toolchain > implications of multiarch paths that we discussed in Prague. Sorry it took > a while, but it got a lot longer than I expected :-/ > > I'd appreciate any feedback and comments! Thanks Ulr

Re: Multiarch paths and toolchain implications

On 02/08/10 12:46, Ulrich Weigand wrote: > The second half of the section "Loading/running an executable" is about > thw HWCAP stuff (look for "capability suffix"). In the summary I have > this point: > > * If capability-optimized ISA/ABI-compatible library variants are desired, >they can be b

Re: -fremove-local-statics optimization

On 29/07/10 17:23, Andrew Stubbs wrote: > So basically we're left with this patch that does something we want, but > not in a way that can go upstream. :( > > The question is, should I merge this to Linaro, or not? Loic and I > agreed to hold off until I'd done a bit more

GCC PRE patch; apply or not?

CS has this patch in SG++: http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00199.html This patch improves code size in a useful, target independent way, but was not committed upstream. It's not clear why. Since the patch does not belong to CodeSourcery, we can't upstream it ourselves either. Is th

Re: [gnu-linaro-tools] Re: GCC PRE patch; apply or not?

On 02/08/10 16:03, Ulrich Weigand wrote: > Latest status seems to be that the original patch no longer applies, > but Joern did an updated (and somewhat modified) version. This seems > to have triggered a more general discussion on how to correctly > estimate the effect of adding PHI nodes on code

Re: Multiarch paths and toolchain implications

On 02/08/10 20:16, Ulrich Weigand wrote: > Now this point is where the suggestion to use something like a bind mount > on startup comes in. That way, there would be no violation of the > multiarch rules, because /lib/ld.so.1 would not be part of any package, > and in fact not even part of any file

Re: Patch tracking method

On 17/08/10 00:23, Michael Hope wrote: > Thoughts? This isn't what we discussed at all Yes, keeping a bug open to track work begun upstream is probably a good policy, but it's not at all what we were discussing. The patch tracker should ensure that all revisions in the bzr branch are subm

Re: Patch tracking method

On 17/08/10 10:39, Andrew Stubbs wrote: > I'm going to write a "method 2" to explain what I need/want. Now done: https://wiki.linaro.org/WorkingGroups/ToolChain/PatchTracking#Method%202 Andrew ___ linaro-toolchain mailing lis

Re: Patch tracking method

On 17/08/10 10:39, Andrew Stubbs wrote: > I really wanted this done weeks ago (when I originally implemented it), > so I'm now getting frustrated that every time it looks like we're > getting somewhere, it seems to have gone off on a tangent and lost sight > of all the origin

Re: Patch tracking method

On 17/08/10 23:38, Michael Hope wrote: > Hi Andrew. I'm confused - apart from a few differences, our methods > seem to be the same. > > The differences against Method 1 are: > 1. Every revision has an associated ticket > 2. There's a bot that automatically creates a ticket per revision Yes, b

Re: Patch tracking method

On 18/08/10 22:36, Michael Hope wrote: > You can tell which revisions are untracked by the patchtracker report > at http://ex.seabright.co.nz/helpers/patchtrack. Revisions that are > currently untracked can be added to an existing ticket by adding a one > line 'related:' comment to that ticket, or

Patch Tracking Use Cases

The patch tracking conversation has got a little out-of-hand, and I know I've misunderstood some of the features Michael has been proposing, and I suspect vice versa. So, here's my attempt to compare and contrast the various advantages, disadvantages, and differences of the ideas so far, by mea

Re: Versatile Express board

On 24/08/10 00:39, Michael Hope wrote: > Hi there. We have a Toolchain WG has a Versatile Express board coming > our way. It's a quad-core Cortex-A9 with 1 GB of RAM, so quite decent > really. > > Does anyone have a pressing need for it? If not then I'll take it and > make it available over SSH.

Ubuntu GCC version numbers

Hi all, I've just discovered that Ubuntu is not using the Linaro release information in the --version string. This is not ideal when we get bug reports as it makes it hard to understand what Linaro release to use to reproduce the issue. Therefore, I've created a new wiki page to track the mapp

Re: Ubuntu GCC version numbers

On 27/08/10 13:01, Matthias Klose wrote: > Yes. The Linoro version misuses the DEV-PHASE field, and introduces > another pair of parantheses, and a pair of square brackets. How much > version parsing code out there will break with the new schema? I didn't > want to find out for 10.10/10.11. It is

Re: Thumb2 code size improvements

On 06/09/10 07:16, Yao Qi wrote: > I've put some ideas in this wiki page, > https://wiki.linaro.org/Internal/People/YaoQi/Thumb2Optimize We probably shouldn't post Internal links to this public list. Is there any reason this can't be done in the open? Now for the page content I think you s

Re: Thumb2 code size improvements

On 07/09/10 13:01, Yao Qi wrote: >> * Investigate reduced alignment constraints? > > Any details on this? No, I just know that some targets like to align functions to cache-lines. This is a useful speed optimization, but does lead to lots of "blank" gaps in the code. I have no real idea if ARM d

Re: Thumb2 code size improvements

On 09/09/10 16:22, Yao Qi wrote: > GCC produces code like this, > 0024: >24: f000 000f and.w r0, r0, #15 >28: 2807cmp r0, #7 >2a: d901bls.n 30 >2c: 3810subsr0, #16 >2e: b280uxthr0, r0<--[1] >

Re: 2010.09 build results

On 13/09/10 00:46, Michael Hope wrote: > Your thoughts? The only real regressions are the vectorizer tests, and I'm not worried about those because a) They're only missed optimizations, not correctness issues, and b) I know there are also a number of progressions in the vectorizer tests, so wha

Re: Cross compiling for embedded targets

On 11/09/10 23:03, Michael Hope wrote: > Oh, I have very unusual needs. I want to use the product I'm working > on in an after-hours project. CodeSourcery don't provide a Linaro GCC > 4.5 based toolchain. There will be a GCC 4.5 based toolchain from CodeSourcery in a month or two. Of course, th

Re: NEON vectorization improvements - preliminary notes

On 15/09/10 10:37, Julian Brown wrote: > The "vect256" branch now has a vectorization factor argument for > UNITS_PER_SIMD_WORD (allowing selection of different vector sizes). > Patches to support that would need backporting to 4.5 if that looks > useful. Could investigate the feasibility of doing

Re: [gnu-linaro-tools] Thumb2 size optimization report

On 15/09/10 14:49, Yao Qi wrote: > * Goal >Goal of this work is to look for thumb2 code size improvements on FSF > GCC trunk. Thank you Yao, I think we've definitely got some things we can do good work on here. :) Andrew ___ linaro-toolchain maili

Re: binutils testsuite Thumb-2 coverage

On 16/09/10 09:23, Chung-Lin Tang wrote: > Hi, > about the status of binutils testsuite Thumb coverage (CS204 in the > workplan), I have filed two Launchpad bugs: Thanks Chung-Lin. :) Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.lina

Re: Branding for Linaro GDB package

On 21/09/10 22:44, Michael Hope wrote: >> GNU gdb (Linaro GDB) 7.2-2010.10-0 >> > Copyright (C) 2010 Free Software Foundation, Inc. >> > License GPLv3+: GNU GPL version 3 or later >> > >> > This is free software: you are free to change and redistribute it. >>

Re: NEON vectorization improvements - preliminary notes

On 22/09/10 12:23, Ira Rosen wrote: >> The goal is a 15% speed improvement in EEMBC relative to FSF GCC 4.5.0 > Does this mean to improve a single benchmark from EEMBC by 15%? > Do you have an EEMBC? I have a very old version, without DENBench, which > looks interesting according to EEMBC's site. O

CS MinGW patches

As discussed in the meeting yesterday, CodeSourcery has a few MinGW patches that I had not merged into Linaro GCC. I have now investigated these patches, and I'm fairly happy that most are not necessary for Linaro. They're mainly about interworking with Cygwin. The one exception is this one:

Re: Plan of CS304: Thumb2 tuning investigation

On 05/10/10 15:01, Yao Qi wrote: First of all, the goal of this work is about investigation on speed improvement on linaro gcc 4.5. Finally, the output/result of this work is to list all possible recommendations/actions to improve speed on linaro 4.5. Comments to this plan are welcome. I beli

Re: the linaro toolchain and older arm versions

On 06/10/10 15:48, Loïc Minier wrote: On Wed, Oct 06, 2010, John Rigby wrote: The hypothetical scenario is a developer that maintains u-boot for multiple platforms. Using a codesourcery or eldk (from denx.de) toolchain one can use the appropriate -march= to get the righ

Re: the linaro toolchain and older arm versions

On 07/10/10 12:03, Wookey wrote: gcc has the multilib feature, but the way it is implemented means it works well for about 2 or 3 options, but you rapidly get combinatorial explosion of libgcc instances if you try to do more things than that. (i.e if you ask for v5, v6, v7, vfp, and neon options

Re: the linaro toolchain and older arm versions

On 07/10/10 12:36, Matthias Klose wrote: last time I checked this "multilibs" feature was implemented by building the toolchain N times. By which magic is the correct library selected? I didn't find anything in fsf trunk which supports this kind of multilibs builds. It's there, and has been sin

Re: the linaro toolchain and older arm versions

On 07/10/10 13:08, Matthias Klose wrote: they must have renamed that recently from --enable-multilib ;) Sneaky bunch, those GCC maintainers! right, the multilib options are in t-arm-elf, not in t-linux-armeabi. The old t-linux has the ones for hard/softfp commented out. Right, Linux compile

Re: the linaro toolchain and older arm versions

On 07/10/10 12:54, a...@arndb.de wrote: On Thursday 07 October 2010 13:03:14 Wookey wrote: gcc has the multilib feature, but the way it is implemented means it works well for about 2 or 3 options, but you rapidly get combinatorial explosion of libgcc instances if you try to do more things than t

Re: finding in 4.5.2 20101003 (Linaro) [release 4.5-2010.10-0]

Hi Leonid, You do indeed have a compiler bug here! We now have a fix for it, and the Linaro GCC sources should be updated in the next few days. If you don't want to wait for that, you can find the patch here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45805 Apologies for the inconvenience

Re: Assembler bug blocking Thumb-2 kernel builds

On 04/11/10 17:41, Dave Martin wrote: I believe this may be already by tracked by CodeSourcery as is issue #8775 (?) Has anyone hit this issue before? Is it fixed upstream? Yes, as you say it is CS Issue #8775, reported by ARM. The bug should be fixed in the imminent CS SG++ release. I do no

Re: Assembler bug blocking Thumb-2 kernel builds

On 05/11/10 09:46, Dave Martin wrote: Yes, as you say it is CS Issue #8775, reported by ARM. The bug should be fixed in the imminent CS SG++ release. I do not think the patch is upstream yet. Can we get it upstream and/or into the linaro tools? There's no such thing as Linaro Binutils, just y

Upstream GCC feature freeze

Hi all, As you may or may not know, upstream GCC has now entered 'stage 3' of it's development cycle. This will last until spring. This means that they are only accepting bug fixes and documentation improvements. New features and any performance improvements must wait until GCC 4.6 branches,

GCC SVN vs. BZR/LP

Re my recent email "Upstream GCC feature freeze", I think we're agreed that we need to create a branch that tracks GCC 4.6 development, but has our own performance improvements included. The question is where to host it? Option 1: Launchpad/bzr Pros: * We need no permission to do it * The br

Re: GCC SVN vs. BZR/LP

On 09/11/10 12:55, Ira Rosen wrote: * We can't really apply anything we want just for ourselves Why? It will be our "private" Linaro branch. We can apply whatever we want there (we can also decide on reviewers and/or some submit/commit procedure). We can mark our patches with both [] and

Re: Backport criteria

On 09/11/10 06:51, Michael Hope wrote: I've been going through the ChangeLog for the release and am having trouble justifying some of the changes brought in. In particular: * -fstrict-volatile-bitfields, which is more appropriate for bare metal/kernel code * Cortex-M4 support * C locale su

Re: GCC SVN vs. BZR/LP

On 17/11/10 03:35, Michael Hope wrote: There's two open questions: 1. How easy is it to frequently merge in SVN? It used to be terrible as you had to manually track the merges. These days can you do a 'svn merge trunk' and have it just work? Subversion 1.5 supports merging that appears to b

Re: GCC SVN vs. BZR/LP

On 17/11/10 09:57, Andrew Stubbs wrote: On 17/11/10 03:35, Michael Hope wrote: There's two open questions: 1. How easy is it to frequently merge in SVN? It used to be terrible as you had to manually track the merges. These days can you do a 'svn merge trunk' and have it just wor

[ACTIVITY] 15th - 19th November

LP:663939 - Thumb2 constants * Continued testing, found a few bugs. Tidied a few bits up. * Wrote some new testcases to go with the patch. LP:618684 - ICE * Begun looking at this one. So far I can't reproduce it. I have a debuggable native toolchain building, but it'd been delayed by hardw

GCC Optimization Brain Storming Session

Hi All, As we discussed on Monday, I think it might be helpful to get a number of knowledgeable people together on a call to discuss GCC optimization opportunities. So, I'd like to get some idea of who would like to attend, and we'll try to find a slot we can all make. I'm on vacation next w

[ACTIVITY] 22nd - 28th November

Reviewed Yao's patch for AND optimization. Some back on forth on the best way to tackle this problem. LP:663939 - thumb2 constant loading - backported my patches to GCC 4.5 - awaiting review LP:595479 - .eh_frame broken. - Discovered this problem had been fixed (with Thomas' patch) since Au

Re: Perfromance Test Results using gcc-linaro-4.5-2010.11-1

On 08/12/10 05:59, Prashanth S wrote: Dear All Our team in Samsung collected some performance metrics for the following 3 GCC cross compilers 1. Gentoo Complier(part of Chrome OS Build Environment) 2. GCC 4.4.1 (Code Sourcery). 3. Linaro (gcc-linaro-4.5-2010.11-1) I'd be interested to

Re: GCC Optimization Brain Storming Session

On 26/11/10 11:11, Andrew Stubbs wrote: As we discussed on Monday, I think it might be helpful to get a number of knowledgeable people together on a call to discuss GCC optimization opportunities. So, I'd like to get some idea of who would like to attend, and we'll try to find a slot

[ACTIVITY] 6th - 10th December

* Linaro GCC 4.4/4.5 Merged the latest CS patches and Linaro merge requests into Linaro GCC (4.4 and 4.5). Ran regression tests. Yao's patch failed so I backed it out, and made the release tarballs. Uploaded the releases to Michael Hope for release. lp:686381: luatex fails to build with gcc-

Invitation: TWG GCC Optimization @ Wed 2010-12-15 9am - 10am (linaro-toolchain@lists.linaro.org)

:mailto:ulrich.weig...@de.i bm.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Andrew Stubbs;X-NUM-GUESTS=0:mailto:andrew.stu...@linaro.org ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=OPT-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Yao Qi;X-NUM-GUESTS=0:mailto:yao

GCC Optimizations call minutes

Hi All, Thanks for attending the call. I think we had some interesting discussions. I've posted the minutes from the call on the same page as before: https://wiki.linaro.org/AndrewStubbs/Sandbox/GCCoptimizations I'll try to get the audio posted somewhere for anybody that's interested. Andrew

Re: Profile guided and string routines?

On 16/12/10 15:06, Mark Mitchell wrote: * Have the compiler expose an API for recording information about the value of arguments to a function when profiling. For integer arguments, this might be the minimum, maximum, and average. For pointers, NULL vs. non-NULL. Etc. Presumably recording th

GCC 4.6 BZR branch

You may have noticed that I have created a new BZR/Launchpad branch for Linaro GCC 4.6: lp:gcc-linaro/4.6 https://code.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6 Up until now, this has not been buildable due to unfixed bugs. However, upstream GCC have now straightened out the proble

[ACTIVITY] 13th -18th December 2010

* Linaro GCC lp:686381: C++ link failure on ARM Reproduced the bug and posted my findings to the bug report - user error. Changed the way the Linaro GCC version numbers are handled. Hopefully the new system should be less distasteful to Matthias. Updated the GCC release procedure document to m

Re: GCC 4.6 BZR branch

On 05/01/11 00:56, Michael Hope wrote: I build trunk once a week as part of the automated builds. How about I send you an email with the corresponding SVN revision on every successful build? I've just updated it to the state as of 31st December. Unfortunately there's a bug after that that pre

[ACTIVITY] January 4th - 9th

== 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 no

Linaro GCC 4.4 and 4.5 2011.01-0 released

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

Linaro GCC 4.5 2011.01-1 released

-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

Re: x86_64 bootstrap failure in the 2011.01 release

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 tri

[ACTIVITY] 24th -28th January 2011

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, a

GCC 4.6 Upgrade Plan

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 __

Re: gcc-linaro-4.5+bzr99469 build failure

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 Hop

Re: gcc-linaro-4.5+bzr99469 build failure

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 co

[ACTIVITY] 31st January - 4th February

== 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

Re: Question about big endian

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 par

[ACTIVITY] 7th - 12th February 2011

== 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 patch

[ACTIVITY] 14th - 19th February

== 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

Re: Unavailable for a bit

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 n

[ACTIVITY] 21st - 26th February

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,

Re: [RFC] Linaro Toolchain for Android and NDK

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

What configuration(s) to test?

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 ch

Re: Getting linaro toolchain binaries

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 h

Re: Getting linaro toolchain binaries

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

Re: Getting linaro toolchain binaries

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

Re: Getting linaro toolchain binaries

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

GCC PR43137

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 h

[ACTIVITY] 28th February - 5th March

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

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

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

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

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 mappi

[ACTIVITY] 7th - 13th March

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 prope

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

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 assum

[ACTIVITY] 21st - 25th March

* 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 c

Re: [ACTIVITY] 14th - 18th March

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

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

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

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

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

Re: Linaro 4.5.2 v. CodeSourcery 4.5.1

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 T

[ACTIVITY] 21st - 26th March

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

Re: Linaro toolchain integration with ChromiumOS build

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.

Re: Linaro 4.5.2 v. CodeSourcery 4.5.1

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

[ACTIVITY] 4th - 9th April

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'

[ACTIVITY] 11th -15th April

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

[ACTIVITY] 18th - 21st April

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-archi

Re: Sessions for the summit

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 li

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

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 o

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

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

Re: -O2 cause optimization issues while va parameters functions

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 wi

Re: -O2 cause optimization issues while va parameters functions

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-t

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

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

  1   2   3   >