Hi!
> >> I'm hesitant to enter into this. But from my own experience
> >> the issue with big companies supporting these sort of changes
> >> in gcc have more to do with the acceptance process of changes
> >> into gcc than a lack of desire on the large companies part.
> >
> >Maybe we should create a KGCC fork, optimise it for kernel
> >complilations, then try to get our changes merged back in to GCC
> >mainline at a later date.
>
> That's not really the problem.
>
> I think the problem with gcc is that many of the developers are actually
> much more interested in Ada or C++ (or even Fortran!), than in plain
> old-fashioned C. So it's not a kernel issue per se, gcc is slow to
> compile _any_ C project.
>
> And a lot of the optimizations gcc does aren't even interesting to most
> C projects. Most "old-fashioned" C projects tend to be written in ways
> that mean that the most important optimizations are the truly trivial
> ones, and then doing good register allocation.
>
> I'd love to see a small - and fast - C compiler, and I'd be willing to
> make kernel changes to make it work with it.
What about gcc-1.4 or something like that? If you go back in time,
you'll find gcc is getting smaller and faster ;-). Actually making
kernel compile with gcc-2.7.2 should make it few times faster than
gcc-3.2...
Pavel
-- Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:19 EST