This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
> That's fine. I'm actually not asking that _all_ "inline" keywords actually > be honoured, I'm asking that there be some way of forcing gcc to honour > it, the way it used to do. You are still making one incorrect assumption: that you previously had a guarantee that the compiler would always successfully inline an "extern inline" function. You didn't: any version of gcc you care to name would fail to inline some functions. > Codifying the fact that if you really _rely_ on inlines, do so with an > "extern inline" is ok would be very reasonable. Maybe you could even say > that "extern inline" is honoured even when not optimizing. Given the current state of things, extern inline could either inline the function or "die trying". However, once some standards document says extern inline means something different, someone will have to suffer: either every C user (can't give them a correct compiler), or the kernel developers (we'll have to tell them a new way of forcing "inline"). > Why not just say that for "extern inline" there are NO artifical limits, > because the damn documentation _tells_ you that "extern inline" is a gcc > extension to the language that creates a macro-like function. Why not just say that the Linux kernel fits in 1 Meg no matter how many devices or features you have? After all, it used to. It would be nice. The compiler can do its best to inline the function. But it cannot promise to do the impossible.