Re: Abstract submissions for QEMU Users Forum (March 18th)

2010-11-16 Thread Michael Hope
On Tue, Nov 16, 2010 at 6:37 AM, Loïc Minier  wrote:
> On Sat, Nov 13, 2010, Peter Maydell wrote:
>> You mentioned the abstract deadline -- do you think Linaro has anything
>> to actually talk about in the "submit a presentation" sense here?
>
>  Maybe you could give a lightning talk on the validation work you've
>  started doing?  :-)

Ah, but we're not doing any explicit validation this cycle.  I'd like
to but there are more important.  We'll have to make do with the
fly-fix-fly approach of fixing bugs as found.

-- Michael

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


Re: RFC: -mimplicit-it and GCC upstream

2010-11-16 Thread Michael Hope
In general the product should move forward and drop work-arounds like
-mimplicit-it.  We (the greater ARM community) should fix these
package problems as they are found.  Here's a bunch of quick-fire
statements:

 * Qt is currently broken on ARM multiprocessor systems
 * Qt provides a QAtomic class which provides atomic functions on
integers and pointers
 * You can call different functions depending on your ordering constraints
 * GCC's __sync primitives are ordered only
 * The ARMv6 QAtomic implementation only provides ordered versions
 * AVR32 currently uses the sync primitives in the same way

So there's a precedent there for __sync primitives and they'd be
equivalent to what is already there.  If RVDS also supports __sync_*
(Richard?) then we can also delete the RVDS specific code.

The kernel adds -mimplicit-it via its own build rules.  What else
needs -mimplicit-it?  Matthias, are you running a rebuild at the
moment?  How many extra packages have failed?

I had a play with the Maverick GCC-4.5 and binutils.  This code:

void foo()
{
   asm("it eq\n\t"
   "teqeq r2,#1"
   );
}

compiles fine with -marm, -mthumb, and -march=armv4t -marm.  It seems
the assembler accepts IT instructions in both unified and
compatibility modes.

-- Michael

On Sat, Nov 13, 2010 at 6:33 AM, Dave Martin  wrote:
> Hi Richard,
>
> Recapping on this earlier conversation:
>
> http://lists.linaro.org/pipermail/linaro-toolchain/2010-July/30.html
> http://lists.linaro.org/pipermail/linaro-toolchain/2010-July/35.html
>
> Is it worth another attempt to make a case to upstream for supporting
> passing -mimplicit-it=thumb by default to gas?
>
> According to my understanding of this issue, my argument would go as follows:
>
>  * gcc currently estimates the size of asm blocks, rather than
> determining the size accurately.
>  * gcc cannot guarantee the right answer for asm block size when asm
> blocks contain directives etc., however use of directives in asm
> blocks is widespread
>  * gcc cannot guarantee the right answer for asm block size in
> Thumb-2.  gcc conservatively overestimates the size by assuming that
> each statement of the asm block expands to 4 bytes.
>  * All of Ubuntu lucid and maverick has been built with
> -mimplicit-it=thumb passwd by default, with no known build or runtime
> failures arising from this (so size issues aside, we have confidence
> that the resulting code generation is sound)
>  * -mimplicit-it=thumb -mthumb makes the asm block size estimation
> unsafe: the asm block can exceed the estimated size even in the
> absence of directives, which may lead to fixup range errors during
> assembly.
>  * Following the principles already established for Thumb-2 in
> general the estimation can be made safe (or, as safe as the
> established Thumb-2 behaviour) by raising the assumed maximum
> statement expansion size for asm blocks to 6 bytes, since
> -mimplicit-it will add as most a single (16-bit) IT instruction to
> each statement.
>  * The vast majority of all asm blocks are small (< 20 instructions,
> say), so the overall overestimate in sizes will generally be modest
> for any given compilation unit.
>  * -mimplicit-it is already _required_ by the Linux kernel and
> possible other projects.
>
> ...so...
>
>  * With -mimplicit-it=thumb and a 6-byte asm block statement
> expansion size estimate, we have toolchain behaviour which is as
> reliable, and as correct, as it is in upstream at present.
>  * Layout of data in the compiler output will be more optimal in some
> cases, and less optimal in other cases, compared with the the current
> Thumb-2 behaviour, due to differing asm block size estimates.  The
> exact behaviour will depend on the distribution of conditional
> instructions within asm blocks.
>  * Taken over a whole compilation unit, the total code size
> overestimate (and therefore the impact on object layout) will normally
> be modest, due to the small typical size of asm blocks.
>  * Behaviour for -marm will not be impacted at all.
>
> If gcc currently estimated asm block code size accurately, then I
> could understand upstream's objection; but as it stands it seems to me
> we wouldn't be making anything worse in practice with the proposed
> change; and there is no compatibility impact (other than positive
> impact).
>
>
> Of course, I may have some wrong assumptions here, or there may be
> some background I'm not aware of...
>
> Comments?
>
> Cheers
> ---Dave
>
> ___
> 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 SVN vs. BZR/LP

2010-11-16 Thread Michael Hope
Here's my summary based on these emails and the Monday call:
 https://wiki.linaro.org/MichaelHope/Sandbox/GCC46Hosting

They're the same on the technical side, Launchpad wins on the release
side, and SVN wins on the community side.

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?
 2. Can we host the consolidation branch (the one we do monthly
releases from) in SVN as well?

(1) is a deal breaker.  What are peoples experiences with the SVN
version used on the GCC servers?

Andrew, could you look into (2) please?  We need to have an
authoritative answer from the GCC overseers or to assume 'no'.

-- Michael

On Wed, Nov 10, 2010 at 5:03 AM, Loïc Minier  wrote:
> On Tue, Nov 09, 2010, Mark Mitchell wrote:
>> So, fundamentally, we have to choose whether we want to work as much as
>> possible upstream (using an SVN branch), or whether we want uniformity
>> across Linaro projects (using Launchpad).
>
>  This only lists political options; the quality of the tool should also
>  be considered
>
>  I found Andrew's summary of Pros and Cons a much better base for
>  discussion
>
>  There might also be other options which don't require a choice, like
>  exporting the Bazaar data into a read-only SVN branch for upstream's
>  convenience -- upstream can see and access the data in their preferred
>  format and we can keep existing practices
>
> --
> Loïc Minier
>
> ___
> 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 SVN vs. BZR/LP

2010-11-16 Thread Mark Mitchell
On 11/16/2010 7:35 PM, Michael Hope wrote:

> Andrew, could you look into (2) please?  We need to have an
> authoritative answer from the GCC overseers or to assume 'no'.

GCC policy is simple: you can host any branch you want in GCC SVN, so
long as all the code is assigned to the FSF.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

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