> > comment here's an asm diff (34k) between a kernel compiled (1) with that
> > option, and (2) w/o -fno-strict-aliasing. judge for yourself...
> >
> > http://www.geocities.com/SiliconValley/Heights/6494/sw/difffnsa.txt.gz
> >
> > [kernel 2.3.5+lots of patches, gcc2.95-19990716, CFLAGS as in 2.3.11,
> > configured for 686, +/- std config (ide+scsi+most of networking)]
> >
> > (it doesn't show anything wrt correctness; just what gcc2.95's
> > "strict aliasing" means for code generation)
>
> The "correctness" bothers me a bit: A kernel without -fno-strict-aliasing
> doesn't boot here. Might be a blessing ;-)
yep. fwiw my kernels no longer work when compiled with egcs1.x;
i know what triggers the problem, but haven't enabled the workaround
- i'd rather not take the chance something similar could be happening
somewhere else, only silently.
(as gcc2.95 produces working kernels again, i haven't investigated the
failure properly)
> Could you give a summary of your findings?
given the amount of dicussion about this issue, i got the impression
the strict aliasing stuff was actually a worthwhile optimization.
However after seeing what it does for the kernel case, i don't
think it's worth the effort it would take to audit/fix the code.
(this even assuming there will be a __norestrict/attribute((mayalias))
qualifier in a future gcc) Even if all current "illegal" references
are fixed/marked as such, new code (drivers/subsystems) is likely to
reintroduce some problems, which would then silently bite you.
Bottom line: -fno-strict-aliasing isn't very expensive (if at all);
when comparing gcc 2.7 vs 2.95 the code generation improvements it
triggers are in the noise. If you think -fstrict aliasing will make
your kernel noticably faster, look at the above mentioned diff
(and/or, even better, compare _your_ kernels w/ and w/o that
optimization).
otoh -fno-strict-aliasing gives you correctness guarantees that
are almost impossible to give w/ __norestrict.
-
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/