Re: Semantics of Inline vs non-Inline

From: Arthur Schwarz (aschwarz_at_acm.org)
Date: 10/15/04 

Date: Thu, 14 Oct 2004 17:49:40 -0700

Martin Krischik wrote:

> skidmarks wrote:

>
> 1st: only aliased data is guaranteed to have an 'Address. Even non inline
> functions may use a register for certain data.

   The question still remains concerning the semantics of inline vs
   non-inline. You are saying that the interpretation of inline
   depends on the compiler generated code, not focusing on the
   remapped address at the moment. If this is true, then it would
   seem that the application should not be able to use inline at
   all since the application (writer) can not control the compiler
   generated code and the generated code effects the execution, not
   the semantics implicit in the subprogram.

   Going back to the 'Address issue, it is my (unsubstantiated) belief
   that if the semantics are to be the same for inline and non-inline
   code, then it should be the compilers responsibility to ensure
   that argument passage is guaranteed to be correct. Otherwise any
   argument passed to a subprogram becomes suspect as being able to
   generate a fault at runtime.

   Looking at this issue as a an optimization concern then (to me) it
   appears that generating the same code required for a CALL for an
   inline, but without the CALL and RETURN instructions, would allow
   the semantics to be inviolate and the optimizer to optimize away
   the unnecessary generated code. This is presented as an oversimplified
   model, admitedly. What seems to be done in this case is to do
   'pre-optimization' by not pretending that we are interfacing with
   a subprogram, but by just doing the Ada equivalent of macro text
   substitution, and then not detecting potential runtime errors.

   My objection is that the non-inlined code, with all it's conceptual
   and design flaws, works as expected. The inline code fails at run-
   time without a diagnostic message at compile time. My expectation
   was that the results of inline execution and non-inline execution
   should have been the same.

   And so I am confused. The question is still whether Ada requires
   that the result of execution of the inline and non-inline code to
   be the same, and if not the same, what variances are permitted.
   Another respondent on this newsgroupt said that the the compiler
   can substitute one type of 'number' for another, but he did not
   say whether the result of this substitution would yield the same
   result (or the Ada rationale that allows this substitution to
   occur).

   Any ideas or am I way off-base?

   Thanks for your reply. All typing errors (here) are do to haste
   and not necessarily grammatical deficiency. I am stealing time
   to answer (quickly) and have not edited this document. Sigh.
   Ever the slave to time, never it's master.

thanks

art

>
> With Regards
>
> Martin
>

Relevant Pages

  • Re: [PATCH 1/6] UML - Fix inlines
    ... What are these different semantics? ... function should be compiled inline where the inline definition is seen, ... and that the compiler should also emit a copy of the function body with ... Except for the Alpha port all users in the kernel used "extern inline" ...
    (Linux-Kernel)
  • Re: "inline"?
    ... An inline function is slightly different from a non-inline function, ... it still has a slight effect on the semantics. ... the change in semantics due to using 'inline' is so slight ...
    (comp.lang.cpp)
  • Re: INLINE
    ... INLINE has no semantic content whatsoever. ... nothing to enforce those semantics in terms of "here's code that will ... simply over-ridden in the next parsing action, PARSE-AREA@ can work ... you can't break code that includes it by ...
    (comp.lang.forth)
  • Semantics of Inline vs non-Inline
    ... My compiler vendor says that the semantics of an inline/non-inline ... function can be different at the discretion of the compiler vendor. ... My claim is that the semantics of of an inline and non-inline ... begin -- Push ...
    (comp.lang.ada)
  • Re: [2.6 patch] include/asm-mips/processor.h: "extern inline" -> "static inline"
    ... > "extern inline" will have different semantics with gcc 4.3, ... > and "static inline" is correct here. ... The idea was to have a linker error in case gcc should deciede for some ...
    (Linux-Kernel)