[ACTIVITY] 21st - 25th May

Committed my core-shifts patch into Linaro GCC. Checked and posted my (newly rebased) neon-shifts patch upstream for review. Continued work on my brain-dump of work in progress. Cleaned up, tested and posted example testcases and before/after compiler output for all my work-in-progress patches

[ACTIVITY] 14th -18th May

Remerged the GCC 4.7 branch from upstream. I had previously misunderstood how to resolve a conflict where Uli had committed a different version of the same patch upstream. Spun the GCC 4.6 and 4.7 release tarballs and passed them to Michael for testing. Continued work on improving code gener

Branches unfrozen

The releases have been made, so the branches have been updated and returned to their normal state. Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain

Branches Frozen

The GCC 4.7 merge testing is currently in progress. We're a little late with it, so I'm spinning the release speculatively. This being the case I've made the lp:gcc-linaro branch read-only, just in case. This shouldn't prevent anybody from reading the branch with "lp:gcc-linaro", but the "lp:~

[ACTIVITY] 7th - 11th May

* Linaro GCC Did the merges from upstream ahead of the Linaro releases next week. Unfortunately, with the Linaro office move the test system is running slowly, and it took a long while for Uli's concerns about the 4.7 merge to be confirmed, so this might cause a bit of delay while I remerge, a

[ACTIVITY] 30th April - 4th May.

* Linaro Continued trying to understand lower-subreg and its impact on ARM optimization. After much staring at RTL dumps and trying to minimize test cases from large code bases I've not found an example of code where disabling the lowering of pseudo-to-pseudo copies made the code larger for a

[ACTIVITY] 23rd - 27th April

* Linaro Continued looking at the lower-subreg problem (that the lowering is only really intended for 32-bit targets that don't have 64-bit operation). Without NEON this is only really a problem for "ldrd/strd" 64-bit loads and stores: the patterns are all (or should be all) written such that

[ACTIVITY] 16th - 19th April

* Linaro GCC Investigated the latest test failure for the neon-extend patch. The test for GCC Bugzilla 43137 is failing again. It turns out to be because my switching sign_extend to use a DImode output, rather than two SImode subreg outputs has exposed a bug in the lower-subreg pass. I've spen

[ACTIVITY] 9th - 13th April

* Linaro GCC Spun release tarballs for Linaro GCC 4.6 and 4.7. Pushed them to Michael's servers and launched the testing. Continued trying to get the 64-bit NEON stuff to work. The negdi2 patch needed some reworking following upstream review, and the extend patch has mysteriously reintroduce

[ACTIVITY] 2nd - 5th April

* GCC Identified the latent bug that's upset my NEON-shifts testing. It turns out the define-insn-and-shift patterns in arm/sync.md have no length attributes set. Now that the NEON 64-bit shifts appear to be not broken, I've relaunched the 64-bit extend testing. Identified the problem with

Re: Changing the time of the fortnightly performance call

On 05/04/12 09:58, Ramana Radhakrishnan wrote: Hi there, At the last call Michael asked if we could push this call back by 30 minutes given the changes due to daylight savings. Does anyone have any objections to a new time of 10 a.m. BST - 11 a.m. Central European - 9 p.m. New Zealand. ? No o

[ACTIVITY] 26th - 30th March

Continued work on neon 64-bit correctness. This is really dragging out now. I had hoped to have had it fixed by now, but subtle bugs are subtle. The 16-bit opcodes patch is now committed both upstream and in Linaro GCC 4.7, however, so that's some progress at least. Posted benchmark results f

How to do a manual bzr merge when "bzr merge" fails

Hi all, Right now, it's impossible to merge from lp:gcc/4.7 to lp:gcc-linaro/4.7. This is due to a BZR bug of some kind, so hopefully we won't have to work around it for too much longer. According to the nice folks at #bzr, here's how to do the same merge manually: bzr branch lp:gcc-lina

Re: GCC build speed and backlog

On Tue 27 Mar 2012 22:03:45 BST, Michael Hope wrote: The PandaBoard auto builders are having a hard time keeping with longer build and test times of 4.7 and the re-enabled libstdc++ tests. For reference, here's how much each step costs: Bootstrap GCC with C, C++, Fortran, and Obj-C: 9 hours Te

[ACTIVITY] 19th 23rd March

* Linaro GCC Applied my ARM conditional-execution and thumb 16-bit instruction size optimization patch to upstream and Linaro 4.7. Continued work on (slowly) working the bugs out of my 64-bit NEON patches. Figuring out bootstrap failures is not easy! Eventually discovered that: * the NEO

Re: Plan for changing the binary toolchain to 4.7 and hardfloat

On 19/03/12 08:48, Konstantinos Margaritis wrote: On Sun, 18 Mar 2012 23:27:17 + Mans Rullgard wrote: FWIW, Gentoo has been using arm-hardfloat-linux-gnueabi for hardfloat configurations ever since gcc started supporting it. That's of course not a triplet, strictly speaking. Also fwiw, I

[ACTIVITY] 12th - 17th March

* Linaro GCC Spun release tarballs for Linaro GCC 4.5 and 4.6. Launched the build and test runs. When those completed, briefly checked the results, and launched the package build tests and benchmark runs. Continued trying to figure out how my NEON 64-bit immediates patch had caused a bootstr

[ACTIVITY] 5th - 9th March

Committed the 4.6.3 merge to Linaro GCC 4.6. Merged from FSF 4.5 to Linaro GCC 4.5. Thought about how to do register-class allocation for NEON v. core registers case. Discussed the problem at the GCC performance meeting. Lots of interesting discussion was had. I have some interesting experime

Spec2000

Hi Michael, Spec2000 is now running successfully: there are results at http://ex.seabright.co.nz/benchmarks/gcc-linaro-4.7%2bbzr114965/logs/armv7l-natty-cbuild257-tcpanda05-cortexa9r1/spec2000-o3-neon-run.txt However, they seem to have been run in 'train' mode, and none of the runs are long e

Re: Linaro toolchain and ARMv6

On Wed 07 Mar 2012 04:30:55 GMT, ezjd wrote: Hello, My name is Jiandong Zheng and am working on a few ARM specific projects. I have been using Linaro toolchain coming with Ubuntu to do Cortext-A9 building. I also need to maintain code for old ARM11 SoC so that Linaro toolchain is my preferenc

Re: Problem running updated compiz branches on ARM

Hi Alexandros, Could you use the linaro-toolchain list for stuff like this please? You're more likely to find somebody who knows the answer that way. I'm pretty sure the problem is not the compiler because, as far as I can see, both architectures' compilers emit ".weak" directives. If there i

[ACTIVITY] 27th February - 2nd March

Merged FSF GCC 4.7 to the Linaro GCC 4.7 branch. Merged from GCC 4.6.3 release to Linaro GCC 4.6 branch. Wrote and posted a patch to load DImode immediate constant into NEON registers properly. Unfortunately, testing showed a bootstrap stage 2 vs. 3 miscompare, so there's something not quite r

lp:gcc/4.7

Hi Matthias, GCC 4.7.0 has branched upstream. SVN trunk is now 4.8. Could you please create lp:gcc/4.7 from the release branch. Thanks Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinf

Re: Please pull upstream rev. 184603 into gcc-linaro 4.7

On Wed 29 Feb 2012 18:05:46 GMT, Andrew Stubbs wrote: On 29/02/12 17:23, Bernhard Rosenkränzer wrote: Hi, 184603 fixes an ICE we're running into with Android test builds. Please pull it in ASAP so I don't have to mess with the CFLAGS as a workaround. There's a merge from r18466

[RFC] NEON vs. ARM register selection

Hi All, As you know, the compiler currently has difficulties choosing between whether to do an operation in NEON or not. As I see it there are three problems: 1. Simply, is it profitable? NEON can do many DImode operations in one or two instructions where 2 to 10 normal ARM/Thumb

Re: Please pull upstream rev. 184603 into gcc-linaro 4.7

On 29/02/12 17:23, Bernhard Rosenkränzer wrote: Hi, 184603 fixes an ICE we're running into with Android test builds. Please pull it in ASAP so I don't have to mess with the CFLAGS as a workaround. There's a merge from r184662 begun testing today. That should cover your revision. I'll commit

Spec 2000 broken?

Hi Michael, I ran the benchmark tests on GCC 4.7, but the spec2000 run seems to have failed. This is both on the baseline, and on my patch. See here: http://ex.seabright.co.nz/benchmarks/gcc-linaro-4.7%2bbzr114968~ams-codesourcery~arm-64-bit-shifts-4.7/logs/armv7l-natty-cbuild254-tcpanda06-cor

[ACTIVITY] 20th - 24th February

Investigated and produced and patch for bug lp936863. Continued work on 64-bit shifts. I updated my neon shifts patch twice: once to take -Os optimization into account, and once because I noticed that the CC clobbers were being retained even after they were known to be not required, and presum

Re: gcc: Thumb interworking and weakly linked functions

On Tue 21 Feb 2012 09:57:12 GMT, Dave Martin wrote: struct pad_conf_entry { u16 offset; u16 val; } __attribute__ ((packed)); The "packed" attribute specifies that all struct elements ought to be considered to have alignment requirement 1 instead of their default alignment.

[ACTIVITY] 13th - 19th February

* Linaro GCC Discovered that part of my conditional execution problems were caused by some over-zealous peephole optimizations adding CC register clobbers to arithmetic operations in order to take advantage of the 16-bit encoding. This is a problem because they can't be converted to conditiona

[ACTIVITY] 6th - 10th February

* Linaro GCC Continued work on 64-bit shifts. My patch for shifts in core registers was rejected because I used conditional-execution before it's safe, apparently, so I've spent some time looking at the alternatives. First, conditional move instructions were unsatisfactory - the final instru

Re: No meetings except standup

Sorry Michael, I shall not be able to commit to running the standup. As you know, I don't work normally work Thursday mornings. I try to call in if I am available, but even then I have only one ear on the meeting; the other, and both hands are busy trying to keep Isobelle from eating things sh

[ACTIVITY] 30th January - 3rd February

Adjusted my 64-bit shifts patch to address Richard Earnshaw's concerns, tested it, and posted the new one upstream. Continued trying to figure out how ira-costs.c works, and in particular, why it doesn't choose to do 64-bit stuff in NEON when I think it should. Basically, the problem seems to

[ACTIVITY] January 23rd-27th

Continued work on 64-bit shifts in core registers. This has now been posted to gcc-patches, and is awaiting review. 64-bit shifts in NEON are also working correctly, but the register allocator chooses not to use them most of the time. I've begun trying to work out why, but it's quite involved

[ACTIVITY] 16th - 20th January

* Linaro Continued work on 64-bit multiplies. Cleaned up the patches a lot. Started testing work to check for correctness. Ironed out a few bugs. My turn for patch review week. * Other Spent most of the week in San Diego attending the formerly-known-as CodeSourcery annual meeting, now Men

Re: Automatically save preprocessed source on ICE

On Wed 18 Jan 2012 00:38:49 PST, Asa Sandahl wrote: Hi there! I need some help with how to handle this bug: https://bugs.launchpad.net/gcc-linaro/+bug/873977 It looks like an improvement suggestion more than a bug Yeah, not our raison d'etre. I've politely redirected the request to GCC upstr

[ACTIVITY] 9th - 13th January

Continued work on 64-bit shifts. I've tidied up most of the nastiness I had in my first attempt at this work, unified the logic into fewer places, and fixed the one logic error that I knew about. I had a mysterious reload bug that just wouldn't go away, but having stared at it for some time I'v

Next week

Hi Michael, I can't remember if I told you before, but I shall be away at the CodeSourcery (Ok, Mentor Graphics's ESD TOOLS) annual meeting most of next week. I ought to be back at work on Friday. In the meantime I shall be reading email, but not spending much time on Linaro work. I can pr

[ACTIVITY] 2nd - 6th January

* Linaro Continued work on getting GCC to build on LAVA. I've ironed out a few more bugs from my test scripts, but it's slow going because a test runs takes a long time to run, and there are very few useful error messages when something goes wrong. Wrote, posted, and committed a patch to fix

Re: Building Linaro GCC from source

On 07/01/12 05:31, Javier Martinez Canillas wrote: Before trying to compile I've installed the libgmp, libmpfr and arm cross tool-chain [2] Fedora packages so I guess all gcc dependencies are met (binutils, glibc, etc). If you can build a native compiler then you have all the support library d

[ACTIVITY] 12th - 16th December

Continued work on 64-bit shifts. - Improved 64-bit shifts without NEON (should benefit all cases). - Fixed bugs in constant shift code. - Rewrote 64-bit neon patch to take advantage of the new non-neon code, in the fall-back case. - Titied up the code, in general. - Rewrote SImode shift am

[ACTIVITY] 5th - 9th December

Continued work on 64-bit neon operations. The negdi2 seems to be more difficult than previously thought - vneg won't do it, and there's no way to encode either "0-reg" or "not(reg)+1", so I'm shelving that idea for the moment, and moving on to one_compldi2_neon, which ought to be straight forwa

Release status

Hi Michael, I have finally managed to complete the release process. It wasn't quite as smooth as I would have liked, but we seem the have got there! Notes: - Ramana's VCVT patch caused an Android problem. This was reverted right before the release. - The initial release spin and test went

Linaro GCC 4.6 & 4.5 2011.12 released

The Linaro Toolchain Working Group is pleased to announce the 2011.12 release of both Linaro GCC 4.6 and Linaro GCC 4.5. Linaro GCC 4.6 2011.12 is the tenth release in the 4.6 series. Based off the latest GCC 4.6.2+svn181866, it contains a range of vectoriser performance improvements and general

Release notes for GCC 4.6

Hi all, I've copied all those who made commits to GCC 4.6 this month. Could you please give me a sentence or two for the release notes? Thanks Andrew ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman

[ACTIVITY] 28th November - 2nd December

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

[ACTIVITY] 21st - 25th November

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 migh

Re: [ACTIVITY] 14th - 18th November

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

[ACTIVITY] 14th - 18th November

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

Re: Output miscompare in 175.vpr

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?

[ACTIVITY] 4th -11th November

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 genera

Re: LAVA recipe

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

LAVA recipe

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

[ACTIVITY] 24th - 28th October

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

[ACTIVITY] 17th - 21st October

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

[ACTIVITY] 10th - 14th October

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 opportunitie

How to install an ARM cross compiler

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

[ACTIVITY] 3rd - 7th October

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

[ACTIVITY] 26th - 30th September

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

[ACTIVITY] 12th - 17th September

* 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

Implicit-it upstream discussion.

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

[ACTIVITY] 5th - 11th September

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. Anothe

[ACTIVITY] 29th - August - 3rd September

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

Csmith

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...@g

Re: GCC trunk fails to build

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~/g

[ACTIVITY] 22nd - 27th August

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 th

Re: how to properly enable multilib builds?

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 doe

Re: how to properly enable multilib builds?

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_

Re: GCC 4.6 merge

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 m

[ACTIVITY] 15th - 19th August

* 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

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

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 Ubu

Re: Basic libav profiling

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) __

[ACTIVITY] 8th - 12th August.

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

GCC 4.6 merge

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

[ACTIVITY] 25th - 31st July

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 m

[ACTIVITY] 18th - 22nd July

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 up

Appologies

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/m

[ACTIVITY] 11th - 17th July

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 constan

[ACTIVITY] 4th - 8th July

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

[ACTIVITY] 27th June - 1st July

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

[ACTIVITY] 20th - 24th June

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.

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

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: > Hell

[ACTIVITY] 13th - 18th June

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

[ACTIVITY] 6th - 10th June

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

[ACTIVITY] 30th May - 5th June.

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 rev

[ACTIVITY] 23rd - 27th May

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.or

[ACTIVITY] 16th - 20th May

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

[ACTIVITY] 9th - 13th May

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/

[ACTIVITY] 3th - 6th May

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 hav

Fwd: Linaro forums replaced by "Ask Linaro"

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 Me

Re: Pushing to diverged branches

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 hi

Re: Pushing to diverged branches

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

Re: Pushing to diverged branches

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 wh

Re: Pushing to diverged branches

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?

Re: Pushing to diverged branches

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,

Re: Pushing to diverged branches

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 exi

Re: Pushing to diverged branches

ion 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 o

Pushing to diverged branches

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 spott

[ACTIVITY] 26th -28th April

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 up

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

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

  1   2   3   >