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.
In article <19990212031118.4271.qmail@deer>, <craig@jcb-sc.com> wrote: > >The buglet in gcc has, I gather, already been fixed. Yes. The sad part is that the bug was fixed several months ago. It was just re-introduced _again_ last week. > I haven't >gotten the impression the underlying bug(s) in Linux have, or >will, get fixed. Craig, have you actually bothered to look at the Linux use of "inline" at all? I don't think you have, and you're just spouting sh*t on the list. It's not at all buggy, it just assumes that the compiler does something reasonable. In particular, there are two kinds of "inline" in the kernel. There's the "oh, I'd like to get this inlined" kind of inline, and there's the "consider this a macro" kind of inline. Please go and actually look at the sources you complain about. I'm not an unreasonable person, I just get DAMN irritated when the same bug shows up twice in gcc, and people have a hard time even admitting it is a bug (I think the post by you is the first one that actually calls it a "buglet", finally - it's a bug, and yes, it was small, but by golly it was HARD to get people to even acknowledge it as one). Basically, Linux _does_ already use the "inline as hint" mentality: we have tons of functions that are marked "static inline" or just "inline". Some of those functions are quite large, and some of them actually only make sense inlining on an alpha or other sane architecture that has tons of registers: and I'd be very happy if gcc actually decides at some point that "oh, this function just adds too much register pressure to make sense to inline on an x86". There's another class of "inline" usage, though - the "use as macro" class, because inline functions are often a _lot_ more readable than macros are, and you get tons of other advantages (the compiler does the argument copy so you don't have side effect problems, and often most importantly you get argument type-checking with good error messages with inline functions that you wouldn't get with a macro). Those "use as a macro" inlines are marked, for the edification of gcc, as "extern inline". Guess what? A lot of them _used_ to be "static inline", because "static inline" is safer (it works as expected in the presense of the address-of operator, and yes, if the compiler refuses to inline the thing because it's not optimizing, it will still create the function for you). Most of them were _changed_ to "extern inline" mostly due to the gcc documentation. So Craig, go and look at some of those "extern inline" functions. Instead of just spouting crap on the mailing list without obvously never having even _looked_ at the problem. All of them are _extremely_ reasonable as far as I can tell - feel free to look for yourself. The ones that were bitten by the egcs bug (let's just be honest and call it what it really was) were so small that it would have been completely unreasonable for any good compiler to not inline them. They were essentially two assignments and a copy, they just happened to have the address-of-label thing in some debugging code (because all other gcc methods of getting the current PC have been buggy at various points). Basically, Craig, just come down from your ivory tower and look at the code, and I'd be surprised if you didn't agree with me that Linux "extern inline" usage actually makes sense if you were to just spend a _small_ amount of time actually looking at it instead of spouting off without knowing what's up. Linus