On Mon, Apr 12, 2010 at 03:42:39PM +0200, Richard Guenther wrote:
> On Mon, Apr 12, 2010 at 3:35 PM, Jack Howarth <howa...@bromo.med.uc.edu>
> wrote:
> > On Mon, Apr 12, 2010 at 08:47:54AM +0200, Manuel López-Ibáñez wrote:
> >> On 12 April 2010 00:38, Dave Korn <dave.korn.cyg...@googlemail.com> wrote:
> >> > On 11/04/2010 22:42, Manuel López-Ibáñez wrote:
> >> >
> >> >> [ ... ] lack of test results in some platforms does not mean
> >> >> that GCC developers are uninterested on supporting those platforms and
> >> >> much less that they are against supporting those platforms. The GCC
> >> >> community haven't forbidden anyone from contributing to support any
> >> >> platform in GCC.
> >> >
> >> > I don't know who you're talking to, but it sure isn't to me or about
> >> > anything remotely like anything I said. Put your straw man away.
> >>
> >> I am just trying to negate what a casual reader might conclude from
> >> Jack's original comment about gnulinux mono-culture and your analysis.
> >> I understand that you (and perhaps even Jack) do not actually mean to
> >> say that but the above sentiment is out there, specially among
> >> bsd/darwin users, so let's try not to reinforce it.
> >>
> >> Cheers,
> >>
> >> Manuel.
> >
> > Manuel,
> > What I meant to say was that the reality of the situation is
> > that 90%+ of the code (by line) is probably created by paid
> > employees and the way things have shaken out has placed the bulk
> > of those on linux. So FSF gcc will have to go out of its way to
> > try to limit the monoculture tendencies that this will naturally
> > cause. The llvm project has this issue probably less for linux
> > than for other surviving platforms (like Solaris, etc).
>
> Err, well. I do not see how most of the code is OS specific
> anyway - there is _very_ little code in GCC that is OS specific.
>
> Richard.
Richard,
Except for LTO (for which dragon-egg represents a way around
since we can use the llvm's libLTO with that). In fact, dragon-egg
should be welcomed as a way to directly compare the two approaches
to LTO from within a single compiler (and perhaps prove FSF gcc's choice
superior).
Jack
>
> > Jack
> >
> >
