* Re: kernel-2.2.1-undefined references.
@ 1999-02-08 14:55 Ross Smith
[not found] ` < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz >
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Ross Smith @ 1999-02-08 14:55 UTC (permalink / raw)
To: egcs
From: Per Bothner <bothner@cygnus.com>
>
>[Linus wrote:]
>> I'm not trying to be unreasonable. I'm just saying that if there is a
>> function that is marked inline that can be inlined, it _should_ be
>> inlined, because the compiler _never_ knows better than the programmer.
>
>Er, the compiler often knows better than the programmer. That is why
>we use compilers - to free us from low-level and architecture-dependent
>decisions.
>
>Note you have a rather atypical perspective. You know the hardware
>in depth, and you know which instruction sequences will be faster.
>You probably know (or at least can make an informed guess) if inline
>will help or hinder the code. You also sometimes need precise control
>over low-level code.
>
>We cannot design a compiler for the Linux Torvalds' of the world.
>We have to do what is best for *most* programmers, while still
>providing the needed tools for the experts.
It occurs to me that the real problem here is that "inline" is being
used to refer to two slightly different concepts, and some of the
participants in this thread haven't noticed this and are talking past
each other.
(A) inline == "I [the programmer] know exactly what this code is
supposed to do at low level, and I have determined that this function
must be inline for proper behaviour, so inline it or give me an error
if you [the compiler] can't."
(B) inline == "I [the programmer] believe this code would be more
efficient if this function were expanded inline, so please do so
unless you [the compiler] have a good reason to do otherwise."
Linus wants (A), but the inline keyword, as defined by ISO C++,
mandates (B). Exactly what consitutes a "good reason" is a function of
compiler technology. In many cases, compilers *are* smarter (about
certain specific things) than programmers, and will quite rightly
override the programmer's choice. For inline, this is rare today, but
will get more common until eventually "inline" goes the way of
"register".
But kernel programming (and a few other cases such as embedded systems)
is a special case, with unusual performance and low-level behaviour
requirements. A "gimme inline and keep your opinions to yourself" (i.e.
option A) keyword is really necessary. And the problem is that GCC has
traditionally (since before it included C++) used plain "inline" for
this, whereas ISO C++ (and, I believe, the upcoming C9X standard)
specifies option B.
As far as I can see, there are four possible resolutions:
(1) Decide that EGCS will use the traditional GCC interpretation of
"inline", i.e. option A. This would be unpleasant for non-kernel
programmers, and while it wouldn't strictly violate the letter of
the C++ standard, it would certainly violate the spirit.
(2) Provide a compiler switch that indicates whether "inline" should
have the traditional GCC meaning (option A) or the ISO C++/C9X
meaning (option B).
(3) Give "inline" the ISO C++/C9X meaning, and provide a new keyword
(e.g. "__force_inline") that has option A semantics for the kernel,
embedded system, etc. programmers. IMHO this is the best solution.
(4) Use option A for C and option B for C++. Ugh.
(P.S. #insert <std_rant_about_americans_who_say_ansi_instead_of_iso>)
--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
* * * * *
To err is human. To really screw up requires the root password.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz >
@ 1999-02-08 16:00 ` Lee Iverson
[not found] ` < 199902090000.QAA28993@Canada.AI.SRI.COM >
1999-02-28 22:53 ` Lee Iverson
0 siblings, 2 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-08 16:00 UTC (permalink / raw)
To: Ross Smith; +Cc: egcs, H. Peter Anvin, Linus Torvalds
In message < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz > you write:
> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer. That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
>
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
>
> (A) inline == "I [the programmer] know exactly what this code is
> supposed to do at low level, and I have determined that this function
> must be inline for proper behaviour, so inline it or give me an error
> if you [the compiler] can't."
It occurs to me that we do, in fact have an acceptable method of
*guaranteeing* inlining of a *function* in gcc. That is a combination
of a macro and the "Statement Expression" extension.
#define foo(_x) ({ \
int x = (_x); \
/* Various commands */ \
val; \
)}
is *already* the exact equivalent of:
extern inline foo (int x) {
/* Various commands */
return val;
)
except that it also says, "I know exactly what I'm doing and this function
*must* be inlined". Surely the number of functions in the kernel
which *must* be inlined for correct functioning is small
transformation can be done and ensure that correct code is generated.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090000.QAA28993@Canada.AI.SRI.COM >
@ 1999-02-08 16:12 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-08 16:12 UTC (permalink / raw)
To: Lee Iverson; +Cc: Ross Smith, egcs, H. Peter Anvin
On Mon, 8 Feb 1999, Lee Iverson wrote:
>
> It occurs to me that we do, in fact have an acceptable method of
> *guaranteeing* inlining of a *function* in gcc. That is a combination
> of a macro and the "Statement Expression" extension.
Sure.
Why don't you just remove "inline" completely, then?
It's apparently ok to break documented and existing behaviour of "inline".
Go read the gcc documentation about "extern inline", the whole thing is
_designed_ to be a much more readable form of #define.
Oh, well, I don't care any more. Make up your own rules, and break
documented behaviour.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com >
@ 1999-02-08 16:40 ` Lee Iverson
[not found] ` < 199902090039.QAA01060@Canada.AI.SRI.COM >
1999-02-28 22:53 ` Lee Iverson
1999-02-08 17:17 ` Joe Buck
1999-02-09 11:45 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-08 16:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ross Smith, egcs, H. Peter Anvin
In message < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com > you w
rite:
>
>
> On Mon, 8 Feb 1999, Lee Iverson wrote:
> >
> > It occurs to me that we do, in fact have an acceptable method of
> > *guaranteeing* inlining of a *function* in gcc. That is a combination
> > of a macro and the "Statement Expression" extension.
>
> Sure.
>
> Why don't you just remove "inline" completely, then?
>
> It's apparently ok to break documented and existing behaviour of "inline".
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define.
>
> Oh, well, I don't care any more. Make up your own rules, and break
> documented behaviour.
I've yet to see *any reference* to the claim that it is *documented*
that the inline declaration *guarantees* that the function will always
be inlined. Even with extern. That was your assumption, reading
between the lines...
That said, the documentation *does* clearly seem to strongly imply
such a guarantee. The hedging language that should be there *isn't*
except for the single line: "Note that certain usages in a function
definition can make it unsuitable for inline substitution." Clearly
not as prominent as it should be.
Of course inline is supposed to work, but as you've heard this is
largely a question of *reliably* generating correct code and as in the
past *your assumptions* about what the compiler should be doing rather
than objectively documented behavior. The compiler may not be living
up to your expectations, and I know that it hasn't in the past, but
just as in some of those cases (e.g. the asm clobbering issue or the
inline+label addresses), the problem is that you are relying on
behaviour that is either undocumented and thus not guaranteed or
falling between the cracks of the implementation.
I think this is a case where the documentation is misleading. It does
suggest that inlining is not guaranteed, but IMO not as prominently as
it should. That is what you've been bit by, *not* a guarantee that
isn't being honoured.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090039.QAA01060@Canada.AI.SRI.COM >
@ 1999-02-08 16:44 ` H. Peter Anvin
[not found] ` < 199902090043.QAA21188@cesium.transmeta.com >
1999-02-28 22:53 ` H. Peter Anvin
1999-02-08 17:18 ` Joe Buck
1 sibling, 2 replies; 180+ messages in thread
From: H. Peter Anvin @ 1999-02-08 16:44 UTC (permalink / raw)
To: Lee Iverson; +Cc: torvalds, ross.s, egcs, hpa
>
> Of course inline is supposed to work, but as you've heard this is
> largely a question of *reliably* generating correct code and as in the
> past *your assumptions* about what the compiler should be doing rather
> than objectively documented behavior. The compiler may not be living
> up to your expectations, and I know that it hasn't in the past, but
> just as in some of those cases (e.g. the asm clobbering issue or the
> inline+label addresses), the problem is that you are relying on
> behaviour that is either undocumented and thus not guaranteed or
> falling between the cracks of the implementation.
>
> I think this is a case where the documentation is misleading. It does
> suggest that inlining is not guaranteed, but IMO not as prominently as
> it should. That is what you've been bit by, *not* a guarantee that
> isn't being honoured.
>
On another note, however, it really sucks to have to rely on macro
expansion -- it wrought with pitfalls, and the syntax is different in
the most bleacherous manner (requiring \ at the end of each line.) It
is much nicer to have the compiler check the syntax properly, but it
really requires it to work right. Oh yes, __builtin_constant_p()
really, really ought to work properly in an inline...
-hpa
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 14:55 kernel-2.2.1-undefined references Ross Smith
[not found] ` < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz >
@ 1999-02-08 16:51 ` Bryan W. Headley
[not found] ` < 36BF94AB.A7CD5DF5@interaccess.com >
1999-02-28 22:53 ` Bryan W. Headley
1999-02-28 22:53 ` Ross Smith
2 siblings, 2 replies; 180+ messages in thread
From: Bryan W. Headley @ 1999-02-08 16:51 UTC (permalink / raw)
To: Ross Smith; +Cc: egcs
Ross Smith wrote:
> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer. That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >Note you have a rather atypical perspective. You know the hardware
> >in depth, and you know which instruction sequences will be faster.
> >You probably know (or at least can make an informed guess) if inline
> >will help or hinder the code. You also sometimes need precise control
> >over low-level code.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
>
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
>
> (A) inline == "I [the programmer] know exactly what this code is
> supposed to do at low level, and I have determined that this function
> must be inline for proper behaviour, so inline it or give me an error
> if you [the compiler] can't."
>
> (B) inline == "I [the programmer] believe this code would be more
> efficient if this function were expanded inline, so please do so
> unless you [the compiler] have a good reason to do otherwise."
>
> Linus wants (A), but the inline keyword, as defined by ISO C++,
> mandates (B). Exactly what consitutes a "good reason" is a function of
> compiler technology. In many cases, compilers *are* smarter (about
> certain specific things) than programmers, and will quite rightly
> override the programmer's choice. For inline, this is rare today, but
> will get more common until eventually "inline" goes the way of
> "register".
>
No, I heard more than that. Such as, the compiler may opt to make a function
into an inline based on optimization. Which scares the hell out of me, too.
The argument, though, should be telling you that basing a C compiler
front-end on top of a C++ engine is going to become more and more risky.
There once was a time when there was a tight correlation between the C code
and the assembly. With C++, with "hidden" destructors to deal with exception
handling, jump tables to give the feel of class heirarchy, etc., you cannot
say that anymore.
I like Per's comments about not being able to produce a compiler that behaves
like Linus would want. It sort of makes Messrs Kernighan, Richie and Thompson
just a little bit more special than they are already :-)
#include <bryan/has/little/respect/for/ansi/nor/iso/as/they/are/usually/10/years/behind>
--
____ .:. ____
Bryan W. Headley - bheadley@interaccess.com
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com >
1999-02-08 16:40 ` Lee Iverson
@ 1999-02-08 17:17 ` Joe Buck
[not found] ` < 199902090114.RAA15416@atrus.synopsys.com >
1999-02-28 22:53 ` Joe Buck
1999-02-09 11:45 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-08 17:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: leei, ross.s, egcs, hpa
Linus writes, in response to a suggestion to use a special feature of
macros:
> Why don't you just remove "inline" completely, then?
>
> It's apparently ok to break documented and existing behaviour of "inline".
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define.
Hmm. Linus does seem to have a point here. See the node "Inline"
in the gcc manual.
" If you specify both `inline' and `extern' in the function
definition, then the definition is used only for inlining. In no case
is the function compiled on its own, not even if you refer to its
address explicitly. Such an address becomes an external reference, as
if you had only declared the function, and had not defined it."
This seems to be a fairly strong promise that the function is guaranteed
to be either inline or to come out undefined (unless there is a second
non-extern-inline definition).
Many people have been answering based on general compiler principles
rather than by looking at the promises made in the gcc documentation for
an *extension*.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090039.QAA01060@Canada.AI.SRI.COM >
1999-02-08 16:44 ` H. Peter Anvin
@ 1999-02-08 17:18 ` Joe Buck
[not found] ` < 199902090116.RAA15478@atrus.synopsys.com >
1999-02-28 22:53 ` Joe Buck
1 sibling, 2 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-08 17:18 UTC (permalink / raw)
To: Lee Iverson; +Cc: torvalds, ross.s, egcs, hpa
> I've yet to see *any reference* to the claim that it is *documented*
> that the inline declaration *guarantees* that the function will always
> be inlined. Even with extern. That was your assumption, reading
> between the lines...
RTFM.
Remember, we are not talking about ISO C++ here. We are talking about
*C*, and specifically the GNU "extern inline" extension. So the M to R
is the gcc manual.
We may have an issue later on with C9X, which may define "extern inline"
to mean something different.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090116.RAA15478@atrus.synopsys.com >
@ 1999-02-08 17:28 ` Lee Iverson
[not found] ` < 199902090128.RAA04379@Canada.AI.SRI.COM >
1999-02-28 22:53 ` Lee Iverson
0 siblings, 2 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-08 17:28 UTC (permalink / raw)
To: Joe Buck; +Cc: torvalds, ross.s, egcs, hpa
In message < 199902090116.RAA15478@atrus.synopsys.com > you write:
>
> > I've yet to see *any reference* to the claim that it is *documented*
> > that the inline declaration *guarantees* that the function will always
> > be inlined. Even with extern. That was your assumption, reading
> > between the lines...
>
> RTFM.
>
> Remember, we are not talking about ISO C++ here. We are talking about
> *C*, and specifically the GNU "extern inline" extension. So the M to R
> is the gcc manual.
>
> We may have an issue later on with C9X, which may define "extern inline"
> to mean something different.
I actually did, and while the discussion of "extern inline" strongly
implies that it is guaranteed behavior, it doesn't *really* come out
and say it. There is a hedge above though in the sentence "Note that
certain usages in a function definition can make it unsuitable for
inline substitution." It looks like that is just a hedge on automatic
inlining, but it is really a hedge on the whole process...
I do think that the language is ambiguous and definitely suggests
something that the compiler cannot guarantee. That's why I've
submitted a patch to egcs-patches to clarify this:
http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 36BF94AB.A7CD5DF5@interaccess.com >
@ 1999-02-08 17:36 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
0 siblings, 1 reply; 180+ messages in thread
From: Joe Buck @ 1999-02-08 17:36 UTC (permalink / raw)
To: Bryan W. Headley; +Cc: ross.s, egcs
> No, I heard more than that. Such as, the compiler may opt to make a function
> into an inline based on optimization. Which scares the hell out of me, too.
Get used to it; almost every compiler will do this at high levels of
optimization.
> The argument, though, should be telling you that basing a C compiler
> front-end on top of a C++ engine is going to become more and more risky.
It has nothing to do with C++. Fortran compilers are the most aggressive
at doing major restructuring of this form. If anything, C++ compilers
do *less* of it. The reason is the compiler writers are spending so
much time getting the semantics right that they have no time to do much
optimization.
> There once was a time when there was a tight correlation between the C code
> and the assembly.
Turn off -O if you want that.
> I like Per's comments about not being able to produce a compiler that behaves
> like Linus would want.
Would you be willing to accept 50% slower code for tighter control?
(You could get the 50% back by personally directing every compiler
transformation, but you'd have to get them all right and then redo
them every time you change any of the code).
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090128.RAA04379@Canada.AI.SRI.COM >
@ 1999-02-08 17:42 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
1999-02-08 17:54 ` Linus Torvalds
1 sibling, 1 reply; 180+ messages in thread
From: Joe Buck @ 1999-02-08 17:42 UTC (permalink / raw)
To: Lee Iverson; +Cc: jbuck, torvalds, ross.s, egcs, hpa
> > Remember, we are not talking about ISO C++ here. We are talking about
> > *C*, and specifically the GNU "extern inline" extension. So the M to R
> > is the gcc manual.
>
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it. There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution." It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...
Yes, clearly some functions cannot be inlined. The compiler developers
cannot promise the impossible.
The language implies that if inlining fails you'd just have an external
reference, meaning you'd have an undefined symbol if there is not a
second, non-inline definition.
> I do think that the language is ambiguous and definitely suggests
> something that the compiler cannot guarantee. That's why I've
> submitted a patch to egcs-patches to clarify this:
>
> http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html
It might be appropriate to generate an error, not a warning, if
"extern inline" fails to inline, since it is clear from the documentation
that this is not a mere hint.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090114.RAA15416@atrus.synopsys.com >
@ 1999-02-08 17:51 ` Linus Torvalds
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 1 reply; 180+ messages in thread
From: Linus Torvalds @ 1999-02-08 17:51 UTC (permalink / raw)
To: Joe Buck; +Cc: leei, ross.s, egcs, hpa
On Mon, 8 Feb 1999, Joe Buck wrote:
>
> Hmm. Linus does seem to have a point here. See the node "Inline"
> in the gcc manual.
Thank you. Exactly.
This is not about "what would we do if we redesigned the language". This
is about existing users that have used behaviour and documentation that
has been stable for at least the 8 years I've used gcc, and are extremely
irritated at some willy-nilly changes that break existing documented usage
for no apparent technical reason.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090128.RAA04379@Canada.AI.SRI.COM >
1999-02-08 17:42 ` Joe Buck
@ 1999-02-08 17:54 ` Linus Torvalds
1999-02-28 22:53 ` Linus Torvalds
1 sibling, 1 reply; 180+ messages in thread
From: Linus Torvalds @ 1999-02-08 17:54 UTC (permalink / raw)
To: Lee Iverson; +Cc: Joe Buck, ross.s, egcs, hpa
On Mon, 8 Feb 1999, Lee Iverson wrote:
>
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it. There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution." It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...
And while you're at it, what's your definition for "sex"?
It's ugly in politics, it's ugly in technican discussions. Don't hide
behind technicalities.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com >
1999-02-08 16:40 ` Lee Iverson
1999-02-08 17:17 ` Joe Buck
@ 1999-02-09 11:45 ` craig
[not found] ` < 19990209191412.27056.qmail@deer >
1999-02-28 22:53 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-09 11:45 UTC (permalink / raw)
To: torvalds; +Cc: craig
>Why don't you just remove "inline" completely, then?
Because it works just fine, and as documented, for 99.9999% of the
uses to which its put in code compiled by gcc?
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990209191412.27056.qmail@deer >
@ 1999-02-09 13:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-09 13:53 UTC (permalink / raw)
To: craig; +Cc: leei, ross.s, egcs, hpa
On 9 Feb 1999 craig@jcb-sc.com wrote:
> >Why don't you just remove "inline" completely, then?
>
> Because it works just fine, and as documented, for 99.9999% of the
> uses to which its put in code compiled by gcc?
Right. So why break it then?
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902090043.QAA21188@cesium.transmeta.com >
@ 1999-02-10 3:33 ` Jamie Lokier
[not found] ` < 19990210105658.A1570@tantalophile.demon.co.uk >
1999-02-28 22:53 ` Jamie Lokier
0 siblings, 2 replies; 180+ messages in thread
From: Jamie Lokier @ 1999-02-10 3:33 UTC (permalink / raw)
To: H. Peter Anvin, Lee Iverson; +Cc: torvalds, ross.s, egcs
H. Peter Anvin wrote:
> Oh yes, __builtin_constant_p() really, really ought to work properly
> in an inline...
It does. See egcs-1.0.3.
-- Jamie
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
@ 1999-02-10 5:47 ` craig
1999-02-10 9:42 ` Linus Torvalds
1999-02-28 22:53 ` craig
0 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-10 5:47 UTC (permalink / raw)
To: torvalds; +Cc: craig
>On 9 Feb 1999 craig@jcb-sc.com wrote:
>
>> >Why don't you just remove "inline" completely, then?
>>
>> Because it works just fine, and as documented, for 99.9999% of the
>> uses to which its put in code compiled by gcc?
>
>Right. So why break it then?
By your apparent standards, it always *was* broken, because inlining
didn't always happen.
Yet, as I said, even then, it works just fine, and as documented,
for 99.9999% of the uses to which it is put in code compiled by gcc.
(That's not surprising, since gcc is, generally, based on standards
such as ISO C, which presumably make it much clearer that "inline"
is, like "register", a mere hint.)
Sorry you recently got bit by this, though. That happens quite often
when using tools as complex as gcc, I'm afraid -- review all the
egcs- and gcc2-related discussions regarding 64-bit alignment of
REAL*8 (aka `double') on PPro and PII chips that have gone on
even since we *thought* we had this "fixed" in a long-ago version
of g77 based on gcc 2.7.something. As with your situation, what
we thought "worked" just happened to not fail, and getting it
to truly work properly is much more difficult, politically as well as
technically, than we ever thought.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990210105658.A1570@tantalophile.demon.co.uk >
@ 1999-02-10 9:36 ` Jamie Lokier
[not found] ` < 19990210171623.A2799@tantalophile.demon.co.uk >
1999-02-28 22:53 ` Jamie Lokier
0 siblings, 2 replies; 180+ messages in thread
From: Jamie Lokier @ 1999-02-10 9:36 UTC (permalink / raw)
To: H. Peter Anvin, Lee Iverson; +Cc: torvalds, ross.s, egcs
Jamie Lokier wrote:
> H. Peter Anvin wrote:
> > Oh yes, __builtin_constant_p() really, really ought to work properly
> > in an inline...
>
> It does. See egcs-1.0.3.
Bugger, I was wrong. Sorry Peter.
I was _told_ it is working in some EGCS version, and misread a test I
did earlier. It ought to be working by now: I submitted a patch a very
long time ago, and was told something similar had been installed into
the tree.
-- Jamie
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 5:47 ` craig
@ 1999-02-10 9:42 ` Linus Torvalds
[not found] ` < 79sgd8$p7p$1@palladium.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` craig
1 sibling, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-10 9:42 UTC (permalink / raw)
To: submit-linux-egcs
In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>
>>> >Why don't you just remove "inline" completely, then?
>>>
>>> Because it works just fine, and as documented, for 99.9999% of the
>>> uses to which its put in code compiled by gcc?
>>
>>Right. So why break it then?
>
>By your apparent standards, it always *was* broken, because inlining
>didn't always happen.
No.
gcc _did_ use to always inline if it at all could do so. There were
cases that made it unable to inline, simply because the code itself was
not conducive to inlining. Those were _technical_ reasons for not
chosing to inline something, and completely and utterly understandable.
For example, not inlining a recursive function is just obviously the
right thing to do (yes, in theory you could try to make it iterative,
but if the programmer gave the compiler a recursive function then it's
the _programmer_ who is responsible for it, and nobody really expects
the compiler to do miracles).
>Yet, as I said, even then, it works just fine, and as documented,
>for 99.9999% of the uses to which it is put in code compiled by gcc.
No. It used to work for 100% of the caaes gcc could handle.
The change broke that.
It used to be a feature you could depend on.
The change broke that.
Yes, the documentation had hedges to handle the real cases (like
recursion etc) where inlining just isn't feasible, but the fact that it
hedged its bets doesn't change the fact that people like me used to be
able to rely on the compiler to do what it was asked to do.
If it was a case of "oh, gcc used to have a 50-50 policy on when to
inline, and the change made that a 40-60 policy", then it would have
been much more palatable. But it wasn't. It was a case of 100% success
being turned into "I wonder what the hell they'll break next time
around".
Repeatability is good. Random changes that break existing behaviour for
no technical reason is bad.
>(That's not surprising, since gcc is, generally, based on standards
>such as ISO C, which presumably make it much clearer that "inline"
>is, like "register", a mere hint.)
"extern inline" is a documented gcc extension. It may be covered by ISO
C these days, but it didn't use to be.
"address of a label" is a documented gcc extension, and is NOT covered
by any C standard (pending or accepted) that I know of.
As such, the people who brought up "standards" as an argument for
changing the behaviour are fairly hypocritical: it's a good argument but
in order to hold water it has to be _relevant_.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990210171623.A2799@tantalophile.demon.co.uk >
@ 1999-02-10 9:55 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990210094228.13924A-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-10 9:55 UTC (permalink / raw)
To: Jamie Lokier; +Cc: H. Peter Anvin, Lee Iverson, ross.s, egcs
On Wed, 10 Feb 1999, Jamie Lokier wrote:
> Jamie Lokier wrote:
> > H. Peter Anvin wrote:
> > > Oh yes, __builtin_constant_p() really, really ought to work properly
> > > in an inline...
> >
> > It does. See egcs-1.0.3.
>
> Bugger, I was wrong. Sorry Peter.
It works in development versions of egcs, but as far as I know of it does
not work in _any_ released version of gcc. It certainly is not something
you can really use anyway, as using it requires that all users have to
upgrade: which may be acceptable in some environments, but is certainly
not an option in most places.
The same is true of certain other features like __builtin_return_address()
(which _does_ work in egcs-1.0.3 I've been told, but doesn't work in many
other versions) which makes them essentially a non-issue in production
environments with multiple versions of gcc. It's good that these things
evolve and get fixed, but the fact that they have gotten fixed does NOT
mean that people can just start depending on them - that will happen much
much later.
This is one reason why it's so important to _not_ break backwards
compatibility if at all possible: even if you introduce a new feature that
makes an old feature unnecessary, you can't just force all your users to
upgrade overnight, and you should expect people to use old and new
versions concurrently - so the old feature has to stay (not forever, but
certainly for at least one major release - which for most bigger projects
implies at least a year of "migration time").
No, I don't enjoy it either. Maintenance is not especially exciting or
interesting, but it _is_ important. Expect people to rely on
__builtin_constant_p inside inline functions in another two years or so.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990210094228.13924A-100000@penguin.transmeta.com >
@ 1999-02-10 10:54 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
0 siblings, 1 reply; 180+ messages in thread
From: Joe Buck @ 1999-02-10 10:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs, hpa, leei, ross.s, egcs
[ __builtin_constant_p ]
> It works in development versions of egcs, but as far as I know of it does
> not work in _any_ released version of gcc. It certainly is not something
> you can really use anyway, as using it requires that all users have to
> upgrade: which may be acceptable in some environments, but is certainly
> not an option in most places.
If the feature gives a clear win, it is possible to use it with a
preprocessor check. To oversimplify a bit:
#if __GNUC_MINOR__ > threshold
... code using the feature
#else
... older code
#endif
Since this conditional compilation gives one more thing to test for, the
developers might choose not to use it unless the win is large enough
to justify it.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 79sgd8$p7p$1@palladium.transmeta.com >
@ 1999-02-10 11:04 ` Lee Iverson
1999-02-28 22:53 ` Lee Iverson
1999-02-10 11:51 ` Marc Espie
1999-02-11 12:20 ` craig
2 siblings, 1 reply; 180+ messages in thread
From: Lee Iverson @ 1999-02-10 11:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: submit-linux-egcs, egcs
This response is too long, but it's the last I'll say on the
subject.
In message < 79sgd8$p7p$1@palladium.transmeta.com > you write:
> In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
> >>On 9 Feb 1999 craig@jcb-sc.com wrote:
> >>
> >>> >Why don't you just remove "inline" completely, then?
> >>>
> >>> Because it works just fine, and as documented, for 99.9999% of the
> >>> uses to which its put in code compiled by gcc?
> >>
> >>Right. So why break it then?
> >
> >By your apparent standards, it always *was* broken, because inlining
> >didn't always happen.
>
> No.
>
> gcc _did_ use to always inline if it at all could do so. There were
> cases that made it unable to inline, simply because the code itself was
> not conducive to inlining. Those were _technical_ reasons for not
> chosing to inline something, and completely and utterly understandable.
>
> For example, not inlining a recursive function is just obviously the
> right thing to do (yes, in theory you could try to make it iterative,
> but if the programmer gave the compiler a recursive function then it's
> the _programmer_ who is responsible for it, and nobody really expects
> the compiler to do miracles).
And that was the case here. The problem you faced was *not* due to
any artificial limit arbitrarily imposed by the compiler but a
technical limitation that was discovered in which gcc/egcs was
generating bad code when inlined code used computed jumps. The test
to disable inlining in this case was casting too wide a net... See
Richard Henderson's fix:
http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00172.html
> It used to be a feature you could depend on.
>
> The change broke that.
This was never a feature you could blindly depend on and -Winline is there
for the simple reason that it can fail when the programmer might not expect
it to. This is a technical issue, and always was. You were the one who
turned it into some sort of Jihad and started insulting people
(although some of my friends were quite impressed that I had been
personally insulted by Linus Torvalds, I wasn't too fond of it).
For this particular case, the bug/shortcoming has been fixed, but that doesn't
change the fact that the interaction between certain coding structures and
inlining is fragile. Your mistake was and still is in assuming that it isn't.
> Yes, the documentation had hedges to handle the real cases (like
> recursion etc) where inlining just isn't feasible, but the fact that it
> hedged its bets doesn't change the fact that people like me used to be
> able to rely on the compiler to do what it was asked to do.
>
> If it was a case of "oh, gcc used to have a 50-50 policy on when to
> inline, and the change made that a 40-60 policy", then it would have
> been much more palatable. But it wasn't. It was a case of 100% success
> being turned into "I wonder what the hell they'll break next time
> around".
>
> Repeatability is good. Random changes that break existing behaviour for
> no technical reason is bad.
That's where you are mistaken, this was a "real" case. I'd have to side with
the point of view that says if you can't reliably generate good code then the
best "fix" is to disable the feature. That was the case here, the only
problem was that *you* weren't prepared to recognize and deal with the
failure. If, in the future, egcs developers discover that label
addresses cause bad code to be generated in many circumstances, then
that alone would justify turning off inlining in their presence, even
if those don't include the ones you are relying one. Ideally, bugs
get fixed, but you know as well as I that sometimes they just get
papered over until they are fixed. You do the same thing, I've seen
it in action. Don't impugn the motives of other developers for that.
Get over it. EGCS *is* a very reliable compiler, but one under very
active development. Backwards compatibility has *never*, to my
knowledge, been gratuitously broken. There have been bugs that made
it fail and there have been incompatibilities justified by sound technical
reasoning.
The problem here was primarily with your reliance on a particular
interpretation of a feature which is documented to be unreliable. If
a previous version of the compiler permitted a use which leads to
broken code (inlining with computed gotos), then there was sound
technical reason to disable it. And that should be as obvious to you
as anyone else. The fact that you went off half cocked without even
seeking an explanation doesn't reflect very well on you. And neither
does your insulting everyone who has disagreed with you.
Time for all of us to get back to coding.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 79sgd8$p7p$1@palladium.transmeta.com >
1999-02-10 11:04 ` Lee Iverson
@ 1999-02-10 11:51 ` Marc Espie
[not found] ` < 199902101950.UAA03203@quatramaran.ens.fr >
1999-02-28 22:53 ` Marc Espie
1999-02-11 12:20 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: Marc Espie @ 1999-02-10 11:51 UTC (permalink / raw)
To: torvalds; +Cc: egcs
You could *at least* acknowledge that you read the original documentation
wrong, and that you relied on your interpretation of it...
You have stated repeatedly that egcs broke a *documented* feature, and we
have been repeatedly telling you that it was undocumented, and that your
interpretation was wrong. The *implementation* worked in the way you described,
but the *interface* did not !
Is it *that* hard to state publically ? Nowhere in *any* of your messages
did you even *hint* that you may have made a small misinterpretation.
Afterwards, we can all go back to serious coding, like getting the documentation
straighter, or fixing egcs to get more compatible with old gcc's ways (which
is *the* current problem. but stop referring to it as `breaking old documented
behavior, which is getting on everybody's nerves, haven't you noticed ? :) )
Get your gripes straight, please. We all know that you have been having trouble
with egcs in the past, this is no reason to be downright insulting to people
who have been *very* responsive to motivated queries, as I can attest from
the OpenBSD side of the free world.
(kuddoes to Mike, Jeff, Kaveh, Zack, and the rest).
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902101950.UAA03203@quatramaran.ens.fr >
@ 1999-02-10 16:27 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990210161330.14471K-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-10 16:27 UTC (permalink / raw)
To: Marc.Espie; +Cc: egcs
On Wed, 10 Feb 1999, Marc Espie wrote:
>
> You could *at least* acknowledge that you read the original documentation
> wrong, and that you relied on your interpretation of it...
Would that make you happier?
Yes, I publicly acknowledge that the documentation did not _guarantee_
that "inline" will inline. I've several times mentioned that it makes
perfect sense to not inline in many cases.
My gripe is (and has been) that somebody changed gcc behaviour for no good
reason, and that the behaviour was strongly implied in the documentation.
Furthermore, all features involved were documented gcc extensions, and
that the Linux usage was in no way unreasonable. The functions in question
were
(a) very small
(b) _needed_ to be inlined exactly because they used another gcc feature
in order to report potential problem locations correctly.
(c) did not do _anything_ that could reasonably be considered illegal in
an inline function.
And yes all of it could have been done some other way. The reason Linux
used them as it used them was that all the other portable alternatives
were more broken (I'd have _loved_ to use documented gcc interfaces, but
they didn't actually happen to work).
And no, very few others are complaining, because the breakage only
happened when you used two gcc extensions together ("inline" and address
of a label). Linux is probably the only thing that actually uses a lot of
the extensions.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990210161330.14471K-100000@penguin.transmeta.com >
@ 1999-02-10 17:56 ` Joe Buck
[not found] ` < 199902110155.RAA14069@atrus.synopsys.com >
1999-02-28 22:53 ` Joe Buck
0 siblings, 2 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-10 17:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marc.Espie, egcs
> And no, very few others are complaining, because the breakage only
> happened when you used two gcc extensions together ("inline" and address
> of a label). Linux is probably the only thing that actually uses a lot of
> the extensions.
Unfortunately, this makes it more likely that the egcs development will
occasionally break Linux; we just don't have that many test cases for
interaction between gcc extensions. When these are encountered we'll
just have to fix them.
I think that it's perfectly reasonable to ask that the change that broke
this be reverted enough so that you can get the function in question
inlined again, and I'm sure that folks like Jeff are eager to assist you
with just that. I only hope that in the future it can be handled without
so many insults. The change in question was not "for no good reason", it
was an attempt to decrease the virtual memory consumption of gcc (I don't
know how much it helped). If the change has limited value and harms the
Linux kernel, that may be a good reason to revert the change. It has not
gone into a release, only a snapshot.
In the future if a change to a snapshot breaks Linux, please report it as
a bug, and I'm sure it will be treated as high priority. To avoid another
round of flamage, it's best to indicate clearly that the code relies on
GNU extensions, so that the (rather large) group of people whose main
interest is a good compiler for conforming code won't get bent out of
shape and fill the list with "but the standard doesn't guarantee that
you can do that" mailings.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902110155.RAA14069@atrus.synopsys.com >
@ 1999-02-10 20:01 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 1 reply; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-10 20:01 UTC (permalink / raw)
To: Joe Buck; +Cc: Linus Torvalds, Marc.Espie, egcs
In message < 199902110155.RAA14069@atrus.synopsys.com >you write:
> so many insults. The change in question was not "for no good reason", it
> was an attempt to decrease the virtual memory consumption of gcc (I don't
> know how much it helped). If the change has limited value and harms the
> Linux kernel, that may be a good reason to revert the change. It has not
> gone into a release, only a snapshot.
To clarify, the change was not because c++ memory consumption. It was to fix
a real bug -- imagine what happens if you have label initializers which are
used by indirect jumps and you inline the function.
See execute/980526-1.c
The C++ inline memory changes are still in the queue, they haven't been
installed yet.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 79sgd8$p7p$1@palladium.transmeta.com >
1999-02-10 11:04 ` Lee Iverson
1999-02-10 11:51 ` Marc Espie
@ 1999-02-11 12:20 ` craig
[not found] ` < 19990211201836.2781.qmail@deer >
1999-02-28 22:53 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-11 12:20 UTC (permalink / raw)
To: torvalds; +Cc: craig
>In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
>>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>>
>>>> >Why don't you just remove "inline" completely, then?
>>>>
>>>> Because it works just fine, and as documented, for 99.9999% of the
>>>> uses to which its put in code compiled by gcc?
>>>
>>>Right. So why break it then?
>>
>>By your apparent standards, it always *was* broken, because inlining
>>didn't always happen.
>
>No.
>
>gcc _did_ use to always inline if it at all could do so.
False. gcc *never* inlined 100% reliably. It might have tried,
and succeeded often enough, but other times, it just generated
bad code, or ran out of memory, or similar.
Exactly what would you do if one of those "reliable" gcc compilers
produced bad code when inlining? Remember: you do not have the
option of answering "change my code to work around the bug", since
you are complaining about having to change your code to be correct
according to the gcc docs. So what would you do, that you cannot
possibly cope with doing in the case you are now complaining about?
>There were
>cases that made it unable to inline, simply because the code itself was
>not conducive to inlining. Those were _technical_ reasons for not
>chosing to inline something, and completely and utterly understandable.
Yet, you completely and utterly do *not* understand some of the
common-sense reasons for gcc to choose *not* to inline something,
such as "the gcc developers decided generation of bad code was
too likely if a procedure meeting certain criteria was inlined"
and "the gcc developers decided it took too much memory to inline
this sort of procedure in certain circumstances".
Since "inline" is universally understood to be a *suggestion*, not
a *command*, it's not usually rigorously documented in terms of
exactly what conditions guarantee either 100% or 0% actual inlining,
especially not in the sense of a *specification* of the language
being compiled.
I'd be surprised if you could find a *single* compiler in the entire
market that documented *exactly* the criteria under which a procedure
would be guaranteed to be inlined, saying other procedures would
never be inlined. If you do, please switch to using it instead of
gcc. (It might be a Forth compiler, for example, so you'd have
to translate Linux into Forth. You'd probably be happier with the
results.)
>For example, not inlining a recursive function is just obviously the
>right thing to do (yes, in theory you could try to make it iterative,
>but if the programmer gave the compiler a recursive function then it's
>the _programmer_ who is responsible for it, and nobody really expects
>the compiler to do miracles).
*You* do. You expect the compiler to somehow *know*, all by itself,
with no human intervention, whether it is able to inline a procedure
from first principles and thus *always* produce correct code for any
case where it can be shown that inlining is at all possible.
Either that, or you expect the compiler *developers* to do miracles:
produce a compiler that can inline anything conceptually inlinable,
without ever producing bad code, running out of memory (when *not*
inlining *wouldn't* have), taking too much CPU time (compared to
*not* inlining), etc.
What is seems you're *really* saying, though, is that you prefer
the generation of bad code. Though it's hard to tell *what*
you're saying, other than "I feel the need to spew at people who
are just trying to do a good job, because they disagree with me
about something regarding which I have little expertise".
For example, you seem to think taking the address of a procedure
makes that procedure uninlinable. Wrong. It just does *currently*.
It won't always do so. I can easily imagine several ordinary,
common constructs that involve taking the address of a procedure
that a much smarter code-generation technology could happily take
into account when inlining. Same for recursion.
Therefore, all anyone can truly say about "inline" is that it is a
*suggestion*, and guidelines about whether it actually happens are
just those -- guidelines, which can change from release to release,
perhaps even compile to compile.
If you don't want inlining to happen; don't say "inline"; use
whatever compiler options disable inlining; inspect the generated
code to see if inlining happened, and modify the source code
as necessary to avoid it, or modify the generated code and be done
with it.
If you *do* want inlining to happen, same as above, only inverted:
say "inline"; use whatever compiler options enable inlining; inspect
the generated code to see if inlining happened, and modify the
source code as necessary to force it to, or modify the generated
code and be done with it.
In both cases, once you achieve the desired results, throw them out
the next time you compile, regardless of whether you're using the
exact same compiler, source code, etc., but especially if you're
using a new version.
There. I just stated what I bet *every* compiler vendor of the
industry would say, if pressed, about inlining and similar kinds
of optimizations. Though gcc might be unique in simplifying some
of the above by offering `-Winline', I would *not* stake my life,
limbs, or property on the assumption that any failure to inline
would result in that warning, because a bug preventing the
warning is just too easy to put into gcc.
>>Yet, as I said, even then, it works just fine, and as documented,
>>for 99.9999% of the uses to which it is put in code compiled by gcc.
>
>No. It used to work for 100% of the caaes gcc could handle.
Again, a false, and useless, statement. Any of the cases gcc could not
handle either it did not inline, or it generated bad code. I guess
you call generating bad code an example of inlinining being properly
"handled".
Essentially, you're making a case for generating bad code. It's rather
disturbing to know that the author of the most visible free-software
product prefers bad code to be generated, when given a choice
between that and not inlining as "directed" by the programmer.
>The change broke that.
Your code was broken, AFAICT, and the change brought that to your
attention. Please, deal with that and stop bugging us, though we
don't mind hearing about collateral changes resulting from bug-fixes,
especially when presented as such.
>It used to be a feature you could depend on.
It was always a feature you should *not* depend on, without using
`-Winline', providing external definitions to go with `extern inline',
or whatever was appropriate.
People who read the documentation *carefully* always understood that.
In that sense, you could and still *can* depend on "inline" working
properly. That means you have to *use* it properly, which you
clearly haven't been doing.
You really ought to research the extensions you're using more carefully
before using them. Perhaps you shouldn't be using them at all in a
product like Linux.
>The change broke that.
Again, no, it didn't. You could always depend on "inline" to be
a *recommendation* that gcc try and inline the procedure, and
that if it couldn't or wouldn't, fine. The results might or might
not be bad code; if bad code got produced, you could depend on the
gcc authors to try to quickly fix it, perhaps by disabling inlining
under certain circumstances until the underlying problem was fixed.
>Yes, the documentation had hedges to handle the real cases (like
>recursion etc) where inlining just isn't feasible, but the fact that it
>hedged its bets doesn't change the fact that people like me used to be
>able to rely on the compiler to do what it was asked to do.
That's correct. However, the blame does not fall on gcc, or on gcc
developers.
Guess who's left.
The documentation did *not* say "any procedure meeting criteria X
*will* be inlined" and then expand on criteria X. It *did* say
something much more like "procedures not meeting criteria X are
examples of those that won't be inlined". That's a very different
thing.
Even if the documentation had been incorrect, relying so much on
the documentation for a product like gcc is, to put it simply,
rather unwise. I don't trust documentation much, in general.
I've seen how it's put together. And I know something about
the language(s) in which it is written, and their propensity for
making it easy for the author to write things readers can
misunderstand.
>If it was a case of "oh, gcc used to have a 50-50 policy on when to
>inline, and the change made that a 40-60 policy", then it would have
>been much more palatable. But it wasn't. It was a case of 100% success
>being turned into "I wonder what the hell they'll break next time
>around".
In reality, it's a case of "I wonder how many more bugs like this
exist in Linux, which future changes in gcc might expose".
Your repeated claims that this constitutes "breakage" on *our* part
now constitutes an out-and-out lie, and I find it to be highly offensive,
since you've already been *thoroughly* corrected on this matter, yet
continue to state it.
The fact is: *your* code had the bug, not gcc, it was *your* code
that was broken, by relying on "inline" guaranteeing actual inlining.
Period.
That being said, yes, you *should* wonder what we'll break next time
around, given how much you depend on behavior not promised in iron-
clad terms in the documentation, and on the interaction of lots of
extensions, some of which are some combination of poorly documented,
poorly designed, poorly implemented, and rarely tested, even in
isolation.
>Repeatability is good. Random changes that break existing behaviour for
>no technical reason is bad.
I agree, but nothing was broken by this change that I've been able to
discern, based on the posts I've read.
In fact, it appears something was fixed.
There was a clear *technical* reason for the change, from what I
understand, and nothing particularly random about it.
That there apparently were collateral *changes* -- not *breakages* --
to generated code due to the fixes is unfortunate, and generally we
try to minimize that sort of thing, as a much-lower-priority thing
to worry about than, say, generating correct code or maintaining
some reasonable degree of performance vs. previous releases
(rougly speaking).
But, those kinds of collateral changes do *not* necessarily constitute
a bug in the end-user sense of the term, not even in the ordinary
sense of the term. Sometimes, things just change. Sometimes, these
changes expose previously hidden, broken code elsewhere, as appears
to be the case here.
>>(That's not surprising, since gcc is, generally, based on standards
>>such as ISO C, which presumably make it much clearer that "inline"
>>is, like "register", a mere hint.)
>
>"extern inline" is a documented gcc extension. It may be covered by ISO
>C these days, but it didn't use to be.
My old copy of ANSI C (draft) doesn't even cover `inline'. So, the
*only* source of information on it was the gcc docs, as it turns out,
unless you want to include drafts of subsequent standards or
something (*none* of which promised the behavior on which you're
depending, I'd guess).
Good engineering means not constructing a large-scale project to
depend on features specific to only one incarnation of a standard,
including its extensions, especially poorly-documented ones.
You'd be smart to stop using gcc-specific extensions in general,
at least to stop using them in so many dizzying combinations.
By "smart" I mean you'd be a better engineer.
If you don't care to be a better engineer, you shouldn't be surprised
when things that used to work fine stop working. (And if you do
become a true engineer, you'll learn to *expect* that ;-). Engineering
is, among other things, the science of designing things so they work,
period, AFAIK. I don't think gcc is very well-engineered in that sense;
it's clear Linux isn't, based on your posts, because innocuous
changes to gcc can, apparently, break it (else you're making a huge
fuss over nothing). At least the gcc developers seem to agree on
making it, on the whole, better engineered -- they generally know
better than to design it assuming undocumented behavior in underlying
products never changes.
You seem to think everything is black-or-white: do what the programmer
said to do, even if it means generating incorrect code, and, oh
by the way, never generate incorrect code.
Reality is different. Good engineering means having to come to terms
with reality.
>"address of a label" is a documented gcc extension, and is NOT covered
>by any C standard (pending or accepted) that I know of.
So why are you using it? Why would you design a product to so
completely depend on the correct interaction of a variety of
extensions supported by only one compiler out of so many choices
on the market?
How many *other* products do you know out there that depend to
a similar degree on the correct interaction of so many gcc
extensions? Are *their* authors so sensitive to changes in
code generation? If the answer is "none", then why are you
making *your* code *more* unreliable than the rest of the
industry by so depending? Is being on the "cutting edge"
that important? If so, why not *act* like someone who *understands*
what being on the cutting edge *means*?
("Hey, I've driven around this 25mph-posted turn at 80mph for
years now and never skidded out. *Now* you tell me this stuff
called `black ice' made me skid out and smash up my hugely
expensive car. It was *your* fault for not making this clear,
you should reimburse me for my car, and make sure this `black ice'
stuff never, ever happens again!")
>As such, the people who brought up "standards" as an argument for
>changing the behaviour are fairly hypocritical: it's a good argument but
>in order to hold water it has to be _relevant_.
I don't know that it isn't relevant or that they're being hypocritical:
my impression is, "inline" *is* covered by drafts of upcoming standards
of some relevance. But if you didn't read a product document, or even
a standards document, guaranteeing actual inlining in the presence of
"inline" in iron-clad, unambiguous terms, *you* were at fault for
depending on such actual inlining.
The reality is, you're trying to exploit nearly every detail of how a
particular compiler works without understanding what a compiler is, what
it does, how it evolves vis-a-vis the development process, language and
library standardization, and so on.
Please stop doing that. Stop using compilers, or at least stop using any
extensions they offer and stop relying on any *particular* behavior they
exhibit. Or, *learn* what compilers are all about, if you have the
10 years or so to spend doing it.
You've gotten *tons* of good, solid advice about the issues involved
from people with far more pertinent expertise than you have developing
operating systems, and have so far done a damn fine job of ignoring it.
If you think the "fixes" to the recent "objectionable" patch will
solve your problems, they won't -- because the underlying problems
are *yours* and thus Linux's, not gcc's. The problem, or some
problem just like it, *will* occur in the future, and our response
will be basically the same: sincere attempt to minimize collateral
changes while striving, *first and foremost*, to prevent the generation
of bad code. You Have Been Warned. Yet Again.
Given that we've gone through this with you in the past (and not
just in the area of compilers, IIRC), I suggest you wean Linux
from depending on gcc at all. Make it compilable by any ANSI C
compiler, for example. Then maybe you won't get so upset every
time a fairly trivial change to gcc's code generation occurs, and/or
we won't have to endure your flames.
That would be a heck of a lot more progressive than just deciding to
stick with gcc-2.7.2.1 forever. But if you want to go that route, it
isn't necessarily a bad decision either, as it'll amount to "nailing
down" the behavior of one crucial component in a much larger, complicated
system (Linux), meaning the developers of the larger system can learn
how to avoid the problems in the nailed-down gcc, which they'll
learn more and more about as time goes on. (There are disadvantages
to that approach, of course. You'd be changing your code to work
around known bugs in 2.7.2.1 rather than changing it to better
accommodate ongoing improvements in compiler technology, for example.
In the long run, Linux would end up either coded entirely in `asm'
directives, or running slower than other operating systems that
had fewer lines of code and, probably, more features.)
The decision is yours. Our viewpoints on this matter will not change,
because they cannot -- if we made you the promises you seem to want,
we'd be lying, in which case we might as well go into politics so
we can get babes and power. That'd just leave gcc development open
to others who aren't suited for that kind of thing, i.e. the current
situation. So the only reasonable possibility is for *you* to adapt.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990211201836.2781.qmail@deer >
@ 1999-02-11 12:57 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990211125202.18523E-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
1999-02-11 15:15 ` David J. Dooling
1 sibling, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-11 12:57 UTC (permalink / raw)
To: craig; +Cc: egcs
On 11 Feb 1999 craig@jcb-sc.com wrote:
>
> >"address of a label" is a documented gcc extension, and is NOT covered
> >by any C standard (pending or accepted) that I know of.
>
> So why are you using it? Why would you design a product to so
> completely depend on the correct interaction of a variety of
> extensions supported by only one compiler out of so many choices
> on the market?
Are you being stupid or argumentative?
To _me_, "standard C" has not been important at all. I'm _more_ than happy
to use gcc extensions, because I think they are worthwhile in the kernel.
So "address of label" is a documented feature of the only compiler I
compile the kernel with. As is "inline". And my argument was that
_neither_ of those features were mentioned in any C standard ("inline" has
since been added to the proposed standards) - but they were very much
mentioned in the gcc documentation.
Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
their argument just needs to think twice. That was my only argument. I'm
just trying to show people how silly it is to say that "oh, the standard
says that 'inline' is just a hint", when the current C standard says
nothing of the sort at ALL.
[ rest of your silly email removed - you seem to be arguing against using
gcc in the first place. I just want to make sure that gcc continues to
be usable and good for Linux ]
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990211201836.2781.qmail@deer >
1999-02-11 12:57 ` Linus Torvalds
@ 1999-02-11 15:15 ` David J. Dooling
[not found] ` < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
1999-02-28 22:53 ` David J. Dooling
1 sibling, 2 replies; 180+ messages in thread
From: David J. Dooling @ 1999-02-11 15:15 UTC (permalink / raw)
To: egcs
>In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
>>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>>
>>>> >Why don't you just remove "inline" completely, then?
>>>>
>>>> Because it works just fine, and as documented, for 99.9999% of the
>>>> uses to which its put in code compiled by gcc?
>>>
>>>Right. So why break it then?
>>
>>By your apparent standards, it always *was* broken, because inlining
>>didn't always happen.
>
>No.
>
>gcc _did_ use to always inline if it at all could do so.
False. gcc *never* inlined 100% reliably. It might have tried,
and succeeded often enough, but other times, it just generated
bad code, or ran out of memory, or similar.
ENOUGH!!!!!!!!!!!
This whole thread only serves to fill all our mailboxes with a bunch
of name-calling and nitpicking. It does not help the development of
gcc or linux (I assume the reason we are all subscribed to this
listserv is to _help_ the development of gcc, no?). It is the
software development equivalent of ``my dad can beat up your dad!''.
Basically (without all the name-calling), the developers of egcs found
that combining two gcc extensions did not produce reliable code. So,
they took the easy fix: don't allow them to be combined. This broke a
significant amount of code for one user, Linus (granted he is not just
_any_ user, nonetheless ...). I am sure other people who depend on
these gcc extensions will also feel the pinch. This is all fact,
everything else that has been said is superfluous.
That being said, is there anything we can do together to improve the
situation for all of us? Obviously the combination of these
extensions worked sometimes. Is there any way to find out when it
works and when it doesn't? It should be a deterministic problem, no?
Perhaps Linus has some cases in his code where he knows it works.
Perhaps other has incidences where it doesn't. Is there not time to
address these issues now? Can it be put on the TODO list? Can we at
least agree on how to warn/error when gcc can't comply with what the
programmer wants? There has to be something that can be done to make
the compiler (and the atmosphere on this thread) better.
Admittedly, I have not the knowledge nor the expertise to investigate
these options myself (I am but a lowly chemical engineer). I
apologize for this (my only intention is to help).
Let's turn this thread around, discuss some specifics, and get
something done.
DAVID?
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
@ 1999-02-11 16:28 ` Lee Iverson
1999-02-28 22:53 ` Lee Iverson
1999-02-11 16:32 ` Paul Derbyshire
1999-02-11 19:41 ` craig
2 siblings, 1 reply; 180+ messages in thread
From: Lee Iverson @ 1999-02-11 16:28 UTC (permalink / raw)
To: d-dooling; +Cc: egcs
In message < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu > you write:
>
> ENOUGH!!!!!!!!!!!
>
> [deleted]
>
> Let's turn this thread around, discuss some specifics, and get
> something done.
Already done and in the CVS tree thanks to Richard Henderson.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
1999-02-11 16:28 ` Lee Iverson
@ 1999-02-11 16:32 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-11 19:41 ` craig
2 siblings, 1 reply; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-11 16:32 UTC (permalink / raw)
To: egcs
At 11:15 PM 2/11/99 -0000, you wrote:
>Obviously the combination of these extensions worked sometimes.
>Is there any way to find out when it works and when it doesn't?
>It should be a deterministic problem, no?
So is the halting problem <g>
[deletia]
Well said. Let's all get along.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990211125202.18523E-100000@penguin.transmeta.com >
@ 1999-02-11 19:41 ` craig
[not found] ` < 19990212033918.4310.qmail@deer >
1999-02-28 22:53 ` craig
0 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-11 19:41 UTC (permalink / raw)
To: torvalds; +Cc: craig
>On 11 Feb 1999 craig@jcb-sc.com wrote:
>>
>> >"address of a label" is a documented gcc extension, and is NOT covered
>> >by any C standard (pending or accepted) that I know of.
>>
>> So why are you using it? Why would you design a product to so
>> completely depend on the correct interaction of a variety of
>> extensions supported by only one compiler out of so many choices
>> on the market?
>
>Are you being stupid or argumentative?
Actually, I was curious. Your extreme reaction at gcc not behaving
exactly the way you wanted and as it had in the past suggested
you might not be aware of the implications of using such features,
despite having been (IIRC) burnt by this before. I was attempting,
among other things, to educate you (and others reading this thread)
as to some of those implications.
But go ahead, cast your aspersions on my motivations for taking time
out of my busy schedule to try to 'splain this stuff to you. Obviously
a huge waste of time, but I factored that in, figuring *somebody*
out there on the Internet might learn from these discussions.
(I've spent much of my career offering explanations like that. I'm
almost *never* wrong in those cases, but I have taken a lot of heat
from people who see only the short term. I remember, over a year ago,
trying to explain to a roomful of numerical engineers why a certain
design being proposed for new Fortran features was actually dangerous,
because instead of causing people to make mistakes 50% of the time,
it would cause them to do so more like .5% of the time, make the
mistakes much harder to detect, and thus lead to more actual errors
in deployed code. They thought I was crazy to reason that way. I'm
thinking of sending your recent email to them, since you are a great
example of the sort of person that considers 50% failure *better*
than .5% failure in many cases, and I prefer to engineer products
to accommodate that viewpoint, since I somewhat share it, especially
when it comes to stuff involving man-machine interfaces, like gcc.)
>To _me_, "standard C" has not been important at all. I'm _more_ than happy
>to use gcc extensions, because I think they are worthwhile in the kernel.
That means, like I already said, you have to be prepared for a very
bumpy ride. You've shown that you have trouble coping with that.
Please learn to adapt to the reality of what happens when you use
cutting-edge, poorly-tested extensions in a compiler undergoing
rapid development.
>So "address of label" is a documented feature of the only compiler I
>compile the kernel with. As is "inline". And my argument was that
>_neither_ of those features were mentioned in any C standard ("inline" has
>since been added to the proposed standards) - but they were very much
>mentioned in the gcc documentation.
Oh, I *thought* your argument was that, if any release of gcc did
not support the combination of the features in exactly the way
*you* expected, despite not being documented to do so, that
meant *gcc* broke your code.
>Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
>their argument just needs to think twice. That was my only argument.
Okay. I must have misread your earlier posts, including the one to
me, which kept saying things like "what are these [gcc/egcs] guys
going to *break* next?" [emphasis added]. I apologize.
>I'm
>just trying to show people how silly it is to say that "oh, the standard
>says that 'inline' is just a hint", when the current C standard says
>nothing of the sort at ALL.
I didn't realize that was *all* you were trying to say. I *thought*
you were also trying to say that a change to gcc's decision-making
process as to whether to actually inline an "inline" function
constituted a bug in gcc, rather than a bug in code that somehow
depended on the inlining actually happening.
>[ rest of your silly email removed - you seem to be arguing against using
> gcc in the first place. I just want to make sure that gcc continues to
> be usable and good for Linux ]
It would be, if Linux didn't make use of so many extensions, as I
explained earlier, in the portion of my email you call "silly".
IIRC, I've occasionally suggested, on USENET, that Linux shouldn't
depend so much on gcc's peculiar characteristics, in the past. Though
I'm a big fan of gcc/egcs and GNU software in general, from an
engineering standpoint, keeping Linux at arms' length from gcc-specific
extensions would be better for Linux, and I think it'd be, in the
long run, better for gcc as well, because it'd tend to encourage
more general optimizations in gcc, rather than having Linux rely
so much on hand-coded use of extensions to get faster code. (That's
a stretch, though, for applications like kernel-code generation,
I realize.)
I guess your only motivation is to make gcc better for Linux, but
not make Linux more robust by lessening its dependencies on
particular code-generation strategies used by any particular
version of gcc.
Me, I'd like to see *both* gcc and Linux be usable and good.
gcc, being an optimizing compiler, will someday simply ignore
some instances of "inline" entirely, and use procedure calls instead,
unless it dies for lack of interest first. That's because inlining
a procedure does not always make for the most optimal code.
(It's obvious enough why, when `-Os' is specified, since that
means optimize for space. It's less obvious otherwise, that
avoiding inlining will tend to reduce the Icache footprint
of the generated code sufficiently to actually make it go
faster than if inlining was naively done.)
But the larger problem is that you seem to think that, once
a behavior is observed, it is guaranteed in future versions of
that product, even though not clearly documented. You would
do well to learn the lesson that this is not true, just as
a good engineer knows that, no matter how many widgets he's
seen exactly .542cm wide, he'd better take seriously the
published specs for them that say ".542cm +/- .005cm" and
not design his product to *assume* exactly .542cm for all
future widgets.
Tolerance isn't just for the political-correctness crowd. It
has real meaning, and, when properly employed, real value
in engineering, including software design.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990212031118.4271.qmail@deer >
@ 1999-02-11 19:41 ` craig
[not found] ` < 19990212034058.4359.qmail@deer >
1999-02-28 22:53 ` kernel-2.2.1-undefined references craig
0 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-11 19:41 UTC (permalink / raw)
To: d-dooling, egcs; +Cc: craig
>and on the whole we'd like to try triggering that sort of thing,
I meant "try *to avoid* triggering", which I hope was obvious.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
1999-02-11 16:28 ` Lee Iverson
1999-02-11 16:32 ` Paul Derbyshire
@ 1999-02-11 19:41 ` craig
[not found] ` < 19990212031118.4271.qmail@deer >
` (2 more replies)
2 siblings, 3 replies; 180+ messages in thread
From: craig @ 1999-02-11 19:41 UTC (permalink / raw)
To: d-dooling; +Cc: craig
>This whole thread only serves to fill all our mailboxes with a bunch
>of name-calling and nitpicking. It does not help the development of
>gcc or linux (I assume the reason we are all subscribed to this
>listserv is to _help_ the development of gcc, no?). It is the
>software development equivalent of ``my dad can beat up your dad!''.
Sorry, I'm not here to play the "let's all get along" game.
If Linus persists in assuming he'll be promised actual inline whenever
he says "inline", he'll continue making Linux *worse*. If he learns
how to better engineer the code within Linux to at least work within
reasonable tolerances of how gcc extensions behave, he'll make it
*better*.
As I said, this is at least the second time around with him on this
sort of thing. *He* has chosen to not get along, and to repeatedly
disregard the solid advice he's been given.
>Basically (without all the name-calling), the developers of egcs found
>that combining two gcc extensions did not produce reliable code. So,
>they took the easy fix: don't allow them to be combined. This broke a
>significant amount of code for one user, Linus (granted he is not just
As far as I can tell, it broke no *correct* code at all.
>_any_ user, nonetheless ...). I am sure other people who depend on
>these gcc extensions will also feel the pinch. This is all fact,
>everything else that has been said is superfluous.
Sorry, I disagree. Much of what I said, if actually paid attention
to, would help people produce more solid code, and perhaps a more
solid compiler as well. I don't appreciate being told everything
else I said was "superfluous". Is this your idea of trying to get
people to stop "name-calling and nitpicking"??
>That being said, is there anything we can do together to improve the
>situation for all of us? Obviously the combination of these
>extensions worked sometimes.
AFAICT, they still worked, for correct code. And someday gcc will
outright *ignore* "extern inline" sometimes for even ordinary
functions, because someday it will be an even better optimizing
compiler, which is what it is advertised as (as versus a macro-based
code generator, which is what some people seem to treat it as).
>Is there any way to find out when it
>works and when it doesn't? It should be a deterministic problem, no?
It was and is working fine, AFAIK. Bad code that depended on the
generated code having certain undocumented properties stopped working,
and on the whole we'd like to try triggering that sort of thing,
but it's something we can't always prevent, and the world would be
a better place if people who wrote bad code like that took well-
intentioned advice to stop.
>Perhaps Linus has some cases in his code where he knows it works.
>Perhaps other has incidences where it doesn't. Is there not time to
>address these issues now? Can it be put on the TODO list? Can we at
>least agree on how to warn/error when gcc can't comply with what the
>programmer wants? There has to be something that can be done to make
>the compiler (and the atmosphere on this thread) better.
There apparently already was, -Winline, and it wasn't being used.
The atmosphere on this thread will get better only once Linus retracts
his claims that it was *gcc* that broke *his* code, and accepts
that his code was wrong.
>Admittedly, I have not the knowledge nor the expertise to investigate
>these options myself (I am but a lowly chemical engineer). I
>apologize for this (my only intention is to help).
I have rarely seen anybody step into an argument in the way you've
done actually succeed at helping. Playing "good cop" when your
tactics include casting aspersions on the points people like
myself have taken our time to carefully make frankly does *not*
help.
But it sure seems to make some people *think* it helps, and I guess,
these days, that's all that matters. Kinda like those executives
who felt it was better to "get along" with the folks their company
was contracting for than to tell them bad news about risks involving
their products.
Of course, the result was the Challenger explosion and seven
people killed, but the nice motivation to "get along" was all that
mattered, right?
>Let's turn this thread around, discuss some specifics, and get
>something done.
The buglet in gcc has, I gather, already been fixed. I haven't
gotten the impression the underlying bug(s) in Linux have, or
will, get fixed.
If that's right, this problem will occur again, sooner or later.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Bad puppies and coding practices
[not found] ` < 19990212034058.4359.qmail@deer >
@ 1999-02-12 4:10 ` Marc Espie
[not found] ` < 199902121210.NAA04037@quatramaran.ens.fr >
1999-02-28 22:53 ` Marc Espie
0 siblings, 2 replies; 180+ messages in thread
From: Marc Espie @ 1999-02-12 4:10 UTC (permalink / raw)
To: craig; +Cc: egcs
In article < 19990212034058.4359.qmail@deer > you write:
>>and on the whole we'd like to try triggering that sort of thing,
>I meant "try *to avoid* triggering", which I hope was obvious.
Actually, no, it's not obvious at all. It's better if the compiler
says `your code is plain wrong, you dummy', but a compiler that breaks
things when you don't follow clean coding practices is a GREAT teaching
tools. :->
A bit like wacking puppies on the nose to teach them proper toilet
habits...
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
[not found] ` < 199902121210.NAA04037@quatramaran.ens.fr >
@ 1999-02-12 4:25 ` Alex Buell
[not found] ` < Pine.LNX.4.05.9902120729110.2093-100000@tahallah.demon.co.uk >
1999-02-28 22:53 ` Alex Buell
1999-02-12 9:04 ` craig
1 sibling, 2 replies; 180+ messages in thread
From: Alex Buell @ 1999-02-12 4:25 UTC (permalink / raw)
To: egcs
On Fri, 12 Feb 1999, Marc Espie wrote:
> A bit like wacking puppies on the nose to teach them proper toilet
> habits...
Are you saying Linus needs toilet training? <ducks>
Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - Leaving the States for good!
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
[not found] ` < Pine.LNX.4.05.9902120729110.2093-100000@tahallah.demon.co.uk >
@ 1999-02-12 6:37 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-12 9:00 ` craig
1 sibling, 1 reply; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-12 6:37 UTC (permalink / raw)
To: egcs
At 07:29 AM 2/12/99 -0500, you wrote:
>Are you saying Linus needs toilet training? <ducks>
>
>Cheers,
>Alex
Ohhhh now the fat's in the fire.
Although, I'm rather surprised to see the side of Linus I've seen recently.
I understood all along that he's actually nothing more than a human being,
but .......
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
[not found] ` < Pine.LNX.4.05.9902120729110.2093-100000@tahallah.demon.co.uk >
1999-02-12 6:37 ` Paul Derbyshire
@ 1999-02-12 9:00 ` craig
1999-02-28 22:53 ` craig
1 sibling, 1 reply; 180+ messages in thread
From: craig @ 1999-02-12 9:00 UTC (permalink / raw)
To: alex.buell; +Cc: craig
>On Fri, 12 Feb 1999, Marc Espie wrote:
>
>> A bit like wacking puppies on the nose to teach them proper toilet
>> habits...
>
>Are you saying Linus needs toilet training? <ducks>
Maybe it's been too long since I was involved in any toilet training,
but, my word, I don't remember *ducks* being involved....
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
[not found] ` < 199902121210.NAA04037@quatramaran.ens.fr >
1999-02-12 4:25 ` Alex Buell
@ 1999-02-12 9:04 ` craig
1999-02-28 22:53 ` craig
1 sibling, 1 reply; 180+ messages in thread
From: craig @ 1999-02-12 9:04 UTC (permalink / raw)
To: Marc.Espie; +Cc: craig
>In article < 19990212034058.4359.qmail@deer > you write:
>>>and on the whole we'd like to try triggering that sort of thing,
>
>>I meant "try *to avoid* triggering", which I hope was obvious.
>
>Actually, no, it's not obvious at all. It's better if the compiler
>says `your code is plain wrong, you dummy', but a compiler that breaks
>things when you don't follow clean coding practices is a GREAT teaching
>tools. :->
I agree with that last sentiment, but I'm not sure there'll be much
agreement that *gcc* should default to be a great teaching tool.
And as long as people who *think* they don't need teaching can
turn off its teaching facilities, they'll do it...while the people
who really *don't* need it for teaching would avoid a product
that insists on wildly changing its behavior (even if entirely within
spec) even as their overall product nears deployment stage.
But, as it turns out, if we just concentrate on making it a better
optimizing compiler with only modest emphasis on teaching-tool-like
features (-pedantic, -Wall, etc.), it'll someday, sometime, somehow,
somewhere, teach most of its users *not* to make so many assumptions
about how it works.
And, from an engineering perspective, I prefer that tools as complex
as gcc be designed so they offer a simple "switch" of sorts between
the default mode -- "work as much like you always have as possible" --
and the stress-my-system mode, aka "change as much as you can about
how you work while remaining within specs, so I can see if my system
is designed to use it with the proper tolerances".
(Which makes me wonder if we should offer a switch to make gcc
go increasingly out of spec, for people who want to find the point
of actual failure. Kind of like how aircraft manufacturers don't
just test to see whether the wings of a jet can flex *within* specs
without breaking, but literally flex them until they *do* break
so they can see how far out of the specs the wings' tolerances are,
or how drug manufacturers stuff helpless animals full of a new drug
until it dies to see what it really takes to do that. When it
comes to the equivalent for gcc, these days, I feel like I want
to nominate penguins for the testing.)
>A bit like wacking puppies on the nose to teach them proper toilet
>habits...
I don't know whether there have been better (less physical) methods
devised vis-a-vis house-training dogs, but I'm under the impression
that there have been improvements in "breaking" horses, requiring
much less physical control of the animal and achieving much faster
results. I gather this has to do with using techniques that gain
the animal's respect using the cues the horses themselves are
genetically predisposed to recognize, as compared to the traditional
methods, which are more like whacking them on the nose with a paper
(use of infliction of pain and direct physical control).
It is true that, if you don't know how to reach the subject directly
using it's own open mind, sometimes the best you can do is develop
some kind of Pavlovian response in it so that it avoids bad behavior.
But, I like to think we can do better. By figuring out how to earn
the respect of potential gcc users by showing we have a solid appreciation
of what it takes to work in *their* field and, at the same time,
that we won't tolerate their attempting to control us in our own,
perhaps we can gain their respect (making it mutual, since we'll
be coming into the situation with our own respect for their field),
making the job of educating them much easier.
Then, instead of relying on the unexpectedly disastrous-but-conforming
behavior of products like gcc to frustrate them out of employing bad
coding habits, we might find they're much more receptive to employing
*good* coding habits from the outset, making the mutual relationship
much more enjoyable, and less stressful, for all.
In my personal experience, I've found this to be pretty easy with the
Fortran audience, to the (very modest) extent to which I've been able
to practice it.
What we now need is someone who is able to practice these techniques
with regards to the Linux developers, especially Linus Torvalds.
I.e., a "Norse Whisperer".
(Okay, seriously, how many of you *really* saw that coming? :)
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990212033918.4310.qmail@deer >
@ 1999-02-12 10:12 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212095518.31280C-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 10:12 UTC (permalink / raw)
To: craig; +Cc: egcs
On 12 Feb 1999 craig@jcb-sc.com wrote:
>
> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
> >to use gcc extensions, because I think they are worthwhile in the kernel.
>
> That means, like I already said, you have to be prepared for a very
> bumpy ride. You've shown that you have trouble coping with that.
Umm..
I had no problems with gcc features for about six or seven years of Linux
development. These things simply didn't use to happen: despite upgrading
_major_ versions of gcc (when Linux started we were using gcc-1.40), for
those six-seven years there weren't really any changes that I ever had
problems with.
There were tons of code generation bugs over time, but hey, I _expect_
bugs, and while compiler bugs are sometimes really hard and nasty to find,
I don't complain too much: I report them, and I tell people not to use
certain versions. I may be grumpy for a while because I spent ages looking
at a bug that didn't turn out to be mine, but I never get the feeling that
I should really dislike the compiler people.
The reason I have been complaining so much lately is that I think that the
egcs development has lost that stability. Again, never mind code
generation bugs, I'm talking about _interface_ stability. I've had much
more problems in the last year than I had in the seven years preceding
this.
This may actually not be due to technical reasons as much as simply due to
a different open development model - it may just be that more people see
"partial" work, and some of that partial work breaks stuff. Fine - I like
open development myself, and I use it. But when somebody complains to _me_
that I broke old interfaces, I consider that a bug unless I have a very
very strong technical reason to tell people that I simply _cannot_ support
some old interface any more.
In contrast, on this list, when people complain that egcs breaks existing
code, the answer is "shut up and live with it" - and then they Cc: me on
the damn thing. And that's why I get so upset, and why these flame-wars
erupt.
"Shut up and live with it" is not a way of caring for your customers. And
creating the best compiler in the world is not just about code generation:
it's about supporting the people that use it, too.
I could change my kernel interfaces and tell people that "shut up,
recompile, and be happy". Trust me, that doesn't work when you have a
serious project that you expect others to be serious about too. I make
_damned_ sure that I don't break binaries, and when I do it by mistake I
have egg on my face and I fess up to screwing up.
On this list, nobody 'fesses up to screwing up any more. And that's sad.
It makes the egcs project look less serious, and more like a bunch of
people that just want to play at making a commercial-grade compiler.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 19:41 ` craig
[not found] ` < 19990212031118.4271.qmail@deer >
@ 1999-02-12 11:40 ` Linus Torvalds
[not found] ` < 7a203j$9cf$1@palladium.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 11:40 UTC (permalink / raw)
To: submit-linux-egcs
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 7a203j$9cf$1@palladium.transmeta.com >
@ 1999-02-12 14:24 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990212172337.0082de00@pop.netaddress.com >
1999-02-28 22:53 ` Paul Derbyshire
1999-02-12 14:50 ` kernel-2.2.1-undefined references craig
1 sibling, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-12 14:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
>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.
Uh... it kind of occurs to me that perhaps the simplest solution is just to
actually use a macro there? Then you can be damn sure it will inline,
because the preprocessor will have done it before egcs ever gets to see
your sources. :-)
>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".
Ah. I see your point about inline versus actual macros. Maybe the solution
is this. First, 'extern inline' loses special significance, particularly
because of the standard likely covering the usage soon. On the other hand,
GCC can add __attribute__ ((always)) as an extension that will force
inlining of the function under well-determined conditions, specifically,
that it is not recursive. (The same rule that governs whether a macro
"inline function" will work properly.)
That leaves the sticky issue of taking addresses. An ordinary pointer to
function address taking can just force "exlining" a copy as a normal
function whose address will be used for pointers to functions (what is
presumably already done with plain-jane "inline" when it is inlined but the
function address is used). GCC can also perhaps try to optimize by
replacing function invocations through pointers with inline functions if a)
the function that will be invoked is known at compile time and b) it is
inline.
As for taking the address of a label in an inline function and using it,
this is trickier.
1: If the label will be encountered and then a goto is used on it,
the compiler could use setjmp/longjmp to do it, thereby making
sure thre goto goes to the correct inlined version.
2: Otherwise, it is trickier. One possibility is to exline an
instance as a normal function and use the address of the label in
that copy.
3: To dodge the ambiguous address problem altogether when only one
instance will be inlined anyways, add an __attribute__ ((once)),
and have the compiler inevitably inline the function (if
nonrecursive) the first time it sees it. If it sees a second
invocation, that's an error. Otherwise, label addresses
unambiguously refer to the one instance.
4: An __attribute__ ((always)) or __attribute__ ((once)) that is
recursive or otherwise uninlinable generates an error, regardless
of -Winline.
Now, does this look like it'll make everybody happy?
>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.
Have you tried changing them back to see if everything works perfectly?
>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).
The address-of-label is just used to generate displayed information? That
simplifies things a lot. If the address is only taken right at the label
itself, then it seems reasonable to make an inline __attribute__ ((always))
label and label address situation work like this:
-- The address-of-label operator can be invoked on the label only
inside the function.
-- Then, it refers to the specific instance in the same inlined copy
with the address operator.
-- Other uses are an error.
-- This can be implemented by making inlined functions with
__attribute__ ((always)) and labels generate a different label
symbol according to some mangling scheme for each instance, and
the address-of refer to the appropriate mangled symbol when used
legally.
-- The documentation can be made to reflect the details of this and
of the circumstances for its legality.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 7a203j$9cf$1@palladium.transmeta.com >
1999-02-12 14:24 ` A final solution. (Was Re: kernel-2.2.1-undefined references.) Paul Derbyshire
@ 1999-02-12 14:50 ` craig
[not found] ` < 19990212221225.22651.qmail@deer >
1999-02-28 22:53 ` kernel-2.2.1-undefined references craig
1 sibling, 2 replies; 180+ messages in thread
From: craig @ 1999-02-12 14:50 UTC (permalink / raw)
To: torvalds; +Cc: craig
>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.
I realize you think that. That's because you're rather uninformed,
or intentionally forgetful, about what has really been going on here,
and prefer to insult others than to take responsibility for mistakes
committed (repeatedly) on your end.
>It's not at all buggy, it just assumes that the compiler does something
>reasonable.
No, it assumes that the compiler does something *some* people consider
reasonable, but others don't, and which is not *documented* by the
compiler to do any particular thing, implementation-wise.
>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.
In other words, the kernel makes two uses of "inline", one that is
correct, the other that is incorrect.
>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).
First, I based my comments on what *you* were saying when *you* were
slinging mud at the egcs developers, the decisions they were making,
and the help they were offering you.
If you had wanted us to look at any sources, *you* should have posted
the relevant bits here first, perhaps in place of mud-slinging, which
you continue to prefer to engage in.
>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".
Fine and dandy.
>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".
Which is incorrect, if the code actually *depends* on inlining
actually happening, as the documentation should have made clearer,
but most everyone already knew.
>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.
Mostly due to an *incorrect reading* of the gcc documentation, which
didn't help things.
>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.
More below on your continuing attack on my efforts to educate you
as to proper use of gcc extensions.
>The ones that were bitten by the egcs bug (let's just be honest and call
>it what it really was)
I have concluded that *you* wouldn't know "honesty" if it bit
you in the ass. You have lied about this before, and you are
continuing to lie about it now. egcs not inlining an "extern inline"
function is not, never has been, and never will be a bug. The
*developers* might consider it a bug, in that they'd prefer some
cases be inlined for performance reasons, but to the user, it is
*never* a bug in the sense of violating the "contract" the compiler
makes with its users, in the form of an explicit language
specification.
In that sense, it's what I call a "buglet", meaning, not necessarily
a high-priority bug -- not a violation of the "contract", or
specification, of how the compiler behaves in terms of implementing
the language it compiles.
In writing the g77 documentation, I tried to make the distinction
between promises made on behalf of the GNU Fortran *language* and
the behavior of the current GNU Fortran *compiler* as clear as I could.
If, as a programmer, I don't see that clear a distinction in a product's
documentation, I assume *fuzziness*.
It's been *your* error that you've assumed that any behavior you observe
and which the gcc documentation doesn't clearly say might change will
therefore be promised for all of eternity. That's a *very* frequent
error, but rare is the person who insists on insulting those who
try and point it out to him, especially as repeatedly and as nastily
as you've done.
>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).
The only reasons it should have mattered to you that inlining did
not happen are that you didn't get the performance you want, or
the generated code was actually wrong. Neither was the case. Therefore,
if the overall result was that *your* code broke, it was not *egcs*
that broke it -- it was a change to egcs that triggered a long-hidden
bug in your code. Please stop saying things like "this change broke
egcs", as that's a lie.
>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.
Okay, Linus, now that you've *totally* destroyed any and all credibility
you've *ever* had with me, and converted me from promoting your
abilities, and Linux, to friends and neighbors to warning them away
from anything you touch, I'll enclose a copy of some emails sent *six
months* ago on a closely-related issue.
I want you to read these emails *very* carefully, and then come back and
explain exactly how you still believe I'm simply up in an "ivory tower",
have never had a "look" at code *you* have not (to my knowledge)
offered here, and how I should still agree that Linux' use of
"extern inline" as "guarantee me inlining" makes sense.
(For *other* readers, who *are* allowed to not bother reading the
emails quoted below: the summary is, this problem came up before,
was specified as being related to Linux, and was *thoroughly* and
*completely* explained as being the result of a combination of
poorly-specified extensions, inadequate documentation, and Linux'
inappropriate reliance on the behavior of extensions. Further,
viable alternatives were proposed. Apparently that did no good
then, though I'm willing to take the blame for not fixing the
gcc docs myself, and there is plenty of reason to assume all this
verbage will do no good now.)
tq vm, (burley)
P.S. Yes, folks, I realize that Linus almost certainly won't bother
actually reading the below, as he's already cast my posts on this
topic as "silly" and so on. I'm writing all this for the public
record, basically: I want it clearly on record that Linux developers
(which I assume included David Miller, involved in the emails below)
were *warned* about this problem, told to change their code and
how to properly read the documentation *months* ago, that Linus
himself continually and repeatedly ignores the same advice given
now and insists on continuing to tell the lie that egcs is the
source of the problem. It does *not* matter to me whether Linus
ever "gets" it, all things considered.
>Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
> rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807281242.FAA31050@dm.cobaltmicro.com>
> (davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>> Date: Tue, 28 Jul 98 08:36:39 EDT
>> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
>>
>> Inlining tells the compiler "for efficiency reasons, I'd like you to
>> do your best to inline this function", not "even if you do it wrong, I'd
>> like you to inline it".
>>
>>Then what does "extern inline" say?
>
>It says "if you can inline this function, great, but even if you can't,
>don't compile it as a separate function". E.g. if you compile without
>optimization, it doesn't get inlined.
>
>>Forget for a moment what you know about C and compiler implementation
>>details, and all of the issues surrounding this topic. And pretend
>>for a moment you are a programmer using GNU C to accomplish some task
>>and you wish to express something, and you find that GNU C allows you
>>to express this by saying:
>>
>>extern __inline__ check_a(int a)
>>{
>> __label__ here;
>>
>> if(my_test(a) != 0)
>> printf("Assertion on 'a' failed at %p\n", &here);
>
>(I think that should be `, &&here'.)
>
>>&&here:
>
>(I think that should be "here:".)
>
>>}
>>
>>Can you tell me that this does not seem like a useful construct or
>>feature? Can you also tell me that this is hard for the person
>>writing such code to understand? Which behavior of the above function
>>do you deem would be correct in any case?
>
>I'm confused -- what are the choices? I've already tried to construct
>an example showing the differences, and can't do so without resorting
>to bogosities like having some external code somehow depend upon
>the uniqueness, or value, of labels passed to it as `void *' arguments.
>(See below for an example.)
>
>>It depends, for standard C constructs, I can understand this
>>completely. For GNU C extensions, we can say whatever we like about
>>semantics wrt. inline functions, and in fact document them.
>
>I think we should first figure out whether the proposed semantics
>make good linguistic sense in the first place. When I first looked
>into this as a result of this discussion, I *thought* there were some
>very interesting issues here, but so far all I can find is places
>in the gcc docs where we could do a better job clarifying stuff
>most programmers would regard as "natural" for them (and perhaps
>in disagreement with each other).
>
>>This issue is different from most others, because it is an issue of
>>semantics when two different GNU C extensions are used together, so we
>>can define the semantics any way we wish to in such cases. I contend
>>that the current behavior makes the most sense and is the most useful
>>for users of GNU C (the fact that this behavior has been in known
>>active use for 4 or 5 years is a testament to this!).
>
>I'm still confused as to what the current behavior *is* that is
>being depended upon.
>
>My *guess* is that the current behavior is to try and inline functions,
>which is not always done. That's what the docs say (especially if you
>read carefully, and between the lines -- they could stand improving
>though).
>
>What exactly *breaks* when code like the examples you post aren't
>actually inlined by gcc? If it's just that you get unresolved
>references to the externals, well, that's what is *supposed* to happen,
>based on my reading of what `extern inline' means in gcc.
>
>If it's just that when the code doesn't get inlined, the application
>(Linux?) goes slower, well, that's not a linguistic or semantic
>issue -- even if the decision revolves around whether a construct
>like `&&foo' is present.
>
>If that's the case, then it's just a matter of the application no
>longer using `&&foo', or teaching gcc to change that decision again
>(but only when it's safe to do so, to preserve the semantics of
>the function), or teaching gcc a new construct meaning "*inline* this,
>dammit!", such as __force_inline__. Programmers would be responsible
>for any code-generation bugs resulting from their combining this
>specification with features gcc normally would detect as "I can't
>safely inline this".
>
>
>As far as how hard it is to tell what labels should really "mean",
>here's a contrived example:
>
>#include <stdio.h>
>
>void *
>f (void *arg)
>{
> static void *x = NULL;
> void *y;
>
> if (x == NULL)
> {
> x = arg;
> return arg;
> }
>
> y = x;
> x = arg;
> return y;
>}
>
>inline int
>myjump ()
>{
> __label__ bar;
> void *f();
> void *foo;
> static int myval = 1;
>
> foo = f(&&bar);
> goto *foo;
>
>bar:
> return myval++;
>}
>
>int
>main()
>{
> int i;
> int j;
> int k;
>
> i = myjump();
> j = myjump();
> k = myjump();
> printf ("%d %d %d\n", i, j, k);
> return 0;
>}
>
>Compiled using gcc 2.8.1 or egcs, without optimization, it prints
>"1 2 3", but with enough optimization to cause inlining, it prints
>"2 4 5" on my RH 4.2 Linux system, probably because the label
>feature is being abused (which gcc doesn't detect, but it does
>print "interesting" warnings about `i' and `j' when inlining, so
>perhaps it could detect this?).
>
>So, depending on the nature of code labels, vis-a-vis whether they're
>static a la variables, or static on a per-copy-of-function basis, seems
>to be unwise. Even though the gcc docs don't seem to explicitly disallow
>such use, they don't allow it either, and wise programmers wouldn't
>depend on such behavior. (Not only does the code above not work,
>but neither would depending on the equality of a `void *'-passed label
>determining whether the calling function was the same as some previous
>caller, or some such thing, be wise.)
>
>I suggest we revise the gcc docs regarding labels to clarify that
>any addresses of labels taken within a function during its invocation
>become invalid as soon as the function returns, just as is the case
>for passing `&a' given `int a;' within a function.
>
>We probably also should specify that comparing labels as addresses is
>not a reliable way to determine whether they refer to the same, or
>different, addresses. That is, &&foo and &&bar, even within a single
>function invocation with foo and bar being labels on different chunks
>of code, could evaluate to equal (gcc could place the generated code
>in the same place in memory, and use state info to disambiguate the
>code at run time), and perhaps even &&foo and another &&foo could
>yield different addresses within the same function (gcc could "flatten"
>programmer-visible state info into distinct code sequences, as long
>as it preserves the correctness of "goto *label;" following each
>corresponding "label = &&foo;").
>
>I think it's okay to allow passing &&label to another procedure, though,
>as long as the lifetime of that argument is the calling function
>invocation's lifetime, and the only use of the argument is to return
>the value back to the function or to print it out (or otherwise make
>it available) for debugging/logging purposes.
>
>Also, perhaps we should clarify the text on "inline" so readers know
>it is never safe to depend on inlining of any given function always
>happening. It's already said, but perhaps not clearly enough --
>some of the verbage seems to suggest otherwise in a few places, and
>not everyone reads the entire description before jumping to
>conclusions.
>
>In summary, I haven't seen any clear description of the semantic
>lossage being complained about, and can only guess that the problem
>is that gcc has decided to stop inlining something it used to inline,
>which is not great, but not a semantic problem, just an optimization
>issue that bare-to-the-metal coders must deal with on an ongoing
>basis. (To wit: if these functions hadn't *previously* been inlined
>due to their using &&foo, would the programmers have nevertheless
>used that feature, and given up the inlining, or given up &&foo?
>Either way, that's what they *can* do now, although ideally they
>shouldn't be made to choose. And they can macro-ize their way out
>of relying on &&foo, if they like.)
>
>I do wonder if a "pointer to `here'" feature might be useful in
>place of what I gather is a kludge to get some kind of pointer
>useful for debugging, logging, and so on. Perhaps `&& .' or
>`&& __label_here__' or similar could be reserved for that purpose,
>and be valid *only* as a `void *' that can be copied, printed, written
>to a file, etc., but not as the target of a `goto *x;' or any
>other pointer-like operation (++, +, -, ==, unary *, etc.).
>
> tq vm, (burley)
>Date: Tue, 28 Jul 1998 20:00:13 -0700
>From: "David S. Miller" <davem@dm.cobaltmicro.com>
>To: burley@gnu.org
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
> rth@cygnus.com, burley@gnu.org
>In-reply-to: <199807281536.LAA11100@melange.gnu.org> (message from Craig
> Burley on Tue, 28 Jul 1998 11:36:27 -0400 (EDT))
>Subject: Re: inline functions and local labels
>References: <199807281536.LAA11100@melange.gnu.org>
>
> Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
> From: Craig Burley <burley@gnu.org>
>
> I'm confused -- what are the choices? I've already tried to
> construct an example showing the differences, and can't do so
> without resorting to bogosities like having some external code
> somehow depend upon the uniqueness, or value, of labels passed to
> it as `void *' arguments. (See below for an example.)
>
>Craig, I apologize, I should have posted the code which behaves
>differently if not inlined (due to kenners patch) so that the behavior
>issue in question is more clear. There is a performance concern, but
>this is secondary compared to the loss in functionality change:
>
>extern __inline__ unsigned char *skb_put(struct sk_buff *skb, unsigned int len)
>{
> unsigned char *tmp=skb->tail;
> skb->tail+=len;
> skb->len+=len;
> if(skb->tail>skb->end)
> {
> __label__ here;
> skb_over_panic(skb, len, &&here);
>here: ;
> }
> return tmp;
>}
>
>We use this for debugging, and the debugging information becomes
>useless if the procedure is not inlined.
>
>Later,
>David S. Miller
>davem@dm.cobaltmicro.com
>Date: Wed, 29 Jul 1998 12:33:49 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
> rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807290300.UAA05668@dm.cobaltmicro.com>
> (davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>>Craig, I apologize, I should have posted the code which behaves
>>differently if not inlined (due to kenners patch) so that the behavior
>>issue in question is more clear. There is a performance concern, but
>>this is secondary compared to the loss in functionality change:
>[...]
>>We use this for debugging, and the debugging information becomes
>>useless if the procedure is not inlined.
>
>Ah, I think I get it now.
>
>What you *want* is to "dump" the address of the caller's reference
>to the current function, so the ability to quickly localize the
>cause of the problem is improved somewhat.
>
>What you're *using* to get this is something different, which sometimes
>amounts to the same thing (e.g. when the code is inlined), but
>sometimes doesn't (e.g. when it isn't).
>
>A new notation added to gcc might be handy here (a notation that
>would basically be of roughly the same class as __PRETTY_FUNCTION__,
>though it'd involve lower-level code-gen issues than that).
>
>But it seems to me it'd be more worthwhile to consider implementing
>a general way to print a limited stack backtrace, which is an issue
>outside the language definition, and would require less cruft in
>your code overall.
>
> tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990212095518.31280C-100000@penguin.transmeta.com >
@ 1999-02-12 14:50 ` craig
1999-02-12 17:28 ` Benjamin Scherrey
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: craig @ 1999-02-12 14:50 UTC (permalink / raw)
To: torvalds; +Cc: craig
>On 12 Feb 1999 craig@jcb-sc.com wrote:
>>
>> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
>> >to use gcc extensions, because I think they are worthwhile in the kernel.
>>
>> That means, like I already said, you have to be prepared for a very
>> bumpy ride. You've shown that you have trouble coping with that.
>
>Umm..
>
>I had no problems with gcc features for about six or seven years of Linux
>development. These things simply didn't use to happen: despite upgrading
>_major_ versions of gcc (when Linux started we were using gcc-1.40), for
>those six-seven years there weren't really any changes that I ever had
>problems with.
Which means, what, exactly? That you therefore can claim some kind
of *ownership* of the exact behavior of gcc in the presence of
all sorts of extensions, regardless of the degree to which they're
clearly specified and documented? Sorry, you *should* know better.
>There were tons of code generation bugs over time, but hey, I _expect_
>bugs, and while compiler bugs are sometimes really hard and nasty to find,
>I don't complain too much: I report them, and I tell people not to use
>certain versions. I may be grumpy for a while because I spent ages looking
>at a bug that didn't turn out to be mine, but I never get the feeling that
>I should really dislike the compiler people.
Given how you've treated the egcs developers lately, for daring to:
- Offer you a free compiler
- Offer you free upgrades
- Offer you free responses to bug reports
- Offer you free bug fixes
- Offer you free improvements to unclear documentation
- Offer you free advice as to how to improve your code to make
it more immune to likely changes to egcs code development
I think we're *all* grateful you don't feel you should actually
*dislike* us.
>The reason I have been complaining so much lately is that I think that the
>egcs development has lost that stability. Again, never mind code
>generation bugs, I'm talking about _interface_ stability. I've had much
>more problems in the last year than I had in the seven years preceding
>this.
Yet, that's *exactly* the kind of symptom I would *expect*, speaking
objectively, given the problems *I've* been claiming exist here.
In short, you're saying that you decided long ago to depend mightily
on particular implementation details of gcc, despite not having a
clear specification constituting a promise that those details would
not change in future versions of gcc.
For several years, as gcc development slowed down more and more, including
around two years when *no* major changes were made in released versions,
you experienced no problems.
Then, when the floodgates of development were opened, and development
increased to a heretofore-unknown level of activity, suddenly you
ran into nasty surprises as the (sometimes-obscure, like regparm)
extensions you relied upon stopped working as they used to.
Linus, there is *nothing* surprising in that, and *nothing* that
suggests the problem is due to the attitude of the egcs developers,
or the pace of egcs development. Even if egcs had been "perfectly"
developed in this regard, the results would have been better
documentation of the limitations of "extern inline" and addresses
of labels, which you probably wouldn't have noticed changed, and/or
vehemently disagreed with the "direction" in which egcs is going.
(By proof, I offer the fact that, now that we're fixing this, you're
*still* arguing.)
There are *plenty* of people who are quite happily continuing to use
egcs on their codes, as it evolves, because *they* wrote *their* codes
to properly use the pertinent languages. (To the extent they're
not happy with bugs, I suppose they're wondering why we're wasting
our time accommodating your use of obscure extensions when we could
be making specification-conforming code actually work in the first
place, go faster, be smaller, etc.)
>This may actually not be due to technical reasons as much as simply due to
>a different open development model - it may just be that more people see
>"partial" work, and some of that partial work breaks stuff. Fine - I like
>open development myself, and I use it. But when somebody complains to _me_
>that I broke old interfaces, I consider that a bug unless I have a very
>very strong technical reason to tell people that I simply _cannot_ support
>some old interface any more.
You cannot support the "extern inline" interface anymore, as a promise
that inlining will happen. There, I said it, others have said it,
and the strong technical reasons are that *gcc* will not promise it
to you, nor will any *other* compiler that undergoes any useful
development over the next 10-20 years.
>In contrast, on this list, when people complain that egcs breaks existing
>code, the answer is "shut up and live with it" - and then they Cc: me on
>the damn thing. And that's why I get so upset, and why these flame-wars
>erupt.
I didn't see those answers. FIrst thing *I* noticed was *your* flames.
If you want to send along a few pointers to the earlier posts, I
wouldn't mind reading them to see what you're talking about.
>"Shut up and live with it" is not a way of caring for your customers. And
>creating the best compiler in the world is not just about code generation:
>it's about supporting the people that use it, too.
I agree with that. I'm not claiming egcs is perfect in this regard.
What I *do* know is that you've caused many of us to burn lots of time
on what was a non-issue, long-ago dealt with, but ignored by,
apparently, at least one Linux developer in the past.
And if you think it is *our* job to support *you*, ask yourself how
many donations you've made to egcs developers lately, and compare
that to your recent tendencies (not just in this thread) to accuse
them of breaking your code and then not listening to their explanations
regarding how you can avoid these problems in the future.
>I could change my kernel interfaces and tell people that "shut up,
>recompile, and be happy". Trust me, that doesn't work when you have a
>serious project that you expect others to be serious about too. I make
>_damned_ sure that I don't break binaries, and when I do it by mistake I
>have egg on my face and I fess up to screwing up.
Look, I probably care more, and perhaps know more, about preserving
the integrity of interfaces to products like kernels and compilers
than most anyone on the egcs or Linux development teams. I say that
not so much because of my technical abilities vis-a-vis programming
(which aren't bad), but because of my understanding that you don't
*get* integrity of interfaces without *first* starting with a
solid design, specification, development, and *documentation* effort.
And I've got a pretty good understanding of what *those* entail,
and how rarely they're practiced in much of the software industry.
That's why I've taken the time to so *carefully* explain to you,
and others, exactly why your assumptions about "extern inline" are
wrong, and even if you manage to wrangle a promise about to preserve
them from some well-meaning egcs developers *today*, that promise
will someday be broken.
Yet, because I've *dared* cross the Great Linus Torvalds, you've
taken to trashing *my* posts as "silly", claim I'm posting "sh*t",
"crap", and so on.
There's not a *single thing* I've said in these posts that has been
shown to have been even remotely incorrect, aside from my realizing
I might have confused you and David Miller in the emails about
this issue six months ago. Much of what I said is valuable guidance
for people working on projects that have nothing to do with either
egcs or Linux, and represents the understanding I've gained by working
on OS, tool, interface, and compiler development and documentation
for nearly 30 years now.
But, to you, it means *nothing*, because you apparently don't value
actually using *documented interfaces* correctly in the first place,
meaning that if an interface isn't clearly specified, don't make
assumptions about it.
>On this list, nobody 'fesses up to screwing up any more. And that's sad.
>It makes the egcs project look less serious, and more like a bunch of
>people that just want to play at making a commercial-grade compiler.
We admitted the documentation needed improving. I *think* that has
happened already (if not, I'll do it myself). And we apparently
fixed the buglet that triggered the bugs in your code, so you can
ignore those for awhile longer if you want.
If that isn't admitting to screwing up, I don't know what is. I know
it isn't exactly *what* you think we should have admitted to. But
if we admitted that the whole problem was the the compiler needed
to *always* ensure inlining of "extern inline", you'd *love* that
response, pat us on the heads, and say "good jobs", but we'd have
implicitly made a promise we could not possibly keep down the road.
But it's *our* compiler. It's *our* documentation. It's *our*
language specification. Therefore, *we* get to decide which of
these are broken, when conflicts like this arise.
I'm pretty confident the right decision has been made. I'm absolutely
*certain* you haven't presented sufficient reasons, to date, to have
made a different decision.
And it's also quite clear you have *zero* respect for the decisions
made by us about our product. So if you like them, you're happy, and
if you don't, you flame us, and anybody like myself who comes along
and tries to explain them to you in more detail.
So all your PR efforts at trying to rah-rah us into being better
compiler developers don't amount to much, since we can all see
what you *really* care about: getting us to do exactly what you say,
without question, without thought, even if that includes making
promises we *know* we can't keep.
If you *really* value what we're doing here on the egcs project,
you'll not say *one more word* on this topic, except perhaps for
offering some pretty serious apologies, if you've got the integrity
to do that.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 3.0.6.32.19990212172337.0082de00@pop.netaddress.com >
@ 1999-02-12 15:31 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212152049.31280H-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 15:35 ` Linus Torvalds
1999-02-12 16:16 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 15:31 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Fri, 12 Feb 1999, Paul Derbyshire wrote:
>
> Uh... it kind of occurs to me that perhaps the simplest solution is just to
> actually use a macro there? Then you can be damn sure it will inline,
> because the preprocessor will have done it before egcs ever gets to see
> your sources. :-)
Doesn't anybody actually read what I'm saying?
Yes, I could have used a macro. I didn't, because:
- macro syntax sucks
- macros don't do type testing
- macros don't handle arguments with side effects nicely, so you have to
work around that in various ways.
which is why I _want_ to use "extern inline", because the compiler does
support the notion of inlining, and it's a very powerful notion. But it
does require that if you want to use it as a macro, the compiler had
better have some way of marking it important. I always read "extern" as
being that marker.
But if people tell me that I really can't, then I have to say that it just
sucks. It's useless for something where you really want to use it as a
macro, and that's a bad thing.
And yes, before people say that gcc documentation said that "extern
inline" was documented to be _almost_ like a macro, then instead of being
a language layer, please consider for a moment using your brains for
something else than syntax, and using them for asking yourself "what is
reasonable for a programmer"?
I took the "almost" to mean:
- there are differences between macros and inline functions. See above on
arguments with side effects.
- some functions fundamentally cannot be inlined due to purely technical
reasons, like recursion.
But obviously some people want to use it as a hedge against actually
having any sane use at all for "extern inline", but that, I think, makes
for a worse compiler.
Oh, well. People seem to care less about actually _using_ gcc features
than about coming up with excuses for why they don't work in a sane
manner.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 3.0.6.32.19990212172337.0082de00@pop.netaddress.com >
1999-02-12 15:31 ` Linus Torvalds
@ 1999-02-12 15:35 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212153140.31280I-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 16:16 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 15:35 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Fri, 12 Feb 1999, Paul Derbyshire wrote:
> 4: An __attribute__ ((always)) or __attribute__ ((once)) that is
> recursive or otherwise uninlinable generates an error, regardless
> of -Winline.
>
> Now, does this look like it'll make everybody happy?
I would be happy with this.
> The address-of-label is just used to generate displayed information? That
> simplifies things a lot.
Yes. And I realize that people don't like that, but the fact is that the
sane way of doing the same thing (and that wouldn't have been bitten by
the current problem in the first place) was to use the gcc intrisic
__builtin_return_address() inside the panic printout. That would have been
the right way of implementing the debugging (the panic printout just
prints out who called it), but it doesn't work correctly in most versions
of gcc, which is why we instead ended up using this really stupid code
snippet:
__label_ l;
l:
skb_under_panic(.., &&l);
which triggered the problem with newer versions of egcs.
> If the address is only taken right at the label
> itself, then it seems reasonable to make an inline __attribute__ ((always))
> label and label address situation work like this:
Agreed. That would work beautifully, and I wouldn't have to think that the
egcs people are just trying to make it difficult to do something
reasonable.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990212221225.22651.qmail@deer >
@ 1999-02-12 15:44 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212153656.31280J-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 16:02 ` Enough is enough... truce time. Re: kernel blah blah blah Paul Derbyshire
1 sibling, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 15:44 UTC (permalink / raw)
To: craig; +Cc: egcs
On 12 Feb 1999 craig@jcb-sc.com wrote:
>
> P.S. Yes, folks, I realize that Linus almost certainly won't bother
> actually reading the below
I actually do real the email I get. I just don't have time to answer all
of it. I've answered most of the relevant postings (but not all of the
contents) in this thread because I feel strongly that there _is_ a real
need to have what I call a "working inline" while you obviously don't
think so.
The emails you quote are from the previous time this happened. As now,
nobody actually suggested a good working way to do what we wanted to do
without just completely resorting to macros (and I've already explained
why I dislike macros).
What you suggested then isn't any better than what you're suggesting now:
implementing new features in gcc doesn't obviate the need to be able to do
the same thing with old code. And implementing a back-trace by hand is
architecture- and compiler-dependent, which is silly because when that
breaks due to compiler changes you'd just complain that we should do
something else. You can't have it both ways, Craig.
Face it: what Linux does is entirely reasonable, trying to get a backtrace
in a architecture-independent way. Yes, it bit us, but it was certainly
not an unreasonable thing to do.
Do you really think it's unreasonable to ask for some way of forcing
inlining, when the compiler obviously can do it? It doesn't have to be
"extern inline", if you're afraid of polluting a future standard
namespace.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212152049.31280H-100000@penguin.transmeta.com >
@ 1999-02-12 15:44 ` Zack Weinberg
[not found] ` < 199902122344.SAA28257@blastula.phys.columbia.edu >
1999-02-28 22:53 ` Zack Weinberg
1999-02-12 15:53 ` Paul Derbyshire
1999-02-12 19:00 ` craig
2 siblings, 2 replies; 180+ messages in thread
From: Zack Weinberg @ 1999-02-12 15:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
On Fri, 12 Feb 1999 15:31:05 -0800 (PST), Linus Torvalds wrote:
>And yes, before people say that gcc documentation said that "extern
>inline" was documented to be _almost_ like a macro, then instead of being
>a language layer, please consider for a moment using your brains for
>something else than syntax, and using them for asking yourself "what is
>reasonable for a programmer"?
For most uses, I think the existing behavior of "extern inline" is the
reasonable behavior. We use it heavily in libc - take a look at
string.h sometime (actually bits/string.h, bits/string2.h). That code
absolutely relies on the behavior of `inline if possible, otherwise
generate a reference to the real function'.
There is legitimate code where you must inline for correct behavior,
but it's rare enough that I think it's reasonable to do something
special, like an __attribute__ declaration. It's not surprising to
find examples of that in the kernel, which has to do more "strange
stuff" than user code.
zw
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212152049.31280H-100000@penguin.transmeta.com >
1999-02-12 15:44 ` Zack Weinberg
@ 1999-02-12 15:53 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-12 19:00 ` craig
2 siblings, 1 reply; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-12 15:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
At 03:31 PM 2/12/99 -0800, you wrote:
>Doesn't anybody actually read what I'm saying?
Yeah, but I read from word one to the end linearly like most mere mortals
rather than receiving the email into a direct neural interface and
apprehending the whole thing at a mental glance. ;-)
I hadn't encountered your objections to macros, re: type checking and
side effects, until after reading and responding to the section where you
wistfully longed for the days when inline functions behaved like macros. :-)
>which is why I _want_ to use "extern inline", because the compiler does
>support the notion of inlining, and it's a very powerful notion. But it
>does require that if you want to use it as a macro, the compiler had
>better have some way of marking it important. I always read "extern" as
>being that marker.
Apparently it no longer has that rule, which is why I suggested a new
marker or two; suggestions to which neither you nor the compiler gurus
appear to have responded yet.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 199902122344.SAA28257@blastula.phys.columbia.edu >
@ 1999-02-12 15:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 15:53 UTC (permalink / raw)
To: Zack Weinberg; +Cc: egcs
On Fri, 12 Feb 1999, Zack Weinberg wrote:
>
> For most uses, I think the existing behavior of "extern inline" is the
> reasonable behavior. We use it heavily in libc - take a look at
> string.h sometime (actually bits/string.h, bits/string2.h). That code
> absolutely relies on the behavior of `inline if possible, otherwise
> generate a reference to the real function'.
Ok. I think that what people have convinced me off is that I _will_ end up
changing the kernel to avoid this problem in the future. I apologize for
spamming the egcs lists on this issue - I don't actually like flame wars,
and I try to avoid them where possible (and sometimes I fail, like this
time - sorry).
I'm also sorry that almost nobody saw the point of having a macro-like
inline. I don't like duplicating code like in libc (where code duplication
makes sense - having a "official compiled sequence" to link against, with
a separate version for inlining for optimization). As it is, I guess
"extern inline" is just useless for what I wanted to do, and nobody seems
to have a good alternative that doesn't result in more flamage, so while
I'm disappointed I'll just shut up and lick my wounds.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Enough is enough... truce time. Re: kernel blah blah blah
[not found] ` < 19990212221225.22651.qmail@deer >
1999-02-12 15:44 ` Linus Torvalds
@ 1999-02-12 16:02 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 1 reply; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-12 16:02 UTC (permalink / raw)
To: craig; +Cc: egcs
Ohh....my...GOD.
*referee whistle blowing sound*
HEY. Lets have a truce here... no more mudslinging and general aggravated
shouting. I'd think that's beneath the station of the likes of Linus
Torvalds and the GCC/EGCS development gurus.
In "A Final Solution." I suggested some ways to change the compiler or
Linux or both to meet everyone's needs and leave everyone happy.
As for who's wrong, I don't think anyone is. There has been a
*misunderstanding* about the ambiguous phrase "like a macro" in the
documentation. Some took this fairly literally regarding faithfulness of it
being expanded inline; others took it to mean "like a macro when it is
inlinable". Chalk it up to ambiguous documentation, and let's bury the
hatchet. And to reiterate, there are 3 things that can be done.
1. Make the dox clearer about "extern inline".
2. Linus, if worse comes to worst, you may just have to replace one-
off inlines with macros, or at least use -Winline and jiggle it
until it inlines. This strikes me as rather unsatisfactory
however.
3. EGCS developers, if "extern inline" can't be and wasn't meant to
be what Linus had in mind after reading the dox for it, I suggest
adding an __attribute__ ((always)) that causes an error if the
function is not inlinable or a label address from a label inside
the function is used outside it and an __attribute__ ((once)) that
inlines a function where it's used, making an error if it's used
more than once; this means that the compiler can inline the
functions with these attributes without any worry that it will
lead to ambiguous references to addressed labels.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 3.0.6.32.19990212172337.0082de00@pop.netaddress.com >
1999-02-12 15:31 ` Linus Torvalds
1999-02-12 15:35 ` Linus Torvalds
@ 1999-02-12 16:16 ` craig
1999-02-28 22:53 ` craig
2 siblings, 1 reply; 180+ messages in thread
From: craig @ 1999-02-12 16:16 UTC (permalink / raw)
To: pderbysh; +Cc: craig
>Ah. I see your point about inline versus actual macros. Maybe the solution
>is this. First, 'extern inline' loses special significance[...]
It never actually had the special significance attributed to it, so
nothing would actually get lost.
>because of the standard likely covering the usage soon. On the other hand,
>GCC can add __attribute__ ((always)) as an extension that will force
>inlining of the function under well-determined conditions, specifically,
>that it is not recursive. (The same rule that governs whether a macro
>"inline function" will work properly.)
That's an awful lot of work for a very small amount of usefulness.
Why don't they just use unique IDs in the Linux source or, as I
recommended six months ago, output a short stack trace (say, two or
three frames), or some other such solution that is *appropriately*
outside the specification of a language like C?
>Now, does this look like it'll make everybody happy?
Even if somebody else did all the work, it'd make egcs a whole
lot harder to improve and maintain, for very little gain: the
ease of coding one particular type of application.
I don't see what would be achieved by increasing the complexity
of the C language supported by gcc that Linux developers couldn't
achieve just as well by some combination of:
- Using a more powerful preprocessor for their C source than
cpp (in addition to, or in lieu of, cpp)
- Post-processing the generated assembly, e.g. via a Perl tool,
to insert unique identifiers or other markers to make
debugging easier
The proposals you are making don't seem, to me, to belong in a
*language specification* for a language like GNU C. That's not
normally, by itself, a case for a veto, but when combined with
the complexity of the implementation of the features and the
extra burden it'd almost certainly add to maintainining egcs, I
think a veto would be the best solution. Especially since hardly
anyone other than Linux developers would need or want the features.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212153140.31280I-100000@penguin.transmeta.com >
@ 1999-02-12 17:21 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990212202016.0081bb30@pop.netaddress.com >
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-12 17:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
At 03:35 PM 2/12/99 -0800, you wrote:
>> If the address is only taken right at the label
>> itself, then it seems reasonable to make an inline __attribute__ ((always))
>> label and label address situation work like this:
>
>Agreed. That would work beautifully, and I wouldn't have to think that the
>egcs people are just trying to make it difficult to do something
>reasonable.
I'm sure they're just trying to make it difficult to cause egcs to generate
bad code, and didn't realize it'd accidentally step on some unusual code in
one particular place.
Getting them to fix __builtin_return_address would be even better since
your code is (to put it bluntly) a kluge to get around a wart in GCC to
begin with. But my suggestions sure look doable...I'm not exactly sporting
a PhD in compiler theory, but 15 years of programming experience must count
for something =)
Not only do they look doable, they also don't look tricky to implement... a
few lines added here and there should suffice. Probably a 24 hour job tops
to create a patch that will generate those attributes and give them the
appropriate behavior.
(At least for someone like me that spends hours behind a keyboard with a
six-pack of something strongly caffeinated... but unlike me knows a lot of
gcc internals and is experienced hacking gcc.)
Hopefully, we can now put the who's wrong and the who broke what code
arguments behind us and start actually correcting the problem in a sane and
rational manner worthy of the advanced hackers and assorted wizards that I
see here.
I just wish I could help in some way more substantial than pitching in some
needed levelheaded mediating and some ideas on how to fiddle EGCS and linux
to everyone's satisfaction. Without, that is, poring over egcs sources for
years and then tentatively submitting a patch someone here already familiar
with the egcs guts can probably produce in less than a week, and doing a
better job.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 14:50 ` craig
@ 1999-02-12 17:28 ` Benjamin Scherrey
1999-02-28 22:53 ` Benjamin Scherrey
[not found] ` < 19990212224331.22671.qmail@deer >
1999-02-28 22:53 ` craig
2 siblings, 1 reply; 180+ messages in thread
From: Benjamin Scherrey @ 1999-02-12 17:28 UTC (permalink / raw)
To: egcs; +Cc: craig, torvalds
Geez people lighten up! This is worse than the C++-in-kernel thread that
occurs in the linux list. I think we've identified what the issue is here
(right?). Now - who's the guy who makes the decision (Jeff?) and what's it going
to be?
I think Linus and company are slightly aware of what the egcs team has
provided and I don't think your recitation was intended to clarify his mind. This
"discussion" is only wasting my time and every one else's who attempts to keep up
with this list.
If the issue isn't completely understood by both sides yet perhaps Linus could
provide a couple of source examples (if he hasn't already - I haven't bothered to
read every tirade, err message in this thread) who's behavior has changed and an
egcs maintainer could either say "it will be fixed" or, at least, explain how one
might predict whether or not the code will inline as expected. The last I heard,
these computer things were still deterministic and truly random results were still
hard to generate...
flame out,
Ben Scherrey
craig@jcb-sc.com wrote:
> Which means, what, exactly? That you therefore can claim some kind
> of *ownership* of the exact behavior of gcc in the presence of
> all sorts of extensions, regardless of the degree to which they're
> clearly specified and documented? Sorry, you *should* know better.
>
> >There were tons of code generation bugs over time, but hey, I _expect_
> >bugs, and while compiler bugs are sometimes really hard and nasty to find,
> >I don't complain too much: I report them, and I tell people not to use
> >certain versions. I may be grumpy for a while because I spent ages looking
> >at a bug that didn't turn out to be mine, but I never get the feeling that
> >I should really dislike the compiler people.
>
> Given how you've treated the egcs developers lately, for daring to:
>
> - Offer you a free compiler
>
> - Offer you free upgrades
>
> - Offer you free responses to bug reports
>
> - Offer you free bug fixes
>
> - Offer you free improvements to unclear documentation
>
> - Offer you free advice as to how to improve your code to make
> it more immune to likely changes to egcs code development
>
> I think we're *all* grateful you don't feel you should actually
> *dislike* us.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com >
@ 1999-02-12 17:50 ` Jeffrey A Law
[not found] ` < 10147.918870502@hurl.cygnus.com >
1999-02-28 22:53 ` Jeffrey A Law
1999-02-12 19:01 ` craig
1 sibling, 2 replies; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-12 17:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Zack Weinberg, egcs
In message < Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com >yo
u write:
> I'm also sorry that almost nobody saw the point of having a macro-like
> inline. I don't like duplicating code like in libc (where code duplication
> makes sense - having a "official compiled sequence" to link against, with
> a separate version for inlining for optimization). As it is, I guess
> "extern inline" is just useless for what I wanted to do, and nobody seems
> to have a good alternative that doesn't result in more flamage, so while
> I'm disappointed I'll just shut up and lick my wounds.
Yea, the way this is handled (code duplication) is suboptimal, but it has been
the way the docs have suggested handling extern inline functions since at
least 1991.
This combination of inline and extern has almost the effect of a macro. The
way to use it is to put a function definition in a header file with these
keywords, and put another copy of the definition (lacking inline and extern)
in a library file. The definition in th header file will cause MOST calls
to the function to be inlined. If any uses of the function remain, then
will refer to the single copy in the library.
Emphasis on MOST added by me.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 3.0.6.32.19990212202016.0081bb30@pop.netaddress.com >
@ 1999-02-12 17:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212174436.31280N-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 17:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Fri, 12 Feb 1999, Paul Derbyshire wrote:
>
> Getting them to fix __builtin_return_address would be even better since
> your code is (to put it bluntly) a kluge to get around a wart in GCC to
> begin with. But my suggestions sure look doable...I'm not exactly sporting
> a PhD in compiler theory, but 15 years of programming experience must count
> for something =)
Well, __builtin_return_address() has actually worked for a longish time.
That's kind of the secondary problem: I'd love to track new releases and
use new features when they come out, but I can't. Even if _I_ switch to a
new compiler, few other people will, and then I get bug-reports with the
old stuff - reports that are useless because the data they report is just
bogus.
Most of these debugging things are not something that developers ever see
themselves - this one hasn't triggered in a _long_ time for anybody that I
can recall. It used to trigger under some very specific circumstances
(using IPIP tunnelling with certain other combinations, for example), and
exactly because the developers couldn't easily reproduce them they have
extra code to pinpoint exactly where they happen.
So in this case what I'm just probably going to do it to remove the
particular backtrace debugging code, because we no longer need it (it's
quite old, and doesn't trigger - and if it ever starts to be a problem we
can introduce something else).
The problem for me is that if I really have to create duplicates of all
"extern inline" functions, the while thing is completely useless to me. It
does _not_ act "almost as a macro" any more, it acts almost completely
differently.
So then I can't use it for anything else either. And the reason we
switched away from using "static inline" for these things was that some
versions of gcc complain loudly about "xxxx was declared static but was
never used", which is really aggravating, because this is in header files
that you should be able to include _without_ having to use every single
function you happened to have exposed to you.
See my problem? "extern inline" is useless, and "static inline", while
working (because even if gcc doesn't inline it will actually create the
function for you), is really obnoxious with certain gcc versions.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 10147.918870502@hurl.cygnus.com >
@ 1999-02-12 18:01 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212175435.31280O-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 18:01 UTC (permalink / raw)
To: law; +Cc: Zack Weinberg, egcs
On Fri, 12 Feb 1999, Jeffrey A Law wrote:
>
> Yea, the way this is handled (code duplication) is suboptimal, but it has been
> the way the docs have suggested handling extern inline functions since at
> least 1991.
Note that "static inline" is fine for me, if it 99% of the time is
honoured: even if the thing is sometimes statically compiled a few extra
times, who cares because it's not going to be a big issue.
However, then we get people with compiler warnings. I don't remember which
particular version of gcc it was that warns about "static but not used"
(it's not the one I use, but it was one reason why we switched over
whole-sale to "extern inline" in header files). That gcc may be rare
enough that we can just make sure nobody uses it any more.
If I were to do that, I'd at least ask the egcs people to add to their
regression suite a testcase like this:
static inline int unused_fn(int dummyarg)
{
return dummyarg*dummyarg;
}
int main(int argc, char **argv)
{
return 0;
}
and the test-suite would be compiled with "-Wall -Werror" so that nobody
ever makes it a warning to not use a "static inline" thing?
Then I could just ignore "extern inline", or maybe use it if I ever want
to re-introduce the skb_put() kind of "must be inlined to get correct
debugging information" thing for some hack.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212174436.31280N-100000@penguin.transmeta.com >
@ 1999-02-12 18:02 ` Zack Weinberg
[not found] ` < 199902130202.VAA28998@blastula.phys.columbia.edu >
1999-02-28 22:53 ` A final solution. (Was Re: kernel-2.2.1-undefined references.) Zack Weinberg
1999-02-12 18:13 ` Mark Mitchell
1 sibling, 2 replies; 180+ messages in thread
From: Zack Weinberg @ 1999-02-12 18:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
On Fri, 12 Feb 1999 17:53:50 -0800 (PST), Linus Torvalds wrote:
>
>
>On Fri, 12 Feb 1999, Paul Derbyshire wrote:
>>
>> Getting them to fix __builtin_return_address would be even better since
>> your code is (to put it bluntly) a kluge to get around a wart in GCC to
>> begin with. But my suggestions sure look doable...I'm not exactly sporting
>> a PhD in compiler theory, but 15 years of programming experience must count
>> for something =)
>
>Well, __builtin_return_address() has actually worked for a longish time.
>
>That's kind of the secondary problem: I'd love to track new releases and
>use new features when they come out, but I can't. Even if _I_ switch to a
>new compiler, few other people will, and then I get bug-reports with the
>old stuff - reports that are useless because the data they report is just
>bogus.
In this particular case, you could use conditional compilation based
on __GNUC_MINOR__. All the compilers that miscompile the
address-of-label hack do __builtin_return_address correctly, as I
understand it.
>The problem for me is that if I really have to create duplicates of all
>"extern inline" functions, the while thing is completely useless to me. It
>does _not_ act "almost as a macro" any more, it acts almost completely
>differently.
I don't think you have to do that. You can carry on using "extern
inline" as you have been. If there's no other definition of a
particular function and gcc fails to inline it, you'll get a link
error, and then you can track down why that particular function
doesn't inline and tweak it or submit bugreports.
Or you can isolate the inline functions in their own header file, and
have a separate C file that just does
#define inline /* nothing */
#include <linux/inlinefuns.h>
No code duplication, and if all the inlines went through, the linker
will throw away the unnecessary object module.
zw
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212174436.31280N-100000@penguin.transmeta.com >
1999-02-12 18:02 ` Zack Weinberg
@ 1999-02-12 18:13 ` Mark Mitchell
1999-02-28 22:53 ` Mark Mitchell
1 sibling, 1 reply; 180+ messages in thread
From: Mark Mitchell @ 1999-02-12 18:13 UTC (permalink / raw)
To: torvalds; +Cc: pderbysh, egcs
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
Linus> The problem for me is that if I really have to create
Linus> duplicates of all "extern inline" functions, the while
Linus> thing is completely useless to me. It does _not_ act
Linus> "almost as a macro" any more, it acts almost completely
Linus> differently.
Why not put the inlines in a header file, and #include them (with
suitable macros to make the `extern inline' go away) in a .c file?
For example:
foo.h
-----
#ifndef EXTERN_INLINE
#define EXTERN_INLINE extern inline
#endif
EXTERN_INLINE int foo () { return 1; }
foo.c
-----
/* I bet `foo' will always be inlined, but just in case, and for
debugging, we provide an out-of-line version here. Put me in an
archive, so that I am only linked if if every occurrence of foo
is not inlined. */
#define EXTERN_INLINE
#include "foo.h"
I know this might require a bit of reorganization, but it is without a
doubt the idiom that GCC's documentation has explicitly endorsed for
quite some time.
Conflicts with C9X are another matter, of course, but you can be quite
sure that GCC will suport the C89+GNU dialect for quite some time to
come, I think. (I know that you might take objection to that last
statement w.r.t. your recent address-of-label/inline experience, but
let's not get into that. I think you know what I mean.)
By the way, I bet that you will at some point have to declare that the
kernel cannot be compiled with a GCC version older than `X' for some
`X', especially if you use anything other than straight ANSI C. After
all, those old versions had different bugs than current versions, and
you're quite likely to see different code-generation problems. You
say that using new features of GCC would cause people to complain when
old compilers failed to compile the code, or silently generated bad
code, but you could avoid that with
#if __GNUC__ <= 2 || __GNUC_MINOR__ <= XXX
#error "Your compiler is too old to compile this kernel."
#endif
I bet people would understand. But, you're a lot more in touch with
the people building kernels than I am, so I'll defer to your opinion.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 199902130202.VAA28998@blastula.phys.columbia.edu >
1999-02-12 18:24 ` Joern Rennecke
@ 1999-02-12 18:24 ` Linus Torvalds
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 21:02 ` Removing code dupe in libc (Was: A final solution...) Paul Derbyshire
2 siblings, 1 reply; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 18:24 UTC (permalink / raw)
To: Zack Weinberg; +Cc: egcs
On Fri, 12 Feb 1999, Zack Weinberg wrote:
>
> Or you can isolate the inline functions in their own header file, and
> have a separate C file that just does
>
> #define inline /* nothing */
> #include <linux/inlinefuns.h>
>
> No code duplication, and if all the inlines went through, the linker
> will throw away the unnecessary object module.
We used to do things this way for string operations, because gcc used to
do some of the string operations on its own (memcpy etc), and we wanted to
use the same ones we had in <asm-i386/string.h>.
It's _really_ painful if it ever happens, because the linker doesn't know
how to extract just one function from the object file, and you end up with
one big object file that contains all of it. I really want to avoid this
kind of approach (a lot of the header files depend on each other, so the
above would get just about every single inline function in the whole
kernel, ugh).
So no, you don't want to do it like the above - it works, but not very
well.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 199902130202.VAA28998@blastula.phys.columbia.edu >
@ 1999-02-12 18:24 ` Joern Rennecke
1999-02-28 22:53 ` Joern Rennecke
1999-02-12 18:24 ` Linus Torvalds
1999-02-12 21:02 ` Removing code dupe in libc (Was: A final solution...) Paul Derbyshire
2 siblings, 1 reply; 180+ messages in thread
From: Joern Rennecke @ 1999-02-12 18:24 UTC (permalink / raw)
To: Zack Weinberg; +Cc: torvalds, egcs
> Or you can isolate the inline functions in their own header file, and
> have a separate C file that just does
>
> #define inline /* nothing */
> #include <linux/inlinefuns.h>
That's only good if all these functions are needed at least once in non-inline
form, or if they are so small to be neglegible.
To get a library where you only link the stuff that you need, you could
either put each function in it's own file, with EXTERN_INLINE in the
declaration and compiler with -DEXTERN_INLINE= , and then in the header file
use something like:
#define EXTERN_INLINE extern inline
#include "foo.c"
#include "bar.c"
...
Or you could use a scheme like in libgcc2.c to compile a large file one
function at a time, but slightly modified so that you can use it as a
header file too. That is good when you have a lot of small functions
and the header needs to be included often - building the library takes
a bit longer, but you safe a lot of time when using the file as a header
file.
#ifndef EXTERN_INLINE
#define HEADER
#define EXTERN_INLINE extern inline
#endif
#if defined(FOO) || defined(HEADER)
EXTERN_INLINE foo() {...}
#endif
#if defined(BAR) || defined(HEADER)
EXTERN_INLINE bar() {...}
#endif
...
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212152049.31280H-100000@penguin.transmeta.com >
1999-02-12 15:44 ` Zack Weinberg
1999-02-12 15:53 ` Paul Derbyshire
@ 1999-02-12 19:00 ` craig
1999-02-28 22:53 ` craig
2 siblings, 1 reply; 180+ messages in thread
From: craig @ 1999-02-12 19:00 UTC (permalink / raw)
To: torvalds; +Cc: craig
>Yes, I could have used a macro. I didn't, because:
> - macro syntax sucks
> - macros don't do type testing
> - macros don't handle arguments with side effects nicely, so you have to
> work around that in various ways.
I'd like to add the following item more clearly than I've expressed
it, buried in my previous emails:
- macros don't guarantee inlining of the sort Linus probably wants
(They might *today*. They probably won't in future versions of gcc.)
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < Pine.LNX.3.95.990212153656.31280J-100000@penguin.transmeta.com >
@ 1999-02-12 19:01 ` craig
[not found] ` < 19990213011316.23309.qmail@deer >
1999-02-28 22:53 ` craig
0 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-12 19:01 UTC (permalink / raw)
To: torvalds; +Cc: craig
>The emails you quote are from the previous time this happened. As now,
>nobody actually suggested a good working way to do what we wanted to do
>without just completely resorting to macros (and I've already explained
>why I dislike macros).
But, even if Linux developers didn't consider any of the proposals
as "a good working way", that didn't mean they were free to ignore
the *warnings*, which accompanied the proposals, about the dangers
of continuing to rely on the extensions in question as they were doing.
(BTW, I dislike macros too. C is just too weak a language to get
much done without them, though. I had high hopes for C++ around
10 years ago, but....)
>What you suggested then isn't any better than what you're suggesting now:
>implementing new features in gcc doesn't obviate the need to be able to do
>the same thing with old code. And implementing a back-trace by hand is
>architecture- and compiler-dependent, which is silly because when that
>breaks due to compiler changes you'd just complain that we should do
>something else. You can't have it both ways, Craig.
Of course, the code to do a limited back-trace would have to be part
of the system-specific, perhaps even compiler-specific, code that
pretty much any OS has. I didn't imagine otherwise -- sorry if you
thought I was saying gcc somehow offered a feature to portably
obtain stack-trace information!
I do think there might be some feasability, depending on what it
is you're trying to accomplish *generally*, in the idea of
special pre-processing and/or post-processing of the source code
and assembler output. It wouldn't be portable, but it might be
much more robust than anything we can feasibly do for you, and
more responsive to changes whenever your needs change, making your
project more tolerant of changes to gcc (for example).
But I don't know enough about what you need, on the whole, to really
offer any specific suggestions at this point. I can only guess.
And that's part of why I, personally, would tend to resist adding
a new feature because you say it'll help you. Not to be disrespectful
to you specifically, but generally, I find it is often the case
that a user asking for a new feature, in a situation where I don't
fully understand their need for it, won't find that new feature
completely addresses their problem, once I implement it. So they'll
come back and ask for yet another new feature, to address the corner
cases or whatever they didn't previously think about.
In the end, if I'm not careful, I'll implement a handful of features
just for that kind of customer that are increasingly difficult for
users to really make good use of, hard for me to maintain, and which
don't really fully address the original problem.
>Face it: what Linux does is entirely reasonable, trying to get a backtrace
>in a architecture-independent way. Yes, it bit us, but it was certainly
>not an unreasonable thing to do.
I wouldn't call it "unreasonable". But I think the implementation
of something like this should have been much more carefully studied
up-front, and/or, upon discovering it didn't always work if the
compiler had subtle changes made to it, an alternative quickly
looked-for, rather than blaming the compiler for changing. (Though,
I still believe, we like to *know* when buglets like this creep in,
e.g. stuff stops inlining that really should inline in a reasonable
compiler.)
That relates back to my point about tolerances. *We* want to know
when our compiler gets *near* the boundaries of its published
tolerances (and certainly when it exceeds those boundaries), but
we also want people to use it in ways that *accommodate* those published
tolerances, rather than assuming we'll always be able to keep it
within some unpublished, tighter tolerances. Of course, they
can choose to ignore our advice, but they have to understand that
our priorities usually put bringing the compiler to *within* published
tolerances higher than *tightening* the compiler's tolerances
(which constitutes a promise of future performance and behavior).
This means you might get no help from the compiler doing what you
need. That's unfortunate, but not necessarily the fault of the
compiler -- it might just mean the problem is better solved outside
the arena of the generation of optimized code from an "as if" language
like C.
>Do you really think it's unreasonable to ask for some way of forcing
>inlining, when the compiler obviously can do it? It doesn't have to be
>"extern inline", if you're afraid of polluting a future standard
>namespace.
I think the complexity of just figuring out what exactly is *meant*
by "forcing inlining" probably greatly exceeds the benefits of
doing that, implementing the resulting specification, and maintaining
the it down the road. For example, just how many copies of a
given invocation of inlined code end up in RAM; whether a
short-call interface may be used for inline code to quickly gain free
registers in a register-window machine like SPARC; whether
addresses of static variables are guaranteed to be unique across
all of the inlining "sites"; whether visible code-generation differences
between an inlined "maybe inline" and "always inline" would be permitted...
these would need to be nailed down, and not just by looking at the current
implementation, but by looking at what might be appropriate in the future,
for new architectures, such as massively parallel machines,
"massively serial" machines, etc.
Further, as I said in another post, which perhaps didn't go directly
to you, the C language upon which GNU C is based follows the "as if"
rule. Much of the implementation of gcc assumes the "as if" rule.
Every extension and command-line option added to work around the "as if"
rule tends to not work very well and make gcc less maintainable
overall.
And, the "force inlining" phrase almost certainly connotes the idea
that "I don't mean *as if*, I mean *do exactly what I say*". Though
there's no consensus likely to emerge anytime soon on exactly *what*
is meant by that, in implementation terms that make sense across
all current and future processors targeted by gcc. (Please don't
say "it just means compile the code in line". That means almost
*nothing*, just as "inline" itself means almost nothing! For
your purposes, you'd need to offer exactly what visible semantics
you expect to take hold when forcing inline over not forcing inline,
or not inlining.)
In that sense, frankly, even if you *did* like using macros, you
wouldn't get a 100% guarantee of inlining, just like you wouldn't
when using any form of "inline". That is, the compiler is free
to implement your repeated macro invocations as calls to a single
procedure, as long as they worked "as if" they were simply
code-generated as you'd currently expect. Who knows, `-Os' might
someday be able to do that sort of thing, and people would certainly
want it to be able to.
I won't speak for the gcc developers who'll probably make the
decisions, but it's generally not wise to introduce extensions
outside the "zeitgeist" of a product just to satisfy a single
customer. Even if you make that customer happy, it will be
only for the short term, in almost every case. And I think the
"zeitgeist" for gcc is, despite a plethora of apparently "as-if-less"
extensions, strongly along "as if" lines.
So, is it "unreasonable" to ask for this? No. It's not unreasonable
for us to say "no", either, though. If you haven't studied all
the code that gets involved in making inlining work, and making
subsequent processing phases properly account for inlining (in
terms of producing correct debugging info and so on), you might
take a moment to do so -- and then you might see while, on the whole,
it could indeed be unreasonable for us to decide to offer the
feature, even based just on how gcc *currently* does inlining and
ignoring how and when it might do so in the future.
But, that's for us to decide. Even if *we* decide it's unreasonable
to provide the feature, that does *not* mean, IMO, that it's
unreasonable for you to ask for it. Your job isn't to think
about the long-term viability of gcc, although I think we prefer
it when users give that some consideration *before* asking for
new features.
After all, it seems that much of this current debate stems from
one particular extension -- addresses of labels -- that seemed
entirely "reasonable" to add, long ago, and which has proved
handy, on occasion. I think it's likely that the difficulties
that extension has caused exceeds the benefits it granted, compared
to if it hadn't been introduced in the first place. (Maybe a
more Fortran-like feature, a quite simple but limited form,
would have been a better alternative, though even Fortran's
assigned GOTO has caused lots of pain over the decades. And
it wouldn't have been useful for the skb_put type of case.)
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com >
1999-02-12 17:50 ` Jeffrey A Law
@ 1999-02-12 19:01 ` craig
[not found] ` < 19990213003025.23197.qmail@deer >
1999-02-28 22:53 ` craig
1 sibling, 2 replies; 180+ messages in thread
From: craig @ 1999-02-12 19:01 UTC (permalink / raw)
To: torvalds; +Cc: craig
>I'm also sorry that almost nobody saw the point of having a macro-like
>inline.
Oh, I think *that* point was plenty clear, and certainly has a lot
going for it, in isolation. I happen to think adding a feature
to support it is probably more expensive, in the long run, than it's
worth, but perhaps having a site-specific attribute corresponding
directly to `-Winline', meaning "okay to not inline as long as a
warning is issue", wouldn't be too much.
>I don't like duplicating code like in libc (where code duplication
>makes sense - having a "official compiled sequence" to link against, with
>a separate version for inlining for optimization). As it is, I guess
>"extern inline" is just useless for what I wanted to do, and nobody seems
>to have a good alternative that doesn't result in more flamage, so while
>I'm disappointed I'll just shut up and lick my wounds.
One of the problems is that C doesn't have modules a la Fortran 90 and
Ada. So you have to resort to putting stuff like this (a function
for which "extern inline" is appropriate) in source code *and* in a
header file, which, to make for only one copy, means one #include file
that both the header and the .c file #include.
I'd recommend macros combined with statement expressions, but I don't
know that statement expressions are really robust enough yet, or
if they ever will be. (And I'm not saying they're all that well
designed, or that they, or even macros, will always guarantee the
inlining you seem to want.)
Also, I don't think you can get the same degree of argument type-
checking via a statement expression within a macro as via a
function.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Removing code dupe in libc (Was: A final solution...)
[not found] ` < 199902130202.VAA28998@blastula.phys.columbia.edu >
1999-02-12 18:24 ` Joern Rennecke
1999-02-12 18:24 ` Linus Torvalds
@ 1999-02-12 21:02 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990213000128.0089c2a0@pop.netaddress.com >
1999-02-28 22:53 ` Paul Derbyshire
2 siblings, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-12 21:02 UTC (permalink / raw)
To: egcs
At 09:02 PM 2/12/99 -0500, you wrote:
>Or you can isolate the inline functions in their own header file, and
>have a separate C file that just does
>
>#define inline /* nothing */
>#include <linux/inlinefuns.h>
>
>No code duplication, and if all the inlines went through, the linker
>will throw away the unnecessary object module.
That same technique might be usable to remove the code duplication wart
with libc. The object module generated goes in libc.a; the linker will
ignore it if all the functions used inlined.
For dynamic linked implementations, the object module goes in libc.so and
the dynamic linker will ignore it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990212224331.22671.qmail@deer >
@ 1999-02-12 21:08 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990213000806.008529f0@pop.netaddress.com >
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-12 21:08 UTC (permalink / raw)
To: egcs
Christ Craig, give it a rest. This is a dead horse you're beating. Some
reasonable sane and rational suggestions for solving the problems both with
Linux and egcs have appeared; someone's found that a conditional compile
can be used to make the extern inline thing compile and work on every gcc
by either using __builtin_return_address or the label hack; Linus has said
the panic code isn't too critical anyways and has apologized for some of
the tirades earlier in the week; and it seems to be high time this issue
was let drop on the list; yet I keep seeing more tirades from you every few
minutes to an hour.
BTW, did you know that your ISP's mail server was bouncing mail
inexplicably all afternoon? Was bouncing messages with "Service
unavailable". Never heard of downtime causing mail to bounce before;
usually it's deferred. You should have a few stern words with your ISP's
customer service reps about this; if the downtime had been much longer the
bounces would have caused yo to be removed from this list and any others
you're on more than likely. They should just defer the mail.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Removing code dupe in libc (Was: A final solution...)
[not found] ` < 3.0.6.32.19990213000128.0089c2a0@pop.netaddress.com >
@ 1999-02-12 21:14 ` Zack Weinberg
[not found] ` < 199902130514.AAA00047@blastula.phys.columbia.edu >
1999-02-28 22:53 ` Zack Weinberg
0 siblings, 2 replies; 180+ messages in thread
From: Zack Weinberg @ 1999-02-12 21:14 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Sat, 13 Feb 1999 00:01:28 -0500, Paul Derbyshire wrote:
>At 09:02 PM 2/12/99 -0500, you wrote:
>>Or you can isolate the inline functions in their own header file, and
>>have a separate C file that just does
>>
>>#define inline /* nothing */
>>#include <linux/inlinefuns.h>
>>
>>No code duplication, and if all the inlines went through, the linker
>>will throw away the unnecessary object module.
>
>That same technique might be usable to remove the code duplication wart
>with libc. The object module generated goes in libc.a; the linker will
>ignore it if all the functions used inlined.
>For dynamic linked implementations, the object module goes in libc.so and
>the dynamic linker will ignore it.
Actually, there isn't code duplication in libc. The inline functions
in the headers are limited in what they'll do themselves, they fall
back to out-of-line calls for the general case. This is done with an
ungodly mess of macros, special-case-only functions, and compiler
extensions. We rely on cse to crush out the mess.
I do wish there was a cleaner way to do it. Replacing cpp with M4
wouldn't be a bad start...
zw
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212175435.31280O-100000@penguin.transmeta.com >
@ 1999-02-12 23:48 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 1 reply; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-12 23:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Zack Weinberg, egcs
In message < Pine.LNX.3.95.990212175435.31280O-100000@penguin.transmeta.com >yo
u write:
> If I were to do that, I'd at least ask the egcs people to add to their
> regression suite a testcase like this:
[ ... ]
Agreed and done.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990213011316.23309.qmail@deer >
@ 1999-02-13 1:22 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 1 reply; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-13 1:22 UTC (permalink / raw)
To: egcs
>(BTW, I dislike macros too. C is just too weak a language to get
>much done without them, though. I had high hopes for C++ around
>10 years ago, but....)
But... what?
C++ is great. Templates, consts, ... no more macros exceptto
controlcompilation.
Now we just have to sit and wait for a compiler to come out that finally
supports the standard completely, from the standard library (including
<limits>) down to proper template linkage. Which some experimental egcs
snapshot is purportedly able to do.
[some deletia]
He didn't want lots of new features. He didn't even want a cross vendor
portable way to get a stack trace. He just wanted a way portable across GCC
implementations to get a stack trace.
>...new architectures, such as massively parallel machines,
>"massively serial" machines, etc.
"Massively serial"? By which you mean what, with thousands of cpu
registers, or terahertz clock rate, or...?
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Removing code dupe in libc (Was: A final solution...)
[not found] ` < 199902130514.AAA00047@blastula.phys.columbia.edu >
@ 1999-02-13 1:26 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990213042627.008c0960@pop.netaddress.com >
1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-13 1:26 UTC (permalink / raw)
To: egcs
>I do wish there was a cleaner way to do it. Replacing cpp with M4
>wouldn't be a bad start...
M4?
WTH?
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 3.0.6.32.19990213000806.008529f0@pop.netaddress.com >
@ 1999-02-13 7:24 ` craig
[not found] ` < 19990213152402.25468.qmail@deer >
1999-02-28 22:53 ` craig
0 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-13 7:24 UTC (permalink / raw)
To: pderbysh; +Cc: craig
>Christ Craig, give it a rest. This is a dead horse you're beating. Some
>reasonable sane and rational suggestions for solving the problems both with
>Linux and egcs have appeared; someone's found that a conditional compile
>can be used to make the extern inline thing compile and work on every gcc
>by either using __builtin_return_address or the label hack; Linus has said
>the panic code isn't too critical anyways and has apologized for some of
>the tirades earlier in the week; and it seems to be high time this issue
>was let drop on the list; yet I keep seeing more tirades from you every few
>minutes to an hour.
Yet, later, you followed up one of my "tirades" offering your own
opinions. I guess it's okay if I don't respond to that?
Be aware that __builtin_return_address probably will stop working
someday in gcc. Read my latest tirade to get an idea of why that is.
>BTW, did you know that your ISP's mail server was bouncing mail
>inexplicably all afternoon? Was bouncing messages with "Service
>unavailable". Never heard of downtime causing mail to bounce before;
>usually it's deferred. You should have a few stern words with your ISP's
>customer service reps about this; if the downtime had been much longer the
>bounces would have caused yo to be removed from this list and any others
>you're on more than likely. They should just defer the mail.
Do you have any bounced email to forward along, so I can see what
was actually happening? That's the first thing my ISP would
ask for, probably.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990213152402.25468.qmail@deer >
@ 1999-02-13 10:47 ` Joe Buck
[not found] ` < 199902131846.KAA25341@atrus.synopsys.com >
1999-02-28 22:53 ` Joe Buck
1999-02-14 9:08 ` Paul Derbyshire
1 sibling, 2 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-13 10:47 UTC (permalink / raw)
To: craig; +Cc: pderbysh, egcs
> Be aware that __builtin_return_address probably will stop working
> someday in gcc. Read my latest tirade to get an idea of why that is.
Craig, gcc is the GNU project's compiler. That means that one of its
important roles is to be able to compile kernels (Linux or the Hurd).
Since you're the Fortran guy, you are somewhat insulated from these
issues (Fortran just doesn't make provisions for writing "close to the
machine" code).
The result is that gcc is going to have to continue to support certain
extensions for the indefinite future (though kernel developers should
not assume that "it worked in version x.y.z" is a commitment for the
future, we will need to supply some mechanisms in some cases.
It may actually be easier to support features like this if they are
specified at a higher level of abstraction. That is, understand why Linus
is using some trick to do something, and then recommend alternative ways
to do them that are actually supportable. e.g. if the real job is to get
a stack trace, maybe there could be some facility to provide for that
directly, possibly borrowing some code from gdb.
Despite Linus's tendency to be insulting, he is one our most important
"customers" (or, more accurately, the people who depend on the Linux
kernel working are). We need to have sufficient facilities so that C plus
inline assembly can do the whole job.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902131846.KAA25341@atrus.synopsys.com >
@ 1999-02-13 13:03 ` craig
[not found] ` < 19990213205319.19426.qmail@deer >
1999-02-28 22:53 ` craig
0 siblings, 2 replies; 180+ messages in thread
From: craig @ 1999-02-13 13:03 UTC (permalink / raw)
To: jbuck; +Cc: craig
>> Be aware that __builtin_return_address probably will stop working
>> someday in gcc. Read my latest tirade to get an idea of why that is.
>
>Craig, gcc is the GNU project's compiler. That means that one of its
>important roles is to be able to compile kernels (Linux or the Hurd).
>Since you're the Fortran guy, you are somewhat insulated from these
>issues (Fortran just doesn't make provisions for writing "close to the
>machine" code).
Actually, I'm not talking as the "Fortran guy". I'm talking as someone
who understands operating systems development and computer-architecture
issues better than he understands Fortran compiler development.
And, note, C doesn't really make provisions for writing "close to the
machine" code any better than Fortran. It provides a *model* that
more closely parallels many of today's most popular architectures,
making it more "obvious" to today's programmers that a straightforward
translation is possible, but *nothing* in the C standard, aside
from stuff like `volatile' (assuming that's even in the standard),
says anything about the mapping to the underlying machine. But the
"as if" rule means you can't just *assume* the machine will behave
a certain way when running C code.
(I've worked on operating systems written in Fortran, assembler, and
PL/1, but no C, by the way.)
I've written on this range of topics, especially involving C, C++,
Fortran, and operators, on USENET many times in the past, so I don't
think it behooves anyone to go into more details. I'll just disagree
with the assertion and leave it at that, noting that the way Fortran
offers similar *effects* as almost all of C's facilities does, usually,
require somewhat more typing. :)
>The result is that gcc is going to have to continue to support certain
>extensions for the indefinite future (though kernel developers should
>not assume that "it worked in version x.y.z" is a commitment for the
>future, we will need to supply some mechanisms in some cases.
Oh, I agree. I'm not saying that feature *will* stop working, just
that, at some point in the future, when gcc is *expected* to support
high-performance platforms like massively parallel machines, it will
either have to stop returning anything other than 0 from that
function in many cases, or the mere use of that function will
mandate a substantial drop in performance of the compiled code,
if my guesses about future directions of computing are correct (and
they're hardly controversial).
If that substantial drop happens, the users who notice it will
complain saying "it stopped working", is my prediction.
>It may actually be easier to support features like this if they are
>specified at a higher level of abstraction. That is, understand why Linus
>is using some trick to do something, and then recommend alternative ways
>to do them that are actually supportable. e.g. if the real job is to get
>a stack trace, maybe there could be some facility to provide for that
>directly, possibly borrowing some code from gdb.
Exactly. Doing that is pretty hard, but I think it's better to try
and do it up front, offer the most SWYM-like ways for people like
Linus to express themselves, and support *that* as well as possible.
(After all, what the heck *is* a "stack trace", precisely defined,
and exactly how does "getting" it help Linux developers? As soon
as you start answering by talking about frame and stack pointers,
you've headed off the SWYM reservation and are assuming a particular
machine model for gcc to permanently cater to, at the expense of
more powerful machines that don't fit that model.)
Instead, for the time being, practical concerns dictate (or have
dictated) offering fairly straightforward hooks of the DWIS variety,
which tend to mandate some kind of common machine model which,
though ill-defined, matches most or all of today's targets, but
which won't necessarily match some of tomorrow's.
If and when that happens, the old DWIS constructs must, for the
new, different models, either be dropped (rendered innocuous,
whatever), or implemented such that their mere presence shuts
down lots of important optimizations.
>Despite Linus's tendency to be insulting, he is one our most important
>"customers" (or, more accurately, the people who depend on the Linux
>kernel working are). We need to have sufficient facilities so that C plus
>inline assembly can do the whole job.
That's a highly worthy goal. Do you think gcc's important customers
also include all those people who just write straightforward,
standard-conforming code and want it to go as fast as possible on
the most powerful machines available at the time? I do, and these
customers basically rely on the SWYM aspects of code generation for
gcc's family of languages.
Do you think gcc can evolve to handle both those kinds of customers
and the Linux kind, which expects all the existing DWIS-like hooks
(which assume a certain static machine model) to continue working
forever, without becoming unmaintainable? I don't.
In any case, do you think it'll be *easier* or *harder* to maintain
gcc if products like Linux are encouraged to slowly dispense with
dependencies on gcc's current DWIS-like extensions, so both Linux
and gcc are less dependent on assuming a certain static machine
model that has informed the development and use of so many of gcc's
extensions?
I think it'd be *easier*, and the sooner it's done, the better.
Finally, I'll ask a different version of the same question I posed
earlier:
Will it ever be acceptable for any version of gcc to generate substantially
different code for an application due to the addition of a single
reference to a function like `__builtin_return_address', making for
possibly *large* differences in performance between the two versions,
and perhaps in the reproducibility of bugs in the code, due to
all sorts of code and data being moved around?
tq vm, (burley)
P.S. It's unclear to me whether C will survive long enough to make
any of the issues I raise above matter. That is, if we can predict
its "death", meaning the point at which improving it further becomes
a non-issue for the industry, then perhaps we can also predict the
final sorts of uses to which it'll be put. There's reasons to believe
those uses will be much more DWIS-like than SWYM-like, and others
reasons to believe the other way. I lean towards the former, which
is why I don't get excited about the SWYM features C9X or whoever
are adding to the language: I think they'll hasten, not delay, the
death of C, because they'll just keep making a hard language harder
to use, which is death for SWYM purposes.
Anyway, once the industry decides C will finally become a DWIS-like
language for sure (let's say), then its "body of development" will
become like a corpse -- anyone who wants to pick at it, by adding
the DWIS features they need at the moment, will feel comfortable
doing so. They'll know they aren't coding for the distant future.
gcc can then support whatever DWIS extensions it wants at that point.
But the same issues persist for other gcc languages, though I think
C++ will die before C does, because they include Fortran, Java,
Ada, and so on.
So the gcc *back end* will have to support *all* of these combinations
of SWYM and DWIS extensions, and still meet all the expectations placed
on it to generate great code for every machine imaginable.
I think that might become extremely hard to manage someday, and the
symptoms will probably be a serious development split when it comes
to supporting some new, weird, high-performance machine, for which
many of the DWIS extensions make little or no sense.
But I could be wrong, and wouldn't mind being proven so: if gcc could
literally become the world's catch-all code generator, beautifully
optimizing clean code targeting every machine, including the bizarre
ones, while also accommodating the needs of people who want to micro-
manage its code generation, that'd be *great*.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990213152402.25468.qmail@deer >
1999-02-13 10:47 ` Joe Buck
@ 1999-02-14 9:08 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214120800.0087f100@pop.netaddress.com >
1999-02-28 22:53 ` kernel-2.2.1-undefined references Paul Derbyshire
1 sibling, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-14 9:08 UTC (permalink / raw)
To: egcs
At 03:24 PM 2/13/99 -0000, you wrote:
>Do you have any bounced email to forward along, so I can see what
>was actually happening? That's the first thing my ISP would
>ask for, probably.
Yeah. Here. (Apologies to list, but since Craig's mail server is still
bouncing mail intermittently...)
I already tried sending this to postmaster@jcb-sc.com, and got the same
sort of bounce. I did Whois lookup and saw their technical and admin
contacts at world.std.com; I mailed them suggesting they fire the
postmaster and noc at jcb-sc.com and telling them why, and world.std.com
bounced as well. Is damned weird.
At least if you suddenly find that your subscription to egcs lists has
evaporated, you'll know why (your server started bouncing incoming mail
again and triggered the automatic bad-address-unsubscribe) and who to blame
(your ISP).
>The original message was received at Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>from dialin109.ottawa.globalserve.net [207.176.153.109]
>
> ----- The following addresses had permanent fatal errors -----
><craig@jcb-sc.com>
>
> ----- Transcript of session follows -----
>... while talking to world.std.com.:
>>>> MAIL From:<pderbysh@usa.net>
><<< 550 Wrong.
>554 <craig@jcb-sc.com>... Service unavailable
>Reporting-MTA: dns; smtp2.globalserve.net
>Received-From-MTA: DNS; dialin109.ottawa.globalserve.net
>Arrival-Date: Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>
>Final-Recipient: RFC822; craig@jcb-sc.com
>Action: failed
>Status: 5.0.0
>Remote-MTA: DNS; world.std.com
>Diagnostic-Code: SMTP; 550 Wrong.
>Last-Attempt-Date: Fri, 12 Feb 1999 19:02:40 -0500 (EST)
>Return-Path: <pderbysh@usa.net>
>Received: from chaoszone (dialin109.ottawa.globalserve.net [207.176.153.109])
> by smtp2.globalserve.net (8.9.1/8.9.1) with SMTP id TAA19254;
> Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>Message-Id: < 3.0.6.32.19990212190141.00891c70@pop.netaddress.com >
>X-Sender: pderbysh@pop.netaddress.com
>X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
>Date: Fri, 12 Feb 1999 19:01:41 -0500
>To: craig@jcb-sc.com
>From: Paul Derbyshire <pderbysh@usa.net>
>Subject: Enough is enough... truce time. Re: kernel blah blah blah
>Cc: egcs@egcs.cygnus.com
>In-Reply-To: < 19990212221225.22651.qmail@deer >
>References: < 7a203j$9cf$1@palladium.transmeta.com >
> < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
> < 19990211201836.2781.qmail@deer >
> < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
> < 19990212031118.4271.qmail@deer >
> < 7a203j$9cf$1@palladium.transmeta.com >
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>Ohh....my...GOD.
>
>*referee whistle blowing sound*
>
>HEY. Lets have a truce here... no more mudslinging and general aggravated
>shouting. I'd think that's beneath the station of the likes of Linus
>Torvalds and the GCC/EGCS development gurus.
>
>In "A Final Solution." I suggested some ways to change the compiler or
>Linux or both to meet everyone's needs and leave everyone happy.
>
>As for who's wrong, I don't think anyone is. There has been a
>*misunderstanding* about the ambiguous phrase "like a macro" in the
>documentation. Some took this fairly literally regarding faithfulness of it
>being expanded inline; others took it to mean "like a macro when it is
>inlinable". Chalk it up to ambiguous documentation, and let's bury the
>hatchet. And to reiterate, there are 3 things that can be done.
>
>1. Make the dox clearer about "extern inline".
>2. Linus, if worse comes to worst, you may just have to replace one-
> off inlines with macros, or at least use -Winline and jiggle it
> until it inlines. This strikes me as rather unsatisfactory
> however.
>3. EGCS developers, if "extern inline" can't be and wasn't meant to
> be what Linus had in mind after reading the dox for it, I suggest
> adding an __attribute__ ((always)) that causes an error if the
> function is not inlinable or a label address from a label inside
> the function is used outside it and an __attribute__ ((once)) that
> inlines a function where it's used, making an error if it's used
> more than once; this means that the compiler can inline the
> functions with these attributes without any worry that it will
> lead to ambiguous references to addressed labels.
>
>--
> .*. "Clouds are not spheres, mountains are not cones, coastlines are not
>-() < circles, and bark is not smooth, nor does lightning travel in a
> `*' straight line." -------------------------------------------------
> -- B. Mandelbrot | http://surf.to/pgd.net
>_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
>Programmer & Humanist|ICQ: 10423848|
>
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* mail sent to <craig@jcb-sc.com> is bouncing, why?
[not found] ` < 3.0.6.32.19990214120800.0087f100@pop.netaddress.com >
@ 1999-02-14 12:19 ` craig
1999-02-28 22:53 ` craig
0 siblings, 1 reply; 180+ messages in thread
From: craig @ 1999-02-14 12:19 UTC (permalink / raw)
To: pderbysh; +Cc: craig
[egcs taken off the reply-to list, so anyone replying to this, add
it back only if you think it's pertinent to the list. I think *this*
might be, because Paul isn't the only one who reported this problem
with email they tried to send to me. Whoever that was, please send
me a note so I can look at your headers and see if you and Paul
share any obvious 'net pathways or MTAs in common.]
>At 03:24 PM 2/13/99 -0000, you wrote:
>>Do you have any bounced email to forward along, so I can see what
>>was actually happening? That's the first thing my ISP would
>>ask for, probably.
>
>Yeah. Here. (Apologies to list, but since Craig's mail server is still
>bouncing mail intermittently...)
Thanks. That's so weird: I saw the email you enclosed sometime late
Friday night, when I fetched my email (I could narrow that down by
examining my archives, if necessary, I suppose).
(I'm cc'ing my ISP on this email, as they indeed asked to see a bounce.)
>I already tried sending this to postmaster@jcb-sc.com, and got the same
>sort of bounce. I did Whois lookup and saw their technical and admin
>contacts at world.std.com; I mailed them suggesting they fire the
>postmaster and noc at jcb-sc.com and telling them why, and world.std.com
>bounced as well. Is damned weird.
In case this gives you some sudden insight into what I, or my ISP,
might be doing wrong, `jcb-sc.com' is my domain name, so I'm "everyone"
there, including postmaster (and, yes, postmaster mail goes to my
root account and, no, there's no bounce-related email there, just
the usual mumblings relating to my having not yet configured news
properly).
And, `jcb-sc.com' is, to the rest of the Internet, just an MX record
pointing to `world.std.com'. So any email sent to anybody at `jcb-sc.com'
just ends up going to my account at world.std.com (via that system's
SMTP server), where I pick it up via fetchmail, and deliver it to myself,
on my local LAN, via qmail (SMTP). At least, that's how I understand it
is *supposed* to work, from what I've read.
So, I *suppose* I could fire myself, as both postmaster and `noc',
whatever that is ("network oxymoron consultant"? :). But there's
got to be a better way.
>At least if you suddenly find that your subscription to egcs lists has
>evaporated, you'll know why (your server started bouncing incoming mail
>again and triggered the automatic bad-address-unsubscribe) and who to blame
>(your ISP).
So far, I'm not aware that I've actually missed anything. Are *all*
my messages bouncing (this wouldn't count the ones from egcs-cvs,
since those are sent by the egcs repository server, I assume)? Or
just some of them?
As far as what little I can make of the header below: there seems to
be little semantic information in the message "550 Wrong." from which
I can gather a clue. But, from "554 <craig@jcb-sc.com>... Service
unavailable", it looks like maybe what happened is that some MTA
tried to deliver the mail *directly* to `jcb-sc.com', instead of
to `world.std.com'.
How could this happen, with me still getting the email, I ask myself,
since my LAN shouldn't accept any outsiders trying to connect to its
SMTP server?
Well, the one copy I *know* I got, in my archives, came via owner-egcs,
so it came via the mailing list.
But, there's a `Cc: craig@jcb-sc.com' on it, so the message was *also*
copied to me directly.
And perhaps *that* copy never made it here, because some MTA didn't
take the advice of the MX record to deliver it to `world.std.com',
and I happened to be off-line and/or my SMTP server (qmail) rejected
the connection (I have a non-null rcpthosts, which will mean something
to the qmail-aware).
I'll enclose a copy of the nslookup session I had from my LAN using
my ISP's DNS server Saturday morning when I first saw your notices
about the apparent email problems here. You'll notice the MX record
points to `world.std.com'. (My LAN's local DNS isn't really set up
right yet. I've convinced qmail to ignore it, by feeding it all the
appropriate info in /var/qmail/control/.)
[craig@deer gnu]$ nslookup
*** Can't find server name for address 192.168.0.1: Non-existent host/domain
Default Server: world.std.com
Address: 192.74.137.5
> jcb-sc.com
Server: world.std.com
Address: 192.74.137.5
*** world.std.com can't find jcb-sc.com: Non-existent host/domain
> ls -d jcb-sc.com
[world.std.com]
$ORIGIN jcb-sc.com.
@ 1d2s IN SOA world.std.com. netadmin.world.std.com. (
98101501 ; serial
5D ; refresh
1H ; retry
2w6d ; expiry
1d2s ) ; minimum
1d2s IN NS world.std.com.
1d2s IN NS AUTH01.NS.UU.NET.
1d2s IN MX 10 world.std.com.
1d2s IN SOA world.std.com. netadmin.world.std.com. (
98101501 ; serial
5D ; refresh
1H ; retry
2w6d ; expiry
1d2s ) ; minimum
So it might not be a problem on my end, or even my ISP's end at all,
though I'm *really* speculating here, as I'm a newbie with all this
email stuff (whatever happened to smoke signals?).
If you want to test my theory, and you've had bounces from me
at <craig@jcb-sc.com>, try sending the same test message to that
*and* to <burley@world.std.com>, the "unposted" address to which
the former is turned into before waiting for fetchmail to pick
it up for my LAN. I can then look at which copies arrived, and
at their headers. (If you haven't gotten bounces from me, don't
bother testing it -- I've tested it myself enough times that I
know the setup basically works, and I can do it again myself, since
I still have logins elsewhere in the net, invisible to anything
on my LAN except an old kermit binary.)
tq vm, (burley)
>>The original message was received at Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>>from dialin109.ottawa.globalserve.net [207.176.153.109]
>>
>> ----- The following addresses had permanent fatal errors -----
>><craig@jcb-sc.com>
>>
>> ----- Transcript of session follows -----
>>... while talking to world.std.com.:
>>>>> MAIL From:<pderbysh@usa.net>
>><<< 550 Wrong.
>>554 <craig@jcb-sc.com>... Service unavailable
>>Reporting-MTA: dns; smtp2.globalserve.net
>>Received-From-MTA: DNS; dialin109.ottawa.globalserve.net
>>Arrival-Date: Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>>
>>Final-Recipient: RFC822; craig@jcb-sc.com
>>Action: failed
>>Status: 5.0.0
>>Remote-MTA: DNS; world.std.com
>>Diagnostic-Code: SMTP; 550 Wrong.
>>Last-Attempt-Date: Fri, 12 Feb 1999 19:02:40 -0500 (EST)
>>Return-Path: <pderbysh@usa.net>
>>Received: from chaoszone (dialin109.ottawa.globalserve.net [207.176.153.109])
>> by smtp2.globalserve.net (8.9.1/8.9.1) with SMTP id TAA19254;
>> Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>>Message-Id: < 3.0.6.32.19990212190141.00891c70@pop.netaddress.com >
>>X-Sender: pderbysh@pop.netaddress.com
>>X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
>>Date: Fri, 12 Feb 1999 19:01:41 -0500
>>To: craig@jcb-sc.com
>>From: Paul Derbyshire <pderbysh@usa.net>
>>Subject: Enough is enough... truce time. Re: kernel blah blah blah
>>Cc: egcs@egcs.cygnus.com
>>In-Reply-To: < 19990212221225.22651.qmail@deer >
>>References: < 7a203j$9cf$1@palladium.transmeta.com >
>> < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
>> < 19990211201836.2781.qmail@deer >
>> < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
>> < 19990212031118.4271.qmail@deer >
>> < 7a203j$9cf$1@palladium.transmeta.com >
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset="us-ascii"
[...rest of message elided, there were no more headers beyond the
final one shown...]
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Removing code dupe in libc (Was: A final solution...)
[not found] ` < 3.0.6.32.19990213042627.008c0960@pop.netaddress.com >
@ 1999-02-14 15:21 ` Gerald Pfeifer
1999-02-28 22:53 ` Gerald Pfeifer
0 siblings, 1 reply; 180+ messages in thread
From: Gerald Pfeifer @ 1999-02-14 15:21 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Sat, 13 Feb 1999, Paul Derbyshire wrote:
> M4?
`man m4` on (nearly) any Unix system.
---- cut ----
NAME
m4 - macro processor
SYNOPSIS
/usr/ccs/bin/m4 [ -e ] [ -s ] [ -B int ] [ -H int ]
[ -S int ] [ -T int ] [ -Dname [=val] ] ...
[ -U name ] ... [ file ... ]
/usr/xpg4/bin/m4 [ -e ] [ -s ] [ -B int ] [ -H int ]
[ -S int ] [ -T int ] [ -Dname [=val] ] ...
[ -U name ] ... [ file ... ]
DESCRIPTION
The m4 utility is a macro processor intended as a front end
for C, assembler, and other languages. Each of the argument
files is processed in order; if there are no files, or if a
file is -, the standard input is read. The processed text
is written on the standard output.
Macro Syntax
Macro calls have the form:
name(arg1,arg2, ..., argn)
:
---- cut ----
Gerald
--
Gerald Pfeifer (Jerry) Vienna University of Technology
pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990213205319.19426.qmail@deer >
@ 1999-02-14 16:25 ` Joe Buck
[not found] ` < 199902150025.QAA00417@atrus.synopsys.com >
1999-02-28 22:53 ` Joe Buck
0 siblings, 2 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-14 16:25 UTC (permalink / raw)
To: craig; +Cc: jbuck, egcs
> And, note, C doesn't really make provisions for writing "close to the
> machine" code any better than Fortran.
You are incorrect, I'm afraid. What Fortran construct corresponds
to "volatile", which is in essence a model for a memory-mapped device
register?
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902150025.QAA00417@atrus.synopsys.com >
@ 1999-02-14 17:26 ` craig
[not found] ` < 19990215011831.28108.qmail@deer >
1999-02-28 22:53 ` craig
1999-02-14 17:59 ` Paul Derbyshire
1 sibling, 2 replies; 180+ messages in thread
From: craig @ 1999-02-14 17:26 UTC (permalink / raw)
To: jbuck; +Cc: craig
>> And, note, C doesn't really make provisions for writing "close to the
>> machine" code any better than Fortran.
>
>You are incorrect, I'm afraid. What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?
I stand by my original statement -- including the part you didn't
quote in my email about "volatile" -- but I'm not about to argue this
anymore.
Read archives of comp.compilers and related works if you really
want to learn why "C is closer to the machine than Fortran" is,
for all intents and purposes, something between a myth and a self-
fulfilling prophecy. And why "volatile" is a great example of a
supposedly necessary feature that, linguistically speaking, makes
almost every computer language that incorporates it *worse* than
it would be without it.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 199902150025.QAA00417@atrus.synopsys.com >
1999-02-14 17:26 ` craig
@ 1999-02-14 17:59 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 1 reply; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-14 17:59 UTC (permalink / raw)
To: egcs
At 04:25 PM 2/14/99 PST, you wrote:
>You are incorrect, I'm afraid. What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?
Or a variable that may be modified asynchronously by software, e.g. a
hardware interrupt, a signal handler, multiple threads in a multithreaded
program...
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990215011831.28108.qmail@deer >
@ 1999-02-14 18:08 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
1999-02-14 19:13 ` Paul Derbyshire
1 sibling, 1 reply; 180+ messages in thread
From: Joe Buck @ 1999-02-14 18:08 UTC (permalink / raw)
To: craig; +Cc: jbuck, egcs
> Read archives of comp.compilers and related works if you really
> want to learn why "C is closer to the machine than Fortran" is,
> for all intents and purposes, something between a myth and a self-
> fulfilling prophecy.
Of course it is a "self-fulfilling prophecy" -- given that a major use of
C is in embedded systems, the customer base believes that C (rather, at
least some C constructs) is "close to the machine" and will demand the
ability to do things like write code that interacts with memory-mapped
hardware in C, and compiler vendors will respond to this demand (in
practice, C++ is just as "close to the machine" in this sense as C). It
appears that you don't like this, and I know that many of the academics
that hang out on comp.compilers object to it (but then, they don't like C
-- some of their reasons are valid, some are merely prejudices). But
these are only opinions.
And please drop phrases like "if you really want to learn" ... I have
extensive experience with the issues involved.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 19990215011831.28108.qmail@deer >
1999-02-14 18:08 ` Joe Buck
@ 1999-02-14 19:13 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214221218.008eacc0@pop.netaddress.com >
1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-14 19:13 UTC (permalink / raw)
To: egcs
>Read archives of comp.compilers and related works if you really
>want to learn why "C is closer to the machine than Fortran" is,
>for all intents and purposes, something between a myth and a self-
>fulfilling prophecy. And why "volatile" is a great example of a
>supposedly necessary feature that, linguistically speaking, makes
>almost every computer language that incorporates it *worse* than
>it would be without it.
I don't think so. How the hell else can you write C code that works with
data that changes asynchronously, e.g. because of multiple threads or
because of hardware or interrupts or signal handlers or...
The choices are:
1. Don't optimize at all -- UNACCEPTABLE
2. Mark data the compiler isn't to optimize into registers and about
which it isn't to make any assumptions regarding the value being
consistent.
The latter gets us 'volatile'.
Which do you choose?
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
[not found] ` < 3.0.6.32.19990214221218.008eacc0@pop.netaddress.com >
@ 1999-02-14 19:51 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214225028.00820ea0@pop.netaddress.com >
1999-02-28 22:53 ` kernel-2.2.1-undefined references Paul Derbyshire
0 siblings, 2 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-14 19:51 UTC (permalink / raw)
To: egcs
At 10:12 PM 2/14/99 -0500, you wrote:
>I don't think so. How the hell else can you write C code that works with
>data that changes asynchronously, e.g. because of multiple threads or
>because of hardware or interrupts or signal handlers or...
By the way, don't say use mutexes and semaphores.
1. Hardware doesn't understand these things, and you do need software
to interface to hardware.
2. A modal signal/exception handler would be in deep trouble if it
encountered a mutex that was locked and decided to wait for it to
unlock...and wait, and wait, and wait...
3. The semaphores and mutexes need to be coded as well. They need
state variables, and those state variables need to be modified
asynchronously, *without* using a mutex or semaphore as this would
be a chicken and egg problem! So the mutex flag or semaphore
counter needs to be 'volatile', so code like this:
void mutex::get_lock (void) throw () {
suspend_task_switching();
while (locked) {
resume_task_switching();
yield();
suspend_task_switching();
}
locked=true;
resume_task_switching();
}
doesn't hang in an infinite loop because 'locked' was optimized
into a register and the while loop therefore never exits since its
register copy of 'locked' never changes! So we need
private:
volatile bool locked;
or the mutex class won't work worth a damn.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* off-topic ramblings [Re: kernel-2.2.1-undefined references.]
[not found] ` < 3.0.6.32.19990214225028.00820ea0@pop.netaddress.com >
@ 1999-02-14 20:01 ` Mumit Khan
1999-02-28 22:53 ` Mumit Khan
0 siblings, 1 reply; 180+ messages in thread
From: Mumit Khan @ 1999-02-14 20:01 UTC (permalink / raw)
To: egcs
Paul Derbyshire <pderbysh@usa.net> writes:
> At 10:12 PM 2/14/99 -0500, you wrote:
> >I don't think so. How the hell else can you write C code that works with
> >data that changes asynchronously, e.g. because of multiple threads or
> >because of hardware or interrupts or signal handlers or...
>
> By the way, don't say use mutexes and semaphores.
> 1. Hardware doesn't understand these things, and you do need software
> to interface to hardware.
[ ... ]
Could you PLEASE take this off-line?
This thread has long become irrelevant to the focus of this mailing list,
but now it's fast getting to the point of ridiculous.
Regards,
Mumit
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 19990213003025.23197.qmail@deer >
@ 1999-02-15 7:33 ` Joern Rennecke
1999-02-28 22:53 ` Joern Rennecke
1999-02-15 7:40 ` Joern Rennecke
1 sibling, 1 reply; 180+ messages in thread
From: Joern Rennecke @ 1999-02-15 7:33 UTC (permalink / raw)
To: craig; +Cc: torvalds, zack, egcs
> One of the problems is that C doesn't have modules a la Fortran 90 and
> Ada. So you have to resort to putting stuff like this (a function
> for which "extern inline" is appropriate) in source code *and* in a
> header file, which, to make for only one copy, means one #include file
> that both the header and the .c file #include.
You can also have the header file include the .c file.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 19990213003025.23197.qmail@deer >
1999-02-15 7:33 ` Joern Rennecke
@ 1999-02-15 7:40 ` Joern Rennecke
1999-02-28 22:53 ` Joern Rennecke
1 sibling, 1 reply; 180+ messages in thread
From: Joern Rennecke @ 1999-02-15 7:40 UTC (permalink / raw)
To: craig; +Cc: torvalds, zack, egcs
> Also, I don't think you can get the same degree of argument type-
> checking via a statement expression within a macro as via a
> function.
Well, you could call an inline function with an empty function body.
Of course, if the argument passing alone forces non-inlinability, you
loose...
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-14 17:59 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 04:25 PM 2/14/99 PST, you wrote:
>You are incorrect, I'm afraid. What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?
Or a variable that may be modified asynchronously by software, e.g. a
hardware interrupt, a signal handler, multiple threads in a multithreaded
program...
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 16:16 ` craig
@ 1999-02-28 22:53 ` craig
0 siblings, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: pderbysh; +Cc: craig
>Ah. I see your point about inline versus actual macros. Maybe the solution
>is this. First, 'extern inline' loses special significance[...]
It never actually had the special significance attributed to it, so
nothing would actually get lost.
>because of the standard likely covering the usage soon. On the other hand,
>GCC can add __attribute__ ((always)) as an extension that will force
>inlining of the function under well-determined conditions, specifically,
>that it is not recursive. (The same rule that governs whether a macro
>"inline function" will work properly.)
That's an awful lot of work for a very small amount of usefulness.
Why don't they just use unique IDs in the Linux source or, as I
recommended six months ago, output a short stack trace (say, two or
three frames), or some other such solution that is *appropriately*
outside the specification of a language like C?
>Now, does this look like it'll make everybody happy?
Even if somebody else did all the work, it'd make egcs a whole
lot harder to improve and maintain, for very little gain: the
ease of coding one particular type of application.
I don't see what would be achieved by increasing the complexity
of the C language supported by gcc that Linux developers couldn't
achieve just as well by some combination of:
- Using a more powerful preprocessor for their C source than
cpp (in addition to, or in lieu of, cpp)
- Post-processing the generated assembly, e.g. via a Perl tool,
to insert unique identifiers or other markers to make
debugging easier
The proposals you are making don't seem, to me, to belong in a
*language specification* for a language like GNU C. That's not
normally, by itself, a case for a veto, but when combined with
the complexity of the implementation of the features and the
extra burden it'd almost certainly add to maintainining egcs, I
think a veto would be the best solution. Especially since hardly
anyone other than Linux developers would need or want the features.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-13 13:03 ` craig
[not found] ` < 19990213205319.19426.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: jbuck; +Cc: craig
>> Be aware that __builtin_return_address probably will stop working
>> someday in gcc. Read my latest tirade to get an idea of why that is.
>
>Craig, gcc is the GNU project's compiler. That means that one of its
>important roles is to be able to compile kernels (Linux or the Hurd).
>Since you're the Fortran guy, you are somewhat insulated from these
>issues (Fortran just doesn't make provisions for writing "close to the
>machine" code).
Actually, I'm not talking as the "Fortran guy". I'm talking as someone
who understands operating systems development and computer-architecture
issues better than he understands Fortran compiler development.
And, note, C doesn't really make provisions for writing "close to the
machine" code any better than Fortran. It provides a *model* that
more closely parallels many of today's most popular architectures,
making it more "obvious" to today's programmers that a straightforward
translation is possible, but *nothing* in the C standard, aside
from stuff like `volatile' (assuming that's even in the standard),
says anything about the mapping to the underlying machine. But the
"as if" rule means you can't just *assume* the machine will behave
a certain way when running C code.
(I've worked on operating systems written in Fortran, assembler, and
PL/1, but no C, by the way.)
I've written on this range of topics, especially involving C, C++,
Fortran, and operators, on USENET many times in the past, so I don't
think it behooves anyone to go into more details. I'll just disagree
with the assertion and leave it at that, noting that the way Fortran
offers similar *effects* as almost all of C's facilities does, usually,
require somewhat more typing. :)
>The result is that gcc is going to have to continue to support certain
>extensions for the indefinite future (though kernel developers should
>not assume that "it worked in version x.y.z" is a commitment for the
>future, we will need to supply some mechanisms in some cases.
Oh, I agree. I'm not saying that feature *will* stop working, just
that, at some point in the future, when gcc is *expected* to support
high-performance platforms like massively parallel machines, it will
either have to stop returning anything other than 0 from that
function in many cases, or the mere use of that function will
mandate a substantial drop in performance of the compiled code,
if my guesses about future directions of computing are correct (and
they're hardly controversial).
If that substantial drop happens, the users who notice it will
complain saying "it stopped working", is my prediction.
>It may actually be easier to support features like this if they are
>specified at a higher level of abstraction. That is, understand why Linus
>is using some trick to do something, and then recommend alternative ways
>to do them that are actually supportable. e.g. if the real job is to get
>a stack trace, maybe there could be some facility to provide for that
>directly, possibly borrowing some code from gdb.
Exactly. Doing that is pretty hard, but I think it's better to try
and do it up front, offer the most SWYM-like ways for people like
Linus to express themselves, and support *that* as well as possible.
(After all, what the heck *is* a "stack trace", precisely defined,
and exactly how does "getting" it help Linux developers? As soon
as you start answering by talking about frame and stack pointers,
you've headed off the SWYM reservation and are assuming a particular
machine model for gcc to permanently cater to, at the expense of
more powerful machines that don't fit that model.)
Instead, for the time being, practical concerns dictate (or have
dictated) offering fairly straightforward hooks of the DWIS variety,
which tend to mandate some kind of common machine model which,
though ill-defined, matches most or all of today's targets, but
which won't necessarily match some of tomorrow's.
If and when that happens, the old DWIS constructs must, for the
new, different models, either be dropped (rendered innocuous,
whatever), or implemented such that their mere presence shuts
down lots of important optimizations.
>Despite Linus's tendency to be insulting, he is one our most important
>"customers" (or, more accurately, the people who depend on the Linux
>kernel working are). We need to have sufficient facilities so that C plus
>inline assembly can do the whole job.
That's a highly worthy goal. Do you think gcc's important customers
also include all those people who just write straightforward,
standard-conforming code and want it to go as fast as possible on
the most powerful machines available at the time? I do, and these
customers basically rely on the SWYM aspects of code generation for
gcc's family of languages.
Do you think gcc can evolve to handle both those kinds of customers
and the Linux kind, which expects all the existing DWIS-like hooks
(which assume a certain static machine model) to continue working
forever, without becoming unmaintainable? I don't.
In any case, do you think it'll be *easier* or *harder* to maintain
gcc if products like Linux are encouraged to slowly dispense with
dependencies on gcc's current DWIS-like extensions, so both Linux
and gcc are less dependent on assuming a certain static machine
model that has informed the development and use of so many of gcc's
extensions?
I think it'd be *easier*, and the sooner it's done, the better.
Finally, I'll ask a different version of the same question I posed
earlier:
Will it ever be acceptable for any version of gcc to generate substantially
different code for an application due to the addition of a single
reference to a function like `__builtin_return_address', making for
possibly *large* differences in performance between the two versions,
and perhaps in the reproducibility of bugs in the code, due to
all sorts of code and data being moved around?
tq vm, (burley)
P.S. It's unclear to me whether C will survive long enough to make
any of the issues I raise above matter. That is, if we can predict
its "death", meaning the point at which improving it further becomes
a non-issue for the industry, then perhaps we can also predict the
final sorts of uses to which it'll be put. There's reasons to believe
those uses will be much more DWIS-like than SWYM-like, and others
reasons to believe the other way. I lean towards the former, which
is why I don't get excited about the SWYM features C9X or whoever
are adding to the language: I think they'll hasten, not delay, the
death of C, because they'll just keep making a hard language harder
to use, which is death for SWYM purposes.
Anyway, once the industry decides C will finally become a DWIS-like
language for sure (let's say), then its "body of development" will
become like a corpse -- anyone who wants to pick at it, by adding
the DWIS features they need at the moment, will feel comfortable
doing so. They'll know they aren't coding for the distant future.
gcc can then support whatever DWIS extensions it wants at that point.
But the same issues persist for other gcc languages, though I think
C++ will die before C does, because they include Fortran, Java,
Ada, and so on.
So the gcc *back end* will have to support *all* of these combinations
of SWYM and DWIS extensions, and still meet all the expectations placed
on it to generate great code for every machine imaginable.
I think that might become extremely hard to manage someday, and the
symptoms will probably be a serious development split when it comes
to supporting some new, weird, high-performance machine, for which
many of the DWIS extensions make little or no sense.
But I could be wrong, and wouldn't mind being proven so: if gcc could
literally become the world's catch-all code generator, beautifully
optimizing clean code targeting every machine, including the bizarre
ones, while also accommodating the needs of people who want to micro-
manage its code generation, that'd be *great*.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-14 16:25 ` Joe Buck
[not found] ` < 199902150025.QAA00417@atrus.synopsys.com >
@ 1999-02-28 22:53 ` Joe Buck
1 sibling, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: jbuck, egcs
> And, note, C doesn't really make provisions for writing "close to the
> machine" code any better than Fortran.
You are incorrect, I'm afraid. What Fortran construct corresponds
to "volatile", which is in essence a model for a memory-mapped device
register?
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 17:28 ` Benjamin Scherrey
@ 1999-02-28 22:53 ` Benjamin Scherrey
0 siblings, 0 replies; 180+ messages in thread
From: Benjamin Scherrey @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs; +Cc: craig, torvalds
Geez people lighten up! This is worse than the C++-in-kernel thread that
occurs in the linux list. I think we've identified what the issue is here
(right?). Now - who's the guy who makes the decision (Jeff?) and what's it going
to be?
I think Linus and company are slightly aware of what the egcs team has
provided and I don't think your recitation was intended to clarify his mind. This
"discussion" is only wasting my time and every one else's who attempts to keep up
with this list.
If the issue isn't completely understood by both sides yet perhaps Linus could
provide a couple of source examples (if he hasn't already - I haven't bothered to
read every tirade, err message in this thread) who's behavior has changed and an
egcs maintainer could either say "it will be fixed" or, at least, explain how one
might predict whether or not the code will inline as expected. The last I heard,
these computer things were still deterministic and truly random results were still
hard to generate...
flame out,
Ben Scherrey
craig@jcb-sc.com wrote:
> Which means, what, exactly? That you therefore can claim some kind
> of *ownership* of the exact behavior of gcc in the presence of
> all sorts of extensions, regardless of the degree to which they're
> clearly specified and documented? Sorry, you *should* know better.
>
> >There were tons of code generation bugs over time, but hey, I _expect_
> >bugs, and while compiler bugs are sometimes really hard and nasty to find,
> >I don't complain too much: I report them, and I tell people not to use
> >certain versions. I may be grumpy for a while because I spent ages looking
> >at a bug that didn't turn out to be mine, but I never get the feeling that
> >I should really dislike the compiler people.
>
> Given how you've treated the egcs developers lately, for daring to:
>
> - Offer you a free compiler
>
> - Offer you free upgrades
>
> - Offer you free responses to bug reports
>
> - Offer you free bug fixes
>
> - Offer you free improvements to unclear documentation
>
> - Offer you free advice as to how to improve your code to make
> it more immune to likely changes to egcs code development
>
> I think we're *all* grateful you don't feel you should actually
> *dislike* us.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 17:36 ` Joe Buck
@ 1999-02-28 22:53 ` Joe Buck
0 siblings, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Bryan W. Headley; +Cc: ross.s, egcs
> No, I heard more than that. Such as, the compiler may opt to make a function
> into an inline based on optimization. Which scares the hell out of me, too.
Get used to it; almost every compiler will do this at high levels of
optimization.
> The argument, though, should be telling you that basing a C compiler
> front-end on top of a C++ engine is going to become more and more risky.
It has nothing to do with C++. Fortran compilers are the most aggressive
at doing major restructuring of this form. If anything, C++ compilers
do *less* of it. The reason is the compiler writers are spending so
much time getting the semantics right that they have no time to do much
optimization.
> There once was a time when there was a tight correlation between the C code
> and the assembly.
Turn off -O if you want that.
> I like Per's comments about not being able to produce a compiler that behaves
> like Linus would want.
Would you be willing to accept 50% slower code for tighter control?
(You could get the 50% back by personally directing every compiler
transformation, but you'd have to get them all right and then redo
them every time you change any of the code).
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 16:44 ` H. Peter Anvin
[not found] ` < 199902090043.QAA21188@cesium.transmeta.com >
@ 1999-02-28 22:53 ` H. Peter Anvin
1 sibling, 0 replies; 180+ messages in thread
From: H. Peter Anvin @ 1999-02-28 22:53 UTC (permalink / raw)
To: Lee Iverson; +Cc: torvalds, ross.s, egcs, hpa
>
> Of course inline is supposed to work, but as you've heard this is
> largely a question of *reliably* generating correct code and as in the
> past *your assumptions* about what the compiler should be doing rather
> than objectively documented behavior. The compiler may not be living
> up to your expectations, and I know that it hasn't in the past, but
> just as in some of those cases (e.g. the asm clobbering issue or the
> inline+label addresses), the problem is that you are relying on
> behaviour that is either undocumented and thus not guaranteed or
> falling between the cracks of the implementation.
>
> I think this is a case where the documentation is misleading. It does
> suggest that inlining is not guaranteed, but IMO not as prominently as
> it should. That is what you've been bit by, *not* a guarantee that
> isn't being honoured.
>
On another note, however, it really sucks to have to rely on macro
expansion -- it wrought with pitfalls, and the syntax is different in
the most bleacherous manner (requiring \ at the end of each line.) It
is much nicer to have the compiler check the syntax properly, but it
really requires it to work right. Oh yes, __builtin_constant_p()
really, really ought to work properly in an inline...
-hpa
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 15:31 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212152049.31280H-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Fri, 12 Feb 1999, Paul Derbyshire wrote:
>
> Uh... it kind of occurs to me that perhaps the simplest solution is just to
> actually use a macro there? Then you can be damn sure it will inline,
> because the preprocessor will have done it before egcs ever gets to see
> your sources. :-)
Doesn't anybody actually read what I'm saying?
Yes, I could have used a macro. I didn't, because:
- macro syntax sucks
- macros don't do type testing
- macros don't handle arguments with side effects nicely, so you have to
work around that in various ways.
which is why I _want_ to use "extern inline", because the compiler does
support the notion of inlining, and it's a very powerful notion. But it
does require that if you want to use it as a macro, the compiler had
better have some way of marking it important. I always read "extern" as
being that marker.
But if people tell me that I really can't, then I have to say that it just
sucks. It's useless for something where you really want to use it as a
macro, and that's a bad thing.
And yes, before people say that gcc documentation said that "extern
inline" was documented to be _almost_ like a macro, then instead of being
a language layer, please consider for a moment using your brains for
something else than syntax, and using them for asking yourself "what is
reasonable for a programmer"?
I took the "almost" to mean:
- there are differences between macros and inline functions. See above on
arguments with side effects.
- some functions fundamentally cannot be inlined due to purely technical
reasons, like recursion.
But obviously some people want to use it as a hedge against actually
having any sane use at all for "extern inline", but that, I think, makes
for a worse compiler.
Oh, well. People seem to care less about actually _using_ gcc features
than about coming up with excuses for why they don't work in a sane
manner.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Bad puppies and coding practices
1999-02-12 4:10 ` Bad puppies and coding practices Marc Espie
[not found] ` < 199902121210.NAA04037@quatramaran.ens.fr >
@ 1999-02-28 22:53 ` Marc Espie
1 sibling, 0 replies; 180+ messages in thread
From: Marc Espie @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: egcs
In article < 19990212034058.4359.qmail@deer > you write:
>>and on the whole we'd like to try triggering that sort of thing,
>I meant "try *to avoid* triggering", which I hope was obvious.
Actually, no, it's not obvious at all. It's better if the compiler
says `your code is plain wrong, you dummy', but a compiler that breaks
things when you don't follow clean coding practices is a GREAT teaching
tools. :->
A bit like wacking puppies on the nose to teach them proper toilet
habits...
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-15 7:40 ` Joern Rennecke
@ 1999-02-28 22:53 ` Joern Rennecke
0 siblings, 0 replies; 180+ messages in thread
From: Joern Rennecke @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: torvalds, zack, egcs
> Also, I don't think you can get the same degree of argument type-
> checking via a statement expression within a macro as via a
> function.
Well, you could call an inline function with an empty function body.
Of course, if the argument passing alone forces non-inlinability, you
loose...
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 17:17 ` Joe Buck
[not found] ` < 199902090114.RAA15416@atrus.synopsys.com >
@ 1999-02-28 22:53 ` Joe Buck
1 sibling, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: leei, ross.s, egcs, hpa
Linus writes, in response to a suggestion to use a special feature of
macros:
> Why don't you just remove "inline" completely, then?
>
> It's apparently ok to break documented and existing behaviour of "inline".
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define.
Hmm. Linus does seem to have a point here. See the node "Inline"
in the gcc manual.
" If you specify both `inline' and `extern' in the function
definition, then the definition is used only for inlining. In no case
is the function compiled on its own, not even if you refer to its
address explicitly. Such an address becomes an external reference, as
if you had only declared the function, and had not defined it."
This seems to be a fairly strong promise that the function is guaranteed
to be either inline or to come out undefined (unless there is a second
non-extern-inline definition).
Many people have been answering based on general compiler principles
rather than by looking at the promises made in the gcc documentation for
an *extension*.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 5:47 ` craig
1999-02-10 9:42 ` Linus Torvalds
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>On 9 Feb 1999 craig@jcb-sc.com wrote:
>
>> >Why don't you just remove "inline" completely, then?
>>
>> Because it works just fine, and as documented, for 99.9999% of the
>> uses to which its put in code compiled by gcc?
>
>Right. So why break it then?
By your apparent standards, it always *was* broken, because inlining
didn't always happen.
Yet, as I said, even then, it works just fine, and as documented,
for 99.9999% of the uses to which it is put in code compiled by gcc.
(That's not surprising, since gcc is, generally, based on standards
such as ISO C, which presumably make it much clearer that "inline"
is, like "register", a mere hint.)
Sorry you recently got bit by this, though. That happens quite often
when using tools as complex as gcc, I'm afraid -- review all the
egcs- and gcc2-related discussions regarding 64-bit alignment of
REAL*8 (aka `double') on PPro and PII chips that have gone on
even since we *thought* we had this "fixed" in a long-ago version
of g77 based on gcc 2.7.something. As with your situation, what
we thought "worked" just happened to not fail, and getting it
to truly work properly is much more difficult, politically as well as
technically, than we ever thought.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 17:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212174436.31280N-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Fri, 12 Feb 1999, Paul Derbyshire wrote:
>
> Getting them to fix __builtin_return_address would be even better since
> your code is (to put it bluntly) a kluge to get around a wart in GCC to
> begin with. But my suggestions sure look doable...I'm not exactly sporting
> a PhD in compiler theory, but 15 years of programming experience must count
> for something =)
Well, __builtin_return_address() has actually worked for a longish time.
That's kind of the secondary problem: I'd love to track new releases and
use new features when they come out, but I can't. Even if _I_ switch to a
new compiler, few other people will, and then I get bug-reports with the
old stuff - reports that are useless because the data they report is just
bogus.
Most of these debugging things are not something that developers ever see
themselves - this one hasn't triggered in a _long_ time for anybody that I
can recall. It used to trigger under some very specific circumstances
(using IPIP tunnelling with certain other combinations, for example), and
exactly because the developers couldn't easily reproduce them they have
extra code to pinpoint exactly where they happen.
So in this case what I'm just probably going to do it to remove the
particular backtrace debugging code, because we no longer need it (it's
quite old, and doesn't trigger - and if it ever starts to be a problem we
can introduce something else).
The problem for me is that if I really have to create duplicates of all
"extern inline" functions, the while thing is completely useless to me. It
does _not_ act "almost as a macro" any more, it acts almost completely
differently.
So then I can't use it for anything else either. And the reason we
switched away from using "static inline" for these things was that some
versions of gcc complain loudly about "xxxx was declared static but was
never used", which is really aggravating, because this is in header files
that you should be able to include _without_ having to use every single
function you happened to have exposed to you.
See my problem? "extern inline" is useless, and "static inline", while
working (because even if gcc doesn't inline it will actually create the
function for you), is really obnoxious with certain gcc versions.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 17:42 ` Joe Buck
@ 1999-02-28 22:53 ` Joe Buck
0 siblings, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Lee Iverson; +Cc: jbuck, torvalds, ross.s, egcs, hpa
> > Remember, we are not talking about ISO C++ here. We are talking about
> > *C*, and specifically the GNU "extern inline" extension. So the M to R
> > is the gcc manual.
>
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it. There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution." It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...
Yes, clearly some functions cannot be inlined. The compiler developers
cannot promise the impossible.
The language implies that if inlining fails you'd just have an external
reference, meaning you'd have an undefined symbol if there is not a
second, non-inline definition.
> I do think that the language is ambiguous and definitely suggests
> something that the compiler cannot guarantee. That's why I've
> submitted a patch to egcs-patches to clarify this:
>
> http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html
It might be appropriate to generate an error, not a warning, if
"extern inline" fails to inline, since it is clear from the documentation
that this is not a mere hint.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 11:51 ` Marc Espie
[not found] ` < 199902101950.UAA03203@quatramaran.ens.fr >
@ 1999-02-28 22:53 ` Marc Espie
1 sibling, 0 replies; 180+ messages in thread
From: Marc Espie @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: egcs
You could *at least* acknowledge that you read the original documentation
wrong, and that you relied on your interpretation of it...
You have stated repeatedly that egcs broke a *documented* feature, and we
have been repeatedly telling you that it was undocumented, and that your
interpretation was wrong. The *implementation* worked in the way you described,
but the *interface* did not !
Is it *that* hard to state publically ? Nowhere in *any* of your messages
did you even *hint* that you may have made a small misinterpretation.
Afterwards, we can all go back to serious coding, like getting the documentation
straighter, or fixing egcs to get more compatible with old gcc's ways (which
is *the* current problem. but stop referring to it as `breaking old documented
behavior, which is getting on everybody's nerves, haven't you noticed ? :) )
Get your gripes straight, please. We all know that you have been having trouble
with egcs in the past, this is no reason to be downright insulting to people
who have been *very* responsive to motivated queries, as I can attest from
the OpenBSD side of the free world.
(kuddoes to Mike, Jeff, Kaveh, Zack, and the rest).
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-15 7:33 ` Joern Rennecke
@ 1999-02-28 22:53 ` Joern Rennecke
0 siblings, 0 replies; 180+ messages in thread
From: Joern Rennecke @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: torvalds, zack, egcs
> One of the problems is that C doesn't have modules a la Fortran 90 and
> Ada. So you have to resort to putting stuff like this (a function
> for which "extern inline" is appropriate) in source code *and* in a
> header file, which, to make for only one copy, means one #include file
> that both the header and the .c file #include.
You can also have the header file include the .c file.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Removing code dupe in libc (Was: A final solution...)
1999-02-13 1:26 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990213042627.008c0960@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
>I do wish there was a cleaner way to do it. Replacing cpp with M4
>wouldn't be a bad start...
M4?
WTH?
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 17:54 ` Linus Torvalds
@ 1999-02-28 22:53 ` Linus Torvalds
0 siblings, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Lee Iverson; +Cc: Joe Buck, ross.s, egcs, hpa
On Mon, 8 Feb 1999, Lee Iverson wrote:
>
> I actually did, and while the discussion of "extern inline" strongly
> implies that it is guaranteed behavior, it doesn't *really* come out
> and say it. There is a hedge above though in the sentence "Note that
> certain usages in a function definition can make it unsuitable for
> inline substitution." It looks like that is just a hedge on automatic
> inlining, but it is really a hedge on the whole process...
And while you're at it, what's your definition for "sex"?
It's ugly in politics, it's ugly in technican discussions. Don't hide
behind technicalities.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-13 7:24 ` craig
[not found] ` < 19990213152402.25468.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: pderbysh; +Cc: craig
>Christ Craig, give it a rest. This is a dead horse you're beating. Some
>reasonable sane and rational suggestions for solving the problems both with
>Linux and egcs have appeared; someone's found that a conditional compile
>can be used to make the extern inline thing compile and work on every gcc
>by either using __builtin_return_address or the label hack; Linus has said
>the panic code isn't too critical anyways and has apologized for some of
>the tirades earlier in the week; and it seems to be high time this issue
>was let drop on the list; yet I keep seeing more tirades from you every few
>minutes to an hour.
Yet, later, you followed up one of my "tirades" offering your own
opinions. I guess it's okay if I don't respond to that?
Be aware that __builtin_return_address probably will stop working
someday in gcc. Read my latest tirade to get an idea of why that is.
>BTW, did you know that your ISP's mail server was bouncing mail
>inexplicably all afternoon? Was bouncing messages with "Service
>unavailable". Never heard of downtime causing mail to bounce before;
>usually it's deferred. You should have a few stern words with your ISP's
>customer service reps about this; if the downtime had been much longer the
>bounces would have caused yo to be removed from this list and any others
>you're on more than likely. They should just defer the mail.
Do you have any bounced email to forward along, so I can see what
was actually happening? That's the first thing my ISP would
ask for, probably.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 11:04 ` Lee Iverson
@ 1999-02-28 22:53 ` Lee Iverson
0 siblings, 0 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: submit-linux-egcs, egcs
This response is too long, but it's the last I'll say on the
subject.
In message < 79sgd8$p7p$1@palladium.transmeta.com > you write:
> In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
> >>On 9 Feb 1999 craig@jcb-sc.com wrote:
> >>
> >>> >Why don't you just remove "inline" completely, then?
> >>>
> >>> Because it works just fine, and as documented, for 99.9999% of the
> >>> uses to which its put in code compiled by gcc?
> >>
> >>Right. So why break it then?
> >
> >By your apparent standards, it always *was* broken, because inlining
> >didn't always happen.
>
> No.
>
> gcc _did_ use to always inline if it at all could do so. There were
> cases that made it unable to inline, simply because the code itself was
> not conducive to inlining. Those were _technical_ reasons for not
> chosing to inline something, and completely and utterly understandable.
>
> For example, not inlining a recursive function is just obviously the
> right thing to do (yes, in theory you could try to make it iterative,
> but if the programmer gave the compiler a recursive function then it's
> the _programmer_ who is responsible for it, and nobody really expects
> the compiler to do miracles).
And that was the case here. The problem you faced was *not* due to
any artificial limit arbitrarily imposed by the compiler but a
technical limitation that was discovered in which gcc/egcs was
generating bad code when inlined code used computed jumps. The test
to disable inlining in this case was casting too wide a net... See
Richard Henderson's fix:
http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00172.html
> It used to be a feature you could depend on.
>
> The change broke that.
This was never a feature you could blindly depend on and -Winline is there
for the simple reason that it can fail when the programmer might not expect
it to. This is a technical issue, and always was. You were the one who
turned it into some sort of Jihad and started insulting people
(although some of my friends were quite impressed that I had been
personally insulted by Linus Torvalds, I wasn't too fond of it).
For this particular case, the bug/shortcoming has been fixed, but that doesn't
change the fact that the interaction between certain coding structures and
inlining is fragile. Your mistake was and still is in assuming that it isn't.
> Yes, the documentation had hedges to handle the real cases (like
> recursion etc) where inlining just isn't feasible, but the fact that it
> hedged its bets doesn't change the fact that people like me used to be
> able to rely on the compiler to do what it was asked to do.
>
> If it was a case of "oh, gcc used to have a 50-50 policy on when to
> inline, and the change made that a 40-60 policy", then it would have
> been much more palatable. But it wasn't. It was a case of 100% success
> being turned into "I wonder what the hell they'll break next time
> around".
>
> Repeatability is good. Random changes that break existing behaviour for
> no technical reason is bad.
That's where you are mistaken, this was a "real" case. I'd have to side with
the point of view that says if you can't reliably generate good code then the
best "fix" is to disable the feature. That was the case here, the only
problem was that *you* weren't prepared to recognize and deal with the
failure. If, in the future, egcs developers discover that label
addresses cause bad code to be generated in many circumstances, then
that alone would justify turning off inlining in their presence, even
if those don't include the ones you are relying one. Ideally, bugs
get fixed, but you know as well as I that sometimes they just get
papered over until they are fixed. You do the same thing, I've seen
it in action. Don't impugn the motives of other developers for that.
Get over it. EGCS *is* a very reliable compiler, but one under very
active development. Backwards compatibility has *never*, to my
knowledge, been gratuitously broken. There have been bugs that made
it fail and there have been incompatibilities justified by sound technical
reasoning.
The problem here was primarily with your reliance on a particular
interpretation of a feature which is documented to be unreliable. If
a previous version of the compiler permitted a use which leads to
broken code (inlining with computed gotos), then there was sound
technical reason to disable it. And that should be as obvious to you
as anyone else. The fact that you went off half cocked without even
seeking an explanation doesn't reflect very well on you. And neither
does your insulting everyone who has disagreed with you.
Time for all of us to get back to coding.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 15:15 ` David J. Dooling
[not found] ` < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
@ 1999-02-28 22:53 ` David J. Dooling
1 sibling, 0 replies; 180+ messages in thread
From: David J. Dooling @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
>In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
>>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>>
>>>> >Why don't you just remove "inline" completely, then?
>>>>
>>>> Because it works just fine, and as documented, for 99.9999% of the
>>>> uses to which its put in code compiled by gcc?
>>>
>>>Right. So why break it then?
>>
>>By your apparent standards, it always *was* broken, because inlining
>>didn't always happen.
>
>No.
>
>gcc _did_ use to always inline if it at all could do so.
False. gcc *never* inlined 100% reliably. It might have tried,
and succeeded often enough, but other times, it just generated
bad code, or ran out of memory, or similar.
ENOUGH!!!!!!!!!!!
This whole thread only serves to fill all our mailboxes with a bunch
of name-calling and nitpicking. It does not help the development of
gcc or linux (I assume the reason we are all subscribed to this
listserv is to _help_ the development of gcc, no?). It is the
software development equivalent of ``my dad can beat up your dad!''.
Basically (without all the name-calling), the developers of egcs found
that combining two gcc extensions did not produce reliable code. So,
they took the easy fix: don't allow them to be combined. This broke a
significant amount of code for one user, Linus (granted he is not just
_any_ user, nonetheless ...). I am sure other people who depend on
these gcc extensions will also feel the pinch. This is all fact,
everything else that has been said is superfluous.
That being said, is there anything we can do together to improve the
situation for all of us? Obviously the combination of these
extensions worked sometimes. Is there any way to find out when it
works and when it doesn't? It should be a deterministic problem, no?
Perhaps Linus has some cases in his code where he knows it works.
Perhaps other has incidences where it doesn't. Is there not time to
address these issues now? Can it be put on the TODO list? Can we at
least agree on how to warn/error when gcc can't comply with what the
programmer wants? There has to be something that can be done to make
the compiler (and the atmosphere on this thread) better.
Admittedly, I have not the knowledge nor the expertise to investigate
these options myself (I am but a lowly chemical engineer). I
apologize for this (my only intention is to help).
Let's turn this thread around, discuss some specifics, and get
something done.
DAVID?
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 17:28 ` Lee Iverson
[not found] ` < 199902090128.RAA04379@Canada.AI.SRI.COM >
@ 1999-02-28 22:53 ` Lee Iverson
1 sibling, 0 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-28 22:53 UTC (permalink / raw)
To: Joe Buck; +Cc: torvalds, ross.s, egcs, hpa
In message < 199902090116.RAA15478@atrus.synopsys.com > you write:
>
> > I've yet to see *any reference* to the claim that it is *documented*
> > that the inline declaration *guarantees* that the function will always
> > be inlined. Even with extern. That was your assumption, reading
> > between the lines...
>
> RTFM.
>
> Remember, we are not talking about ISO C++ here. We are talking about
> *C*, and specifically the GNU "extern inline" extension. So the M to R
> is the gcc manual.
>
> We may have an issue later on with C9X, which may define "extern inline"
> to mean something different.
I actually did, and while the discussion of "extern inline" strongly
implies that it is guaranteed behavior, it doesn't *really* come out
and say it. There is a hedge above though in the sentence "Note that
certain usages in a function definition can make it unsuitable for
inline substitution." It looks like that is just a hedge on automatic
inlining, but it is really a hedge on the whole process...
I do think that the language is ambiguous and definitely suggests
something that the compiler cannot guarantee. That's why I've
submitted a patch to egcs-patches to clarify this:
http://egcs.cygnus.com/ml/egcs-patches/1999-02/msg00176.html
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 16:28 ` Lee Iverson
@ 1999-02-28 22:53 ` Lee Iverson
0 siblings, 0 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-28 22:53 UTC (permalink / raw)
To: d-dooling; +Cc: egcs
In message < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu > you write:
>
> ENOUGH!!!!!!!!!!!
>
> [deleted]
>
> Let's turn this thread around, discuss some specifics, and get
> something done.
Already done and in the CVS tree thanks to Richard Henderson.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 15:35 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212153140.31280I-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Fri, 12 Feb 1999, Paul Derbyshire wrote:
> 4: An __attribute__ ((always)) or __attribute__ ((once)) that is
> recursive or otherwise uninlinable generates an error, regardless
> of -Winline.
>
> Now, does this look like it'll make everybody happy?
I would be happy with this.
> The address-of-label is just used to generate displayed information? That
> simplifies things a lot.
Yes. And I realize that people don't like that, but the fact is that the
sane way of doing the same thing (and that wouldn't have been bitten by
the current problem in the first place) was to use the gcc intrisic
__builtin_return_address() inside the panic printout. That would have been
the right way of implementing the debugging (the panic printout just
prints out who called it), but it doesn't work correctly in most versions
of gcc, which is why we instead ended up using this really stupid code
snippet:
__label_ l;
l:
skb_under_panic(.., &&l);
which triggered the problem with newer versions of egcs.
> If the address is only taken right at the label
> itself, then it seems reasonable to make an inline __attribute__ ((always))
> label and label address situation work like this:
Agreed. That would work beautifully, and I wouldn't have to think that the
egcs people are just trying to make it difficult to do something
reasonable.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 14:50 ` kernel-2.2.1-undefined references craig
[not found] ` < 19990212221225.22651.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>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.
I realize you think that. That's because you're rather uninformed,
or intentionally forgetful, about what has really been going on here,
and prefer to insult others than to take responsibility for mistakes
committed (repeatedly) on your end.
>It's not at all buggy, it just assumes that the compiler does something
>reasonable.
No, it assumes that the compiler does something *some* people consider
reasonable, but others don't, and which is not *documented* by the
compiler to do any particular thing, implementation-wise.
>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.
In other words, the kernel makes two uses of "inline", one that is
correct, the other that is incorrect.
>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).
First, I based my comments on what *you* were saying when *you* were
slinging mud at the egcs developers, the decisions they were making,
and the help they were offering you.
If you had wanted us to look at any sources, *you* should have posted
the relevant bits here first, perhaps in place of mud-slinging, which
you continue to prefer to engage in.
>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".
Fine and dandy.
>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".
Which is incorrect, if the code actually *depends* on inlining
actually happening, as the documentation should have made clearer,
but most everyone already knew.
>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.
Mostly due to an *incorrect reading* of the gcc documentation, which
didn't help things.
>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.
More below on your continuing attack on my efforts to educate you
as to proper use of gcc extensions.
>The ones that were bitten by the egcs bug (let's just be honest and call
>it what it really was)
I have concluded that *you* wouldn't know "honesty" if it bit
you in the ass. You have lied about this before, and you are
continuing to lie about it now. egcs not inlining an "extern inline"
function is not, never has been, and never will be a bug. The
*developers* might consider it a bug, in that they'd prefer some
cases be inlined for performance reasons, but to the user, it is
*never* a bug in the sense of violating the "contract" the compiler
makes with its users, in the form of an explicit language
specification.
In that sense, it's what I call a "buglet", meaning, not necessarily
a high-priority bug -- not a violation of the "contract", or
specification, of how the compiler behaves in terms of implementing
the language it compiles.
In writing the g77 documentation, I tried to make the distinction
between promises made on behalf of the GNU Fortran *language* and
the behavior of the current GNU Fortran *compiler* as clear as I could.
If, as a programmer, I don't see that clear a distinction in a product's
documentation, I assume *fuzziness*.
It's been *your* error that you've assumed that any behavior you observe
and which the gcc documentation doesn't clearly say might change will
therefore be promised for all of eternity. That's a *very* frequent
error, but rare is the person who insists on insulting those who
try and point it out to him, especially as repeatedly and as nastily
as you've done.
>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).
The only reasons it should have mattered to you that inlining did
not happen are that you didn't get the performance you want, or
the generated code was actually wrong. Neither was the case. Therefore,
if the overall result was that *your* code broke, it was not *egcs*
that broke it -- it was a change to egcs that triggered a long-hidden
bug in your code. Please stop saying things like "this change broke
egcs", as that's a lie.
>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.
Okay, Linus, now that you've *totally* destroyed any and all credibility
you've *ever* had with me, and converted me from promoting your
abilities, and Linux, to friends and neighbors to warning them away
from anything you touch, I'll enclose a copy of some emails sent *six
months* ago on a closely-related issue.
I want you to read these emails *very* carefully, and then come back and
explain exactly how you still believe I'm simply up in an "ivory tower",
have never had a "look" at code *you* have not (to my knowledge)
offered here, and how I should still agree that Linux' use of
"extern inline" as "guarantee me inlining" makes sense.
(For *other* readers, who *are* allowed to not bother reading the
emails quoted below: the summary is, this problem came up before,
was specified as being related to Linux, and was *thoroughly* and
*completely* explained as being the result of a combination of
poorly-specified extensions, inadequate documentation, and Linux'
inappropriate reliance on the behavior of extensions. Further,
viable alternatives were proposed. Apparently that did no good
then, though I'm willing to take the blame for not fixing the
gcc docs myself, and there is plenty of reason to assume all this
verbage will do no good now.)
tq vm, (burley)
P.S. Yes, folks, I realize that Linus almost certainly won't bother
actually reading the below, as he's already cast my posts on this
topic as "silly" and so on. I'm writing all this for the public
record, basically: I want it clearly on record that Linux developers
(which I assume included David Miller, involved in the emails below)
were *warned* about this problem, told to change their code and
how to properly read the documentation *months* ago, that Linus
himself continually and repeatedly ignores the same advice given
now and insists on continuing to tell the lie that egcs is the
source of the problem. It does *not* matter to me whether Linus
ever "gets" it, all things considered.
>Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
> rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807281242.FAA31050@dm.cobaltmicro.com>
> (davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>> Date: Tue, 28 Jul 98 08:36:39 EDT
>> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
>>
>> Inlining tells the compiler "for efficiency reasons, I'd like you to
>> do your best to inline this function", not "even if you do it wrong, I'd
>> like you to inline it".
>>
>>Then what does "extern inline" say?
>
>It says "if you can inline this function, great, but even if you can't,
>don't compile it as a separate function". E.g. if you compile without
>optimization, it doesn't get inlined.
>
>>Forget for a moment what you know about C and compiler implementation
>>details, and all of the issues surrounding this topic. And pretend
>>for a moment you are a programmer using GNU C to accomplish some task
>>and you wish to express something, and you find that GNU C allows you
>>to express this by saying:
>>
>>extern __inline__ check_a(int a)
>>{
>> __label__ here;
>>
>> if(my_test(a) != 0)
>> printf("Assertion on 'a' failed at %p\n", &here);
>
>(I think that should be `, &&here'.)
>
>>&&here:
>
>(I think that should be "here:".)
>
>>}
>>
>>Can you tell me that this does not seem like a useful construct or
>>feature? Can you also tell me that this is hard for the person
>>writing such code to understand? Which behavior of the above function
>>do you deem would be correct in any case?
>
>I'm confused -- what are the choices? I've already tried to construct
>an example showing the differences, and can't do so without resorting
>to bogosities like having some external code somehow depend upon
>the uniqueness, or value, of labels passed to it as `void *' arguments.
>(See below for an example.)
>
>>It depends, for standard C constructs, I can understand this
>>completely. For GNU C extensions, we can say whatever we like about
>>semantics wrt. inline functions, and in fact document them.
>
>I think we should first figure out whether the proposed semantics
>make good linguistic sense in the first place. When I first looked
>into this as a result of this discussion, I *thought* there were some
>very interesting issues here, but so far all I can find is places
>in the gcc docs where we could do a better job clarifying stuff
>most programmers would regard as "natural" for them (and perhaps
>in disagreement with each other).
>
>>This issue is different from most others, because it is an issue of
>>semantics when two different GNU C extensions are used together, so we
>>can define the semantics any way we wish to in such cases. I contend
>>that the current behavior makes the most sense and is the most useful
>>for users of GNU C (the fact that this behavior has been in known
>>active use for 4 or 5 years is a testament to this!).
>
>I'm still confused as to what the current behavior *is* that is
>being depended upon.
>
>My *guess* is that the current behavior is to try and inline functions,
>which is not always done. That's what the docs say (especially if you
>read carefully, and between the lines -- they could stand improving
>though).
>
>What exactly *breaks* when code like the examples you post aren't
>actually inlined by gcc? If it's just that you get unresolved
>references to the externals, well, that's what is *supposed* to happen,
>based on my reading of what `extern inline' means in gcc.
>
>If it's just that when the code doesn't get inlined, the application
>(Linux?) goes slower, well, that's not a linguistic or semantic
>issue -- even if the decision revolves around whether a construct
>like `&&foo' is present.
>
>If that's the case, then it's just a matter of the application no
>longer using `&&foo', or teaching gcc to change that decision again
>(but only when it's safe to do so, to preserve the semantics of
>the function), or teaching gcc a new construct meaning "*inline* this,
>dammit!", such as __force_inline__. Programmers would be responsible
>for any code-generation bugs resulting from their combining this
>specification with features gcc normally would detect as "I can't
>safely inline this".
>
>
>As far as how hard it is to tell what labels should really "mean",
>here's a contrived example:
>
>#include <stdio.h>
>
>void *
>f (void *arg)
>{
> static void *x = NULL;
> void *y;
>
> if (x == NULL)
> {
> x = arg;
> return arg;
> }
>
> y = x;
> x = arg;
> return y;
>}
>
>inline int
>myjump ()
>{
> __label__ bar;
> void *f();
> void *foo;
> static int myval = 1;
>
> foo = f(&&bar);
> goto *foo;
>
>bar:
> return myval++;
>}
>
>int
>main()
>{
> int i;
> int j;
> int k;
>
> i = myjump();
> j = myjump();
> k = myjump();
> printf ("%d %d %d\n", i, j, k);
> return 0;
>}
>
>Compiled using gcc 2.8.1 or egcs, without optimization, it prints
>"1 2 3", but with enough optimization to cause inlining, it prints
>"2 4 5" on my RH 4.2 Linux system, probably because the label
>feature is being abused (which gcc doesn't detect, but it does
>print "interesting" warnings about `i' and `j' when inlining, so
>perhaps it could detect this?).
>
>So, depending on the nature of code labels, vis-a-vis whether they're
>static a la variables, or static on a per-copy-of-function basis, seems
>to be unwise. Even though the gcc docs don't seem to explicitly disallow
>such use, they don't allow it either, and wise programmers wouldn't
>depend on such behavior. (Not only does the code above not work,
>but neither would depending on the equality of a `void *'-passed label
>determining whether the calling function was the same as some previous
>caller, or some such thing, be wise.)
>
>I suggest we revise the gcc docs regarding labels to clarify that
>any addresses of labels taken within a function during its invocation
>become invalid as soon as the function returns, just as is the case
>for passing `&a' given `int a;' within a function.
>
>We probably also should specify that comparing labels as addresses is
>not a reliable way to determine whether they refer to the same, or
>different, addresses. That is, &&foo and &&bar, even within a single
>function invocation with foo and bar being labels on different chunks
>of code, could evaluate to equal (gcc could place the generated code
>in the same place in memory, and use state info to disambiguate the
>code at run time), and perhaps even &&foo and another &&foo could
>yield different addresses within the same function (gcc could "flatten"
>programmer-visible state info into distinct code sequences, as long
>as it preserves the correctness of "goto *label;" following each
>corresponding "label = &&foo;").
>
>I think it's okay to allow passing &&label to another procedure, though,
>as long as the lifetime of that argument is the calling function
>invocation's lifetime, and the only use of the argument is to return
>the value back to the function or to print it out (or otherwise make
>it available) for debugging/logging purposes.
>
>Also, perhaps we should clarify the text on "inline" so readers know
>it is never safe to depend on inlining of any given function always
>happening. It's already said, but perhaps not clearly enough --
>some of the verbage seems to suggest otherwise in a few places, and
>not everyone reads the entire description before jumping to
>conclusions.
>
>In summary, I haven't seen any clear description of the semantic
>lossage being complained about, and can only guess that the problem
>is that gcc has decided to stop inlining something it used to inline,
>which is not great, but not a semantic problem, just an optimization
>issue that bare-to-the-metal coders must deal with on an ongoing
>basis. (To wit: if these functions hadn't *previously* been inlined
>due to their using &&foo, would the programmers have nevertheless
>used that feature, and given up the inlining, or given up &&foo?
>Either way, that's what they *can* do now, although ideally they
>shouldn't be made to choose. And they can macro-ize their way out
>of relying on &&foo, if they like.)
>
>I do wonder if a "pointer to `here'" feature might be useful in
>place of what I gather is a kludge to get some kind of pointer
>useful for debugging, logging, and so on. Perhaps `&& .' or
>`&& __label_here__' or similar could be reserved for that purpose,
>and be valid *only* as a `void *' that can be copied, printed, written
>to a file, etc., but not as the target of a `goto *x;' or any
>other pointer-like operation (++, +, -, ==, unary *, etc.).
>
> tq vm, (burley)
>Date: Tue, 28 Jul 1998 20:00:13 -0700
>From: "David S. Miller" <davem@dm.cobaltmicro.com>
>To: burley@gnu.org
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
> rth@cygnus.com, burley@gnu.org
>In-reply-to: <199807281536.LAA11100@melange.gnu.org> (message from Craig
> Burley on Tue, 28 Jul 1998 11:36:27 -0400 (EDT))
>Subject: Re: inline functions and local labels
>References: <199807281536.LAA11100@melange.gnu.org>
>
> Date: Tue, 28 Jul 1998 11:36:27 -0400 (EDT)
> From: Craig Burley <burley@gnu.org>
>
> I'm confused -- what are the choices? I've already tried to
> construct an example showing the differences, and can't do so
> without resorting to bogosities like having some external code
> somehow depend upon the uniqueness, or value, of labels passed to
> it as `void *' arguments. (See below for an example.)
>
>Craig, I apologize, I should have posted the code which behaves
>differently if not inlined (due to kenners patch) so that the behavior
>issue in question is more clear. There is a performance concern, but
>this is secondary compared to the loss in functionality change:
>
>extern __inline__ unsigned char *skb_put(struct sk_buff *skb, unsigned int len)
>{
> unsigned char *tmp=skb->tail;
> skb->tail+=len;
> skb->len+=len;
> if(skb->tail>skb->end)
> {
> __label__ here;
> skb_over_panic(skb, len, &&here);
>here: ;
> }
> return tmp;
>}
>
>We use this for debugging, and the debugging information becomes
>useless if the procedure is not inlined.
>
>Later,
>David S. Miller
>davem@dm.cobaltmicro.com
>Date: Wed, 29 Jul 1998 12:33:49 -0400 (EDT)
>From: Craig Burley <burley@gnu.org>
>To: davem@dm.cobaltmicro.com
>CC: kenner@vlsi1.ultra.nyu.edu, egcs-patches@cygnus.com, gcc2@cygnus.com,
> rth@cygnus.com
>Cc: burley@gnu.org
>In-reply-to: <199807290300.UAA05668@dm.cobaltmicro.com>
> (davem@dm.cobaltmicro.com)
>Subject: Re: inline functions and local labels
>
>>Craig, I apologize, I should have posted the code which behaves
>>differently if not inlined (due to kenners patch) so that the behavior
>>issue in question is more clear. There is a performance concern, but
>>this is secondary compared to the loss in functionality change:
>[...]
>>We use this for debugging, and the debugging information becomes
>>useless if the procedure is not inlined.
>
>Ah, I think I get it now.
>
>What you *want* is to "dump" the address of the caller's reference
>to the current function, so the ability to quickly localize the
>cause of the problem is improved somewhat.
>
>What you're *using* to get this is something different, which sometimes
>amounts to the same thing (e.g. when the code is inlined), but
>sometimes doesn't (e.g. when it isn't).
>
>A new notation added to gcc might be handy here (a notation that
>would basically be of roughly the same class as __PRETTY_FUNCTION__,
>though it'd involve lower-level code-gen issues than that).
>
>But it seems to me it'd be more worthwhile to consider implementing
>a general way to print a limited stack backtrace, which is an issue
>outside the language definition, and would require less cruft in
>your code overall.
>
> tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 12:20 ` craig
[not found] ` < 19990211201836.2781.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
>>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>>
>>>> >Why don't you just remove "inline" completely, then?
>>>>
>>>> Because it works just fine, and as documented, for 99.9999% of the
>>>> uses to which its put in code compiled by gcc?
>>>
>>>Right. So why break it then?
>>
>>By your apparent standards, it always *was* broken, because inlining
>>didn't always happen.
>
>No.
>
>gcc _did_ use to always inline if it at all could do so.
False. gcc *never* inlined 100% reliably. It might have tried,
and succeeded often enough, but other times, it just generated
bad code, or ran out of memory, or similar.
Exactly what would you do if one of those "reliable" gcc compilers
produced bad code when inlining? Remember: you do not have the
option of answering "change my code to work around the bug", since
you are complaining about having to change your code to be correct
according to the gcc docs. So what would you do, that you cannot
possibly cope with doing in the case you are now complaining about?
>There were
>cases that made it unable to inline, simply because the code itself was
>not conducive to inlining. Those were _technical_ reasons for not
>chosing to inline something, and completely and utterly understandable.
Yet, you completely and utterly do *not* understand some of the
common-sense reasons for gcc to choose *not* to inline something,
such as "the gcc developers decided generation of bad code was
too likely if a procedure meeting certain criteria was inlined"
and "the gcc developers decided it took too much memory to inline
this sort of procedure in certain circumstances".
Since "inline" is universally understood to be a *suggestion*, not
a *command*, it's not usually rigorously documented in terms of
exactly what conditions guarantee either 100% or 0% actual inlining,
especially not in the sense of a *specification* of the language
being compiled.
I'd be surprised if you could find a *single* compiler in the entire
market that documented *exactly* the criteria under which a procedure
would be guaranteed to be inlined, saying other procedures would
never be inlined. If you do, please switch to using it instead of
gcc. (It might be a Forth compiler, for example, so you'd have
to translate Linux into Forth. You'd probably be happier with the
results.)
>For example, not inlining a recursive function is just obviously the
>right thing to do (yes, in theory you could try to make it iterative,
>but if the programmer gave the compiler a recursive function then it's
>the _programmer_ who is responsible for it, and nobody really expects
>the compiler to do miracles).
*You* do. You expect the compiler to somehow *know*, all by itself,
with no human intervention, whether it is able to inline a procedure
from first principles and thus *always* produce correct code for any
case where it can be shown that inlining is at all possible.
Either that, or you expect the compiler *developers* to do miracles:
produce a compiler that can inline anything conceptually inlinable,
without ever producing bad code, running out of memory (when *not*
inlining *wouldn't* have), taking too much CPU time (compared to
*not* inlining), etc.
What is seems you're *really* saying, though, is that you prefer
the generation of bad code. Though it's hard to tell *what*
you're saying, other than "I feel the need to spew at people who
are just trying to do a good job, because they disagree with me
about something regarding which I have little expertise".
For example, you seem to think taking the address of a procedure
makes that procedure uninlinable. Wrong. It just does *currently*.
It won't always do so. I can easily imagine several ordinary,
common constructs that involve taking the address of a procedure
that a much smarter code-generation technology could happily take
into account when inlining. Same for recursion.
Therefore, all anyone can truly say about "inline" is that it is a
*suggestion*, and guidelines about whether it actually happens are
just those -- guidelines, which can change from release to release,
perhaps even compile to compile.
If you don't want inlining to happen; don't say "inline"; use
whatever compiler options disable inlining; inspect the generated
code to see if inlining happened, and modify the source code
as necessary to avoid it, or modify the generated code and be done
with it.
If you *do* want inlining to happen, same as above, only inverted:
say "inline"; use whatever compiler options enable inlining; inspect
the generated code to see if inlining happened, and modify the
source code as necessary to force it to, or modify the generated
code and be done with it.
In both cases, once you achieve the desired results, throw them out
the next time you compile, regardless of whether you're using the
exact same compiler, source code, etc., but especially if you're
using a new version.
There. I just stated what I bet *every* compiler vendor of the
industry would say, if pressed, about inlining and similar kinds
of optimizations. Though gcc might be unique in simplifying some
of the above by offering `-Winline', I would *not* stake my life,
limbs, or property on the assumption that any failure to inline
would result in that warning, because a bug preventing the
warning is just too easy to put into gcc.
>>Yet, as I said, even then, it works just fine, and as documented,
>>for 99.9999% of the uses to which it is put in code compiled by gcc.
>
>No. It used to work for 100% of the caaes gcc could handle.
Again, a false, and useless, statement. Any of the cases gcc could not
handle either it did not inline, or it generated bad code. I guess
you call generating bad code an example of inlinining being properly
"handled".
Essentially, you're making a case for generating bad code. It's rather
disturbing to know that the author of the most visible free-software
product prefers bad code to be generated, when given a choice
between that and not inlining as "directed" by the programmer.
>The change broke that.
Your code was broken, AFAICT, and the change brought that to your
attention. Please, deal with that and stop bugging us, though we
don't mind hearing about collateral changes resulting from bug-fixes,
especially when presented as such.
>It used to be a feature you could depend on.
It was always a feature you should *not* depend on, without using
`-Winline', providing external definitions to go with `extern inline',
or whatever was appropriate.
People who read the documentation *carefully* always understood that.
In that sense, you could and still *can* depend on "inline" working
properly. That means you have to *use* it properly, which you
clearly haven't been doing.
You really ought to research the extensions you're using more carefully
before using them. Perhaps you shouldn't be using them at all in a
product like Linux.
>The change broke that.
Again, no, it didn't. You could always depend on "inline" to be
a *recommendation* that gcc try and inline the procedure, and
that if it couldn't or wouldn't, fine. The results might or might
not be bad code; if bad code got produced, you could depend on the
gcc authors to try to quickly fix it, perhaps by disabling inlining
under certain circumstances until the underlying problem was fixed.
>Yes, the documentation had hedges to handle the real cases (like
>recursion etc) where inlining just isn't feasible, but the fact that it
>hedged its bets doesn't change the fact that people like me used to be
>able to rely on the compiler to do what it was asked to do.
That's correct. However, the blame does not fall on gcc, or on gcc
developers.
Guess who's left.
The documentation did *not* say "any procedure meeting criteria X
*will* be inlined" and then expand on criteria X. It *did* say
something much more like "procedures not meeting criteria X are
examples of those that won't be inlined". That's a very different
thing.
Even if the documentation had been incorrect, relying so much on
the documentation for a product like gcc is, to put it simply,
rather unwise. I don't trust documentation much, in general.
I've seen how it's put together. And I know something about
the language(s) in which it is written, and their propensity for
making it easy for the author to write things readers can
misunderstand.
>If it was a case of "oh, gcc used to have a 50-50 policy on when to
>inline, and the change made that a 40-60 policy", then it would have
>been much more palatable. But it wasn't. It was a case of 100% success
>being turned into "I wonder what the hell they'll break next time
>around".
In reality, it's a case of "I wonder how many more bugs like this
exist in Linux, which future changes in gcc might expose".
Your repeated claims that this constitutes "breakage" on *our* part
now constitutes an out-and-out lie, and I find it to be highly offensive,
since you've already been *thoroughly* corrected on this matter, yet
continue to state it.
The fact is: *your* code had the bug, not gcc, it was *your* code
that was broken, by relying on "inline" guaranteeing actual inlining.
Period.
That being said, yes, you *should* wonder what we'll break next time
around, given how much you depend on behavior not promised in iron-
clad terms in the documentation, and on the interaction of lots of
extensions, some of which are some combination of poorly documented,
poorly designed, poorly implemented, and rarely tested, even in
isolation.
>Repeatability is good. Random changes that break existing behaviour for
>no technical reason is bad.
I agree, but nothing was broken by this change that I've been able to
discern, based on the posts I've read.
In fact, it appears something was fixed.
There was a clear *technical* reason for the change, from what I
understand, and nothing particularly random about it.
That there apparently were collateral *changes* -- not *breakages* --
to generated code due to the fixes is unfortunate, and generally we
try to minimize that sort of thing, as a much-lower-priority thing
to worry about than, say, generating correct code or maintaining
some reasonable degree of performance vs. previous releases
(rougly speaking).
But, those kinds of collateral changes do *not* necessarily constitute
a bug in the end-user sense of the term, not even in the ordinary
sense of the term. Sometimes, things just change. Sometimes, these
changes expose previously hidden, broken code elsewhere, as appears
to be the case here.
>>(That's not surprising, since gcc is, generally, based on standards
>>such as ISO C, which presumably make it much clearer that "inline"
>>is, like "register", a mere hint.)
>
>"extern inline" is a documented gcc extension. It may be covered by ISO
>C these days, but it didn't use to be.
My old copy of ANSI C (draft) doesn't even cover `inline'. So, the
*only* source of information on it was the gcc docs, as it turns out,
unless you want to include drafts of subsequent standards or
something (*none* of which promised the behavior on which you're
depending, I'd guess).
Good engineering means not constructing a large-scale project to
depend on features specific to only one incarnation of a standard,
including its extensions, especially poorly-documented ones.
You'd be smart to stop using gcc-specific extensions in general,
at least to stop using them in so many dizzying combinations.
By "smart" I mean you'd be a better engineer.
If you don't care to be a better engineer, you shouldn't be surprised
when things that used to work fine stop working. (And if you do
become a true engineer, you'll learn to *expect* that ;-). Engineering
is, among other things, the science of designing things so they work,
period, AFAIK. I don't think gcc is very well-engineered in that sense;
it's clear Linux isn't, based on your posts, because innocuous
changes to gcc can, apparently, break it (else you're making a huge
fuss over nothing). At least the gcc developers seem to agree on
making it, on the whole, better engineered -- they generally know
better than to design it assuming undocumented behavior in underlying
products never changes.
You seem to think everything is black-or-white: do what the programmer
said to do, even if it means generating incorrect code, and, oh
by the way, never generate incorrect code.
Reality is different. Good engineering means having to come to terms
with reality.
>"address of a label" is a documented gcc extension, and is NOT covered
>by any C standard (pending or accepted) that I know of.
So why are you using it? Why would you design a product to so
completely depend on the correct interaction of a variety of
extensions supported by only one compiler out of so many choices
on the market?
How many *other* products do you know out there that depend to
a similar degree on the correct interaction of so many gcc
extensions? Are *their* authors so sensitive to changes in
code generation? If the answer is "none", then why are you
making *your* code *more* unreliable than the rest of the
industry by so depending? Is being on the "cutting edge"
that important? If so, why not *act* like someone who *understands*
what being on the cutting edge *means*?
("Hey, I've driven around this 25mph-posted turn at 80mph for
years now and never skidded out. *Now* you tell me this stuff
called `black ice' made me skid out and smash up my hugely
expensive car. It was *your* fault for not making this clear,
you should reimburse me for my car, and make sure this `black ice'
stuff never, ever happens again!")
>As such, the people who brought up "standards" as an argument for
>changing the behaviour are fairly hypocritical: it's a good argument but
>in order to hold water it has to be _relevant_.
I don't know that it isn't relevant or that they're being hypocritical:
my impression is, "inline" *is* covered by drafts of upcoming standards
of some relevance. But if you didn't read a product document, or even
a standards document, guaranteeing actual inlining in the presence of
"inline" in iron-clad, unambiguous terms, *you* were at fault for
depending on such actual inlining.
The reality is, you're trying to exploit nearly every detail of how a
particular compiler works without understanding what a compiler is, what
it does, how it evolves vis-a-vis the development process, language and
library standardization, and so on.
Please stop doing that. Stop using compilers, or at least stop using any
extensions they offer and stop relying on any *particular* behavior they
exhibit. Or, *learn* what compilers are all about, if you have the
10 years or so to spend doing it.
You've gotten *tons* of good, solid advice about the issues involved
from people with far more pertinent expertise than you have developing
operating systems, and have so far done a damn fine job of ignoring it.
If you think the "fixes" to the recent "objectionable" patch will
solve your problems, they won't -- because the underlying problems
are *yours* and thus Linux's, not gcc's. The problem, or some
problem just like it, *will* occur in the future, and our response
will be basically the same: sincere attempt to minimize collateral
changes while striving, *first and foremost*, to prevent the generation
of bad code. You Have Been Warned. Yet Again.
Given that we've gone through this with you in the past (and not
just in the area of compilers, IIRC), I suggest you wean Linux
from depending on gcc at all. Make it compilable by any ANSI C
compiler, for example. Then maybe you won't get so upset every
time a fairly trivial change to gcc's code generation occurs, and/or
we won't have to endure your flames.
That would be a heck of a lot more progressive than just deciding to
stick with gcc-2.7.2.1 forever. But if you want to go that route, it
isn't necessarily a bad decision either, as it'll amount to "nailing
down" the behavior of one crucial component in a much larger, complicated
system (Linux), meaning the developers of the larger system can learn
how to avoid the problems in the nailed-down gcc, which they'll
learn more and more about as time goes on. (There are disadvantages
to that approach, of course. You'd be changing your code to work
around known bugs in 2.7.2.1 rather than changing it to better
accommodate ongoing improvements in compiler technology, for example.
In the long run, Linux would end up either coded entirely in `asm'
directives, or running slower than other operating systems that
had fewer lines of code and, probably, more features.)
The decision is yours. Our viewpoints on this matter will not change,
because they cannot -- if we made you the promises you seem to want,
we'd be lying, in which case we might as well go into politics so
we can get babes and power. That'd just leave gcc development open
to others who aren't suited for that kind of thing, i.e. the current
situation. So the only reasonable possibility is for *you* to adapt.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 18:13 ` Mark Mitchell
@ 1999-02-28 22:53 ` Mark Mitchell
0 siblings, 0 replies; 180+ messages in thread
From: Mark Mitchell @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: pderbysh, egcs
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
Linus> The problem for me is that if I really have to create
Linus> duplicates of all "extern inline" functions, the while
Linus> thing is completely useless to me. It does _not_ act
Linus> "almost as a macro" any more, it acts almost completely
Linus> differently.
Why not put the inlines in a header file, and #include them (with
suitable macros to make the `extern inline' go away) in a .c file?
For example:
foo.h
-----
#ifndef EXTERN_INLINE
#define EXTERN_INLINE extern inline
#endif
EXTERN_INLINE int foo () { return 1; }
foo.c
-----
/* I bet `foo' will always be inlined, but just in case, and for
debugging, we provide an out-of-line version here. Put me in an
archive, so that I am only linked if if every occurrence of foo
is not inlined. */
#define EXTERN_INLINE
#include "foo.h"
I know this might require a bit of reorganization, but it is without a
doubt the idiom that GCC's documentation has explicitly endorsed for
quite some time.
Conflicts with C9X are another matter, of course, but you can be quite
sure that GCC will suport the C89+GNU dialect for quite some time to
come, I think. (I know that you might take objection to that last
statement w.r.t. your recent address-of-label/inline experience, but
let's not get into that. I think you know what I mean.)
By the way, I bet that you will at some point have to declare that the
kernel cannot be compiled with a GCC version older than `X' for some
`X', especially if you use anything other than straight ANSI C. After
all, those old versions had different bugs than current versions, and
you're quite likely to see different code-generation problems. You
say that using new features of GCC would cause people to complain when
old compilers failed to compile the code, or silently generated bad
code, but you could avoid that with
#if __GNUC__ <= 2 || __GNUC_MINOR__ <= XXX
#error "Your compiler is too old to compile this kernel."
#endif
I bet people would understand. But, you're a lot more in touch with
the people building kernels than I am, so I'll defer to your opinion.
--
Mark Mitchell mark@markmitchell.com
Mark Mitchell Consulting http://www.markmitchell.com
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 17:51 ` Linus Torvalds
@ 1999-02-28 22:53 ` Linus Torvalds
0 siblings, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Joe Buck; +Cc: leei, ross.s, egcs, hpa
On Mon, 8 Feb 1999, Joe Buck wrote:
>
> Hmm. Linus does seem to have a point here. See the node "Inline"
> in the gcc manual.
Thank you. Exactly.
This is not about "what would we do if we redesigned the language". This
is about existing users that have used behaviour and documentation that
has been stable for at least the 8 years I've used gcc, and are extremely
irritated at some willy-nilly changes that break existing documented usage
for no apparent technical reason.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 15:44 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212153656.31280J-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: egcs
On 12 Feb 1999 craig@jcb-sc.com wrote:
>
> P.S. Yes, folks, I realize that Linus almost certainly won't bother
> actually reading the below
I actually do real the email I get. I just don't have time to answer all
of it. I've answered most of the relevant postings (but not all of the
contents) in this thread because I feel strongly that there _is_ a real
need to have what I call a "working inline" while you obviously don't
think so.
The emails you quote are from the previous time this happened. As now,
nobody actually suggested a good working way to do what we wanted to do
without just completely resorting to macros (and I've already explained
why I dislike macros).
What you suggested then isn't any better than what you're suggesting now:
implementing new features in gcc doesn't obviate the need to be able to do
the same thing with old code. And implementing a back-trace by hand is
architecture- and compiler-dependent, which is silly because when that
breaks due to compiler changes you'd just complain that we should do
something else. You can't have it both ways, Craig.
Face it: what Linux does is entirely reasonable, trying to get a backtrace
in a architecture-independent way. Yes, it bit us, but it was certainly
not an unreasonable thing to do.
Do you really think it's unreasonable to ask for some way of forcing
inlining, when the compiler obviously can do it? It doesn't have to be
"extern inline", if you're afraid of polluting a future standard
namespace.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 10:12 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212095518.31280C-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: egcs
On 12 Feb 1999 craig@jcb-sc.com wrote:
>
> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
> >to use gcc extensions, because I think they are worthwhile in the kernel.
>
> That means, like I already said, you have to be prepared for a very
> bumpy ride. You've shown that you have trouble coping with that.
Umm..
I had no problems with gcc features for about six or seven years of Linux
development. These things simply didn't use to happen: despite upgrading
_major_ versions of gcc (when Linux started we were using gcc-1.40), for
those six-seven years there weren't really any changes that I ever had
problems with.
There were tons of code generation bugs over time, but hey, I _expect_
bugs, and while compiler bugs are sometimes really hard and nasty to find,
I don't complain too much: I report them, and I tell people not to use
certain versions. I may be grumpy for a while because I spent ages looking
at a bug that didn't turn out to be mine, but I never get the feeling that
I should really dislike the compiler people.
The reason I have been complaining so much lately is that I think that the
egcs development has lost that stability. Again, never mind code
generation bugs, I'm talking about _interface_ stability. I've had much
more problems in the last year than I had in the seven years preceding
this.
This may actually not be due to technical reasons as much as simply due to
a different open development model - it may just be that more people see
"partial" work, and some of that partial work breaks stuff. Fine - I like
open development myself, and I use it. But when somebody complains to _me_
that I broke old interfaces, I consider that a bug unless I have a very
very strong technical reason to tell people that I simply _cannot_ support
some old interface any more.
In contrast, on this list, when people complain that egcs breaks existing
code, the answer is "shut up and live with it" - and then they Cc: me on
the damn thing. And that's why I get so upset, and why these flame-wars
erupt.
"Shut up and live with it" is not a way of caring for your customers. And
creating the best compiler in the world is not just about code generation:
it's about supporting the people that use it, too.
I could change my kernel interfaces and tell people that "shut up,
recompile, and be happy". Trust me, that doesn't work when you have a
serious project that you expect others to be serious about too. I make
_damned_ sure that I don't break binaries, and when I do it by mistake I
have egg on my face and I fess up to screwing up.
On this list, nobody 'fesses up to screwing up any more. And that's sad.
It makes the egcs project look less serious, and more like a bunch of
people that just want to play at making a commercial-grade compiler.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Removing code dupe in libc (Was: A final solution...)
1999-02-12 21:14 ` Zack Weinberg
[not found] ` < 199902130514.AAA00047@blastula.phys.columbia.edu >
@ 1999-02-28 22:53 ` Zack Weinberg
1 sibling, 0 replies; 180+ messages in thread
From: Zack Weinberg @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Sat, 13 Feb 1999 00:01:28 -0500, Paul Derbyshire wrote:
>At 09:02 PM 2/12/99 -0500, you wrote:
>>Or you can isolate the inline functions in their own header file, and
>>have a separate C file that just does
>>
>>#define inline /* nothing */
>>#include <linux/inlinefuns.h>
>>
>>No code duplication, and if all the inlines went through, the linker
>>will throw away the unnecessary object module.
>
>That same technique might be usable to remove the code duplication wart
>with libc. The object module generated goes in libc.a; the linker will
>ignore it if all the functions used inlined.
>For dynamic linked implementations, the object module goes in libc.so and
>the dynamic linker will ignore it.
Actually, there isn't code duplication in libc. The inline functions
in the headers are limited in what they'll do themselves, they fall
back to out-of-line calls for the general case. This is done with an
ungodly mess of macros, special-case-only functions, and compiler
extensions. We rely on cse to crush out the mess.
I do wish there was a cleaner way to do it. Replacing cpp with M4
wouldn't be a bad start...
zw
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
1999-02-12 9:04 ` craig
@ 1999-02-28 22:53 ` craig
0 siblings, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: Marc.Espie; +Cc: craig
>In article < 19990212034058.4359.qmail@deer > you write:
>>>and on the whole we'd like to try triggering that sort of thing,
>
>>I meant "try *to avoid* triggering", which I hope was obvious.
>
>Actually, no, it's not obvious at all. It's better if the compiler
>says `your code is plain wrong, you dummy', but a compiler that breaks
>things when you don't follow clean coding practices is a GREAT teaching
>tools. :->
I agree with that last sentiment, but I'm not sure there'll be much
agreement that *gcc* should default to be a great teaching tool.
And as long as people who *think* they don't need teaching can
turn off its teaching facilities, they'll do it...while the people
who really *don't* need it for teaching would avoid a product
that insists on wildly changing its behavior (even if entirely within
spec) even as their overall product nears deployment stage.
But, as it turns out, if we just concentrate on making it a better
optimizing compiler with only modest emphasis on teaching-tool-like
features (-pedantic, -Wall, etc.), it'll someday, sometime, somehow,
somewhere, teach most of its users *not* to make so many assumptions
about how it works.
And, from an engineering perspective, I prefer that tools as complex
as gcc be designed so they offer a simple "switch" of sorts between
the default mode -- "work as much like you always have as possible" --
and the stress-my-system mode, aka "change as much as you can about
how you work while remaining within specs, so I can see if my system
is designed to use it with the proper tolerances".
(Which makes me wonder if we should offer a switch to make gcc
go increasingly out of spec, for people who want to find the point
of actual failure. Kind of like how aircraft manufacturers don't
just test to see whether the wings of a jet can flex *within* specs
without breaking, but literally flex them until they *do* break
so they can see how far out of the specs the wings' tolerances are,
or how drug manufacturers stuff helpless animals full of a new drug
until it dies to see what it really takes to do that. When it
comes to the equivalent for gcc, these days, I feel like I want
to nominate penguins for the testing.)
>A bit like wacking puppies on the nose to teach them proper toilet
>habits...
I don't know whether there have been better (less physical) methods
devised vis-a-vis house-training dogs, but I'm under the impression
that there have been improvements in "breaking" horses, requiring
much less physical control of the animal and achieving much faster
results. I gather this has to do with using techniques that gain
the animal's respect using the cues the horses themselves are
genetically predisposed to recognize, as compared to the traditional
methods, which are more like whacking them on the nose with a paper
(use of infliction of pain and direct physical control).
It is true that, if you don't know how to reach the subject directly
using it's own open mind, sometimes the best you can do is develop
some kind of Pavlovian response in it so that it avoids bad behavior.
But, I like to think we can do better. By figuring out how to earn
the respect of potential gcc users by showing we have a solid appreciation
of what it takes to work in *their* field and, at the same time,
that we won't tolerate their attempting to control us in our own,
perhaps we can gain their respect (making it mutual, since we'll
be coming into the situation with our own respect for their field),
making the job of educating them much easier.
Then, instead of relying on the unexpectedly disastrous-but-conforming
behavior of products like gcc to frustrate them out of employing bad
coding habits, we might find they're much more receptive to employing
*good* coding habits from the outset, making the mutual relationship
much more enjoyable, and less stressful, for all.
In my personal experience, I've found this to be pretty easy with the
Fortran audience, to the (very modest) extent to which I've been able
to practice it.
What we now need is someone who is able to practice these techniques
with regards to the Linux developers, especially Linus Torvalds.
I.e., a "Norse Whisperer".
(Okay, seriously, how many of you *really* saw that coming? :)
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Removing code dupe in libc (Was: A final solution...)
1999-02-12 21:02 ` Removing code dupe in libc (Was: A final solution...) Paul Derbyshire
[not found] ` < 3.0.6.32.19990213000128.0089c2a0@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 09:02 PM 2/12/99 -0500, you wrote:
>Or you can isolate the inline functions in their own header file, and
>have a separate C file that just does
>
>#define inline /* nothing */
>#include <linux/inlinefuns.h>
>
>No code duplication, and if all the inlines went through, the linker
>will throw away the unnecessary object module.
That same technique might be usable to remove the code duplication wart
with libc. The object module generated goes in libc.a; the linker will
ignore it if all the functions used inlined.
For dynamic linked implementations, the object module goes in libc.so and
the dynamic linker will ignore it.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 23:48 ` Jeffrey A Law
@ 1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 0 replies; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Zack Weinberg, egcs
In message < Pine.LNX.3.95.990212175435.31280O-100000@penguin.transmeta.com >yo
u write:
> If I were to do that, I'd at least ask the egcs people to add to their
> regression suite a testcase like this:
[ ... ]
Agreed and done.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 14:24 ` A final solution. (Was Re: kernel-2.2.1-undefined references.) Paul Derbyshire
[not found] ` < 3.0.6.32.19990212172337.0082de00@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
>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.
Uh... it kind of occurs to me that perhaps the simplest solution is just to
actually use a macro there? Then you can be damn sure it will inline,
because the preprocessor will have done it before egcs ever gets to see
your sources. :-)
>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".
Ah. I see your point about inline versus actual macros. Maybe the solution
is this. First, 'extern inline' loses special significance, particularly
because of the standard likely covering the usage soon. On the other hand,
GCC can add __attribute__ ((always)) as an extension that will force
inlining of the function under well-determined conditions, specifically,
that it is not recursive. (The same rule that governs whether a macro
"inline function" will work properly.)
That leaves the sticky issue of taking addresses. An ordinary pointer to
function address taking can just force "exlining" a copy as a normal
function whose address will be used for pointers to functions (what is
presumably already done with plain-jane "inline" when it is inlined but the
function address is used). GCC can also perhaps try to optimize by
replacing function invocations through pointers with inline functions if a)
the function that will be invoked is known at compile time and b) it is
inline.
As for taking the address of a label in an inline function and using it,
this is trickier.
1: If the label will be encountered and then a goto is used on it,
the compiler could use setjmp/longjmp to do it, thereby making
sure thre goto goes to the correct inlined version.
2: Otherwise, it is trickier. One possibility is to exline an
instance as a normal function and use the address of the label in
that copy.
3: To dodge the ambiguous address problem altogether when only one
instance will be inlined anyways, add an __attribute__ ((once)),
and have the compiler inevitably inline the function (if
nonrecursive) the first time it sees it. If it sees a second
invocation, that's an error. Otherwise, label addresses
unambiguously refer to the one instance.
4: An __attribute__ ((always)) or __attribute__ ((once)) that is
recursive or otherwise uninlinable generates an error, regardless
of -Winline.
Now, does this look like it'll make everybody happy?
>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.
Have you tried changing them back to see if everything works perfectly?
>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).
The address-of-label is just used to generate displayed information? That
simplifies things a lot. If the address is only taken right at the label
itself, then it seems reasonable to make an inline __attribute__ ((always))
label and label address situation work like this:
-- The address-of-label operator can be invoked on the label only
inside the function.
-- Then, it refers to the specific instance in the same inlined copy
with the address operator.
-- Other uses are an error.
-- This can be implemented by making inlined functions with
__attribute__ ((always)) and labels generate a different label
symbol according to some mangling scheme for each instance, and
the address-of refer to the appropriate mangled symbol when used
legally.
-- The documentation can be made to reflect the details of this and
of the circumstances for its legality.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Enough is enough... truce time. Re: kernel blah blah blah
1999-02-12 16:02 ` Enough is enough... truce time. Re: kernel blah blah blah Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: egcs
Ohh....my...GOD.
*referee whistle blowing sound*
HEY. Lets have a truce here... no more mudslinging and general aggravated
shouting. I'd think that's beneath the station of the likes of Linus
Torvalds and the GCC/EGCS development gurus.
In "A Final Solution." I suggested some ways to change the compiler or
Linux or both to meet everyone's needs and leave everyone happy.
As for who's wrong, I don't think anyone is. There has been a
*misunderstanding* about the ambiguous phrase "like a macro" in the
documentation. Some took this fairly literally regarding faithfulness of it
being expanded inline; others took it to mean "like a macro when it is
inlinable". Chalk it up to ambiguous documentation, and let's bury the
hatchet. And to reiterate, there are 3 things that can be done.
1. Make the dox clearer about "extern inline".
2. Linus, if worse comes to worst, you may just have to replace one-
off inlines with macros, or at least use -Winline and jiggle it
until it inlines. This strikes me as rather unsatisfactory
however.
3. EGCS developers, if "extern inline" can't be and wasn't meant to
be what Linus had in mind after reading the dox for it, I suggest
adding an __attribute__ ((always)) that causes an error if the
function is not inlinable or a label address from a label inside
the function is used outside it and an __attribute__ ((once)) that
inlines a function where it's used, making an error if it's used
more than once; this means that the compiler can inline the
functions with these attributes without any worry that it will
lead to ambiguous references to addressed labels.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 18:01 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212175435.31280O-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: law; +Cc: Zack Weinberg, egcs
On Fri, 12 Feb 1999, Jeffrey A Law wrote:
>
> Yea, the way this is handled (code duplication) is suboptimal, but it has been
> the way the docs have suggested handling extern inline functions since at
> least 1991.
Note that "static inline" is fine for me, if it 99% of the time is
honoured: even if the thing is sometimes statically compiled a few extra
times, who cares because it's not going to be a big issue.
However, then we get people with compiler warnings. I don't remember which
particular version of gcc it was that warns about "static but not used"
(it's not the one I use, but it was one reason why we switched over
whole-sale to "extern inline" in header files). That gcc may be rare
enough that we can just make sure nobody uses it any more.
If I were to do that, I'd at least ask the egcs people to add to their
regression suite a testcase like this:
static inline int unused_fn(int dummyarg)
{
return dummyarg*dummyarg;
}
int main(int argc, char **argv)
{
return 0;
}
and the test-suite would be compiled with "-Wall -Werror" so that nobody
ever makes it a warning to not use a "static inline" thing?
Then I could just ignore "extern inline", or maybe use it if I ever want
to re-introduce the skb_put() kind of "must be inlined to get correct
debugging information" thing for some hack.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 19:41 ` craig
[not found] ` < 19990212034058.4359.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: d-dooling, egcs; +Cc: craig
>and on the whole we'd like to try triggering that sort of thing,
I meant "try *to avoid* triggering", which I hope was obvious.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-14 9:08 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214120800.0087f100@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 03:24 PM 2/13/99 -0000, you wrote:
>Do you have any bounced email to forward along, so I can see what
>was actually happening? That's the first thing my ISP would
>ask for, probably.
Yeah. Here. (Apologies to list, but since Craig's mail server is still
bouncing mail intermittently...)
I already tried sending this to postmaster@jcb-sc.com, and got the same
sort of bounce. I did Whois lookup and saw their technical and admin
contacts at world.std.com; I mailed them suggesting they fire the
postmaster and noc at jcb-sc.com and telling them why, and world.std.com
bounced as well. Is damned weird.
At least if you suddenly find that your subscription to egcs lists has
evaporated, you'll know why (your server started bouncing incoming mail
again and triggered the automatic bad-address-unsubscribe) and who to blame
(your ISP).
>The original message was received at Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>from dialin109.ottawa.globalserve.net [207.176.153.109]
>
> ----- The following addresses had permanent fatal errors -----
><craig@jcb-sc.com>
>
> ----- Transcript of session follows -----
>... while talking to world.std.com.:
>>>> MAIL From:<pderbysh@usa.net>
><<< 550 Wrong.
>554 <craig@jcb-sc.com>... Service unavailable
>Reporting-MTA: dns; smtp2.globalserve.net
>Received-From-MTA: DNS; dialin109.ottawa.globalserve.net
>Arrival-Date: Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>
>Final-Recipient: RFC822; craig@jcb-sc.com
>Action: failed
>Status: 5.0.0
>Remote-MTA: DNS; world.std.com
>Diagnostic-Code: SMTP; 550 Wrong.
>Last-Attempt-Date: Fri, 12 Feb 1999 19:02:40 -0500 (EST)
>Return-Path: <pderbysh@usa.net>
>Received: from chaoszone (dialin109.ottawa.globalserve.net [207.176.153.109])
> by smtp2.globalserve.net (8.9.1/8.9.1) with SMTP id TAA19254;
> Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>Message-Id: < 3.0.6.32.19990212190141.00891c70@pop.netaddress.com >
>X-Sender: pderbysh@pop.netaddress.com
>X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
>Date: Fri, 12 Feb 1999 19:01:41 -0500
>To: craig@jcb-sc.com
>From: Paul Derbyshire <pderbysh@usa.net>
>Subject: Enough is enough... truce time. Re: kernel blah blah blah
>Cc: egcs@egcs.cygnus.com
>In-Reply-To: < 19990212221225.22651.qmail@deer >
>References: < 7a203j$9cf$1@palladium.transmeta.com >
> < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
> < 19990211201836.2781.qmail@deer >
> < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
> < 19990212031118.4271.qmail@deer >
> < 7a203j$9cf$1@palladium.transmeta.com >
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>Ohh....my...GOD.
>
>*referee whistle blowing sound*
>
>HEY. Lets have a truce here... no more mudslinging and general aggravated
>shouting. I'd think that's beneath the station of the likes of Linus
>Torvalds and the GCC/EGCS development gurus.
>
>In "A Final Solution." I suggested some ways to change the compiler or
>Linux or both to meet everyone's needs and leave everyone happy.
>
>As for who's wrong, I don't think anyone is. There has been a
>*misunderstanding* about the ambiguous phrase "like a macro" in the
>documentation. Some took this fairly literally regarding faithfulness of it
>being expanded inline; others took it to mean "like a macro when it is
>inlinable". Chalk it up to ambiguous documentation, and let's bury the
>hatchet. And to reiterate, there are 3 things that can be done.
>
>1. Make the dox clearer about "extern inline".
>2. Linus, if worse comes to worst, you may just have to replace one-
> off inlines with macros, or at least use -Winline and jiggle it
> until it inlines. This strikes me as rather unsatisfactory
> however.
>3. EGCS developers, if "extern inline" can't be and wasn't meant to
> be what Linus had in mind after reading the dox for it, I suggest
> adding an __attribute__ ((always)) that causes an error if the
> function is not inlinable or a label address from a label inside
> the function is used outside it and an __attribute__ ((once)) that
> inlines a function where it's used, making an error if it's used
> more than once; this means that the compiler can inline the
> functions with these attributes without any worry that it will
> lead to ambiguous references to addressed labels.
>
>--
> .*. "Clouds are not spheres, mountains are not cones, coastlines are not
>-() < circles, and bark is not smooth, nor does lightning travel in a
> `*' straight line." -------------------------------------------------
> -- B. Mandelbrot | http://surf.to/pgd.net
>_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
>Programmer & Humanist|ICQ: 10423848|
>
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 12:57 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990211125202.18523E-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: egcs
On 11 Feb 1999 craig@jcb-sc.com wrote:
>
> >"address of a label" is a documented gcc extension, and is NOT covered
> >by any C standard (pending or accepted) that I know of.
>
> So why are you using it? Why would you design a product to so
> completely depend on the correct interaction of a variety of
> extensions supported by only one compiler out of so many choices
> on the market?
Are you being stupid or argumentative?
To _me_, "standard C" has not been important at all. I'm _more_ than happy
to use gcc extensions, because I think they are worthwhile in the kernel.
So "address of label" is a documented feature of the only compiler I
compile the kernel with. As is "inline". And my argument was that
_neither_ of those features were mentioned in any C standard ("inline" has
since been added to the proposed standards) - but they were very much
mentioned in the gcc documentation.
Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
their argument just needs to think twice. That was my only argument. I'm
just trying to show people how silly it is to say that "oh, the standard
says that 'inline' is just a hint", when the current C standard says
nothing of the sort at ALL.
[ rest of your silly email removed - you seem to be arguing against using
gcc in the first place. I just want to make sure that gcc continues to
be usable and good for Linux ]
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 16:32 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 11:15 PM 2/11/99 -0000, you wrote:
>Obviously the combination of these extensions worked sometimes.
>Is there any way to find out when it works and when it doesn't?
>It should be a deterministic problem, no?
So is the halting problem <g>
[deletia]
Well said. Let's all get along.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
1999-02-12 9:00 ` craig
@ 1999-02-28 22:53 ` craig
0 siblings, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: alex.buell; +Cc: craig
>On Fri, 12 Feb 1999, Marc Espie wrote:
>
>> A bit like wacking puppies on the nose to teach them proper toilet
>> habits...
>
>Are you saying Linus needs toilet training? <ducks>
Maybe it's been too long since I was involved in any toilet training,
but, my word, I don't remember *ducks* being involved....
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 17:50 ` Jeffrey A Law
[not found] ` < 10147.918870502@hurl.cygnus.com >
@ 1999-02-28 22:53 ` Jeffrey A Law
1 sibling, 0 replies; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Zack Weinberg, egcs
In message < Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com >yo
u write:
> I'm also sorry that almost nobody saw the point of having a macro-like
> inline. I don't like duplicating code like in libc (where code duplication
> makes sense - having a "official compiled sequence" to link against, with
> a separate version for inlining for optimization). As it is, I guess
> "extern inline" is just useless for what I wanted to do, and nobody seems
> to have a good alternative that doesn't result in more flamage, so while
> I'm disappointed I'll just shut up and lick my wounds.
Yea, the way this is handled (code duplication) is suboptimal, but it has been
the way the docs have suggested handling extern inline functions since at
least 1991.
This combination of inline and extern has almost the effect of a macro. The
way to use it is to put a function definition in a header file with these
keywords, and put another copy of the definition (lacking inline and extern)
in a library file. The definition in th header file will cause MOST calls
to the function to be inlined. If any uses of the function remain, then
will refer to the single copy in the library.
Emphasis on MOST added by me.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 10:54 ` Joe Buck
@ 1999-02-28 22:53 ` Joe Buck
0 siblings, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs, hpa, leei, ross.s, egcs
[ __builtin_constant_p ]
> It works in development versions of egcs, but as far as I know of it does
> not work in _any_ released version of gcc. It certainly is not something
> you can really use anyway, as using it requires that all users have to
> upgrade: which may be acceptable in some environments, but is certainly
> not an option in most places.
If the feature gives a clear win, it is possible to use it with a
preprocessor check. To oversimplify a bit:
#if __GNUC_MINOR__ > threshold
... code using the feature
#else
... older code
#endif
Since this conditional compilation gives one more thing to test for, the
developers might choose not to use it unless the win is large enough
to justify it.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 20:01 ` Jeffrey A Law
@ 1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 0 replies; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Joe Buck; +Cc: Linus Torvalds, Marc.Espie, egcs
In message < 199902110155.RAA14069@atrus.synopsys.com >you write:
> so many insults. The change in question was not "for no good reason", it
> was an attempt to decrease the virtual memory consumption of gcc (I don't
> know how much it helped). If the change has limited value and harms the
> Linux kernel, that may be a good reason to revert the change. It has not
> gone into a release, only a snapshot.
To clarify, the change was not because c++ memory consumption. It was to fix
a real bug -- imagine what happens if you have label initializers which are
used by indirect jumps and you inline the function.
See execute/980526-1.c
The C++ inline memory changes are still in the queue, they haven't been
installed yet.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 17:56 ` Joe Buck
[not found] ` < 199902110155.RAA14069@atrus.synopsys.com >
@ 1999-02-28 22:53 ` Joe Buck
1 sibling, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marc.Espie, egcs
> And no, very few others are complaining, because the breakage only
> happened when you used two gcc extensions together ("inline" and address
> of a label). Linux is probably the only thing that actually uses a lot of
> the extensions.
Unfortunately, this makes it more likely that the egcs development will
occasionally break Linux; we just don't have that many test cases for
interaction between gcc extensions. When these are encountered we'll
just have to fix them.
I think that it's perfectly reasonable to ask that the change that broke
this be reverted enough so that you can get the function in question
inlined again, and I'm sure that folks like Jeff are eager to assist you
with just that. I only hope that in the future it can be handled without
so many insults. The change in question was not "for no good reason", it
was an attempt to decrease the virtual memory consumption of gcc (I don't
know how much it helped). If the change has limited value and harms the
Linux kernel, that may be a good reason to revert the change. It has not
gone into a release, only a snapshot.
In the future if a change to a snapshot breaks Linux, please report it as
a bug, and I'm sure it will be treated as high priority. To avoid another
round of flamage, it's best to indicate clearly that the code relies on
GNU extensions, so that the (rather large) group of people whose main
interest is a good compiler for conforming code won't get bent out of
shape and fill the list with "but the standard doesn't guarantee that
you can do that" mailings.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 16:51 ` Bryan W. Headley
[not found] ` < 36BF94AB.A7CD5DF5@interaccess.com >
@ 1999-02-28 22:53 ` Bryan W. Headley
1 sibling, 0 replies; 180+ messages in thread
From: Bryan W. Headley @ 1999-02-28 22:53 UTC (permalink / raw)
To: Ross Smith; +Cc: egcs
Ross Smith wrote:
> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer. That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >Note you have a rather atypical perspective. You know the hardware
> >in depth, and you know which instruction sequences will be faster.
> >You probably know (or at least can make an informed guess) if inline
> >will help or hinder the code. You also sometimes need precise control
> >over low-level code.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
>
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
>
> (A) inline == "I [the programmer] know exactly what this code is
> supposed to do at low level, and I have determined that this function
> must be inline for proper behaviour, so inline it or give me an error
> if you [the compiler] can't."
>
> (B) inline == "I [the programmer] believe this code would be more
> efficient if this function were expanded inline, so please do so
> unless you [the compiler] have a good reason to do otherwise."
>
> Linus wants (A), but the inline keyword, as defined by ISO C++,
> mandates (B). Exactly what consitutes a "good reason" is a function of
> compiler technology. In many cases, compilers *are* smarter (about
> certain specific things) than programmers, and will quite rightly
> override the programmer's choice. For inline, this is rare today, but
> will get more common until eventually "inline" goes the way of
> "register".
>
No, I heard more than that. Such as, the compiler may opt to make a function
into an inline based on optimization. Which scares the hell out of me, too.
The argument, though, should be telling you that basing a C compiler
front-end on top of a C++ engine is going to become more and more risky.
There once was a time when there was a tight correlation between the C code
and the assembly. With C++, with "hidden" destructors to deal with exception
handling, jump tables to give the feel of class heirarchy, etc., you cannot
say that anymore.
I like Per's comments about not being able to produce a compiler that behaves
like Linus would want. It sort of makes Messrs Kernighan, Richie and Thompson
just a little bit more special than they are already :-)
#include <bryan/has/little/respect/for/ansi/nor/iso/as/they/are/usually/10/years/behind>
--
____ .:. ____
Bryan W. Headley - bheadley@interaccess.com
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 17:18 ` Joe Buck
[not found] ` < 199902090116.RAA15478@atrus.synopsys.com >
@ 1999-02-28 22:53 ` Joe Buck
1 sibling, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: Lee Iverson; +Cc: torvalds, ross.s, egcs, hpa
> I've yet to see *any reference* to the claim that it is *documented*
> that the inline declaration *guarantees* that the function will always
> be inlined. Even with extern. That was your assumption, reading
> between the lines...
RTFM.
Remember, we are not talking about ISO C++ here. We are talking about
*C*, and specifically the GNU "extern inline" extension. So the M to R
is the gcc manual.
We may have an issue later on with C9X, which may define "extern inline"
to mean something different.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-13 1:22 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
>(BTW, I dislike macros too. C is just too weak a language to get
>much done without them, though. I had high hopes for C++ around
>10 years ago, but....)
But... what?
C++ is great. Templates, consts, ... no more macros exceptto
controlcompilation.
Now we just have to sit and wait for a compiler to come out that finally
supports the standard completely, from the standard library (including
<limits>) down to proper template linkage. Which some experimental egcs
snapshot is purportedly able to do.
[some deletia]
He didn't want lots of new features. He didn't even want a cross vendor
portable way to get a stack trace. He just wanted a way portable across GCC
implementations to get a stack trace.
>...new architectures, such as massively parallel machines,
>"massively serial" machines, etc.
"Massively serial"? By which you mean what, with thousands of cpu
registers, or terahertz clock rate, or...?
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-14 19:13 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214221218.008eacc0@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
>Read archives of comp.compilers and related works if you really
>want to learn why "C is closer to the machine than Fortran" is,
>for all intents and purposes, something between a myth and a self-
>fulfilling prophecy. And why "volatile" is a great example of a
>supposedly necessary feature that, linguistically speaking, makes
>almost every computer language that incorporates it *worse* than
>it would be without it.
I don't think so. How the hell else can you write C code that works with
data that changes asynchronously, e.g. because of multiple threads or
because of hardware or interrupts or signal handlers or...
The choices are:
1. Don't optimize at all -- UNACCEPTABLE
2. Mark data the compiler isn't to optimize into registers and about
which it isn't to make any assumptions regarding the value being
consistent.
The latter gets us 'volatile'.
Which do you choose?
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 14:55 kernel-2.2.1-undefined references Ross Smith
[not found] ` < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz >
1999-02-08 16:51 ` Bryan W. Headley
@ 1999-02-28 22:53 ` Ross Smith
2 siblings, 0 replies; 180+ messages in thread
From: Ross Smith @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
From: Per Bothner <bothner@cygnus.com>
>
>[Linus wrote:]
>> I'm not trying to be unreasonable. I'm just saying that if there is a
>> function that is marked inline that can be inlined, it _should_ be
>> inlined, because the compiler _never_ knows better than the programmer.
>
>Er, the compiler often knows better than the programmer. That is why
>we use compilers - to free us from low-level and architecture-dependent
>decisions.
>
>Note you have a rather atypical perspective. You know the hardware
>in depth, and you know which instruction sequences will be faster.
>You probably know (or at least can make an informed guess) if inline
>will help or hinder the code. You also sometimes need precise control
>over low-level code.
>
>We cannot design a compiler for the Linux Torvalds' of the world.
>We have to do what is best for *most* programmers, while still
>providing the needed tools for the experts.
It occurs to me that the real problem here is that "inline" is being
used to refer to two slightly different concepts, and some of the
participants in this thread haven't noticed this and are talking past
each other.
(A) inline == "I [the programmer] know exactly what this code is
supposed to do at low level, and I have determined that this function
must be inline for proper behaviour, so inline it or give me an error
if you [the compiler] can't."
(B) inline == "I [the programmer] believe this code would be more
efficient if this function were expanded inline, so please do so
unless you [the compiler] have a good reason to do otherwise."
Linus wants (A), but the inline keyword, as defined by ISO C++,
mandates (B). Exactly what consitutes a "good reason" is a function of
compiler technology. In many cases, compilers *are* smarter (about
certain specific things) than programmers, and will quite rightly
override the programmer's choice. For inline, this is rare today, but
will get more common until eventually "inline" goes the way of
"register".
But kernel programming (and a few other cases such as embedded systems)
is a special case, with unusual performance and low-level behaviour
requirements. A "gimme inline and keep your opinions to yourself" (i.e.
option A) keyword is really necessary. And the problem is that GCC has
traditionally (since before it included C++) used plain "inline" for
this, whereas ISO C++ (and, I believe, the upcoming C9X standard)
specifies option B.
As far as I can see, there are four possible resolutions:
(1) Decide that EGCS will use the traditional GCC interpretation of
"inline", i.e. option A. This would be unpleasant for non-kernel
programmers, and while it wouldn't strictly violate the letter of
the C++ standard, it would certainly violate the spirit.
(2) Provide a compiler switch that indicates whether "inline" should
have the traditional GCC meaning (option A) or the ISO C++/C9X
meaning (option B).
(3) Give "inline" the ISO C++/C9X meaning, and provide a new keyword
(e.g. "__force_inline") that has option A semantics for the kernel,
embedded system, etc. programmers. IMHO this is the best solution.
(4) Use option A for C and option B for C++. Ugh.
(P.S. #insert <std_rant_about_americans_who_say_ansi_instead_of_iso>)
--
Ross Smith ................................... mailto:ross.s@ihug.co.nz
.............. The Internet Group, Auckland, New Zealand ..............
* * * * *
To err is human. To really screw up requires the root password.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 19:00 ` craig
@ 1999-02-28 22:53 ` craig
0 siblings, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>Yes, I could have used a macro. I didn't, because:
> - macro syntax sucks
> - macros don't do type testing
> - macros don't handle arguments with side effects nicely, so you have to
> work around that in various ways.
I'd like to add the following item more clearly than I've expressed
it, buried in my previous emails:
- macros don't guarantee inlining of the sort Linus probably wants
(They might *today*. They probably won't in future versions of gcc.)
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 18:24 ` Joern Rennecke
@ 1999-02-28 22:53 ` Joern Rennecke
0 siblings, 0 replies; 180+ messages in thread
From: Joern Rennecke @ 1999-02-28 22:53 UTC (permalink / raw)
To: Zack Weinberg; +Cc: torvalds, egcs
> Or you can isolate the inline functions in their own header file, and
> have a separate C file that just does
>
> #define inline /* nothing */
> #include <linux/inlinefuns.h>
That's only good if all these functions are needed at least once in non-inline
form, or if they are so small to be neglegible.
To get a library where you only link the stuff that you need, you could
either put each function in it's own file, with EXTERN_INLINE in the
declaration and compiler with -DEXTERN_INLINE= , and then in the header file
use something like:
#define EXTERN_INLINE extern inline
#include "foo.c"
#include "bar.c"
...
Or you could use a scheme like in libgcc2.c to compile a large file one
function at a time, but slightly modified so that you can use it as a
header file too. That is good when you have a lot of small functions
and the header needs to be included often - building the library takes
a bit longer, but you safe a lot of time when using the file as a header
file.
#ifndef EXTERN_INLINE
#define HEADER
#define EXTERN_INLINE extern inline
#endif
#if defined(FOO) || defined(HEADER)
EXTERN_INLINE foo() {...}
#endif
#if defined(BAR) || defined(HEADER)
EXTERN_INLINE bar() {...}
#endif
...
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 14:50 ` craig
1999-02-12 17:28 ` Benjamin Scherrey
[not found] ` < 19990212224331.22671.qmail@deer >
@ 1999-02-28 22:53 ` craig
2 siblings, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>On 12 Feb 1999 craig@jcb-sc.com wrote:
>>
>> >To _me_, "standard C" has not been important at all. I'm _more_ than happy
>> >to use gcc extensions, because I think they are worthwhile in the kernel.
>>
>> That means, like I already said, you have to be prepared for a very
>> bumpy ride. You've shown that you have trouble coping with that.
>
>Umm..
>
>I had no problems with gcc features for about six or seven years of Linux
>development. These things simply didn't use to happen: despite upgrading
>_major_ versions of gcc (when Linux started we were using gcc-1.40), for
>those six-seven years there weren't really any changes that I ever had
>problems with.
Which means, what, exactly? That you therefore can claim some kind
of *ownership* of the exact behavior of gcc in the presence of
all sorts of extensions, regardless of the degree to which they're
clearly specified and documented? Sorry, you *should* know better.
>There were tons of code generation bugs over time, but hey, I _expect_
>bugs, and while compiler bugs are sometimes really hard and nasty to find,
>I don't complain too much: I report them, and I tell people not to use
>certain versions. I may be grumpy for a while because I spent ages looking
>at a bug that didn't turn out to be mine, but I never get the feeling that
>I should really dislike the compiler people.
Given how you've treated the egcs developers lately, for daring to:
- Offer you a free compiler
- Offer you free upgrades
- Offer you free responses to bug reports
- Offer you free bug fixes
- Offer you free improvements to unclear documentation
- Offer you free advice as to how to improve your code to make
it more immune to likely changes to egcs code development
I think we're *all* grateful you don't feel you should actually
*dislike* us.
>The reason I have been complaining so much lately is that I think that the
>egcs development has lost that stability. Again, never mind code
>generation bugs, I'm talking about _interface_ stability. I've had much
>more problems in the last year than I had in the seven years preceding
>this.
Yet, that's *exactly* the kind of symptom I would *expect*, speaking
objectively, given the problems *I've* been claiming exist here.
In short, you're saying that you decided long ago to depend mightily
on particular implementation details of gcc, despite not having a
clear specification constituting a promise that those details would
not change in future versions of gcc.
For several years, as gcc development slowed down more and more, including
around two years when *no* major changes were made in released versions,
you experienced no problems.
Then, when the floodgates of development were opened, and development
increased to a heretofore-unknown level of activity, suddenly you
ran into nasty surprises as the (sometimes-obscure, like regparm)
extensions you relied upon stopped working as they used to.
Linus, there is *nothing* surprising in that, and *nothing* that
suggests the problem is due to the attitude of the egcs developers,
or the pace of egcs development. Even if egcs had been "perfectly"
developed in this regard, the results would have been better
documentation of the limitations of "extern inline" and addresses
of labels, which you probably wouldn't have noticed changed, and/or
vehemently disagreed with the "direction" in which egcs is going.
(By proof, I offer the fact that, now that we're fixing this, you're
*still* arguing.)
There are *plenty* of people who are quite happily continuing to use
egcs on their codes, as it evolves, because *they* wrote *their* codes
to properly use the pertinent languages. (To the extent they're
not happy with bugs, I suppose they're wondering why we're wasting
our time accommodating your use of obscure extensions when we could
be making specification-conforming code actually work in the first
place, go faster, be smaller, etc.)
>This may actually not be due to technical reasons as much as simply due to
>a different open development model - it may just be that more people see
>"partial" work, and some of that partial work breaks stuff. Fine - I like
>open development myself, and I use it. But when somebody complains to _me_
>that I broke old interfaces, I consider that a bug unless I have a very
>very strong technical reason to tell people that I simply _cannot_ support
>some old interface any more.
You cannot support the "extern inline" interface anymore, as a promise
that inlining will happen. There, I said it, others have said it,
and the strong technical reasons are that *gcc* will not promise it
to you, nor will any *other* compiler that undergoes any useful
development over the next 10-20 years.
>In contrast, on this list, when people complain that egcs breaks existing
>code, the answer is "shut up and live with it" - and then they Cc: me on
>the damn thing. And that's why I get so upset, and why these flame-wars
>erupt.
I didn't see those answers. FIrst thing *I* noticed was *your* flames.
If you want to send along a few pointers to the earlier posts, I
wouldn't mind reading them to see what you're talking about.
>"Shut up and live with it" is not a way of caring for your customers. And
>creating the best compiler in the world is not just about code generation:
>it's about supporting the people that use it, too.
I agree with that. I'm not claiming egcs is perfect in this regard.
What I *do* know is that you've caused many of us to burn lots of time
on what was a non-issue, long-ago dealt with, but ignored by,
apparently, at least one Linux developer in the past.
And if you think it is *our* job to support *you*, ask yourself how
many donations you've made to egcs developers lately, and compare
that to your recent tendencies (not just in this thread) to accuse
them of breaking your code and then not listening to their explanations
regarding how you can avoid these problems in the future.
>I could change my kernel interfaces and tell people that "shut up,
>recompile, and be happy". Trust me, that doesn't work when you have a
>serious project that you expect others to be serious about too. I make
>_damned_ sure that I don't break binaries, and when I do it by mistake I
>have egg on my face and I fess up to screwing up.
Look, I probably care more, and perhaps know more, about preserving
the integrity of interfaces to products like kernels and compilers
than most anyone on the egcs or Linux development teams. I say that
not so much because of my technical abilities vis-a-vis programming
(which aren't bad), but because of my understanding that you don't
*get* integrity of interfaces without *first* starting with a
solid design, specification, development, and *documentation* effort.
And I've got a pretty good understanding of what *those* entail,
and how rarely they're practiced in much of the software industry.
That's why I've taken the time to so *carefully* explain to you,
and others, exactly why your assumptions about "extern inline" are
wrong, and even if you manage to wrangle a promise about to preserve
them from some well-meaning egcs developers *today*, that promise
will someday be broken.
Yet, because I've *dared* cross the Great Linus Torvalds, you've
taken to trashing *my* posts as "silly", claim I'm posting "sh*t",
"crap", and so on.
There's not a *single thing* I've said in these posts that has been
shown to have been even remotely incorrect, aside from my realizing
I might have confused you and David Miller in the emails about
this issue six months ago. Much of what I said is valuable guidance
for people working on projects that have nothing to do with either
egcs or Linux, and represents the understanding I've gained by working
on OS, tool, interface, and compiler development and documentation
for nearly 30 years now.
But, to you, it means *nothing*, because you apparently don't value
actually using *documented interfaces* correctly in the first place,
meaning that if an interface isn't clearly specified, don't make
assumptions about it.
>On this list, nobody 'fesses up to screwing up any more. And that's sad.
>It makes the egcs project look less serious, and more like a bunch of
>people that just want to play at making a commercial-grade compiler.
We admitted the documentation needed improving. I *think* that has
happened already (if not, I'll do it myself). And we apparently
fixed the buglet that triggered the bugs in your code, so you can
ignore those for awhile longer if you want.
If that isn't admitting to screwing up, I don't know what is. I know
it isn't exactly *what* you think we should have admitted to. But
if we admitted that the whole problem was the the compiler needed
to *always* ensure inlining of "extern inline", you'd *love* that
response, pat us on the heads, and say "good jobs", but we'd have
implicitly made a promise we could not possibly keep down the road.
But it's *our* compiler. It's *our* documentation. It's *our*
language specification. Therefore, *we* get to decide which of
these are broken, when conflicts like this arise.
I'm pretty confident the right decision has been made. I'm absolutely
*certain* you haven't presented sufficient reasons, to date, to have
made a different decision.
And it's also quite clear you have *zero* respect for the decisions
made by us about our product. So if you like them, you're happy, and
if you don't, you flame us, and anybody like myself who comes along
and tries to explain them to you in more detail.
So all your PR efforts at trying to rah-rah us into being better
compiler developers don't amount to much, since we can all see
what you *really* care about: getting us to do exactly what you say,
without question, without thought, even if that includes making
promises we *know* we can't keep.
If you *really* value what we're doing here on the egcs project,
you'll not say *one more word* on this topic, except perhaps for
offering some pretty serious apologies, if you've got the integrity
to do that.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-14 18:08 ` Joe Buck
@ 1999-02-28 22:53 ` Joe Buck
0 siblings, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: jbuck, egcs
> Read archives of comp.compilers and related works if you really
> want to learn why "C is closer to the machine than Fortran" is,
> for all intents and purposes, something between a myth and a self-
> fulfilling prophecy.
Of course it is a "self-fulfilling prophecy" -- given that a major use of
C is in embedded systems, the customer base believes that C (rather, at
least some C constructs) is "close to the machine" and will demand the
ability to do things like write code that interacts with memory-mapped
hardware in C, and compiler vendors will respond to this demand (in
practice, C++ is just as "close to the machine" in this sense as C). It
appears that you don't like this, and I know that many of the academics
that hang out on comp.compilers object to it (but then, they don't like C
-- some of their reasons are valid, some are merely prejudices). But
these are only opinions.
And please drop phrases like "if you really want to learn" ... I have
extensive experience with the issues involved.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 15:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Zack Weinberg; +Cc: egcs
On Fri, 12 Feb 1999, Zack Weinberg wrote:
>
> For most uses, I think the existing behavior of "extern inline" is the
> reasonable behavior. We use it heavily in libc - take a look at
> string.h sometime (actually bits/string.h, bits/string2.h). That code
> absolutely relies on the behavior of `inline if possible, otherwise
> generate a reference to the real function'.
Ok. I think that what people have convinced me off is that I _will_ end up
changing the kernel to avoid this problem in the future. I apologize for
spamming the egcs lists on this issue - I don't actually like flame wars,
and I try to avoid them where possible (and sometimes I fail, like this
time - sorry).
I'm also sorry that almost nobody saw the point of having a macro-like
inline. I don't like duplicating code like in libc (where code duplication
makes sense - having a "official compiled sequence" to link against, with
a separate version for inlining for optimization). As it is, I guess
"extern inline" is just useless for what I wanted to do, and nobody seems
to have a good alternative that doesn't result in more flamage, so while
I'm disappointed I'll just shut up and lick my wounds.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 19:01 ` craig
[not found] ` < 19990213003025.23197.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>I'm also sorry that almost nobody saw the point of having a macro-like
>inline.
Oh, I think *that* point was plenty clear, and certainly has a lot
going for it, in isolation. I happen to think adding a feature
to support it is probably more expensive, in the long run, than it's
worth, but perhaps having a site-specific attribute corresponding
directly to `-Winline', meaning "okay to not inline as long as a
warning is issue", wouldn't be too much.
>I don't like duplicating code like in libc (where code duplication
>makes sense - having a "official compiled sequence" to link against, with
>a separate version for inlining for optimization). As it is, I guess
>"extern inline" is just useless for what I wanted to do, and nobody seems
>to have a good alternative that doesn't result in more flamage, so while
>I'm disappointed I'll just shut up and lick my wounds.
One of the problems is that C doesn't have modules a la Fortran 90 and
Ada. So you have to resort to putting stuff like this (a function
for which "extern inline" is appropriate) in source code *and* in a
header file, which, to make for only one copy, means one #include file
that both the header and the .c file #include.
I'd recommend macros combined with statement expressions, but I don't
know that statement expressions are really robust enough yet, or
if they ever will be. (And I'm not saying they're all that well
designed, or that they, or even macros, will always guarantee the
inlining you seem to want.)
Also, I don't think you can get the same degree of argument type-
checking via a statement expression within a macro as via a
function.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-09 13:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: leei, ross.s, egcs, hpa
On 9 Feb 1999 craig@jcb-sc.com wrote:
> >Why don't you just remove "inline" completely, then?
>
> Because it works just fine, and as documented, for 99.9999% of the
> uses to which its put in code compiled by gcc?
Right. So why break it then?
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 16:40 ` Lee Iverson
[not found] ` < 199902090039.QAA01060@Canada.AI.SRI.COM >
@ 1999-02-28 22:53 ` Lee Iverson
1 sibling, 0 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ross Smith, egcs, H. Peter Anvin
In message < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com > you w
rite:
>
>
> On Mon, 8 Feb 1999, Lee Iverson wrote:
> >
> > It occurs to me that we do, in fact have an acceptable method of
> > *guaranteeing* inlining of a *function* in gcc. That is a combination
> > of a macro and the "Statement Expression" extension.
>
> Sure.
>
> Why don't you just remove "inline" completely, then?
>
> It's apparently ok to break documented and existing behaviour of "inline".
> Go read the gcc documentation about "extern inline", the whole thing is
> _designed_ to be a much more readable form of #define.
>
> Oh, well, I don't care any more. Make up your own rules, and break
> documented behaviour.
I've yet to see *any reference* to the claim that it is *documented*
that the inline declaration *guarantees* that the function will always
be inlined. Even with extern. That was your assumption, reading
between the lines...
That said, the documentation *does* clearly seem to strongly imply
such a guarantee. The hedging language that should be there *isn't*
except for the single line: "Note that certain usages in a function
definition can make it unsuitable for inline substitution." Clearly
not as prominent as it should be.
Of course inline is supposed to work, but as you've heard this is
largely a question of *reliably* generating correct code and as in the
past *your assumptions* about what the compiler should be doing rather
than objectively documented behavior. The compiler may not be living
up to your expectations, and I know that it hasn't in the past, but
just as in some of those cases (e.g. the asm clobbering issue or the
inline+label addresses), the problem is that you are relying on
behaviour that is either undocumented and thus not guaranteed or
falling between the cracks of the implementation.
I think this is a case where the documentation is misleading. It does
suggest that inlining is not guaranteed, but IMO not as prominently as
it should. That is what you've been bit by, *not* a guarantee that
isn't being honoured.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 9:55 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990210094228.13924A-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Jamie Lokier; +Cc: H. Peter Anvin, Lee Iverson, ross.s, egcs
On Wed, 10 Feb 1999, Jamie Lokier wrote:
> Jamie Lokier wrote:
> > H. Peter Anvin wrote:
> > > Oh yes, __builtin_constant_p() really, really ought to work properly
> > > in an inline...
> >
> > It does. See egcs-1.0.3.
>
> Bugger, I was wrong. Sorry Peter.
It works in development versions of egcs, but as far as I know of it does
not work in _any_ released version of gcc. It certainly is not something
you can really use anyway, as using it requires that all users have to
upgrade: which may be acceptable in some environments, but is certainly
not an option in most places.
The same is true of certain other features like __builtin_return_address()
(which _does_ work in egcs-1.0.3 I've been told, but doesn't work in many
other versions) which makes them essentially a non-issue in production
environments with multiple versions of gcc. It's good that these things
evolve and get fixed, but the fact that they have gotten fixed does NOT
mean that people can just start depending on them - that will happen much
much later.
This is one reason why it's so important to _not_ break backwards
compatibility if at all possible: even if you introduce a new feature that
makes an old feature unnecessary, you can't just force all your users to
upgrade overnight, and you should expect people to use old and new
versions concurrently - so the old feature has to stay (not forever, but
certainly for at least one major release - which for most bigger projects
implies at least a year of "migration time").
No, I don't enjoy it either. Maintenance is not especially exciting or
interesting, but it _is_ important. Expect people to rely on
__builtin_constant_p inside inline functions in another two years or so.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-09 11:45 ` craig
[not found] ` < 19990209191412.27056.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>Why don't you just remove "inline" completely, then?
Because it works just fine, and as documented, for 99.9999% of the
uses to which its put in code compiled by gcc?
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Removing code dupe in libc (Was: A final solution...)
1999-02-14 15:21 ` Gerald Pfeifer
@ 1999-02-28 22:53 ` Gerald Pfeifer
0 siblings, 0 replies; 180+ messages in thread
From: Gerald Pfeifer @ 1999-02-28 22:53 UTC (permalink / raw)
To: Paul Derbyshire; +Cc: egcs
On Sat, 13 Feb 1999, Paul Derbyshire wrote:
> M4?
`man m4` on (nearly) any Unix system.
---- cut ----
NAME
m4 - macro processor
SYNOPSIS
/usr/ccs/bin/m4 [ -e ] [ -s ] [ -B int ] [ -H int ]
[ -S int ] [ -T int ] [ -Dname [=val] ] ...
[ -U name ] ... [ file ... ]
/usr/xpg4/bin/m4 [ -e ] [ -s ] [ -B int ] [ -H int ]
[ -S int ] [ -T int ] [ -Dname [=val] ] ...
[ -U name ] ... [ file ... ]
DESCRIPTION
The m4 utility is a macro processor intended as a front end
for C, assembler, and other languages. Each of the argument
files is processed in order; if there are no files, or if a
file is -, the standard input is read. The processed text
is written on the standard output.
Macro Syntax
Macro calls have the form:
name(arg1,arg2, ..., argn)
:
---- cut ----
Gerald
--
Gerald Pfeifer (Jerry) Vienna University of Technology
pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 16:12 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Lee Iverson; +Cc: Ross Smith, egcs, H. Peter Anvin
On Mon, 8 Feb 1999, Lee Iverson wrote:
>
> It occurs to me that we do, in fact have an acceptable method of
> *guaranteeing* inlining of a *function* in gcc. That is a combination
> of a macro and the "Statement Expression" extension.
Sure.
Why don't you just remove "inline" completely, then?
It's apparently ok to break documented and existing behaviour of "inline".
Go read the gcc documentation about "extern inline", the whole thing is
_designed_ to be a much more readable form of #define.
Oh, well, I don't care any more. Make up your own rules, and break
documented behaviour.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 19:41 ` craig
[not found] ` < 19990212031118.4271.qmail@deer >
1999-02-12 11:40 ` Linus Torvalds
@ 1999-02-28 22:53 ` craig
2 siblings, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: d-dooling; +Cc: craig
>This whole thread only serves to fill all our mailboxes with a bunch
>of name-calling and nitpicking. It does not help the development of
>gcc or linux (I assume the reason we are all subscribed to this
>listserv is to _help_ the development of gcc, no?). It is the
>software development equivalent of ``my dad can beat up your dad!''.
Sorry, I'm not here to play the "let's all get along" game.
If Linus persists in assuming he'll be promised actual inline whenever
he says "inline", he'll continue making Linux *worse*. If he learns
how to better engineer the code within Linux to at least work within
reasonable tolerances of how gcc extensions behave, he'll make it
*better*.
As I said, this is at least the second time around with him on this
sort of thing. *He* has chosen to not get along, and to repeatedly
disregard the solid advice he's been given.
>Basically (without all the name-calling), the developers of egcs found
>that combining two gcc extensions did not produce reliable code. So,
>they took the easy fix: don't allow them to be combined. This broke a
>significant amount of code for one user, Linus (granted he is not just
As far as I can tell, it broke no *correct* code at all.
>_any_ user, nonetheless ...). I am sure other people who depend on
>these gcc extensions will also feel the pinch. This is all fact,
>everything else that has been said is superfluous.
Sorry, I disagree. Much of what I said, if actually paid attention
to, would help people produce more solid code, and perhaps a more
solid compiler as well. I don't appreciate being told everything
else I said was "superfluous". Is this your idea of trying to get
people to stop "name-calling and nitpicking"??
>That being said, is there anything we can do together to improve the
>situation for all of us? Obviously the combination of these
>extensions worked sometimes.
AFAICT, they still worked, for correct code. And someday gcc will
outright *ignore* "extern inline" sometimes for even ordinary
functions, because someday it will be an even better optimizing
compiler, which is what it is advertised as (as versus a macro-based
code generator, which is what some people seem to treat it as).
>Is there any way to find out when it
>works and when it doesn't? It should be a deterministic problem, no?
It was and is working fine, AFAIK. Bad code that depended on the
generated code having certain undocumented properties stopped working,
and on the whole we'd like to try triggering that sort of thing,
but it's something we can't always prevent, and the world would be
a better place if people who wrote bad code like that took well-
intentioned advice to stop.
>Perhaps Linus has some cases in his code where he knows it works.
>Perhaps other has incidences where it doesn't. Is there not time to
>address these issues now? Can it be put on the TODO list? Can we at
>least agree on how to warn/error when gcc can't comply with what the
>programmer wants? There has to be something that can be done to make
>the compiler (and the atmosphere on this thread) better.
There apparently already was, -Winline, and it wasn't being used.
The atmosphere on this thread will get better only once Linus retracts
his claims that it was *gcc* that broke *his* code, and accepts
that his code was wrong.
>Admittedly, I have not the knowledge nor the expertise to investigate
>these options myself (I am but a lowly chemical engineer). I
>apologize for this (my only intention is to help).
I have rarely seen anybody step into an argument in the way you've
done actually succeed at helping. Playing "good cop" when your
tactics include casting aspersions on the points people like
myself have taken our time to carefully make frankly does *not*
help.
But it sure seems to make some people *think* it helps, and I guess,
these days, that's all that matters. Kinda like those executives
who felt it was better to "get along" with the folks their company
was contracting for than to tell them bad news about risks involving
their products.
Of course, the result was the Challenger explosion and seven
people killed, but the nice motivation to "get along" was all that
mattered, right?
>Let's turn this thread around, discuss some specifics, and get
>something done.
The buglet in gcc has, I gather, already been fixed. I haven't
gotten the impression the underlying bug(s) in Linux have, or
will, get fixed.
If that's right, this problem will occur again, sooner or later.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 9:42 ` Linus Torvalds
[not found] ` < 79sgd8$p7p$1@palladium.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: submit-linux-egcs
In article < 19990210133236.30212.qmail@deer >, <craig@jcb-sc.com> wrote:
>>On 9 Feb 1999 craig@jcb-sc.com wrote:
>>
>>> >Why don't you just remove "inline" completely, then?
>>>
>>> Because it works just fine, and as documented, for 99.9999% of the
>>> uses to which its put in code compiled by gcc?
>>
>>Right. So why break it then?
>
>By your apparent standards, it always *was* broken, because inlining
>didn't always happen.
No.
gcc _did_ use to always inline if it at all could do so. There were
cases that made it unable to inline, simply because the code itself was
not conducive to inlining. Those were _technical_ reasons for not
chosing to inline something, and completely and utterly understandable.
For example, not inlining a recursive function is just obviously the
right thing to do (yes, in theory you could try to make it iterative,
but if the programmer gave the compiler a recursive function then it's
the _programmer_ who is responsible for it, and nobody really expects
the compiler to do miracles).
>Yet, as I said, even then, it works just fine, and as documented,
>for 99.9999% of the uses to which it is put in code compiled by gcc.
No. It used to work for 100% of the caaes gcc could handle.
The change broke that.
It used to be a feature you could depend on.
The change broke that.
Yes, the documentation had hedges to handle the real cases (like
recursion etc) where inlining just isn't feasible, but the fact that it
hedged its bets doesn't change the fact that people like me used to be
able to rely on the compiler to do what it was asked to do.
If it was a case of "oh, gcc used to have a 50-50 policy on when to
inline, and the change made that a 40-60 policy", then it would have
been much more palatable. But it wasn't. It was a case of 100% success
being turned into "I wonder what the hell they'll break next time
around".
Repeatability is good. Random changes that break existing behaviour for
no technical reason is bad.
>(That's not surprising, since gcc is, generally, based on standards
>such as ISO C, which presumably make it much clearer that "inline"
>is, like "register", a mere hint.)
"extern inline" is a documented gcc extension. It may be covered by ISO
C these days, but it didn't use to be.
"address of a label" is a documented gcc extension, and is NOT covered
by any C standard (pending or accepted) that I know of.
As such, the people who brought up "standards" as an argument for
changing the behaviour are fairly hypocritical: it's a good argument but
in order to hold water it has to be _relevant_.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
1999-02-12 6:37 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 07:29 AM 2/12/99 -0500, you wrote:
>Are you saying Linus needs toilet training? <ducks>
>
>Cheers,
>Alex
Ohhhh now the fat's in the fire.
Although, I'm rather surprised to see the side of Linus I've seen recently.
I understood all along that he's actually nothing more than a human being,
but .......
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 19:01 ` craig
[not found] ` < 19990213011316.23309.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>The emails you quote are from the previous time this happened. As now,
>nobody actually suggested a good working way to do what we wanted to do
>without just completely resorting to macros (and I've already explained
>why I dislike macros).
But, even if Linux developers didn't consider any of the proposals
as "a good working way", that didn't mean they were free to ignore
the *warnings*, which accompanied the proposals, about the dangers
of continuing to rely on the extensions in question as they were doing.
(BTW, I dislike macros too. C is just too weak a language to get
much done without them, though. I had high hopes for C++ around
10 years ago, but....)
>What you suggested then isn't any better than what you're suggesting now:
>implementing new features in gcc doesn't obviate the need to be able to do
>the same thing with old code. And implementing a back-trace by hand is
>architecture- and compiler-dependent, which is silly because when that
>breaks due to compiler changes you'd just complain that we should do
>something else. You can't have it both ways, Craig.
Of course, the code to do a limited back-trace would have to be part
of the system-specific, perhaps even compiler-specific, code that
pretty much any OS has. I didn't imagine otherwise -- sorry if you
thought I was saying gcc somehow offered a feature to portably
obtain stack-trace information!
I do think there might be some feasability, depending on what it
is you're trying to accomplish *generally*, in the idea of
special pre-processing and/or post-processing of the source code
and assembler output. It wouldn't be portable, but it might be
much more robust than anything we can feasibly do for you, and
more responsive to changes whenever your needs change, making your
project more tolerant of changes to gcc (for example).
But I don't know enough about what you need, on the whole, to really
offer any specific suggestions at this point. I can only guess.
And that's part of why I, personally, would tend to resist adding
a new feature because you say it'll help you. Not to be disrespectful
to you specifically, but generally, I find it is often the case
that a user asking for a new feature, in a situation where I don't
fully understand their need for it, won't find that new feature
completely addresses their problem, once I implement it. So they'll
come back and ask for yet another new feature, to address the corner
cases or whatever they didn't previously think about.
In the end, if I'm not careful, I'll implement a handful of features
just for that kind of customer that are increasingly difficult for
users to really make good use of, hard for me to maintain, and which
don't really fully address the original problem.
>Face it: what Linux does is entirely reasonable, trying to get a backtrace
>in a architecture-independent way. Yes, it bit us, but it was certainly
>not an unreasonable thing to do.
I wouldn't call it "unreasonable". But I think the implementation
of something like this should have been much more carefully studied
up-front, and/or, upon discovering it didn't always work if the
compiler had subtle changes made to it, an alternative quickly
looked-for, rather than blaming the compiler for changing. (Though,
I still believe, we like to *know* when buglets like this creep in,
e.g. stuff stops inlining that really should inline in a reasonable
compiler.)
That relates back to my point about tolerances. *We* want to know
when our compiler gets *near* the boundaries of its published
tolerances (and certainly when it exceeds those boundaries), but
we also want people to use it in ways that *accommodate* those published
tolerances, rather than assuming we'll always be able to keep it
within some unpublished, tighter tolerances. Of course, they
can choose to ignore our advice, but they have to understand that
our priorities usually put bringing the compiler to *within* published
tolerances higher than *tightening* the compiler's tolerances
(which constitutes a promise of future performance and behavior).
This means you might get no help from the compiler doing what you
need. That's unfortunate, but not necessarily the fault of the
compiler -- it might just mean the problem is better solved outside
the arena of the generation of optimized code from an "as if" language
like C.
>Do you really think it's unreasonable to ask for some way of forcing
>inlining, when the compiler obviously can do it? It doesn't have to be
>"extern inline", if you're afraid of polluting a future standard
>namespace.
I think the complexity of just figuring out what exactly is *meant*
by "forcing inlining" probably greatly exceeds the benefits of
doing that, implementing the resulting specification, and maintaining
the it down the road. For example, just how many copies of a
given invocation of inlined code end up in RAM; whether a
short-call interface may be used for inline code to quickly gain free
registers in a register-window machine like SPARC; whether
addresses of static variables are guaranteed to be unique across
all of the inlining "sites"; whether visible code-generation differences
between an inlined "maybe inline" and "always inline" would be permitted...
these would need to be nailed down, and not just by looking at the current
implementation, but by looking at what might be appropriate in the future,
for new architectures, such as massively parallel machines,
"massively serial" machines, etc.
Further, as I said in another post, which perhaps didn't go directly
to you, the C language upon which GNU C is based follows the "as if"
rule. Much of the implementation of gcc assumes the "as if" rule.
Every extension and command-line option added to work around the "as if"
rule tends to not work very well and make gcc less maintainable
overall.
And, the "force inlining" phrase almost certainly connotes the idea
that "I don't mean *as if*, I mean *do exactly what I say*". Though
there's no consensus likely to emerge anytime soon on exactly *what*
is meant by that, in implementation terms that make sense across
all current and future processors targeted by gcc. (Please don't
say "it just means compile the code in line". That means almost
*nothing*, just as "inline" itself means almost nothing! For
your purposes, you'd need to offer exactly what visible semantics
you expect to take hold when forcing inline over not forcing inline,
or not inlining.)
In that sense, frankly, even if you *did* like using macros, you
wouldn't get a 100% guarantee of inlining, just like you wouldn't
when using any form of "inline". That is, the compiler is free
to implement your repeated macro invocations as calls to a single
procedure, as long as they worked "as if" they were simply
code-generated as you'd currently expect. Who knows, `-Os' might
someday be able to do that sort of thing, and people would certainly
want it to be able to.
I won't speak for the gcc developers who'll probably make the
decisions, but it's generally not wise to introduce extensions
outside the "zeitgeist" of a product just to satisfy a single
customer. Even if you make that customer happy, it will be
only for the short term, in almost every case. And I think the
"zeitgeist" for gcc is, despite a plethora of apparently "as-if-less"
extensions, strongly along "as if" lines.
So, is it "unreasonable" to ask for this? No. It's not unreasonable
for us to say "no", either, though. If you haven't studied all
the code that gets involved in making inlining work, and making
subsequent processing phases properly account for inlining (in
terms of producing correct debugging info and so on), you might
take a moment to do so -- and then you might see while, on the whole,
it could indeed be unreasonable for us to decide to offer the
feature, even based just on how gcc *currently* does inlining and
ignoring how and when it might do so in the future.
But, that's for us to decide. Even if *we* decide it's unreasonable
to provide the feature, that does *not* mean, IMO, that it's
unreasonable for you to ask for it. Your job isn't to think
about the long-term viability of gcc, although I think we prefer
it when users give that some consideration *before* asking for
new features.
After all, it seems that much of this current debate stems from
one particular extension -- addresses of labels -- that seemed
entirely "reasonable" to add, long ago, and which has proved
handy, on occasion. I think it's likely that the difficulties
that extension has caused exceeds the benefits it granted, compared
to if it hadn't been introduced in the first place. (Maybe a
more Fortran-like feature, a quite simple but limited form,
would have been a better alternative, though even Fortran's
assigned GOTO has caused lots of pain over the decades. And
it wouldn't have been useful for the skb_put type of case.)
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-11 19:41 ` craig
[not found] ` < 19990212033918.4310.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: craig
>On 11 Feb 1999 craig@jcb-sc.com wrote:
>>
>> >"address of a label" is a documented gcc extension, and is NOT covered
>> >by any C standard (pending or accepted) that I know of.
>>
>> So why are you using it? Why would you design a product to so
>> completely depend on the correct interaction of a variety of
>> extensions supported by only one compiler out of so many choices
>> on the market?
>
>Are you being stupid or argumentative?
Actually, I was curious. Your extreme reaction at gcc not behaving
exactly the way you wanted and as it had in the past suggested
you might not be aware of the implications of using such features,
despite having been (IIRC) burnt by this before. I was attempting,
among other things, to educate you (and others reading this thread)
as to some of those implications.
But go ahead, cast your aspersions on my motivations for taking time
out of my busy schedule to try to 'splain this stuff to you. Obviously
a huge waste of time, but I factored that in, figuring *somebody*
out there on the Internet might learn from these discussions.
(I've spent much of my career offering explanations like that. I'm
almost *never* wrong in those cases, but I have taken a lot of heat
from people who see only the short term. I remember, over a year ago,
trying to explain to a roomful of numerical engineers why a certain
design being proposed for new Fortran features was actually dangerous,
because instead of causing people to make mistakes 50% of the time,
it would cause them to do so more like .5% of the time, make the
mistakes much harder to detect, and thus lead to more actual errors
in deployed code. They thought I was crazy to reason that way. I'm
thinking of sending your recent email to them, since you are a great
example of the sort of person that considers 50% failure *better*
than .5% failure in many cases, and I prefer to engineer products
to accommodate that viewpoint, since I somewhat share it, especially
when it comes to stuff involving man-machine interfaces, like gcc.)
>To _me_, "standard C" has not been important at all. I'm _more_ than happy
>to use gcc extensions, because I think they are worthwhile in the kernel.
That means, like I already said, you have to be prepared for a very
bumpy ride. You've shown that you have trouble coping with that.
Please learn to adapt to the reality of what happens when you use
cutting-edge, poorly-tested extensions in a compiler undergoing
rapid development.
>So "address of label" is a documented feature of the only compiler I
>compile the kernel with. As is "inline". And my argument was that
>_neither_ of those features were mentioned in any C standard ("inline" has
>since been added to the proposed standards) - but they were very much
>mentioned in the gcc documentation.
Oh, I *thought* your argument was that, if any release of gcc did
not support the combination of the features in exactly the way
*you* expected, despite not being documented to do so, that
meant *gcc* broke your code.
>Ergo, ANYBODY who uses "standard conformance" as a reason for supporting
>their argument just needs to think twice. That was my only argument.
Okay. I must have misread your earlier posts, including the one to
me, which kept saying things like "what are these [gcc/egcs] guys
going to *break* next?" [emphasis added]. I apologize.
>I'm
>just trying to show people how silly it is to say that "oh, the standard
>says that 'inline' is just a hint", when the current C standard says
>nothing of the sort at ALL.
I didn't realize that was *all* you were trying to say. I *thought*
you were also trying to say that a change to gcc's decision-making
process as to whether to actually inline an "inline" function
constituted a bug in gcc, rather than a bug in code that somehow
depended on the inlining actually happening.
>[ rest of your silly email removed - you seem to be arguing against using
> gcc in the first place. I just want to make sure that gcc continues to
> be usable and good for Linux ]
It would be, if Linux didn't make use of so many extensions, as I
explained earlier, in the portion of my email you call "silly".
IIRC, I've occasionally suggested, on USENET, that Linux shouldn't
depend so much on gcc's peculiar characteristics, in the past. Though
I'm a big fan of gcc/egcs and GNU software in general, from an
engineering standpoint, keeping Linux at arms' length from gcc-specific
extensions would be better for Linux, and I think it'd be, in the
long run, better for gcc as well, because it'd tend to encourage
more general optimizations in gcc, rather than having Linux rely
so much on hand-coded use of extensions to get faster code. (That's
a stretch, though, for applications like kernel-code generation,
I realize.)
I guess your only motivation is to make gcc better for Linux, but
not make Linux more robust by lessening its dependencies on
particular code-generation strategies used by any particular
version of gcc.
Me, I'd like to see *both* gcc and Linux be usable and good.
gcc, being an optimizing compiler, will someday simply ignore
some instances of "inline" entirely, and use procedure calls instead,
unless it dies for lack of interest first. That's because inlining
a procedure does not always make for the most optimal code.
(It's obvious enough why, when `-Os' is specified, since that
means optimize for space. It's less obvious otherwise, that
avoiding inlining will tend to reduce the Icache footprint
of the generated code sufficiently to actually make it go
faster than if inlining was naively done.)
But the larger problem is that you seem to think that, once
a behavior is observed, it is guaranteed in future versions of
that product, even though not clearly documented. You would
do well to learn the lesson that this is not true, just as
a good engineer knows that, no matter how many widgets he's
seen exactly .542cm wide, he'd better take seriously the
published specs for them that say ".542cm +/- .005cm" and
not design his product to *assume* exactly .542cm for all
future widgets.
Tolerance isn't just for the political-correctness crowd. It
has real meaning, and, when properly employed, real value
in engineering, including software design.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-14 17:26 ` craig
[not found] ` < 19990215011831.28108.qmail@deer >
@ 1999-02-28 22:53 ` craig
1 sibling, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: jbuck; +Cc: craig
>> And, note, C doesn't really make provisions for writing "close to the
>> machine" code any better than Fortran.
>
>You are incorrect, I'm afraid. What Fortran construct corresponds
>to "volatile", which is in essence a model for a memory-mapped device
>register?
I stand by my original statement -- including the part you didn't
quote in my email about "volatile" -- but I'm not about to argue this
anymore.
Read archives of comp.compilers and related works if you really
want to learn why "C is closer to the machine than Fortran" is,
for all intents and purposes, something between a myth and a self-
fulfilling prophecy. And why "volatile" is a great example of a
supposedly necessary feature that, linguistically speaking, makes
almost every computer language that incorporates it *worse* than
it would be without it.
tq vm, (burley)
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 18:24 ` Linus Torvalds
@ 1999-02-28 22:53 ` Linus Torvalds
0 siblings, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Zack Weinberg; +Cc: egcs
On Fri, 12 Feb 1999, Zack Weinberg wrote:
>
> Or you can isolate the inline functions in their own header file, and
> have a separate C file that just does
>
> #define inline /* nothing */
> #include <linux/inlinefuns.h>
>
> No code duplication, and if all the inlines went through, the linker
> will throw away the unnecessary object module.
We used to do things this way for string operations, because gcc used to
do some of the string operations on its own (memcpy etc), and we wanted to
use the same ones we had in <asm-i386/string.h>.
It's _really_ painful if it ever happens, because the linker doesn't know
how to extract just one function from the object file, and you end up with
one big object file that contains all of it. I really want to avoid this
kind of approach (a lot of the header files depend on each other, so the
above would get just about every single inline function in the whole
kernel, ugh).
So no, you don't want to do it like the above - it works, but not very
well.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 11:40 ` Linus Torvalds
[not found] ` < 7a203j$9cf$1@palladium.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: submit-linux-egcs
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
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: Bad puppies and coding practices
1999-02-12 4:25 ` Alex Buell
[not found] ` < Pine.LNX.4.05.9902120729110.2093-100000@tahallah.demon.co.uk >
@ 1999-02-28 22:53 ` Alex Buell
1 sibling, 0 replies; 180+ messages in thread
From: Alex Buell @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
On Fri, 12 Feb 1999, Marc Espie wrote:
> A bit like wacking puppies on the nose to teach them proper toilet
> habits...
Are you saying Linus needs toilet training? <ducks>
Cheers,
Alex
--
/\_/\ Legalise cannabis now!
( o.o ) Grow some cannabis today!
> ^ < Peace, Love, Unity and Respect to all.
http://www.tahallah.demon.co.uk - *new* - Leaving the States for good!
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-13 10:47 ` Joe Buck
[not found] ` < 199902131846.KAA25341@atrus.synopsys.com >
@ 1999-02-28 22:53 ` Joe Buck
1 sibling, 0 replies; 180+ messages in thread
From: Joe Buck @ 1999-02-28 22:53 UTC (permalink / raw)
To: craig; +Cc: pderbysh, egcs
> Be aware that __builtin_return_address probably will stop working
> someday in gcc. Read my latest tirade to get an idea of why that is.
Craig, gcc is the GNU project's compiler. That means that one of its
important roles is to be able to compile kernels (Linux or the Hurd).
Since you're the Fortran guy, you are somewhat insulated from these
issues (Fortran just doesn't make provisions for writing "close to the
machine" code).
The result is that gcc is going to have to continue to support certain
extensions for the indefinite future (though kernel developers should
not assume that "it worked in version x.y.z" is a commitment for the
future, we will need to supply some mechanisms in some cases.
It may actually be easier to support features like this if they are
specified at a higher level of abstraction. That is, understand why Linus
is using some trick to do something, and then recommend alternative ways
to do them that are actually supportable. e.g. if the real job is to get
a stack trace, maybe there could be some facility to provide for that
directly, possibly borrowing some code from gdb.
Despite Linus's tendency to be insulting, he is one our most important
"customers" (or, more accurately, the people who depend on the Linux
kernel working are). We need to have sufficient facilities so that C plus
inline assembly can do the whole job.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-12 21:08 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990213000806.008529f0@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
Christ Craig, give it a rest. This is a dead horse you're beating. Some
reasonable sane and rational suggestions for solving the problems both with
Linux and egcs have appeared; someone's found that a conditional compile
can be used to make the extern inline thing compile and work on every gcc
by either using __builtin_return_address or the label hack; Linus has said
the panic code isn't too critical anyways and has apologized for some of
the tirades earlier in the week; and it seems to be high time this issue
was let drop on the list; yet I keep seeing more tirades from you every few
minutes to an hour.
BTW, did you know that your ISP's mail server was bouncing mail
inexplicably all afternoon? Was bouncing messages with "Service
unavailable". Never heard of downtime causing mail to bounce before;
usually it's deferred. You should have a few stern words with your ISP's
customer service reps about this; if the downtime had been much longer the
bounces would have caused yo to be removed from this list and any others
you're on more than likely. They should just defer the mail.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 3:33 ` Jamie Lokier
[not found] ` < 19990210105658.A1570@tantalophile.demon.co.uk >
@ 1999-02-28 22:53 ` Jamie Lokier
1 sibling, 0 replies; 180+ messages in thread
From: Jamie Lokier @ 1999-02-28 22:53 UTC (permalink / raw)
To: H. Peter Anvin, Lee Iverson; +Cc: torvalds, ross.s, egcs
H. Peter Anvin wrote:
> Oh yes, __builtin_constant_p() really, really ought to work properly
> in an inline...
It does. See egcs-1.0.3.
-- Jamie
^ permalink raw reply [flat|nested] 180+ messages in thread
* off-topic ramblings [Re: kernel-2.2.1-undefined references.]
1999-02-14 20:01 ` off-topic ramblings [Re: kernel-2.2.1-undefined references.] Mumit Khan
@ 1999-02-28 22:53 ` Mumit Khan
0 siblings, 0 replies; 180+ messages in thread
From: Mumit Khan @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
Paul Derbyshire <pderbysh@usa.net> writes:
> At 10:12 PM 2/14/99 -0500, you wrote:
> >I don't think so. How the hell else can you write C code that works with
> >data that changes asynchronously, e.g. because of multiple threads or
> >because of hardware or interrupts or signal handlers or...
>
> By the way, don't say use mutexes and semaphores.
> 1. Hardware doesn't understand these things, and you do need software
> to interface to hardware.
[ ... ]
Could you PLEASE take this off-line?
This thread has long become irrelevant to the focus of this mailing list,
but now it's fast getting to the point of ridiculous.
Regards,
Mumit
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 16:27 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990210161330.14471K-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Marc.Espie; +Cc: egcs
On Wed, 10 Feb 1999, Marc Espie wrote:
>
> You could *at least* acknowledge that you read the original documentation
> wrong, and that you relied on your interpretation of it...
Would that make you happier?
Yes, I publicly acknowledge that the documentation did not _guarantee_
that "inline" will inline. I've several times mentioned that it makes
perfect sense to not inline in many cases.
My gripe is (and has been) that somebody changed gcc behaviour for no good
reason, and that the behaviour was strongly implied in the documentation.
Furthermore, all features involved were documented gcc extensions, and
that the Linux usage was in no way unreasonable. The functions in question
were
(a) very small
(b) _needed_ to be inlined exactly because they used another gcc feature
in order to report potential problem locations correctly.
(c) did not do _anything_ that could reasonably be considered illegal in
an inline function.
And yes all of it could have been done some other way. The reason Linux
used them as it used them was that all the other portable alternatives
were more broken (I'd have _loved_ to use documented gcc interfaces, but
they didn't actually happen to work).
And no, very few others are complaining, because the breakage only
happened when you used two gcc extensions together ("inline" and address
of a label). Linux is probably the only thing that actually uses a lot of
the extensions.
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 15:44 ` Zack Weinberg
[not found] ` < 199902122344.SAA28257@blastula.phys.columbia.edu >
@ 1999-02-28 22:53 ` Zack Weinberg
1 sibling, 0 replies; 180+ messages in thread
From: Zack Weinberg @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
On Fri, 12 Feb 1999 15:31:05 -0800 (PST), Linus Torvalds wrote:
>And yes, before people say that gcc documentation said that "extern
>inline" was documented to be _almost_ like a macro, then instead of being
>a language layer, please consider for a moment using your brains for
>something else than syntax, and using them for asking yourself "what is
>reasonable for a programmer"?
For most uses, I think the existing behavior of "extern inline" is the
reasonable behavior. We use it heavily in libc - take a look at
string.h sometime (actually bits/string.h, bits/string2.h). That code
absolutely relies on the behavior of `inline if possible, otherwise
generate a reference to the real function'.
There is legitimate code where you must inline for correct behavior,
but it's rare enough that I think it's reasonable to do something
special, like an __attribute__ declaration. It's not surprising to
find examples of that in the kernel, which has to do more "strange
stuff" than user code.
zw
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-14 19:51 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214225028.00820ea0@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: egcs
At 10:12 PM 2/14/99 -0500, you wrote:
>I don't think so. How the hell else can you write C code that works with
>data that changes asynchronously, e.g. because of multiple threads or
>because of hardware or interrupts or signal handlers or...
By the way, don't say use mutexes and semaphores.
1. Hardware doesn't understand these things, and you do need software
to interface to hardware.
2. A modal signal/exception handler would be in deep trouble if it
encountered a mutex that was locked and decided to wait for it to
unlock...and wait, and wait, and wait...
3. The semaphores and mutexes need to be coded as well. They need
state variables, and those state variables need to be modified
asynchronously, *without* using a mutex or semaphore as this would
be a chicken and egg problem! So the mutex flag or semaphore
counter needs to be 'volatile', so code like this:
void mutex::get_lock (void) throw () {
suspend_task_switching();
while (locked) {
resume_task_switching();
yield();
suspend_task_switching();
}
locked=true;
resume_task_switching();
}
doesn't hang in an infinite loop because 'locked' was optimized
into a register and the while loop therefore never exits since its
register copy of 'locked' never changes! So we need
private:
volatile bool locked;
or the mutex class won't work worth a damn.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-10 9:36 ` Jamie Lokier
[not found] ` < 19990210171623.A2799@tantalophile.demon.co.uk >
@ 1999-02-28 22:53 ` Jamie Lokier
1 sibling, 0 replies; 180+ messages in thread
From: Jamie Lokier @ 1999-02-28 22:53 UTC (permalink / raw)
To: H. Peter Anvin, Lee Iverson; +Cc: torvalds, ross.s, egcs
Jamie Lokier wrote:
> H. Peter Anvin wrote:
> > Oh yes, __builtin_constant_p() really, really ought to work properly
> > in an inline...
>
> It does. See egcs-1.0.3.
Bugger, I was wrong. Sorry Peter.
I was _told_ it is working in some EGCS version, and misread a test I
did earlier. It ought to be working by now: I submitted a patch a very
long time ago, and was told something similar had been installed into
the tree.
-- Jamie
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 18:02 ` Zack Weinberg
[not found] ` < 199902130202.VAA28998@blastula.phys.columbia.edu >
@ 1999-02-28 22:53 ` Zack Weinberg
1 sibling, 0 replies; 180+ messages in thread
From: Zack Weinberg @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
On Fri, 12 Feb 1999 17:53:50 -0800 (PST), Linus Torvalds wrote:
>
>
>On Fri, 12 Feb 1999, Paul Derbyshire wrote:
>>
>> Getting them to fix __builtin_return_address would be even better since
>> your code is (to put it bluntly) a kluge to get around a wart in GCC to
>> begin with. But my suggestions sure look doable...I'm not exactly sporting
>> a PhD in compiler theory, but 15 years of programming experience must count
>> for something =)
>
>Well, __builtin_return_address() has actually worked for a longish time.
>
>That's kind of the secondary problem: I'd love to track new releases and
>use new features when they come out, but I can't. Even if _I_ switch to a
>new compiler, few other people will, and then I get bug-reports with the
>old stuff - reports that are useless because the data they report is just
>bogus.
In this particular case, you could use conditional compilation based
on __GNUC_MINOR__. All the compilers that miscompile the
address-of-label hack do __builtin_return_address correctly, as I
understand it.
>The problem for me is that if I really have to create duplicates of all
>"extern inline" functions, the while thing is completely useless to me. It
>does _not_ act "almost as a macro" any more, it acts almost completely
>differently.
I don't think you have to do that. You can carry on using "extern
inline" as you have been. If there's no other definition of a
particular function and gcc fails to inline it, you'll get a link
error, and then you can track down why that particular function
doesn't inline and tweak it or submit bugreports.
Or you can isolate the inline functions in their own header file, and
have a separate C file that just does
#define inline /* nothing */
#include <linux/inlinefuns.h>
No code duplication, and if all the inlines went through, the linker
will throw away the unnecessary object module.
zw
^ permalink raw reply [flat|nested] 180+ messages in thread
* mail sent to <craig@jcb-sc.com> is bouncing, why?
1999-02-14 12:19 ` mail sent to <craig@jcb-sc.com> is bouncing, why? craig
@ 1999-02-28 22:53 ` craig
0 siblings, 0 replies; 180+ messages in thread
From: craig @ 1999-02-28 22:53 UTC (permalink / raw)
To: pderbysh; +Cc: craig
[egcs taken off the reply-to list, so anyone replying to this, add
it back only if you think it's pertinent to the list. I think *this*
might be, because Paul isn't the only one who reported this problem
with email they tried to send to me. Whoever that was, please send
me a note so I can look at your headers and see if you and Paul
share any obvious 'net pathways or MTAs in common.]
>At 03:24 PM 2/13/99 -0000, you wrote:
>>Do you have any bounced email to forward along, so I can see what
>>was actually happening? That's the first thing my ISP would
>>ask for, probably.
>
>Yeah. Here. (Apologies to list, but since Craig's mail server is still
>bouncing mail intermittently...)
Thanks. That's so weird: I saw the email you enclosed sometime late
Friday night, when I fetched my email (I could narrow that down by
examining my archives, if necessary, I suppose).
(I'm cc'ing my ISP on this email, as they indeed asked to see a bounce.)
>I already tried sending this to postmaster@jcb-sc.com, and got the same
>sort of bounce. I did Whois lookup and saw their technical and admin
>contacts at world.std.com; I mailed them suggesting they fire the
>postmaster and noc at jcb-sc.com and telling them why, and world.std.com
>bounced as well. Is damned weird.
In case this gives you some sudden insight into what I, or my ISP,
might be doing wrong, `jcb-sc.com' is my domain name, so I'm "everyone"
there, including postmaster (and, yes, postmaster mail goes to my
root account and, no, there's no bounce-related email there, just
the usual mumblings relating to my having not yet configured news
properly).
And, `jcb-sc.com' is, to the rest of the Internet, just an MX record
pointing to `world.std.com'. So any email sent to anybody at `jcb-sc.com'
just ends up going to my account at world.std.com (via that system's
SMTP server), where I pick it up via fetchmail, and deliver it to myself,
on my local LAN, via qmail (SMTP). At least, that's how I understand it
is *supposed* to work, from what I've read.
So, I *suppose* I could fire myself, as both postmaster and `noc',
whatever that is ("network oxymoron consultant"? :). But there's
got to be a better way.
>At least if you suddenly find that your subscription to egcs lists has
>evaporated, you'll know why (your server started bouncing incoming mail
>again and triggered the automatic bad-address-unsubscribe) and who to blame
>(your ISP).
So far, I'm not aware that I've actually missed anything. Are *all*
my messages bouncing (this wouldn't count the ones from egcs-cvs,
since those are sent by the egcs repository server, I assume)? Or
just some of them?
As far as what little I can make of the header below: there seems to
be little semantic information in the message "550 Wrong." from which
I can gather a clue. But, from "554 <craig@jcb-sc.com>... Service
unavailable", it looks like maybe what happened is that some MTA
tried to deliver the mail *directly* to `jcb-sc.com', instead of
to `world.std.com'.
How could this happen, with me still getting the email, I ask myself,
since my LAN shouldn't accept any outsiders trying to connect to its
SMTP server?
Well, the one copy I *know* I got, in my archives, came via owner-egcs,
so it came via the mailing list.
But, there's a `Cc: craig@jcb-sc.com' on it, so the message was *also*
copied to me directly.
And perhaps *that* copy never made it here, because some MTA didn't
take the advice of the MX record to deliver it to `world.std.com',
and I happened to be off-line and/or my SMTP server (qmail) rejected
the connection (I have a non-null rcpthosts, which will mean something
to the qmail-aware).
I'll enclose a copy of the nslookup session I had from my LAN using
my ISP's DNS server Saturday morning when I first saw your notices
about the apparent email problems here. You'll notice the MX record
points to `world.std.com'. (My LAN's local DNS isn't really set up
right yet. I've convinced qmail to ignore it, by feeding it all the
appropriate info in /var/qmail/control/.)
[craig@deer gnu]$ nslookup
*** Can't find server name for address 192.168.0.1: Non-existent host/domain
Default Server: world.std.com
Address: 192.74.137.5
> jcb-sc.com
Server: world.std.com
Address: 192.74.137.5
*** world.std.com can't find jcb-sc.com: Non-existent host/domain
> ls -d jcb-sc.com
[world.std.com]
$ORIGIN jcb-sc.com.
@ 1d2s IN SOA world.std.com. netadmin.world.std.com. (
98101501 ; serial
5D ; refresh
1H ; retry
2w6d ; expiry
1d2s ) ; minimum
1d2s IN NS world.std.com.
1d2s IN NS AUTH01.NS.UU.NET.
1d2s IN MX 10 world.std.com.
1d2s IN SOA world.std.com. netadmin.world.std.com. (
98101501 ; serial
5D ; refresh
1H ; retry
2w6d ; expiry
1d2s ) ; minimum
So it might not be a problem on my end, or even my ISP's end at all,
though I'm *really* speculating here, as I'm a newbie with all this
email stuff (whatever happened to smoke signals?).
If you want to test my theory, and you've had bounces from me
at <craig@jcb-sc.com>, try sending the same test message to that
*and* to <burley@world.std.com>, the "unposted" address to which
the former is turned into before waiting for fetchmail to pick
it up for my LAN. I can then look at which copies arrived, and
at their headers. (If you haven't gotten bounces from me, don't
bother testing it -- I've tested it myself enough times that I
know the setup basically works, and I can do it again myself, since
I still have logins elsewhere in the net, invisible to anything
on my LAN except an old kermit binary.)
tq vm, (burley)
>>The original message was received at Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>>from dialin109.ottawa.globalserve.net [207.176.153.109]
>>
>> ----- The following addresses had permanent fatal errors -----
>><craig@jcb-sc.com>
>>
>> ----- Transcript of session follows -----
>>... while talking to world.std.com.:
>>>>> MAIL From:<pderbysh@usa.net>
>><<< 550 Wrong.
>>554 <craig@jcb-sc.com>... Service unavailable
>>Reporting-MTA: dns; smtp2.globalserve.net
>>Received-From-MTA: DNS; dialin109.ottawa.globalserve.net
>>Arrival-Date: Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>>
>>Final-Recipient: RFC822; craig@jcb-sc.com
>>Action: failed
>>Status: 5.0.0
>>Remote-MTA: DNS; world.std.com
>>Diagnostic-Code: SMTP; 550 Wrong.
>>Last-Attempt-Date: Fri, 12 Feb 1999 19:02:40 -0500 (EST)
>>Return-Path: <pderbysh@usa.net>
>>Received: from chaoszone (dialin109.ottawa.globalserve.net [207.176.153.109])
>> by smtp2.globalserve.net (8.9.1/8.9.1) with SMTP id TAA19254;
>> Fri, 12 Feb 1999 19:02:26 -0500 (EST)
>>Message-Id: < 3.0.6.32.19990212190141.00891c70@pop.netaddress.com >
>>X-Sender: pderbysh@pop.netaddress.com
>>X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
>>Date: Fri, 12 Feb 1999 19:01:41 -0500
>>To: craig@jcb-sc.com
>>From: Paul Derbyshire <pderbysh@usa.net>
>>Subject: Enough is enough... truce time. Re: kernel blah blah blah
>>Cc: egcs@egcs.cygnus.com
>>In-Reply-To: < 19990212221225.22651.qmail@deer >
>>References: < 7a203j$9cf$1@palladium.transmeta.com >
>> < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
>> < 19990211201836.2781.qmail@deer >
>> < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
>> < 19990212031118.4271.qmail@deer >
>> < 7a203j$9cf$1@palladium.transmeta.com >
>>Mime-Version: 1.0
>>Content-Type: text/plain; charset="us-ascii"
[...rest of message elided, there were no more headers beyond the
final one shown...]
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: kernel-2.2.1-undefined references.
1999-02-08 16:00 ` Lee Iverson
[not found] ` < 199902090000.QAA28993@Canada.AI.SRI.COM >
@ 1999-02-28 22:53 ` Lee Iverson
1 sibling, 0 replies; 180+ messages in thread
From: Lee Iverson @ 1999-02-28 22:53 UTC (permalink / raw)
To: Ross Smith; +Cc: egcs, H. Peter Anvin, Linus Torvalds
In message < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz > you write:
> From: Per Bothner <bothner@cygnus.com>
> >
> >[Linus wrote:]
> >> I'm not trying to be unreasonable. I'm just saying that if there is a
> >> function that is marked inline that can be inlined, it _should_ be
> >> inlined, because the compiler _never_ knows better than the programmer.
> >
> >Er, the compiler often knows better than the programmer. That is why
> >we use compilers - to free us from low-level and architecture-dependent
> >decisions.
> >
> >We cannot design a compiler for the Linux Torvalds' of the world.
> >We have to do what is best for *most* programmers, while still
> >providing the needed tools for the experts.
>
> It occurs to me that the real problem here is that "inline" is being
> used to refer to two slightly different concepts, and some of the
> participants in this thread haven't noticed this and are talking past
> each other.
>
> (A) inline == "I [the programmer] know exactly what this code is
> supposed to do at low level, and I have determined that this function
> must be inline for proper behaviour, so inline it or give me an error
> if you [the compiler] can't."
It occurs to me that we do, in fact have an acceptable method of
*guaranteeing* inlining of a *function* in gcc. That is a combination
of a macro and the "Statement Expression" extension.
#define foo(_x) ({ \
int x = (_x); \
/* Various commands */ \
val; \
)}
is *already* the exact equivalent of:
extern inline foo (int x) {
/* Various commands */
return val;
)
except that it also says, "I know exactly what I'm doing and this function
*must* be inlined". Surely the number of functions in the kernel
which *must* be inlined for correct functioning is small
transformation can be done and ensure that correct code is generated.
-------------------------------------------------------------------------------
Lee Iverson SRI International
leei@ai.sri.com 333 Ravenswood Ave., Menlo Park CA 94025
http://www.ai.sri.com/~leei/ (650) 859-3307
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 17:21 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990212202016.0081bb30@pop.netaddress.com >
@ 1999-02-28 22:53 ` Paul Derbyshire
1 sibling, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
At 03:35 PM 2/12/99 -0800, you wrote:
>> If the address is only taken right at the label
>> itself, then it seems reasonable to make an inline __attribute__ ((always))
>> label and label address situation work like this:
>
>Agreed. That would work beautifully, and I wouldn't have to think that the
>egcs people are just trying to make it difficult to do something
>reasonable.
I'm sure they're just trying to make it difficult to cause egcs to generate
bad code, and didn't realize it'd accidentally step on some unusual code in
one particular place.
Getting them to fix __builtin_return_address would be even better since
your code is (to put it bluntly) a kluge to get around a wart in GCC to
begin with. But my suggestions sure look doable...I'm not exactly sporting
a PhD in compiler theory, but 15 years of programming experience must count
for something =)
Not only do they look doable, they also don't look tricky to implement... a
few lines added here and there should suffice. Probably a 24 hour job tops
to create a patch that will generate those attributes and give them the
appropriate behavior.
(At least for someone like me that spends hours behind a keyboard with a
six-pack of something strongly caffeinated... but unlike me knows a lot of
gcc internals and is experienced hacking gcc.)
Hopefully, we can now put the who's wrong and the who broke what code
arguments behind us and start actually correcting the problem in a sane and
rational manner worthy of the advanced hackers and assorted wizards that I
see here.
I just wish I could help in some way more substantial than pitching in some
needed levelheaded mediating and some ideas on how to fiddle EGCS and linux
to everyone's satisfaction. Without, that is, poring over egcs sources for
years and then tentatively submitting a patch someone here already familiar
with the egcs guts can probably produce in less than a week, and doing a
better job.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 15:53 ` Paul Derbyshire
@ 1999-02-28 22:53 ` Paul Derbyshire
0 siblings, 0 replies; 180+ messages in thread
From: Paul Derbyshire @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
At 03:31 PM 2/12/99 -0800, you wrote:
>Doesn't anybody actually read what I'm saying?
Yeah, but I read from word one to the end linearly like most mere mortals
rather than receiving the email into a direct neural interface and
apprehending the whole thing at a mental glance. ;-)
I hadn't encountered your objections to macros, re: type checking and
side effects, until after reading and responding to the section where you
wistfully longed for the days when inline functions behaved like macros. :-)
>which is why I _want_ to use "extern inline", because the compiler does
>support the notion of inlining, and it's a very powerful notion. But it
>does require that if you want to use it as a macro, the compiler had
>better have some way of marking it important. I always read "extern" as
>being that marker.
Apparently it no longer has that rule, which is why I suggested a new
marker or two; suggestions to which neither you nor the compiler gurus
appear to have responded yet.
--
.*. "Clouds are not spheres, mountains are not cones, coastlines are not
-() < circles, and bark is not smooth, nor does lightning travel in a
`*' straight line." -------------------------------------------------
-- B. Mandelbrot | http://surf.to/pgd.net
_____________________ ____|________ Paul Derbyshire pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 18:58 A final solution. (Was Re: kernel-2.2.1-undefined references.) Mike Stump
[not found] ` < 199902130258.SAA20411@kankakee.wrs.com >
[not found] ` <Pine.LNX.3.95.990212190247.31280Q-100000.cygnus.egcs@penguin.transmeta.com>
@ 1999-02-28 22:53 ` Mike Stump
2 siblings, 0 replies; 180+ messages in thread
From: Mike Stump @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds, zack; +Cc: egcs
> Date: Fri, 12 Feb 1999 18:24:01 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> It's _really_ painful if it ever happens, because the linker doesn't know
> how to extract just one function from the object file, and you end up with
> one big object file that contains all of it.
You like the bleeding edge... Use -ffunction-sections, and
-Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
sure, no problem.
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 22:06 ` Jason Merrill
@ 1999-02-28 22:53 ` Jason Merrill
0 siblings, 0 replies; 180+ messages in thread
From: Jason Merrill @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
>>>>> Linus Torvalds <torvalds@transmeta.com> writes:
> On Fri, 12 Feb 1999, Mike Stump wrote:
>>
>> You like the bleeding edge... Use -ffunction-sections, and
>> -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
>> sure, no problem.
> Hey, does that actually work reliably?
On Linux, --gc-sections only works if you link statically; using it with a
dynamic link produces a non-functional executable. 'twould be nice for
someone to fix this.
It might work fine for the kernel.
Jason
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 19:05 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212190247.31280Q-100000@penguin.transmeta.com >
@ 1999-02-28 22:53 ` Linus Torvalds
1 sibling, 0 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-28 22:53 UTC (permalink / raw)
To: Mike Stump; +Cc: zack, egcs
On Fri, 12 Feb 1999, Mike Stump wrote:
>
> You like the bleeding edge... Use -ffunction-sections, and
> -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
> sure, no problem.
Hey, does that actually work reliably? We've used linker tricks before,
and while I wouldn't like to use them for this particular case, there are
other cases that would be simplified by not having to split up object
files by hand (the string stuff still comes to mind).
Oh, and is it documented and supported without any "maybe" clauses? <evil
grin>
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 19:20 ` Jeffrey A Law
@ 1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 0 replies; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-28 22:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Stump, zack, egcs
In message < Pine.LNX.3.95.990212190247.31280Q-100000@penguin.transmeta.com >yo
u write:
> On Fri, 12 Feb 1999, Mike Stump wrote:
> >
> > You like the bleeding edge... Use -ffunction-sections, and
> > -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
> > sure, no problem.
>
> Hey, does that actually work reliably?
The -ffunction-sections code has been around for a while and as far as I
know works reliably on targets which use ELF or SOM object formats.
Other object formats may or may not support -ffunction-sections either due
to object format limitations or gcc implementation details on those targets.
-ffunction-sections was originally designed to allow for the linker to
reorder functions to improve icache & tlb behavior. It turns out the same
technology (putting each function into its own section) greatly simplifies
the garbage collection of unused functions. The docs are probably in need of
updating since they're probably somewhat biased towards the original use
of -ffunction-sections.
The linker support for garbage collection is newer and I don't have a lot
of experience with it. I would tend to believe that the basic garbage
collection ought to work pretty well since it's just mark, sweep & discard.
Stuff like garbage collecting entries in C++ virtual tables is more on the
bleeding edge and requires more cooperation between the compiler, assembler
and linker.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
1999-02-12 19:35 Mike Stump
@ 1999-02-28 22:53 ` Mike Stump
0 siblings, 0 replies; 180+ messages in thread
From: Mike Stump @ 1999-02-28 22:53 UTC (permalink / raw)
To: torvalds; +Cc: egcs, zack
> Date: Fri, 12 Feb 1999 19:04:42 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: Mike Stump <mrs@wrs.com>
> On Fri, 12 Feb 1999, Mike Stump wrote:
> >
> > You like the bleeding edge... Use -ffunction-sections, and
> > -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
> > sure, no problem.
> Hey, does that actually work reliably? We've used linker tricks
> before, and while I wouldn't like to use them for this particular
> case, there are other cases that would be simplified by not having
> to split up object files by hand (the string stuff still comes to
> mind).
> Oh, and is it documented and supported without any "maybe" clauses?
> <evil grin>
Ok, sounds like we are on good terms again. Sure, go ahead and use
them, there can't be _any_ bugs in those two really cutting edge
features, can there? Naw, we're studs. Rth Rules!
:-)
Ok, that aside, I have used them in trivial cases, and observed they
did exactly what I wanted. If your willing to bleed, welcome to the
edge!
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` <Pine.LNX.3.95.990212190247.31280Q-100000.cygnus.egcs@penguin.transmeta.com>
@ 1999-02-12 22:06 ` Jason Merrill
1999-02-28 22:53 ` Jason Merrill
0 siblings, 1 reply; 180+ messages in thread
From: Jason Merrill @ 1999-02-12 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: egcs
>>>>> Linus Torvalds <torvalds@transmeta.com> writes:
> On Fri, 12 Feb 1999, Mike Stump wrote:
>>
>> You like the bleeding edge... Use -ffunction-sections, and
>> -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
>> sure, no problem.
> Hey, does that actually work reliably?
On Linux, --gc-sections only works if you link statically; using it with a
dynamic link produces a non-functional executable. 'twould be nice for
someone to fix this.
It might work fine for the kernel.
Jason
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
@ 1999-02-12 19:35 Mike Stump
1999-02-28 22:53 ` Mike Stump
0 siblings, 1 reply; 180+ messages in thread
From: Mike Stump @ 1999-02-12 19:35 UTC (permalink / raw)
To: torvalds; +Cc: egcs, zack
> Date: Fri, 12 Feb 1999 19:04:42 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> To: Mike Stump <mrs@wrs.com>
> On Fri, 12 Feb 1999, Mike Stump wrote:
> >
> > You like the bleeding edge... Use -ffunction-sections, and
> > -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
> > sure, no problem.
> Hey, does that actually work reliably? We've used linker tricks
> before, and while I wouldn't like to use them for this particular
> case, there are other cases that would be simplified by not having
> to split up object files by hand (the string stuff still comes to
> mind).
> Oh, and is it documented and supported without any "maybe" clauses?
> <evil grin>
Ok, sounds like we are on good terms again. Sure, go ahead and use
them, there can't be _any_ bugs in those two really cutting edge
features, can there? Naw, we're studs. Rth Rules!
:-)
Ok, that aside, I have used them in trivial cases, and observed they
did exactly what I wanted. If your willing to bleed, welcome to the
edge!
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < Pine.LNX.3.95.990212190247.31280Q-100000@penguin.transmeta.com >
@ 1999-02-12 19:20 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
0 siblings, 1 reply; 180+ messages in thread
From: Jeffrey A Law @ 1999-02-12 19:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Mike Stump, zack, egcs
In message < Pine.LNX.3.95.990212190247.31280Q-100000@penguin.transmeta.com >yo
u write:
> On Fri, 12 Feb 1999, Mike Stump wrote:
> >
> > You like the bleeding edge... Use -ffunction-sections, and
> > -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
> > sure, no problem.
>
> Hey, does that actually work reliably?
The -ffunction-sections code has been around for a while and as far as I
know works reliably on targets which use ELF or SOM object formats.
Other object formats may or may not support -ffunction-sections either due
to object format limitations or gcc implementation details on those targets.
-ffunction-sections was originally designed to allow for the linker to
reorder functions to improve icache & tlb behavior. It turns out the same
technology (putting each function into its own section) greatly simplifies
the garbage collection of unused functions. The docs are probably in need of
updating since they're probably somewhat biased towards the original use
of -ffunction-sections.
The linker support for garbage collection is newer and I don't have a lot
of experience with it. I would tend to believe that the basic garbage
collection ought to work pretty well since it's just mark, sweep & discard.
Stuff like garbage collecting entries in C++ virtual tables is more on the
bleeding edge and requires more cooperation between the compiler, assembler
and linker.
jeff
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
[not found] ` < 199902130258.SAA20411@kankakee.wrs.com >
@ 1999-02-12 19:05 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212190247.31280Q-100000@penguin.transmeta.com >
1999-02-28 22:53 ` Linus Torvalds
0 siblings, 2 replies; 180+ messages in thread
From: Linus Torvalds @ 1999-02-12 19:05 UTC (permalink / raw)
To: Mike Stump; +Cc: zack, egcs
On Fri, 12 Feb 1999, Mike Stump wrote:
>
> You like the bleeding edge... Use -ffunction-sections, and
> -Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
> sure, no problem.
Hey, does that actually work reliably? We've used linker tricks before,
and while I wouldn't like to use them for this particular case, there are
other cases that would be simplified by not having to split up object
files by hand (the string stuff still comes to mind).
Oh, and is it documented and supported without any "maybe" clauses? <evil
grin>
Linus
^ permalink raw reply [flat|nested] 180+ messages in thread
* Re: A final solution. (Was Re: kernel-2.2.1-undefined references.)
@ 1999-02-12 18:58 Mike Stump
[not found] ` < 199902130258.SAA20411@kankakee.wrs.com >
` (2 more replies)
0 siblings, 3 replies; 180+ messages in thread
From: Mike Stump @ 1999-02-12 18:58 UTC (permalink / raw)
To: torvalds, zack; +Cc: egcs
> Date: Fri, 12 Feb 1999 18:24:01 -0800 (PST)
> From: Linus Torvalds <torvalds@transmeta.com>
> It's _really_ painful if it ever happens, because the linker doesn't know
> how to extract just one function from the object file, and you end up with
> one big object file that contains all of it.
You like the bleeding edge... Use -ffunction-sections, and
-Wl,--gc-sections when you compile. [duck] Make that kernel smaller,
sure, no problem.
^ permalink raw reply [flat|nested] 180+ messages in thread
end of thread, other threads:[~1999-02-28 22:53 UTC | newest]
Thread overview: 180+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-02-08 14:55 kernel-2.2.1-undefined references Ross Smith
[not found] ` < 003c01be53b6$5b04ff40$a8a11dcb@animal.ihug.co.nz >
1999-02-08 16:00 ` Lee Iverson
[not found] ` < 199902090000.QAA28993@Canada.AI.SRI.COM >
1999-02-08 16:12 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990208160839.433A-100000@penguin.transmeta.com >
1999-02-08 16:40 ` Lee Iverson
[not found] ` < 199902090039.QAA01060@Canada.AI.SRI.COM >
1999-02-08 16:44 ` H. Peter Anvin
[not found] ` < 199902090043.QAA21188@cesium.transmeta.com >
1999-02-10 3:33 ` Jamie Lokier
[not found] ` < 19990210105658.A1570@tantalophile.demon.co.uk >
1999-02-10 9:36 ` Jamie Lokier
[not found] ` < 19990210171623.A2799@tantalophile.demon.co.uk >
1999-02-10 9:55 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990210094228.13924A-100000@penguin.transmeta.com >
1999-02-10 10:54 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Jamie Lokier
1999-02-28 22:53 ` Jamie Lokier
1999-02-28 22:53 ` H. Peter Anvin
1999-02-08 17:18 ` Joe Buck
[not found] ` < 199902090116.RAA15478@atrus.synopsys.com >
1999-02-08 17:28 ` Lee Iverson
[not found] ` < 199902090128.RAA04379@Canada.AI.SRI.COM >
1999-02-08 17:42 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
1999-02-08 17:54 ` Linus Torvalds
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Lee Iverson
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Lee Iverson
1999-02-08 17:17 ` Joe Buck
[not found] ` < 199902090114.RAA15416@atrus.synopsys.com >
1999-02-08 17:51 ` Linus Torvalds
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Joe Buck
1999-02-09 11:45 ` craig
[not found] ` < 19990209191412.27056.qmail@deer >
1999-02-09 13:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990209135218.2116D-100000@penguin.transmeta.com >
1999-02-10 5:47 ` craig
1999-02-10 9:42 ` Linus Torvalds
[not found] ` < 79sgd8$p7p$1@palladium.transmeta.com >
1999-02-10 11:04 ` Lee Iverson
1999-02-28 22:53 ` Lee Iverson
1999-02-10 11:51 ` Marc Espie
[not found] ` < 199902101950.UAA03203@quatramaran.ens.fr >
1999-02-10 16:27 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990210161330.14471K-100000@penguin.transmeta.com >
1999-02-10 17:56 ` Joe Buck
[not found] ` < 199902110155.RAA14069@atrus.synopsys.com >
1999-02-10 20:01 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Marc Espie
1999-02-11 12:20 ` craig
[not found] ` < 19990211201836.2781.qmail@deer >
1999-02-11 12:57 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990211125202.18523E-100000@penguin.transmeta.com >
1999-02-11 19:41 ` craig
[not found] ` < 19990212033918.4310.qmail@deer >
1999-02-12 10:12 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212095518.31280C-100000@penguin.transmeta.com >
1999-02-12 14:50 ` craig
1999-02-12 17:28 ` Benjamin Scherrey
1999-02-28 22:53 ` Benjamin Scherrey
[not found] ` < 19990212224331.22671.qmail@deer >
1999-02-12 21:08 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990213000806.008529f0@pop.netaddress.com >
1999-02-13 7:24 ` craig
[not found] ` < 19990213152402.25468.qmail@deer >
1999-02-13 10:47 ` Joe Buck
[not found] ` < 199902131846.KAA25341@atrus.synopsys.com >
1999-02-13 13:03 ` craig
[not found] ` < 19990213205319.19426.qmail@deer >
1999-02-14 16:25 ` Joe Buck
[not found] ` < 199902150025.QAA00417@atrus.synopsys.com >
1999-02-14 17:26 ` craig
[not found] ` < 19990215011831.28108.qmail@deer >
1999-02-14 18:08 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
1999-02-14 19:13 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214221218.008eacc0@pop.netaddress.com >
1999-02-14 19:51 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214225028.00820ea0@pop.netaddress.com >
1999-02-14 20:01 ` off-topic ramblings [Re: kernel-2.2.1-undefined references.] Mumit Khan
1999-02-28 22:53 ` Mumit Khan
1999-02-28 22:53 ` kernel-2.2.1-undefined references Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` craig
1999-02-14 17:59 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Joe Buck
1999-02-14 9:08 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990214120800.0087f100@pop.netaddress.com >
1999-02-14 12:19 ` mail sent to <craig@jcb-sc.com> is bouncing, why? craig
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` kernel-2.2.1-undefined references Paul Derbyshire
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-11 15:15 ` David J. Dooling
[not found] ` < 19990211231523.14202.qmail@piglet.chem-eng.nwu.edu >
1999-02-11 16:28 ` Lee Iverson
1999-02-28 22:53 ` Lee Iverson
1999-02-11 16:32 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-11 19:41 ` craig
[not found] ` < 19990212031118.4271.qmail@deer >
1999-02-11 19:41 ` craig
[not found] ` < 19990212034058.4359.qmail@deer >
1999-02-12 4:10 ` Bad puppies and coding practices Marc Espie
[not found] ` < 199902121210.NAA04037@quatramaran.ens.fr >
1999-02-12 4:25 ` Alex Buell
[not found] ` < Pine.LNX.4.05.9902120729110.2093-100000@tahallah.demon.co.uk >
1999-02-12 6:37 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-12 9:00 ` craig
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Alex Buell
1999-02-12 9:04 ` craig
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Marc Espie
1999-02-28 22:53 ` kernel-2.2.1-undefined references craig
1999-02-12 11:40 ` Linus Torvalds
[not found] ` < 7a203j$9cf$1@palladium.transmeta.com >
1999-02-12 14:24 ` A final solution. (Was Re: kernel-2.2.1-undefined references.) Paul Derbyshire
[not found] ` < 3.0.6.32.19990212172337.0082de00@pop.netaddress.com >
1999-02-12 15:31 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212152049.31280H-100000@penguin.transmeta.com >
1999-02-12 15:44 ` Zack Weinberg
[not found] ` < 199902122344.SAA28257@blastula.phys.columbia.edu >
1999-02-12 15:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212154725.31280K-100000@penguin.transmeta.com >
1999-02-12 17:50 ` Jeffrey A Law
[not found] ` < 10147.918870502@hurl.cygnus.com >
1999-02-12 18:01 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212175435.31280O-100000@penguin.transmeta.com >
1999-02-12 23:48 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Jeffrey A Law
1999-02-12 19:01 ` craig
[not found] ` < 19990213003025.23197.qmail@deer >
1999-02-15 7:33 ` Joern Rennecke
1999-02-28 22:53 ` Joern Rennecke
1999-02-15 7:40 ` Joern Rennecke
1999-02-28 22:53 ` Joern Rennecke
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Zack Weinberg
1999-02-12 15:53 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-12 19:00 ` craig
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 15:35 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212153140.31280I-100000@penguin.transmeta.com >
1999-02-12 17:21 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990212202016.0081bb30@pop.netaddress.com >
1999-02-12 17:53 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212174436.31280N-100000@penguin.transmeta.com >
1999-02-12 18:02 ` Zack Weinberg
[not found] ` < 199902130202.VAA28998@blastula.phys.columbia.edu >
1999-02-12 18:24 ` Joern Rennecke
1999-02-28 22:53 ` Joern Rennecke
1999-02-12 18:24 ` Linus Torvalds
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 21:02 ` Removing code dupe in libc (Was: A final solution...) Paul Derbyshire
[not found] ` < 3.0.6.32.19990213000128.0089c2a0@pop.netaddress.com >
1999-02-12 21:14 ` Zack Weinberg
[not found] ` < 199902130514.AAA00047@blastula.phys.columbia.edu >
1999-02-13 1:26 ` Paul Derbyshire
[not found] ` < 3.0.6.32.19990213042627.008c0960@pop.netaddress.com >
1999-02-14 15:21 ` Gerald Pfeifer
1999-02-28 22:53 ` Gerald Pfeifer
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Zack Weinberg
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` A final solution. (Was Re: kernel-2.2.1-undefined references.) Zack Weinberg
1999-02-12 18:13 ` Mark Mitchell
1999-02-28 22:53 ` Mark Mitchell
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 16:16 ` craig
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Paul Derbyshire
1999-02-12 14:50 ` kernel-2.2.1-undefined references craig
[not found] ` < 19990212221225.22651.qmail@deer >
1999-02-12 15:44 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212153656.31280J-100000@penguin.transmeta.com >
1999-02-12 19:01 ` craig
[not found] ` < 19990213011316.23309.qmail@deer >
1999-02-13 1:22 ` Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-12 16:02 ` Enough is enough... truce time. Re: kernel blah blah blah Paul Derbyshire
1999-02-28 22:53 ` Paul Derbyshire
1999-02-28 22:53 ` kernel-2.2.1-undefined references craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` David J. Dooling
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` craig
1999-02-28 22:53 ` Linus Torvalds
1999-02-28 22:53 ` Lee Iverson
1999-02-08 16:51 ` Bryan W. Headley
[not found] ` < 36BF94AB.A7CD5DF5@interaccess.com >
1999-02-08 17:36 ` Joe Buck
1999-02-28 22:53 ` Joe Buck
1999-02-28 22:53 ` Bryan W. Headley
1999-02-28 22:53 ` Ross Smith
1999-02-12 18:58 A final solution. (Was Re: kernel-2.2.1-undefined references.) Mike Stump
[not found] ` < 199902130258.SAA20411@kankakee.wrs.com >
1999-02-12 19:05 ` Linus Torvalds
[not found] ` < Pine.LNX.3.95.990212190247.31280Q-100000@penguin.transmeta.com >
1999-02-12 19:20 ` Jeffrey A Law
1999-02-28 22:53 ` Jeffrey A Law
1999-02-28 22:53 ` Linus Torvalds
[not found] ` <Pine.LNX.3.95.990212190247.31280Q-100000.cygnus.egcs@penguin.transmeta.com>
1999-02-12 22:06 ` Jason Merrill
1999-02-28 22:53 ` Jason Merrill
1999-02-28 22:53 ` Mike Stump
1999-02-12 19:35 Mike Stump
1999-02-28 22:53 ` Mike Stump
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).