GNAT and subunits

GNAT and subunits

[Philip Brashear]

I'm posting this rather than sending it to gnat-report because it's a far
more general question that should be considered by people outside the GNAT
project.

It is possible (OF COURSE!) that I'm merely being stupid, but I've got a
problem with the scenario described below.

QUESTION:
Is GNAT's processing of subunits really in accordance with language rules?
More importantly, is it in accordance with the spirit and intent of separate
compilation?

Here's my problem:  I have a program (Prog) with a subunit (procedure Sub).
When I compile Prog, GNAT requires me to provide a file containing Sub.  OK,
I can live with that -- I'll just provide a stub.  So, compiling shows me
that my interfaces are pretty much correct.  I link and execute.

Now, I complete Sub (in the file Prog-Sub.adb).  If I just submit Prog-Sub.adb 
to the compiler (as is my usual habit, and, I think, the common way of doing
things), I get the usual "No code generated ... " message.  I now link and
execute.  Guess what!  The STUB version of Sub is still used!  That is, 
re-compiling the separate subprogram (alone) does not appear to affect the
"library".

Can someone convince me that this is OK?

Can someone convince me that this is a GOOD THING?

Phil Brashear
brashepw@msrc.wpafb.af.mil
brashear@sw-eng.falls-church.va.us

Re: GNAT and subunits

[Michael Feldman]

In article <3l6j48$82t@ns1.sw-eng.falls-church.va.us>,
Philip Brashear <brashear@ns1.sw-eng.falls-church.va.us> wrote:

>Here's my problem:  I have a program (Prog) with a subunit (procedure Sub).
>When I compile Prog, GNAT requires me to provide a file containing Sub.  OK,
>I can live with that -- I'll just provide a stub.  So, compiling shows me
>that my interfaces are pretty much correct.  I link and execute.

I'm not terribly happy with that; IMHO it is not in keeping with the
whole idea of subunits, which is that one can compile the parent of
subunits without having any completion at all. It's not much different,
in my view, from being able to compile a spec without the body of a
package.

>Now, I complete Sub (in the file Prog-Sub.adb).  If I just submit Prog-Sub.adb 
>to the compiler (as is my usual habit, and, I think, the common way of doing
>things), I get the usual "No code generated ... " message.  I now link and
>execute.  Guess what!  The STUB version of Sub is still used!  That is, 
>re-compiling the separate subprogram (alone) does not appear to affect the
>"library".

GNAT wants to compile a parent and its subunits in the same compilation.
Given that this is the case (and I said above that I don;t like it), then,
in my opinion, the situation you describe is a binder bug. 

GNAT cannot have it both ways. If a subunit has been changed (and GNAT uses 
the file-modification timestamp to detect this), then GNAT should not allow 
simple re-binding, but should require the parent to be compiled. To do 
otherwise is to violate consistency rules.

Did you just re-_link_, or go back through the GNAT binder? Given that
GNAT is more "open" than many other compilers, you can end-run 
the binding process very easily. If you went through the binder, and
were not asked to re-compile the parent package body, I think this is a
serious bug.

>Can someone convince me that this is OK?

No.
>
>Can someone convince me that this is a GOOD THING?

No.

BTW - the GNAT group always asks that if you post a note like this to CLA,
you always cc: gnat-report@cs.nyu.edu, because they always read that
mail but don;t always  get around to reading the newsgroup.

:-)

Mike Feldman

Re: GNAT and subunits

[Robert I. Eachus]

In article <3l6j48$82t@ns1.sw-eng.falls-church.va.us> brashear@ns1.sw-eng.falls-church.va.us (Philip Brashear) writes:

  > I'm posting this rather than sending it to gnat-report because
  > it's a far more general question that should be considered by
  > people outside the GNAT project.

    Send it to gnat-report.

  > Is GNAT's processing of subunits really in accordance with
  > language rules?

    The model chosen for GNAT is perfectly acceptable, but it is not
one I would choose for an "industrial strength" compiler.  Fine, GNAT
is aimed at education and casual users first and foremost.

 > More importantly, is it in accordance with the spirit and intent of separate
 > compilation?

    No, but it is not intended to be.  Separate compilation is a tool
which is appropriate for some environments and some types of projects.
It is not appropriate for everything.  The GNAT team decided that in
their envirionment supporting the required syntax and semantics while
not providing the intended model, gave them some useful freedom of
design. You get improved code quality, you waste some time recompiling
code--it's a trade-off.

 > Here's my problem: I have a program (Prog) with a subunit
 > (procedure Sub).  When I compile Prog, GNAT requires me to provide
 > a file containing Sub.  OK, I can live with that -- I'll just
 > provide a stub.  So, compiling shows me that my interfaces are
 > pretty much correct.  I link and execute.

 > Now, I complete Sub (in the file Prog-Sub.adb).  If I just submit
 > Prog-Sub.adb to the compiler (as is my usual habit, and, I think,
 > the common way of doing things), I get the usual "No code generated
 > ... " message.  I now link and execute.  Guess what!  The STUB
 > version of Sub is still used!  That is, re-compiling the separate
 > subprogram (alone) does not appear to affect the "library".

   This sounds like a bug, but I, and I think the people at NYU would
need more details to be sure.

 > Can someone convince me that this is OK?

  I won't try...

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: GNAT and subunits

[Robert Dewar]

First of all, it is perfectly possible to compile a parent without 
having the subunits around if all you want to do is check its semantic
consistency. Use the -gnatc switch as you would do when compiling a
package spec on its own. No code is generated of course. Similarly you
can compile subunits on their own with the -gnatc to check their semantic
consistency.

Actual code generation requires the entire subunit tree to be present. We do
this because in its current configuration, GCC does not support separate
compilation of nested procedures (which is essentially what a subunit is).
It is not particularly intended as a GOOD THING, just as a pragmatic
priority ordering. Some day we may try to implement separate compilation
of nested procedures in GCC, but right now it is certainly NOT on the to-do
list. 

I guess the one GOOD THING is that we can of course generate much more efficient
code for subunits, since we know what is in a subunit (in a conventional
model of subunit compilation, you have to make worst case assumptions about
what might be in the subunit, which gets worse in Ada 95 (for isntance you
have to assume that finalizable entities MIGHT be present). Also if you are
compiling  the parent anyway (which would normally require recompilation of
the subunits anyway), then this approach is faster. It is of course slower
if you just change one subunit.

Anyway, the point is that the only compilation that generates code is the
compilation of the parent unit, and of course in this case, all the subunits
must be present.

Now as to the second effect Phil noticed, this is really pilot error. Here
is the scoop. When you compile in -gnatc mode (or you goof and try to compile
something which can't generate code and get the error message "no code
generated") then you have not affected the object files in any way AT ALL.

Now there are three options in the binder. Phil was apparently using the
first, which is the default, and is what is used by gnatbl if you let
gnatbl do the bind. I suspect that Phil wants to use the second or third.

Option 1 (default). Use object files only (and ALI files). The binder 
in this mode COMPLETELY IGNORES source files. So of course when Phil
updated his subunit, and did a compilation to check its correctness which
had no effect on the object files, then the binder did not notice and used
the old objects without complaint. In this mode the binder merely checks
that the objects it sees are self consistent version-wide, but it does not
check that they are compatible with the source versions.

Option 2 (-a) All source file mode. In this mode, the binder requires that
(a) all sourrce files are present for all object files in the bind.
(b) the source file versions are consistent with the versions referenced
	in the object files.

Option 3 (-s) Sources if available. In this mode, the binder will find sources
for whatever source files it can locate, and for this subset of sources, it
will ensure consistency with the object files.

Note: to use gnatbl with these switches, do the gnatbind step separately, 
and then run gnatbl with the -linkonly switch.

Phil, if you want the binder to reject the program in the situation you
describe, where you have updated one of the subunit files, then you should
use option 2 or option 3. Clearly from your description of the behavior,
you used option 1.

I don't particularly feel the need to convince anyone that this is a legal
implementation, of course it is! Phil if you have some reason to think it
is not, I think it is your devious ACVC trained mind showing, and by all
means quote chapter and vese :-) :-)

In practice, when gnatmake is available, these kind of issues largely
disappear, because gnatmake will ensure that all necessary sources are
compiled automatically.

Is this GNAT treatment of subunits a GOOD THING, not particularly, and it
will particularly creak with giant subunit trees. On the other hand, with
Ada 95, I think subunits will be used less, since private child units can
be used for the same purposes in many situations and are preferable. Time
will tell whether it is worth doing the (considerable) amount of work to
add the necessary features to GCC to support "true" separate compilation
of subunits.

P.S. Phil, in trying to prove this is an invalid approach from the RM, 
remember that it is perfectly valid to COMPLETELY defer all code genration
to the bind step!

P.P.S. In discussing these issues earlier today, we contemplated two
features that might reduce the surrprise factor for people who don't
read the documentation carefully:

   1. If a parent unit is compiled with subunits missing, then revert
	automatically to -gnatc mode, complaining that "no code is
	generated because subunits are missing" or somesuch.

   2. Change the default of the binder to -s mode, we have been considering
	this for a while.

I would particularly be interested in people's reactions to suggestion 2.

P.P.P.S. Another note to Phil: remember also that it is perfectly fine to
automatically recompile things that need recompiling if the system detects
that such recompilations are required!

Re: GNAT and subunits

[Philip Brashear]

In article <3l79nr$nnt@felix.seas.gwu.edu>,
Michael Feldman <mfeldman@seas.gwu.edu> wrote:
>
...
>
>Did you just re-_link_, or go back through the GNAT binder? Given that
>GNAT is more "open" than many other compilers, you can end-run 
>the binding process very easily. If you went through the binder, and
>were not asked to re-compile the parent package body, I think this is a
>serious bug.                            ^^^^^^^^^^^^
>
...

I used the "gnatbl" command to invoke the GNAT binder.  BTW, I had a
(main) PROCEDURE (not a package) with a subunit that was also a procedure.
I don't think this would make any difference.

Phil

Re: GNAT and subunits

[Tucker Taft]

Philip Brashear (brashear@ns1.sw-eng.falls-church.va.us) wrote:

: ...
: Is GNAT's processing of subunits really in accordance with language rules?
: More importantly, is it in accordance with the spirit and intent of separate
: compilation?

: Here's my problem:  I have a program (Prog) with a subunit (procedure Sub).
: When I compile Prog, GNAT requires me to provide a file containing Sub.  OK,
: I can live with that -- I'll just provide a stub.  So, compiling shows me
: that my interfaces are pretty much correct.  I link and execute.

: Now, I complete Sub (in the file Prog-Sub.adb).  If I just submit Prog-Sub.adb 
: to the compiler (as is my usual habit, and, I think, the common way of doing
: things), I get the usual "No code generated ... " message.  I now link and
: execute.  Guess what!  The STUB version of Sub is still used!  That is, 
: re-compiling the separate subprogram (alone) does not appear to affect the
: "library".

This sounds like a bug.  Unfortunately, it is a bit hard to know
because it may depend on what you mean by "submit" a file to GNAT.

: Can someone convince me that this is OK?

No, it sounds like a bug, unless your notion of what it means to "submit"
a file to GNAT disagrees with their notion.  The key principle in GNAT
is that the sources are what matters.  If you update a source file,
then at link-time, it should provide a mode where it complains
if the sources and the object modules are inconsistent.

: Can someone convince me that this is a GOOD THING?

I would put your energy into getting the GNAT folks to fix the bug.
I presume you have already tried gnat-report@cs.nyu.edu ...

: Phil Brashear
: brashepw@msrc.wpafb.af.mil
: brashear@sw-eng.falls-church.va.us

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: GNAT and subunits

[Tucker Taft]

Robert Dewar (dewar@cs.nyu.edu) wrote:
: ...
: Now there are three options in the binder. Phil was apparently using the
: first, which is the default, and is what is used by gnatbl if you let
: gnatbl do the bind. I suspect that Phil wants to use the second or third.

: Option 1 (default). Use object files only (and ALI files). The binder 
: in this mode COMPLETELY IGNORES source files. So of course when Phil
: updated his subunit, and did a compilation to check its correctness which
: had no effect on the object files, then the binder did not notice and used
: the old objects without complaint. In this mode the binder merely checks
: that the objects it sees are self consistent version-wide, but it does not
: check that they are compatible with the source versions.

: Option 2 (-a) All source file mode. In this mode, the binder requires that
: (a) all sourrce files are present for all object files in the bind.
: (b) the source file versions are consistent with the versions referenced
: 	in the object files.

: Option 3 (-s) Sources if available. In this mode, the binder will find sources
: for whatever source files it can locate, and for this subset of sources, it
: will ensure consistency with the object files.

..

: P.P.S. In discussing these issues earlier today, we contemplated two
: features that might reduce the surrprise factor for people who don't
: read the documentation carefully:

:    1. If a parent unit is compiled with subunits missing, then revert
: 	automatically to -gnatc mode, complaining that "no code is
: 	generated because subunits are missing" or somesuch.

Sounds like a good idea.  You probably want to make it a warning instead
of an error, or else it will scare people.

:    2. Change the default of the binder to -s mode, we have been considering
: 	this for a while.

: I would particularly be interested in people's reactions to suggestion 2.

I think you should make the binder default "-s" to minimize the likelihood
of "pilot" error.  This also seems most compatible with the "conventional"
Ada library model.

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.

Re: GNAT and subunits

[Michael Feldman]

In article <D69I6D.nF@inmet.camb.inmet.com>,
Tucker Taft <stt@spock.camb.inmet.com> wrote:
>Robert Dewar (dewar@cs.nyu.edu) wrote:

>:    1. If a parent unit is compiled with subunits missing, then revert
>: 	automatically to -gnatc mode, complaining that "no code is
>: 	generated because subunits are missing" or somesuch.

>Sounds like a good idea.  You probably want to make it a warning instead
>of an error, or else it will scare people.

I agree with Tucker. I think this is a good idea.

>:    2. Change the default of the binder to -s mode, we have been considering
>: 	this for a while.
>
>: I would particularly be interested in people's reactions to suggestion 2.

I think the difficulties some folks have had is that, while the -gnat
options to gcc, and those of gnatbl, are quite well documented in the 
"user guide" known as gnatinfo.txt, the options of gnatbind do not
appear ajywhere in that document. This is, I'm sure, an oversight and
can easily be rectified. In the meantime, Robert pointed out to me
that typing "gnatbind" by itself will produce a list of the options.

>I think you should make the binder default "-s" to minimize the likelihood
>of "pilot" error.  This also seems most compatible with the "conventional"
>Ada library model.
>
>-Tucker Taft   stt@inmet.com
>Intermetrics, Inc.

Again I think Robert and Tucker have put their finger on it. When it comes
to new or casual users, and especially users who are not new to Ada but are
new to GNAT, IMHO GNAT's various _default_ options should be as safe as
possible and as intuitive as possible, even if (as in the case of -s)
there is some performance penalty.

As is the case with all software, really experienced GNAT users, and
those with multi-language compilations, etc., will figure out the
optimal combination of options and encapsulate them in makefiles,
scripts, etc. For GNAT newbies writing "conventional" Ada code, there
should be as few surprises as possible in using simple commands with
default options.

It's clear to me that the GNAT team is sensitive to these matters and
working on the right solutions.

Mike Feldman

Re: GNAT and subunits

[Robert Dewar]

Note that in the latest version of GNAT, version 2.04, we have indeed
changed the binder to default to -s mode, in which it will check for
consistency between the object files and current source files. This
would mean that Phil would have got the behavior he expected. The
no-sources mode is still available by option.