Re: GCC

[Lars Segerlund <lars dot segerlund at comsys dot se>]

 There is poor documentation, ( in the sence that it is not easily 
digested if you haven't done a couple of runs of the code ), and also 
not much in the howto getting started.

 Also the overall workings of the frontends/gcc and some major parts of 
it is not that well documented.

 Take the tree's, GENERIC and GIMPLE have just started to have decent 
documentation, which have probably excluded a lot of people from doing 
work related to that.

 It's quite a bit of an undertaking getting started in writing code for 
gcc before you get going.

 I think it is this kind of problems that people refer to as hard to 
work with, also breakage in other ports by their patches.

 / regards, Lars Segerlund.

Steven Bosscher wrote:
> Hi,
>
> In the "Processor Architect's Panel" at the kernel summit, GCC was
> apparently discussed shortly:
>
> "Jon 'maddog' Hall said that the various processor architectures wild
> also benefit from paying more attention to gcc. The architects responded
> uniformly with complaints about how difficult it is to work with the gcc
> team. They all understand their interest in having gcc work will with
> their processors, but actually getting patches into the gcc code base is
> difficult."  (http://lwn.net/Articles/40831/)
>
> I'm not sure why they think it is so difficult.  It would seem that if
> the patch is architecture-specific and well-formed (ie. conforming to
> the coding style, etc), it typically just goes in, period.  And patches
> to target-independent code may go through one or two review cycles, but
> again, if the patch looks good, it goes in.  At least, I got the
> impression that patches are seldomly rejected.
>
> So why would these people think it's difficult to work with the people
> on this list, and to contribute code (and what can be done about it)?
>
> Gr.
> Steven