Elaboration

Elaboration

[Ken Garlington]

I suspect that the following nasty behavior of our Ada83 compiler is legal, but
just in case, I wanted to ask an Ada-literate crowd:

Several applications using our compiler have ended up writing code like the
following (apologies in advance for any stupid typos, etc.) Note that the
package specs, bodies, and subunits are all compiled separately:

-------------------

package UNO is

  function IS_REALLY_SIMPLE return BOOLEAN;
  pragma INLINE(IS_REALLY_SIMPLE);

  procedure DO_SOMETHING;

end UNO;

package body UNO is

  function IS_REALLY_SIMPLE return BOOLEAN is
  begin
     -- simple one-line return statement
  end IS_REALLY_SIMPLE;

  procedure DO_SOMETHING is separate;

end UNO;



package DOS is

  function IS_REALLY_SIMPLE return BOOLEAN;
  pragma INLINE(IS_REALLY_SIMPLE);

  procedure DO_SOMETHING;

end DOS;

package body DOS is

  function IS_REALLY_SIMPLE return BOOLEAN is
  begin
     -- simple one-line return statement
  end IS_REALLY_SIMPLE;

  procedure DO_SOMETHING is separate;

end DOS;



with DOS;

separate (UNO)

procedure DO_SOMETHING is
begin

  if DOS.IS_REALLY_SIMPLE then
    -- etc.
  end if;

end DO_SOMETHING;



with UNO;

separate (DOS)

procedure DO_SOMETHING is
begin

  if UNO.IS_REALLY_SIMPLE then
    -- etc.
  end if;

end DO_SOMETHING;

-------------------

When we link all this together, the linker fails with a message that UNO and
DOS have a circular dependency in the elaboration. If we remove one of the
pragma INLINEs, this allows one of the bodies to not be compiled prior to use
of the corresponding function IS_REALLY_SIMPLE, so all is well. However, this
still seems silly to me, and other compilers can compile and link this
application without problem. We tried to think of a way to use pragma ELABORATE
to fix this, but couldn't.

What does everyone think? Should we expect the linker to have a problem with
this? Is there a simple fix to the source, other than removing an INLINE?

Re: Elaboration

[Robert Dewar]

It is an unfortunate fact that in many implementations of Ada, pragma
Inline does indeed create dependencies of this nature, and can lead to
circular dependencies. Of course compilers are not *required* to introduce
these dependencies.

Using the source library approach of GNAT, you can never get circular
dependencies from pragma Inline, since the only dependencies are from
objects to sources, there are no inter-unit dependencies, or order of
compilation requirements for pragma Inline to work.

I believe that the Telesoft compiler (as opposed to the Alsys compiler) could
also achieve this kind of freedom using the back end optimizer feature that
allowed a number of units to be optimized to gether (of course this approach
gets a bit marginal for really large programs, but it has advantages beyond
simply handling inline "correctly")

SUbunits in particular introduce situations in which inline simply doesn't
work "right" in some Ada implementations. For example, if the body of
a subunit provides the body for an inlined function, the parent will not
be able to inline the function, since it must be compiled before its
subunits.

Re: Elaboration

[Tucker Taft]

The presence or absence of pragma Inline should have no
effect on the order of elaboration, and certainly shouldn't
make a legal program illegal due to claimed elaboration 
circularities.  Sounds like a bug... (not that I don't
sympathize with the implementor in this case, but I sympathize
more with the user ;-).

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.
Cambridge, MA  02138