Re: [RFC, MIPS] Relax NaN rules
"Maciej W. Rozycki" writes: > What I'm concerned the most about is the matter is so obscure to people > outside a narrow group of hardware/kernel/toolchain/library experts (that > regrettably does not include distribution packagers) that once that "don't > care" approach is set in the environment it'll be used universally because > it's the path of least resistance that'll cause the least trouble for > distributions. > > And then it'll hit another group who are expert on using IEEE maths for > their scientific, etc. purposes and require correct results including NaN > special cases, but then are not necessarily expertly enough or have no > resources to rebuild their kernel/toolchain/library environment to their > needs, or maybe even understand why exactly it does not work as they want. > Plus the incorrect NaN case may actually show up only very infrequently, > may require lots of effort to track down, and may eventually ruin their > work. > > Whereas the compromise I proposed will always produce correct results and > I believe will draw anyone's interested attention immediately to bad FP > performance where the wrong binary is used for what hardware used supports > and performance matters. That with a suitable kernel message, e.g.: > > : Unsupported FP mode requested, switching to software FP > emulation, please recompile with `-mnan=2008' for full performance. > > or suchlike I believe will do and point people in the right direction (and > likewise for `-mnan=legacy'). > > The added benefit will be if a popular piece of software is going to > suffer from that, then people will complain to their distribution supplier > giving the vendor a chance to fix the problem up and supply the binary and > any dependent libraries compiled in the desired NaN mode. Pretty much > like some libraries/executables already supplied by distribution vendors > optimised for particular processor families or features, e.g. in the x86 > world (the `cmov' feature/instruction subset comes to my mind). > > Any real cons to doing this? Besides having to invest some effort (but > not really that much) into the kernel to implement this switching and > reporting mechanism -- but in real world there's no free lunch and I think > this investment will be worth it. I think Matthew's point is that some systems (like Android) really aren't going to provide separate system libraries for both encodings. So with the ELF flag scheme as it is today, you won't be able to recompile with a different -mnan flag, because there are no libraries that would be compatible with it. Thanks, Richard
Re: [RFC, MIPS] Relax NaN rules
Matthew Fortune writes: > Richard Sandiford writes: >> Matthew Fortune writes: >> > Maciej W. Rozycki writes: >> >> On Sat, 22 Mar 2014, Richard Sandiford wrote: >> >> >> >> > > Thanks Joseph. I guess I'm not really pushing to have don't-care >> >> > > supported as it would take a lot of effort to determine when code >> >> > > does and does not care, you rightly point out more cases to deal >> >> > > with too. I'm not sure if the benefit would then be worth it or >> >> > > not as there would still be modules which do and do not care >> >> > > about old and new NaNs so it doesn't really relieve any pressure >> >> > > on toolchains or linux distributions. The second part of the >> >> > > proposal is more interesting/useful as it is saying I don't care >> >> > > about the impact of getting NaN encoding wrong and a tools >> >> > > vendor/linux distribution then gets to make that choice. Any >> comments on that aspect? >> >> > >> >> > Maybe it's just me, but I don't understand your use case for (2). >> >> > If 99% of users don't care about the different NaN encodings then >> >> > why would they use a different -mnan setting from the default? >> > >> > MSA requires nan2008. >> >> Ah, OK. >> >> > A couple of ideas to address some of the various concerns: >> > >> > 1) As per my original proposal of allowing the tools to be built in a >> mode >> >that ignores nan encoding... but add a special symbol introduced by >> >the linker which the fenv code could use to warn when enabling >> exceptions >> >that could trigger incorrectly. >> >> The problem with a third mode is that, as discussed upthread, there's no >> way in general to tell whether a given bit of code cares about sNaNs or >> not. >> So the third mode is really just an assertion by the user that NaN >> encodings don't matter. I think in that case a separate mode is only >> useful if: >> >> (a) the entire single-variant base system is built in don't-care mode >> (a bit like it would be built with -mfpxx, which is what makes - >> mfpxx >> useful). But is it really feasible for the system to be completely >> agnostic about the NaN encoding? I assume any long double emulation >> code (if using the normal form of n32/64) and any float parsing code >> would then need to look at the FCSR before generating a NaN. >> NaNs in C initialisers would be disallowed. Etc. These are rules >> that would need to be followed throughout the codebase, even the >> target-independent parts. Would a portable codebase really be >> willing >> to accept that for a MIPS oddity? >> >> If instead some routines in some system libraries assume a >> particular NaN >> encoding but the library binaries themselves claim to be "don't >> care" >> (on the basis that everything is OK if you avoid those routines) >> then we lose the ability to say that using a "don't care" library >> will not in itself cause your application to depend on NaN >> encodings. >> And at that point any automatic rules based on the library-level >> markup >> lose their value. Also, without a guarantee like that, it becomes >> very >> hard for a user to know whether they will be affected by that >> encoding >> or not. >> >> and >> (b) the user has to explicitly say that they don't care, rather than it >> being implied by things like -mmsa. I think you wanted it the other >> way around, with "don't care" being the default and the user having >> to say explicitly that they care. >> >> Otherwise, all the third mode does is cause the system to reject any >> binary that is careful enough to say that it wants one encoding over >> another and relies on no feature that would stop it running on the >> processor otherwise. (This excludes MSA-only binaries, for example, >> since they would be rejected on non-MSA systems anyway.) >> >> Without (a) and (b) it seems like a lot of complication for a very >> narrow use case. If we have a system built for one encoding and a >> processor that uses another then in some ways... > > I don't think I was clear enough here, I agree with your points above about > what would be necessary to support a 3rd 'I don't care' mode. I don't think > this effort is really worth it either Ah, sorry. Reordering slightly... >> > 2) Allow MSA to be built with nan1985 even though the hardware will >> always >> >require nan2008. (This is really just another way of masking the >> problem >> >but is possibly even less safe as the objects would have no record >> of the >> >'correct' encoding requirement. >> >> ...this seems more honest about what we're actually doing. It's also an >> awful lot simpler. > > Yes this is a lot simpler than the 3rd mode but disabling the NAN2008 ELF > Flag checks is even more honest as that is what would happen at the > kernel-userland boundary anyway, so why enforce it elsewhere. The problem is that if you disable the link-time check,
Re: [Question] How to deliver loop-related pragma information from TREE to RTL?
On Mon, Mar 24, 2014 at 10:11 PM, Eric Botcazou wrote: >> Look at how we implement #pragma ivdep (see replace_loop_annotate () >> and fortran/trans-stmt.c where it builds ANNOTATE_EXPR). > > Note that the C and C++ front-ends also support it. > > We are planning to submit a patch to add more loop pragmas as soon as stage #1 > opens, so the design could as well be discussed now. In order to support the > kind of pragmas suggested here, ANNOTATE_EXPR would need to get a 3rd argument > > /* ANNOTATE_EXPR. >Operand 0 is the expression to be annotated. >Operand 1 is the annotation kind. >Operand 2 is the annotation value. */ > DEFTREECODE (ANNOTATE_EXPR, "annotate_expr", tcc_expression, 3) Yep, that's fine. > The current way of attaching the ANNOTATE_EXPR to the condition of the loop is > a bit awkward since it doesn't naturally permit multiple annotations for a > given loop. Any suggestion about how to overcome that? You can certainly nest them, no? ANNOTATE_EXPR , unroll, 2> Richard. > -- > Eric Botcazou
Re: LTO & top-level ASM
The code resides in Chromium project, please see full source code:
https://github.com/scheib/chromium/blob/master/sandbox/linux/seccomp-bpf/syscall.cc
Martin
On 03/24/2014 06:34 PM, Ian Lance Taylor wrote:
On Mon, Mar 24, 2014 at 6:26 AM, Martin Liška wrote:
I've been solving undefined symbols related to:
http://gcc.gnu.org/PR57703. In chromium there's a following inline asm:
asm(".type Syscall, @function\n" ...);
intptr_t SandboxSyscall(...)
{
asm volatile("call SyscallAsm");
}
Can you explain why you need that asm statement?
Normally the .type declaration would appear where the Syscall symbol
is defined. Why are you putting it elsewhere?
Ian
Re: Request for discussion: Rewrite of inline assembler docs
dw writes:
>>asm ("" : "=m" (*x), "=r" (y));
>>
>> you have to assume that the address in %0 might use the same register as %1
>
> Ok, now I'm getting there. It helps that I've compiled some examples
> and can see what is happening. This one is subtle. I'm going to have
> to go back and review my code to see if I've ever done this.
>
> So, the existing text (which only talks about overlaps with input
> parameters) reads:
>
> "Unless an output operand has the '&' constraint modifier (see
> Modifiers), GCC may allocate it in the same register as an unrelated
> input operand, on the assumption that the assembler code will consume
> its inputs before producing outputs. This assumption may be false if the
> assembler code actually consists of more than one instruction. In this
> case, use '&' for each output operand that must not overlap an input."
>
> I'm thinking about adding something like this after it:
>
> "The same problem can occur if one of the output parameters allows a
> register constraint and contains an address. In this case, GCC may use
maybe "...and another output parameter contains..."? Filtering that
through:
> the same register for this parameter as it does for other output
> parameters that allow a memory constraint. This can produce
> inconsistent results if the register address is updated before updating
> the memory address. Combining the '&' constraint with the register
> constraint prevents this overlap and resolves the inconsistency."
>
> That's as clear as I can come up with. Better?
how about:
The same problem can occur if one output parameter @var{a} allows a register
constraint and another output parameter @var{b} allows a memory constraint.
The memory address in @var{b} may contain registers and GCC treats those
registers as inputs to the asm. As above, GCC assumes that such input
registers are consumed before any outputs are written. If in fact the
asm writes to @var{a} before @var{b}, it may inadvertently change the
address used for @var{b}. Combining the '&' constraint with the register
constraint prevents this overlap and ensures that @var{a} and @var{b}
can be written in either order.
Not sure that's much good though, sorry.
Thanks,
Richard
RTL Optimisations
Dear All, The GCC source reference 4.8.1 will synthesized some of the double word operations(SI mode) like add /sub in the below case from the word size (HI) patterns, (code snippet) expand_binop_directly function in the optabs.c. /* These can be done a word at a time by propagating carries. */ 1949 if ((binoptab == add_optab || binoptab == sub_optab) 1950 && mclass == MODE_INT 1951 && GET_MODE_SIZE (mode) >= 2 * UNITS_PER_WORD 1952 && optab_handler (binoptab, word_mode) != CODE_FOR_nothing) (code snippet) Current private target port will hash the above conditions ,hence compiler will synthesizes the double word operation w.r.t word operations . We would like prevent this optimisations ,The reason for the same is we do have the some optimised intrinsic functions ,which is coded in assemble and we want compiler to emit the intrinsic call to these routines instead of synthesizes the double word operations. Anyone in the group can shed some lights here will be appreciated . Thank you ~Umesh
Re: RTL Optimisations
On 03/25/14 06:23, Umesh Kalappa wrote: Dear All, The GCC source reference 4.8.1 will synthesized some of the double word operations(SI mode) like add /sub in the below case from the word size (HI) patterns, (code snippet) expand_binop_directly function in the optabs.c. /* These can be done a word at a time by propagating carries. */ 1949 if ((binoptab == add_optab || binoptab == sub_optab) 1950 && mclass == MODE_INT 1951 && GET_MODE_SIZE (mode) >= 2 * UNITS_PER_WORD 1952 && optab_handler (binoptab, word_mode) != CODE_FOR_nothing) (code snippet) Current private target port will hash the above conditions ,hence compiler will synthesizes the double word operation w.r.t word operations . We would like prevent this optimisations ,The reason for the same is we do have the some optimised intrinsic functions ,which is coded in assemble and we want compiler to emit the intrinsic call to these routines instead of synthesizes the double word operations. Anyone in the group can shed some lights here will be appreciated . Write an expander/pattern which calls your intrinsics. jeff
[ANN] CppCon 2014 Call for Submissions
Hi, CppCon is the annual, week-long face-to-face gathering for the entire C++ community. The conference is organized by the C++ community for the community and so we invite you to present. Have you learned something interesting about C++, maybe a new technique possible in C++11? Or perhaps you have implemented something cool related to C++, maybe a new C++ library? If so, consider sharing it with other C++ enthusiasts by giving a talk at CppCon 2014. Submissions deadline is May 15 with decisions sent by June 13. For topic ideas, possible formats, and submission instructions, see the Submissions page: http://cppcon.org/submissions/ Hope to hear you speak! Boris
Re: LTO & top-level ASM
On Tue, Mar 25, 2014 at 3:26 AM, Martin Liška wrote:
> The code resides in Chromium project, please see full source code:
> https://github.com/scheib/chromium/blob/master/sandbox/linux/seccomp-bpf/syscall.cc
The easy workaround is to make SyscallAsm global. And frankly I would
put it in a .S file. You aren't getting any advantage by wrapping a
large function as a top-level asm.
I'm not opposed to fixing this in GCC somehow, but you are trying to
do something rather tricky. You are providing two different unrelated
asm statements and insisting that they appear in the same file,
specifically to avoid function cloning. GCC gives you the tools you
need to make this work but you don't want to use them because clang
doesn't support them. So you're asking us for a GCC workaround for a
clang workaround. Since we're already into double workarounds, it's
not clear to me whether there is a bug here or not. Just make the
symbol global.
Ian
> On 03/24/2014 06:34 PM, Ian Lance Taylor wrote:
>>
>> On Mon, Mar 24, 2014 at 6:26 AM, Martin Liška wrote:
>>>
>>> I've been solving undefined symbols related to:
>>> http://gcc.gnu.org/PR57703. In chromium there's a following inline asm:
>>>
>>> asm(".type Syscall, @function\n" ...);
>>>
>>> intptr_t SandboxSyscall(...)
>>> {
>>> asm volatile("call SyscallAsm");
>>> }
>>
>> Can you explain why you need that asm statement?
>>
>> Normally the .type declaration would appear where the Syscall symbol
>> is defined. Why are you putting it elsewhere?
>>
>> Ian
>
>
Re: [Question] How to deliver loop-related pragma information from TREE to RTL?
> You can certainly nest them, no? > > ANNOTATE_EXPR , unroll, 2> Yes, that works, thanks. -- Eric Botcazou
RE: [RFC, MIPS] Relax NaN rules
> The easiest way to do that is to add a flag that either (a) stops the
> compiler emitting a .nan at all or (b) gets it to emit ".nan legacy"
> regardless of the actual encoding used. It's really just a slight
> variation on (2), the difference being that we might be using 2008
> under the covers.
>
Hi Richard, we talked about (a.) originally - it was the design of the
libraries. Joseph,
as I recollect, you raised language issues with requirements for compile-time
constant
values for NaNs. Would you accept a non-constant NaN implementation in glibc?
Basically,
I would envision __builtin_nan("") to be 0.0/0.0. Probably not a problem for
C++ or most code.
-rich
Re: WPA stream_out form & memory consumption
> Hello, >I've been compiling Chromium with LTO and I noticed that WPA > stream_out forks and do parallel: > http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02621.html. > > I am unable to fit in 16GB memory: ld uses about 8GB and lto1 about > 6GB. When WPA start to fork, memory consumption increases so that > lto1 is killed. I would appreciate an --param option to disable this > WPA fork. The number of forks is taken from build system (-flto=9) > which is fine for ltrans phase, because LD releases aforementioned > 8GB. > > What do you think about that? I can take a look - our measurements suggested that the WPA memory will be later dominated by ltrans. Perhaps Chromium does something that makes WPA to explode that would be interesting to analyze. I did not managed to get through Chromium LTO build process recently (ninja builds are not my friends), can you send me the instructions? Honza > > Thanks, > Martin
RE: [RFC, MIPS] Relax NaN rules
On Tue, 25 Mar 2014, Rich Fuhler wrote:
> Hi Richard, we talked about (a.) originally - it was the design of the
> libraries. Joseph, as I recollect, you raised language issues with
> requirements for compile-time constant values for NaNs. Would you accept
> a non-constant NaN implementation in glibc? Basically, I would envision
> __builtin_nan("") to be 0.0/0.0. Probably not a problem for C++ or most
> code.
0.0/0.0 is not correct for NaN when used outside static initializers,
because it raises INVALID when doing the division at runtime. Raising
INVALID when not wanted is exactly the same problem you'll get if you mix
code that uses different NaN conventions but doesn't care about signaling
NaNs per se, so 0.0/0.0 doesn't help there. And in static initializers it
doesn't help at all because then it will get folded to the same NaN
bit-pattern as __builtin_nan(""). So you don't gain anything from such a
change. Literally disallowing NaN static initializers brings you into the
realm of weird non-IEEE floating-point configurations we should not be
adding support for in glibc.
If you want to use code built for the new NaN convention without requiring
libraries built for that convention (and are willing to risk random
INVALID exceptions as NaNs get passed between the conventions), as already
stated the obvious approach is a command-line option or combination of
options meaning "build code for this convention, but use the other
convention when marking object files and choosing libraries and a dynamic
linker".
What's the status of the Linux kernel support for the new NaN convention,
incidentally? glibc built for the new convention sets
arch_minimum_kernel=10.0.0 until the support is in kernel.org and so the
value can be set to the actual first kernel with the support
(arch_minimum_kernel=10.0.0 may be used in future for any other cases
where glibc support for a port or port variant gets in before the kernel
support.)
--
Joseph S. Myers
jos...@codesourcery.com
RE: [RFC, MIPS] Relax NaN rules
Joseph Myers writes:
> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>
> > Hi Richard, we talked about (a.) originally - it was the design of the
> > libraries. Joseph, as I recollect, you raised language issues with
> > requirements for compile-time constant values for NaNs. Would you
> > accept a non-constant NaN implementation in glibc? Basically, I would
> > envision
> > __builtin_nan("") to be 0.0/0.0. Probably not a problem for C++ or
> > most code.
>
> 0.0/0.0 is not correct for NaN when used outside static initializers,
> because it raises INVALID when doing the division at runtime. Raising
> INVALID when not wanted is exactly the same problem you'll get if you
> mix code that uses different NaN conventions but doesn't care about
> signaling NaNs per se, so 0.0/0.0 doesn't help there. And in static
> initializers it doesn't help at all because then it will get folded to
> the same NaN bit-pattern as __builtin_nan(""). So you don't gain
> anything from such a change. Literally disallowing NaN static
> initializers brings you into the realm of weird non-IEEE floating-point
> configurations we should not be adding support for in glibc.
>
> If you want to use code built for the new NaN convention without
> requiring libraries built for that convention (and are willing to risk
> random INVALID exceptions as NaNs get passed between the conventions),
> as already stated the obvious approach is a command-line option or
> combination of options meaning "build code for this convention, but use
> the other convention when marking object files and choosing libraries
> and a dynamic linker".
Can you envisage any way of us raising a warning/error if INVALID
exceptions get enabled in this hybrid NaN world? I believe that is the
only major problem area with mixing NaNs. I.e. It should be possible to
introduce a magic symbol if LD merged opposing NaN modules and have
fesetexcept check for it but I can't think up a way to indicate to
fesetexcept if LDSO linked opposing NaN modules (I'm not sufficiently
experienced with dynamic linkers to know what is possible though).
> What's the status of the Linux kernel support for the new NaN
> convention, incidentally? glibc built for the new convention sets
> arch_minimum_kernel=10.0.0 until the support is in kernel.org and so the
> value can be set to the actual first kernel with the support
> (arch_minimum_kernel=10.0.0 may be used in future for any other cases
> where glibc support for a port or port variant gets in before the kernel
> support.)
Kernel support is queued up against a significant number of other features
that are being actively worked on. I do know that it is on the list just
not necessarily close to the top just yet. Given the chicken and egg
situation we have in terms of enabling nan2008 glibc from a specific
kernel version then this of course has to be done before any glibc with
nan2008 support can even be considered by a distribution.
Regards,
Matthew
Re: [RFC, MIPS] Relax NaN rules
Matthew Fortune writes:
> Joseph Myers writes:
>> On Tue, 25 Mar 2014, Rich Fuhler wrote:
>>
>> > Hi Richard, we talked about (a.) originally - it was the design of the
>> > libraries. Joseph, as I recollect, you raised language issues with
>> > requirements for compile-time constant values for NaNs. Would you
>> > accept a non-constant NaN implementation in glibc? Basically, I would
>> > envision
>> > __builtin_nan("") to be 0.0/0.0. Probably not a problem for C++ or
>> > most code.
>>
>> 0.0/0.0 is not correct for NaN when used outside static initializers,
>> because it raises INVALID when doing the division at runtime. Raising
>> INVALID when not wanted is exactly the same problem you'll get if you
>> mix code that uses different NaN conventions but doesn't care about
>> signaling NaNs per se, so 0.0/0.0 doesn't help there. And in static
>> initializers it doesn't help at all because then it will get folded to
>> the same NaN bit-pattern as __builtin_nan(""). So you don't gain
>> anything from such a change. Literally disallowing NaN static
>> initializers brings you into the realm of weird non-IEEE floating-point
>> configurations we should not be adding support for in glibc.
>>
>> If you want to use code built for the new NaN convention without
>> requiring libraries built for that convention (and are willing to risk
>> random INVALID exceptions as NaNs get passed between the conventions),
>> as already stated the obvious approach is a command-line option or
>> combination of options meaning "build code for this convention, but use
>> the other convention when marking object files and choosing libraries
>> and a dynamic linker".
>
> Can you envisage any way of us raising a warning/error if INVALID
> exceptions get enabled in this hybrid NaN world? I believe that is the
> only major problem area with mixing NaNs. I.e. It should be possible to
> introduce a magic symbol if LD merged opposing NaN modules and have
> fesetexcept check for it but I can't think up a way to indicate to
> fesetexcept if LDSO linked opposing NaN modules (I'm not sufficiently
> experienced with dynamic linkers to know what is possible though).
IMO that's an argument in favour of allowing MSA code to be compiled
for the legacy encoding. That way no mixing occurs and the ELF flag
accurately indicates which NaN encoding was used by the compiler.
Anything that wanted to detect mismatches between the "compiled-for"
encoding and the run-time encoding would have all the info it needs.
Another advantage is that it requires no code changes at all. :-)
It's just a case of not adding new code.
Thanks,
Richard
RE: [RFC, MIPS] Relax NaN rules
On Tue, 25 Mar 2014, Matthew Fortune wrote: > Can you envisage any way of us raising a warning/error if INVALID > exceptions get enabled in this hybrid NaN world? I believe that is the > only major problem area with mixing NaNs. I.e. It should be possible to > introduce a magic symbol if LD merged opposing NaN modules and have > fesetexcept check for it but I can't think up a way to indicate to > fesetexcept if LDSO linked opposing NaN modules (I'm not sufficiently > experienced with dynamic linkers to know what is possible though). fesetexcept - a new function in TS 18661-1, not implemented in glibc - has nothing to do with this; the issue is about exceptions from arithmetic rather than those from functions explicitly setting them. And to a first approximation you can ignore exceptions being "enabled" (i.e. traps being enabled) and presume they are tested for by C99 facilities such as fetestexcept - which has no way to return any sort of error status. -- Joseph S. Myers jos...@codesourcery.com
Re: Register at the GSoC website to rate projects
[Moving to gcc@ from gcc-patches@]
Community,
We've got 11 student proposals (good job, students!), and only the N top-rated
ones will be accepted into the program. Therefore, we as a community need to
make sure that the ratings are representative of our goals -- making GCC the
best compiler there is.
Go rate the proposals! Make your voice heard!
!
Here is a list of proposals (and, "yes" 'GCC Go escape analysis' is submitted
by two different students).
Generating folding patterns from meta description
Concepts Separate Checking
Integration of ISL code generator into Graphite
GCC Go escape analysis
Dynamically add headers to code
C++11 Support in GCC and libstdc++
GCC: Diagnostics
GCC Go escape analysis
Converting representation levels of GCC back to the source condes
Separate front-end folder from middle-end folder
interested in Minimal support for garbage collection
Thank you,
--
Maxim Kuvyrkov
www.linaro.org
On Mar 15, 2014, at 6:50 PM, Maxim Kuvyrkov wrote:
> Hi,
>
> You are receiving this message because you are in top 50 contributors to GCC
> [1]. Congratulations!
>
> Since you are a top contributor to GCC project it is important for you to
> rate the incoming student GSOC applications. Go and register at
> https://www.google-melange.com/gsoc/homepage/google/gsoc2014 and connect with
> "GCC - GNU Compiler Collection" organization. Pretty. Please. It will take
> 3-5 minutes of your time.
>
> Furthermore, if you work at a college or university (or otherwise interact
> with talented computer science students), encourage them to look at GCC's
> ideas page [2] and run with it for a summer project (or, indeed, propose
> their own idea). They should hurry, only one week is left!
>
> So far we've got several good proposals from students, but we want to see
> more.
>
> Thank you,
>
> [1] As determined by number of checked in patches over the last 2 years (and,
> "yes", I know this is not the fairest metric). Script used:
> $ git log "--pretty=format:%an" | head -n 12000 | awk '{ a[$1]++; } END { for
> (i in a) print a[i] " " i; }' | sort -g | tail -n 50
>
> [2] http://gcc.gnu.org/wiki/SummerOfCode
>
> --
> Maxim Kuvyrkov
> www.linaro.org
>
>
>
