Re: -fobey-inline (was Re: gcc and inlining)

[dewar at gnat dot com (Robert Dewar)]

Just to be clear, I absolutely agree that it is useful to have mandator inlining,
and I already gave a completely different reason from the (perfecgtly reasonable)
ones that have been suggested by others (I gave the certification case).

The setjmp/longjmp case is indeed a nice example. I am quite sure that this
example must be undefined in terms of the standard, and the standard is not
just saying "this is undefined, because it is undefined whether inlining occurs".
The reason is more fundamental. The idea of inlining being somehow semantically
equivalent to having the source code actually inlined is conceptually and pragmatically
reasonable, but is way out of scope of the semantic definition in the standard.

So you really can't figure out what this longjmp/setjmp case means from the standard
whether or not inlining actually takes place.

However, in terms of a particular implementation, which enforces inlining, you can
definitely write (undefined, buggy, improper, non-conforming, use whatever adjectives
you feel like) code that does in fact "work" as intended. Yes, of course the code
is not necessarily portable to other compilers etc, but in certain contexts it seems
quite fine to me to use such code if it is well documented, and it is fine to provide
compiler options etc within reason that support such usage.

As an example of this, we do several "nasty non-standard" things in the GNAt library
that we happen to know will work with GNAT, since the run-time library of GNAT is
only ever intended to be compiled with GNAT. Nothing wrong with this (it has 
occasionally inconvenienced users and vendors of other proprietary compilers who
would like to use the GNAT run-time with their compilers, but satisfying that
need is not one of our requirements :-)

Language lawyers who know the standard can tell you that a given program does or does
not have a fully defined behavior according to the standard, but they have no business
telling you that it is always improper to write programs which are not fully defined
in these terms, and compiler writers who think that this viewpoint is legitimate
will meet the letter of the standard, but will fail to provide a maximally usable
compiler.

Note that there is no general principle here. It is neither always right nor always
wrong to use stuff that is outside the standard. Casual use of non-standard features
that derives from ignorance rather than real need should definitely be discouraged
and certainly need not be pandered to. Each case is a judgment call as to whether
the non-standard usage is legitimate enough to be semi-standardized in a particular
compiler.

It seems clear to me that mandatory inlining is something that meets this test, and
should be supported.