Re: GCC 3.3 release criteria

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Richard Earnshaw <rearnsha at arm dot com> writes:

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

then, do we plan to issue a diagnostic?

To extend my original comment, here are pieaces where C99 blesses ODR
violation:

6.7.4/6
  [...] An inline definition does not provide an external definition
  for the function, and does not forbid an external definition in
  another translation unit.  An inline definition  provides an
  alternative to an external definition, which a translator may use to
  implement any call to the function  in  the  same translation  unit.
  It is unspecified whether a call to the function  uses  the  inline
  definition  or   the   external definition. 


I agree that ideally, C programs should not depend on inlining for
correctness, but in practice that seems to happen more than often.

-- Gaby