Re: GCC 3.3 release criteria

[Richard Earnshaw <rearnsha at arm dot com>]

> Richard Earnshaw <rearnsha at arm dot com> writes:
> 
> [...]
> 
> | > Especially in C, people that do use "inline" probably have strong
> | > reasons for why they want to see this function be inlined.   For example
> | > in the kernel, they want to be able to control and predict what the
> | > compiler does with the code.  It this case it is a mistake on the
> | > compiler's part to think it can outsmart man.
> | > 
> | > Like Franz said, for C++ things are probalby different.
> | > 
> | 
> | The cases in C where I've seen people get most upset about the compiler 
> | not using inline are when the program has subtly different semantics once 
> | inlining has occurred (for example, taking the address of a label and then 
> | using that as a key in a debug message).  But these are precisely the 
> | types of cases where we probably don't want inlining: relying on such 
> | optimization to get correct behaviour is a dangerous mistake.
> 
> Agreed.  Ideally "inline" should not change the observable behaviour.
> However, concerning "inline", ISO C99 has provided and blessed ways to
> violate the ODR and to make "ready for changing semantics" :-(

We have to be fairly careful here, since we are dealing with 3 different 
specifications of "inline": GNU (pre-c99), C99 and C++.  I'm not 
particularly familiar with the subtleties of all three.

C99 says (6.7.4par5):

 ... Making a function an inline function suggests that calls to the
 function be as fast as possible.  The extent to which such suggestions are
 effective is implementation defined.

Note two things.  Firstly, this is only a "suggestion".  Secondly, since 
an implementation is free to ignore such a request any code that relies on 
honouring the request for correct behaviour must be ill-formed.

R.