This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC
- From: <tm_gccmail at mail dot kloo dot net>
- To: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 31 Jul 2003 12:33:55 -0700 (PDT)
- Subject: Re: GCC
On 31 Jul 2003, 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
It's fairly difficult IMHO to get instruction-set-characteristic patches
into mainline. The testing requirements have become rather heavy.
The DFA scheduler wasn't merged into mainline for quite some time, and the
stack-based pseudo work isn't merged yet.
It's possible to look at it from the other viewpoint, e.g. educate
processor designers to not design bad instruction sets. I'd be willing
to write a document describing "Things not to do when designing a
processor for GCC" since it feels like I've dealt with every single bad
idea ever conceived for a processor...
Toshi