Stefan Smietanowski wrote:
> Hristo Grigorov wrote:
> > On Thursday 06 December 2001 01:52, Stefan Smietanowski wrote:
> >>>>>This is not true. RH 7.1 gcc is not broke(as in can't compile code that
> >>>>>runs), but there was an update to it which fixed certain issues. You
> >>>>>definitely CAN compile kernels with that default gcc though that will
> >>>>>boot. Will you have problems? ymmv. The best course of action is to
> >>>>>either get gcc3, or update your current gcc from updates.redhat.com.
> >>>>Gcc3 is known to NOT work with kernel.
> >>>Linux version 2.4.16-xfs (root@magdanoz) (gcc version 3.0.2 20011002 (Red
> >>>Hat Linux 7.1 3.0.1-4))
> >>>Really ? How does it happen that it works here for months already ? Not
> >>>even one single fault. And the system is not idle for sure....
> >>It works for you, have you tried installing every single driver in the
> >>kernel tree? You 100% sure you trust all drivers? I'm not talking about
> >>broken code, I'm talking compiler problems. Also, how can you use 3.0.2
> >>for months already? Was it the ISDN subsystem that didn't work with
> >>gcc3? Something didn't work as it should. Didn't even compile but the
> >>compiler itself died with an internal compiler fault. And lately there
> >>has been kernel modifications to make use of gcc. XFS for one has had a
> >>fix. (Tell me if I'm wrong here).
> >>I sometimes use gcc3 to compile the kernel also, but that doesn't mean I
> >>trust it on a mission-critical server.
> >>// Stefan
> > You are may be right... But here I have used kernel with ISDN, XFS and SB
> > Live!
> > support for some months already w/o any problems. It includes all major
> > kernel
> > subsystems also.
> > By using gcc3 I beleive I help open source community to progress ahead. If
> > something
> > goes wrong I will let gcc guys know it immediatelly. Of course that's not
> > good aproach
> > when running "mission-critical" server but I somehow also beleive that XFS
> > will partly
> > save my ass when needed. :)))
> Sure, I know, that's the reason I use gcc3 also but it was the "stable"
> part I was commenting on, nothing else.
> // Stefan
One other thing that needs to be tested (perhaps more than the others)
before blessing the compiler for all uses would be every possible
optimization. It seems that various optimizations are where a lot of the
failures occur, e.g., compiling (or coding for features of) for i386,
i686, or Athlon. It seems that a number of places where one compiler or
another breaks things (or does things correctly but the app expects old
broken behavior from) are optimizations that rearrange the asm
incorrectly under one level of optimizing, versus others. I have to
wonder just how enormous of a project it would be to create a compiler
testbed that tries every possible code combination and optimization and
then reports on deviations between what is expected or what is in a
standard, versus what it got (such a project could require a large
cluster of both computers and people).
D. Stimits, stimits@xxxxxxxxxx