> > The linux kernel violates certain aliasing rules specified in the
> > ANSI/ISO standard. Starting with GCC 2.95, the gcc optimizer by default
> > relies on thes > e rules to produce more efficient code and thus will
> > produce malfunctioning kernels.
> Will this problem be fixed with the Linux kernel to bring it into
> (closer) compliance with ANSI/ISO standards? IMHO, it can only be a
> good thing to have code which is (close to) 100% compliant with
> recognized and widely used standards.
I'd suspect it will be slowly addressed.
> Which sections of code are affected by this?
All over the place, unfortunately.
> > To work around this problem, the flag -fno-strict-aliasing must be
> > added to the CFLAGS variable in the main kernel Makefile.
This is being taken care of automatically in 2.3.10 and 2.2.11-preX
[...]
> > If you try to build a 2.0.x kernel for Intel machines with any compiler
> > other than GCC 2.7.2, then you are on your own. The 2.0.x kernels are
> > to be built only with gcc 2.7.2. They use certain asm constructs which
> > are incorrect, but (by accident) happen to work with gcc 2.7.2. If you
> > insist on building 2.0.x kernels with egcs, you may be interested in
> > this patch which fixes some of the asm problems. You will also want to
> > change asm constructs to avoid clobbering their input operands.
> I'm not sure exactly what the problem is here. The last I heard, the
> "approved" compiler for 2.0.x was 2.7.2.3.
2.7.2.3 _is_ the latest 2.7.2
> Which is strange, in my
> mind. I started using 2.8.1 when it first appeared, and had absolutely
> no problems with kernel compiles,
With egcs snapshots I had tons of problems with 2.1.x kernels, tried 2.0.x
once and gave up: Just too many errors.
> except for a problem with X with
> 2.0.35, which a patch fixed (said patch was never included in the kernel
> for some strange reason, although it was well-tested and stable, and
> needed). Later, when I got around to actually installing RH 5.1, there
> was egcs. Never had a problem there, either. All my kernels were stock,
> too. Am I just an anomaly?
As the message said: 2.0.x were _only_ tested extensively with 2.7.2
compilers, there are known areas where the kernel wouldn't compile, or
(much worse!) silently generate incorrect code, due to borken assumptions
or coding practices. There was a patch that claimed to fix most of
those. Note carefully the use of the words "claimed" and "most".
Also, at least Red Hat 5.2 had gcc (for compiling the kernel) and egcs (for
compiling other stuff). So your experience isn't exactly strange ;)
> IMHO, based on what little I actually know, it would be a very good idea
> to make the kernel code as ANSI compliant as possible (irrespective of
> what gcc does). This makes it more practical to compile the kernel with
> other than gcc, supposing one wanted to...and used an ANSI-compliant
> compiler.
I agree, but for totally different reasons. Firstly, the kernel uses gcc
extensions very extensively, many of those won't show up in the next
standard. So to do as you say is an enormous task, just to end up where we
are now (if we are so lucky). Much code in the kernel is written with an
eye on the code gcc generates (its optimizations, code generating
strategies, ...), for the sake of efficiency. All the above rules out other
compilers.
OTOH, if the kernel is written in standard conforming C as far as possible,
it won't get into the way of new gcc optimizations when they appear (as the
in the case at hand). gcc development had stagnated for a long time, with
the recent handing over of the gcc development to what was the egcs project
the speed of gcc development _will_ be unheard of (except for Linux
development kernel fans and egcs snapshot followers, that is).
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/