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

[Lars Segerlund <lars dot segerlund at comsys dot se>]

 Well your code doesn't depend on it does it ?

 Here are some people that have the resonable request of having some 
code mandatory inlined, they have supplied examples of where this is 
necessary ( no stack ( happens in kernel ), and setjmp longjmp ).

 Were all very aware that you think this is a bad idea, however I think 
the debate is taking a religious turn, the setjmp/longjmp example was 
exellent, with an example of where this kind of code had occured and 
might occur ( the lib in question ). Trying to deduce the non compliance 
of this code is silly since that argument is based upon the context, 
i.e. "if it works the way I want it's illegal code" instead of quoting 
that setjmp or longjmp is prohibited to be invoked in this context ( 
which they are not ). The alternative is to make the compiler smart 
enough to inline all functions containing a setjump referensed by a 
longjump, I see no other way to enforce compliance.

 Anyhow it doesn't matter since it's possible to do the same thing 
without the flag, it's a lot of hazzle, it will be done, and it will be 
done in a way which is much more 'ugly'.

 Also for some cases of threaded code this would be vital, ( especially 
threaded libs ), in order to make them easy to code. ( thread safe 
library could be built by adding the flag and a non thread safe by 
omitting ), cases like this will now have to be handled with macros and 
defines which tend to make things a bit ugly when you start hitting a 
couple of KLOC's.

 So whatever feedback people provide doesn't seem to generate an open 
debate but instead the standard response that "they're doing it wrong". 
Which perhaps is not the best argument to convince someone of a standpoint.

 I think, "No we don't need another flag" would be a better argument.

 / sincerely, Lars Segerlund.

Richard Earnshaw wrote:
> > > Ah, but if the inline is performed it's not an expired scope any more.  
> > > One of
> > > the early C++ suites did exactly this, expecting the inline to be 
> > > performed.
> >
> > No, that's not correct thinking, the expired scope is a semantic concept. The
> > fact that the undefined effect may be different if inlining takes place or not
> > means nothing (or at least I would guess this). I can't imagine that somethingt
> > like this suddently becomes defined if inlining takes place, the C standard
> > can't be that vague ... but surely someone who knows the standard really well
> > will read us the chapter and verse :-)
>
>
> Of course it's not defined behaviour in C99, since it's unspecified 
> whether inlining will take place for any given function -- and hence 
> anything that depends on inlining occuring is then by definition 
> incorrect.  As soon as you make inlining mandatory, these questions start 
> to rear their heads.
>
> It's precisely because mandatory inlining can have implications on 
> behaviour right across the language that we can't even imagine, let alone 
> test that I'm against supporting this type of behaviour.
>
> If we had a precise and complete specification to work to, and tests to 
> prove that we were adhering to that specification then there would be less 
> of a problem.  At least then we would know when changes in the compiler 
> had altered the way a user's program would be compiled.  But even that 
> doesn't solve the issue that we repeatedly run across where some existing 
> extension prevents us from optimizing a conforming program as well as we 
> could do otherwise.
>
> R.