There are two aspects to this. Firstly egcs inevitably causes some code
breakage as it changes, sometimes bugs, often things like uninitialised
variables that in gcc generated code happened to start at zero. And now
alias analysis, which can be a real PITA, but look at the code output with and
without and it says it all.
The second is having ways to say "don't do any alias analysis on this
variable", which egcs does not as far as I can see have an ideal way to handle
(volatile is not the answer, volatile is one of the more broken bits of C
design. C needs ways to declare points for synchronziation not say 'this
variable is always to cause crap code generation') egcs has asm clobber
stuff which can do memory synchronization. It also has some hacks with
union to stop aliasing going too far astray , so the tools exist even if they
aren't what we like.
> overwhelming mayority of the time. The egcs team is doing exactly the same,
> to them the kernel is just _one_ more client among many thousands. An
> important one, but in no way in a position to dictate egcs policy. And that
> is also fine with me.
> You'll have to live with that.
The egcs team needs to deliver tools that can be used to compile the kernel.
If they produce a compiler that can't be gently told what to do then the
egcs project will split or have a permanent set of linux specific patches.
Right now the egcs compiler _can_ be used to build the kernel, and you can
if you want to contribute go through the source and 2.95 output and fix the
aliasing problems. Egcs does provide the relevant control needed. Your patches
will be to the kernel not egcs.
> Fine. Let others do the grunt work (Alan Cox was instrumental in getting
> linux to compile with egcs; I did my bit too, there were/are many others)
I did nothing with egcs fixing but collect patches from the people who did fix
the kernel code. The credit belongs elsewhere.
Alan
-
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/