On Thu, 29 Dec 2005, Ingo Molnar wrote:
>
> * Andrew Morton <[email protected]> wrote:
> >
> > When it comes to inlining I just don't trust gcc as far as I can spit
> > it. We're putting the kernel at the mercy of future random brainfarts
> > and bugs from the gcc guys. It would be better and safer IMO to
> > continue to force `inline' to have strict and sane semamtics, and to
> > simply be vigilant about our use of it.
>
> i think there's quite an attitude here - we are at the mercy of "gcc
> brainfarts" anyway, and users are at the mercy of "kernel brainfarts"
> just as much.
There's a huge difference here. The gcc people very much have a "Oh, we
changed old documented behaviour - live with it" attitude, together with
"That was a gcc extension, not part of the C language, so when we change
how gcc behaves, it's _your_ problem" approach.
At least they used to.
So yes, there's a huge attitude difference. The gcc people have a BAD
attitude. When the meaning of "inline" changed (from a "inline this" to
"hey, it's a hint"), the gcc people never EVER said "sorry". They
effectively said "screw you".
I know this is why I don't trust gcc wrt inlining. It's not so much about
any technical issues, as about the fact that the kernel tends to be a lot
heavier user of gcc features than most programs, and has correctness
issues with them, AND THE GCC PEOPLE SIMPLY DON'T CARE.
Comparing it to the kernel is ludicrous. We care about user-space
interfaces to an insane degree. We go to extreme lengths to maintain even
badly designed or unintentional interfaces. Breaking user programs simply
isn't acceptable. We're _not_ like the gcc developers. We know that
people use old binaries for years and years, and that making a new
release doesn't mean that you can just throw that out. You can trust us.
Maybe gcc development has changed. Maybe it hasn't.
THAT is what makes me worry. I don't know if this is why Andrew doesn't
trust inlining, but I suspect it has similar roots. Not trusting it
because we haven't been able to trust the people behind it. No heads-up,
no warnings, no discussions. Just a "screw you, things changed, your
usage doesn't matter, and we're not even interested in listening to you
or telling you why things changed".
There have been situations where documented gcc semantics changed, and
instead of saying "sorry", the gcc people changed the documentation. What
the hell is the point of documented semantics if you can't depend on them
anyway?
One thing we could do: I think modern gcc's at least have an option to
warn when they don't inline something. It might make sense to just enable
that warning, and see _which_ functions -Os and -funit-at-a-time say are
too large to be inlined.
Maybe the right thing to do is to just heed that warning, and remove such
functions from header files and make them no-inline? That way we get the
size fixes _regardless_ of any compiler options.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
