Re: Semantics of Inline vs non-Inline

[Simon Wright <simon@pushface.org>]

aschwarz@acm.org (skidmarks) writes:

> My compiler vendor says that the semantics of an inline/non-inline
> function can be different at the discretion of the compiler
> vendor. In particular, if at the point of use of an inline function
> the value of an argument (to the defined subprogram) is in a
> register, then it is acceptable to 'crash' because the address of
> the argument is not known (it's in a register).
> 
> My claim is that the semantics of of an inline and non-inline
> subprogram must be identical, and further, the application writer is
> both unaware and should be unaware of the code generated at the
> point of subprogram use.
> 
> Any idea which view is the correct one?

I can see that those aspects of execution that aren't defined by the
language, or which are erroneous, could be affected by inlining. At
the very least the sequence of instructions is going to be different.

GNAT has occasionally told me that something couldn't be inlined
because of some feature of my code, and I would expect at the least
that this would happen here. (I suspect your code is much cut down, a
simple test here shows no problem -- 3.16a1).

But, the variable only got into the register because the compiler
backend put it there, you would have thought the backend would say
"can I leave this variable into a register? oh no, I see I need
'Address, better spill it to store".

I think your claim sounds 100% right. And even if I'm wrong, the
vendor's view seems less than helpful. The compiler ought to _try_ to
do the Right Thing.

-- 
Simon Wright                               100% Ada, no bugs.