Odd Generic Behaviour <<LRM Experts Whats Going ON??

Odd Generic Behaviour <<LRM Experts Whats Going ON??

[DON BERRYMAN]

I have discovered an odd behavour of ADA when I attempt to specify and use
a generic package inside a package specification (Pack1, code and audit of
compilation follow).  Not being an LRM expert this looked like a reasonable
package specification, and both the Alsys/Hp & Dec/Vax compilers accepted
it with out a single error.  So I assume that the code will work (except for
my stupid logic errors).

With Alsys/Hp the code links fine but blows up with a PROGRAM_ERROR before
executing a single line of code.  None of the TEXT_IO.PUT_LINES gets
executed.  All I get is a trace pointing into PACK1.

This was odd behaviour so I moved the code to the slug VAX and used
Dec/Vax compiler.  It compiled fine but on link complains that: 
instantiations within PACK1 need to be completed. Finally a clue.  It
appeared that compiling the body of PACK1, in particular the body of the
generic package PACK1.GEN1, invalidates at least part of the specificaton
of PACK1.  Initially this made sense to me, since I could understand how it
would be impossible to instansiate GEN1 before GEN1's body was compiled. 
This was consistent with what I was observing, and I can work around the
problem (See GEN2 & PACK2); however if this is the case why does ADA not
screem at me at compile time????  It should be quite easy for ADA to give
me at least a warning that she can't to the Instantiation until the body
was compiled.

Dec/Vax's Ada Compile System (ACS) has a nice RECOMPILE feature which I used to
recompile the necessary units.  The recompile worked fine, and the code now
linked.  However PACK1 still dies with PROGRAM_ERROR just as with Alsys/Hp.

So I worked work around the problem (PACK2).  I moved the generic out of the
package, so that there was no nesting.  Please note the order the packages
were compiled:

   1) Generic Specification
   2) Package Specification with an Instantiation 
      of the Generic compiled at step 1
   3) Generic Body
   4) Procedure 
   5) Link

Now if my earlier assumption was correct this should not work, since the
instantiation is before the body of GEN2 is compiled. To my surprise with
this worked!!!! As before Dec/Vax ADA made me do a recompile, while 
Alsys/Hp didn't need any extra work. Does any one know why this is
acceptable but the first case is unexceptable???

It has been suggested I am having an elaboration problem. Ie: at run time
PACK1 is being elaborated before GEN1 and this is detected resulting in
the PROGRAM_ERROR; and the second case works because I force GEN2 to be 
elaborated before PACK2 using the "WITH GEN2;" statement. Well I can see
why it would be desirable to elaborate PACK1 before a subpackage. But
why is it necessary (or for that matter how can a generic) be elaborated
before it is instansiated? I'd have thought PACK1 would start elaborating
create the NEWGEN1 instance of GEN1 then elaborate NEWGEN1. 

The LRM 10.5 mentions a PRAGMA ELABORATE, but I can not figure out exactly
how to use it to force GEN1 to be elaborated before PACK1. Any ideas?? 

Thanks:   Don Berryman
          Defence Research Establishment Pacific
          Canadian Forces Base Esquimalt
          Victoria, BC, CANADA, V0S-1B0
          604-363-2731    604-363-2856fax
          berryman@orca.drep.dnd.ca

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

package PACK1 is

  generic
  package GEN1 is
    procedure SUB; 
  end GEN1;

  package NEWGEN1 is new GEN1;

  procedure SUB  renames NEWGEN1.SUB;

end PACK1;

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

with text_io;
package body PACK1 is

  package body GEN1 is

    procedure SUB is
    begin
      text_io.put_line ("GEN1.SUB");
    end;

  end GEN1;

begin
  text_io.put_line ("Init");
end PACK1;

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

with PACK1, text_io;
procedure PACKER1 is
begin
  
  text_io.put_line ("Started");

  PACK1.SUB;

  text_io.put_line ("Finished");

end PACKER1;

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

generic
package GEN2 is
   procedure SUB; 
end GEN2;

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

with GEN2;
package PACK2 is

  package NEWGEN2 is new GEN2;

  procedure SUB  renames NEWGEN2.SUB;

end PACK2;

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

with text_io;
package body GEN2 is

  procedure SUB is
  begin
      text_io.put_line ("GEN2.SUB");
  end;

end GEN2;

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

with PACK2, text_io;
procedure PACKER2 is
begin
  
  text_io.put_line ("Started");

  PACK2.SUB;

  text_io.put_line ("Finished");

end PACKER2;

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

What happens with Alsys/Hp:
==========================

$ ada gen.ada  /beowulf1/berryman/adalibs/misc

$ ada -M packer1 -o packer1 /beowulf1/berryman/adalibs/misc   -lcl -lisamstub -
lc -ladahpux

$ packer1

  -- Program terminated by an exception propagated out of the main subprogram.

  -- Exception raised: PROGRAM_ERROR

  ------------- Stack trace of the propagation in the main stack --------------

  Compilation unit name      Scope name                Scope kind   Line number

  PACK1                      PACK1                     LIBRARY_PACKAGE      12
     (the above from original line      8 of inlined or instantiated unit)

  -- End of propagation: Program aborted.
Killed

$
$ ada -M packer2 -o packer2 /beowulf1/berryman/adalibs/misc   -lcl -lisamstub -
lc -ladahpux
Ada Binder: Warning: The following compilation units are not compiled but in
 | this case they are not required [RM 7.1 (5)]:
 |    PACK2 package body

$ packer2
Started
GEN2.SUB
Finished

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

What happens with Dec/Vms:
==========================

HAL$ ada /noopt /debug generic.ada

HAL$ acs link/debug packer1  
%ACS-E-CL_OBSLIBUNI, Obsolete library units are detected
%ACS-I-CL_COMPLETE, Instantiations within the following units need to be comple
ted (use ACS COMPILE or ACS RECOMPILE)
PACK1
    package specification           26-AUG-1993 08:29:52.51

HAL$ acs recompile pack1 /command
HAL$ type pack1.com 
$SET DEFAULT FLD$CENTRAL:[BERRYMAN]
$ADA:=-
ADA-
/LIBR=FLD$SYS:[BERRYMAN.MOTIF]/NOPATH
$ON ERROR THEN CONTINUE
$ADA-
 FLD$SYS:[BERRYMAN.MOTIF]PACK1_.ADC/ACS=(CC,1,0,PACK1.-IS1,S)/CHECK/DEBUG=ALL/O
PTIMIZE=(NONE,INLI=NONE,SHAR=NONE)-
/NOCOPY-

$EOD

HAL$ @pack1
HAL$ acs link/debug packer1
%ACS-I-CL_LINKING, Invoking the VMS Linker for VAX_VMS target

HAL$ run /nodebug packer1
%ADA-F-PROGRAM_ERROR, PROGRAM_ERROR
-ADA-I-EXCRAIPRI, Exception raised prior to PC = 00000667
%TRACE-E-TRACEBACK, symbolic stack dump follows
module name     routine name                     line       rel PC    abs PC

                                                           00051DAD  00051DAD
----- above condition handler called with exception 00318964:
%ADA-F-PROGRAM_ERROR, PROGRAM_ERROR
-ADA-I-EXCRAIPRI, Exception raised prior to PC = 00000667
----- end of exception message
                                                           00055A8F  00055A8F
PACK1_          NEWGEN1_                           12      00000000  00000667
                                                           000009A1  000009A1
                                                           00051B7D  00051B7D
ADA$ELAB_PACKER ADA$ELAB_PACKER1                           0000001B  0000061B
                                                           000009A1  000009A1

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

HAL$ acs link/debug packer2
%ACS-E-CL_OBSLIBUNI, Obsolete library units are detected

%ACS-I-CL_COMPLETE, Instantiations within the following units need to be comple
ted (use ACS COMPILE or ACS RECOMPILE)
:
PACK2
    package specification           26-AUG-1993 09:15:24.46

HAL$ acs recompile pack2 /command
HAL$ type pack2.com
$SET DEFAULT FLD$CENTRAL:[BERRYMAN]
$ADA:=-
ADA-
/LIBR=FLD$CENTRAL:[BERRYMAN.QUICK]/NOPATH
$ON ERROR THEN CONTINUE
$ADA-
 FLD$CENTRAL:[BERRYMAN.QUICK]PACK2_.ADC/ACS=(CC,57,0,PACK2.-IS1,S)/CHECK/DEBUG=
ALL/OPTIMIZE=(NONE,INLI=NONE,SHAR=NONE
)-
/NOCOPY-

$EOD
HAL$ @pack2
HAL$ acs link/debug packer2
%ACS-I-CL_LINKING, Invoking the VMS Linker for VAX_VMS target
HAL$ run /nodebug packer2
Started
GEN2.SUB
Finished
HAL$ 

Don Berryman
Defence Research Establishment Pacific
Canadian Forces Base Esquimalt
Victoria, BC, CANADA, V0S-1B0
604-363-2731    604-363-2856fax
berryman@orca.drep.dnd.ca

Re: Odd Generic Behaviour <<LRM Experts Whats Going ON??

[agate!howland.reston.ans.net!math.ohio-state.edu!uwm.edu!linac!convex!con]

I suspect you have found a compiler bug. I ran this through the Convex Ada
compiler (VADS-based), and everything was OK. Note the compilation order. 
After the pack1 spec is compiled, pack1.newgen becomes a pending instantiation,
waiting for a body. When the body of pack1 is compiled, code is also generated
for the instantiation.

<mozart : ada> ada -v -M packer1.a

Convex Ada Compiler, Copyright 1988, 1989, 1990
Verdix Ada Compiler, Copyright 1984-9, 1990
Version 2.1 - ConvexOS
Sun Aug  8 00:23:04 CDT 1993

ada pre processor: /devsw4/ada/COADS/bin/a.app
ada front end: /devsw4/ada/COADS/sup/fe
ada assembler: /devsw4/ada/COADS/sup/as
ada optimizer: /devsw4/ada/COADS/sup/optim
ada code generator: /devsw4/ada/COADS/sup/cg

ada common code generator: /devsw4/ada/COADS/sup/vada


File: /scratch/pelakh/ada/packer1.a
        compiled Thu Aug 26 14:26:02 1993
        by user pelakh

        floating point processor NATIVE

unit: package pack1
        NO Ada ERRORS           UNIT ENTERED
unit: package body pack1
        NO Ada ERRORS           UNIT ENTERED
unit: package body newgen1.pack1
        NO Ada ERRORS           UNIT ENTERED
unit: subprogram body packer1
        NO Ada ERRORS           UNIT ENTERED

16 statements   45 lines
optimization pass       1       pack1..NLPS
        16       IL instructions in
        14       IL instructions out
optimization pass       1       pack1..NLPB
        25       IL instructions in
        21       IL instructions out
optimization pass       1       newgen1.pack1..ILPB
        41       IL instructions in
        28       IL instructions out
optimization pass       1       packer1..NLSB
        53       IL instructions in
        42       IL instructions out

Storage used    bytes
        Text    640
        Data    84
        BSS     0

ada linker: /devsw4/ada/COADS/sup/a.ld

<mozart : ada> a.out
Init
Started
GEN1.SUB
Finished
-- 
Boris Pelakh		Ada Project Leader          pelakh@convex.com
		     Convex Computer Corporation
"If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek TNG.
			

Re: Odd Generic Behaviour <<LRM Experts Whats Going ON??

[dog.ee.lbl.gov!agate!howland.reston.ans.net!noc.near.net!nic.umass.edu!ym]

BERRYMAN@orca.drep.dnd.ca (DON BERRYMAN) writes:
   I have discovered an odd behavour of ADA when I attempt to specify and use
   a generic package inside a package specification (Pack1, code and audit of
   compilation follow).  Not being an LRM expert this looked like a reasonable
   package specification, and both the Alsys/Hp & Dec/Vax compilers accepted
   it with out a single error.  So I assume that the code will work (except for
   my stupid logic errors).

   With Alsys/Hp the code links fine but blows up with a PROGRAM_ERROR before
   executing a single line of code.  None of the TEXT_IO.PUT_LINES gets
   executed.  All I get is a trace pointing into PACK1.

Welcome the mysterious world of elaboration order...

LRM 11.1 indicates that "PROGRAM_ERROR is raised upon an attempt [...]
to elaborate a generic instatiation, if the body of the corresponding
unit has not yet been elaborated."

LRM 10.5 requires that a spec be elaborated before any entity that
with's it and that a spec be elaborated before its body.  But does not
place any requirements on the elaboration order of bodies except that
they must be elaborated before the program starts.

So.  The problem here is that you are violating LRM 11.1 since the
body of GEN1 is not elaborated at the time of instantiation.

Moreover, the body of GEN1 is nested inside PACK1 and cannot have been
elaborated yet since that would require the elaboration of the body of
PACK1 before the elaboration of GEN1 (forbidden by 10.5).

Move GEN1 outside of PACK1.  The header to PACK1 becomes:

with GEN1;
pragma ELABORATE (GEN1); -- ensure the body of GEN1 is elaborated
                         -- before use...
package PACK1 is ...

        /s
--
Alexander Erskine Wise /\/\/\/\/\/\/\/\/\/\/\/\ Software Development Laboratory
/\/\/\/\/\/\/\/\/\/\/\/\/\/\ WISE@CS.UMASS.EDU /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\ This situation calls for large amounts of unadulterated CHOCOLATE! /\/\/\

Re: Odd Generic Behaviour <<LRM Experts Whats Going ON??

[cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!spool.mu.ed]

In <1993Aug26.192757.2109@news.eng.convex.com> pelakh@convex.com writes:

> I suspect you have found a compiler bug. I ran this through the Convex Ada
> compiler (VADS-based), and everything was OK. Note the compilation order. 
> After the pack1 spec is compiled, pack1.newgen becomes a pending instantiatio
n,
> waiting for a body. When the body of pack1 is compiled, code is also generate
d
> for the instantiation.
>
> Boris Pelakh		Ada Project Leader          pelakh@convex.com
> 		     Convex Computer Corporation
> "If winning isn't important, why keep score ?"	-- Lt. Worf, Star Trek 
TNG.

I want a CONVEX compiler!! From an earlier set of articles I know that
it generates very good numeric code which is very important to me.
With CONVEX developing a massively parallel computer based on PA/RISC
is there any hope CONVEX will port its Ada compiler to PA/RISC?? And
if so will it run on my HP735??

Does any one know if GNAT will be ported to HPUX and the HP700s soon??


Don Berryman
Defence Research Establishment Pacific
Canadian Forces Base Esquimalt
Victoria, BC, CANADA, V0S-1B0
604-363-2731    604-363-2856fax
berryman@orca.drep.dnd.ca