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

[Richard Earnshaw <rearnsha at arm dot com>]

> > 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.