Andrew Haley <[EMAIL PROTECTED]> writes: > > Most new gcc back-ends are private, so I don't buy that part of the > > argument. And in any case nobody is talking about plug-ins for gcc > > backends. We're talking about plugins at the tree/GIMPLE level. > > Yeah, I know. I'm thinking about proprietary compilers (not just > back-ends, optimization passes) bolted on to a gcc front-end to get > Linux compatibility.
As we've discussed previously, we are already seeing that without plugins: GCCfss. Sun took gcc's frontend and attached it to their proprietary backend. So in my view introducing plugins will not make a substantive difference here. > > When I was in the business of convincing people to pay for gcc > > work, I had a laundry list of general gcc improvements to sell. I > > was never able to get a dime except for target specific > > improvements. A plugin architecture would not make any difference > > to that kind of work. > > No, but it might mean that entire gcc ports go away, as people who > already have in-house compilers use them with a gcc front-end for > Linux ports, rather than funding gcc ports. But as you know, most gcc ports are never contributed anyhow. Ports that people hire Red Hat to do are contributed, but I can easily count six gcc ports I've seen myself that were never contributed. So again I don't see a substantive difference here. Ian
