CVS difference for ais/ai-00245.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00245.txt

--- ais/ai-00245.txt	2000/11/01 01:05:06	1.1
+++ ais/ai-00245.txt	2000/11/04 01:10:29	1.2
@@ -356,4 +356,225 @@
 
 ****************************************************************
 
+From: Dan Eilers
+Sent: Wednesday, November 01, 2000 8:58 PM
+
+Randy wrote:
+> Certainly, *I* think that implicit inlines should be exactly that, and if
+> that means that you have to do link-time compilation, so be it. (If you
+> don't like that, don't implement implicit inlining!!!)
+
+Our implementation implements implicit inlines "as if" there was
+an explicit inline in the source code, taking advantage of the
+permission to remove units with out-of-date inlined code from the
+library.
+
+Are you saying our implementation violates the standard?
+
+> So, whether or not 10.1.4(7.d) is tested, it is still true. And it has no
+> bearing on whether 10.1.4(10.a) should be tested, given that there is a
+> Defect Report (8652/0108) confirming  10.1.4(10-10.a). Indeed, there is
+> already a test requiring this behavior. (I converted the test to a 'C' test
+> after an implementor complained that the test was misclassified as an 'L'
+> test.)
+
+I am familiar with Defect Report 8652/0108, and quite sure that it
+does not confirm or even mention AARM 10.1.4(10-10.a).  8652/0108 is a
+compile-time issue, (requiring the compiler not to reject a unit that
+depends on an incomplete generic unit).  10.1.4(10-10.a) is non-normative
+link-time advise regarding the commands for invoking the linker.
+Your C test for AARM 10.1.4(10-10.a) is invalid as a test for 8652/0108.
+A proper test for 8652/0108 would be a B test checking that no error
+was generated.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Wednesday, November 01, 2000 8:33 PM
+
+Randy wrote:
+> As I understand the index, it indexes only places where things are
+> *defined*, not where they are *used*.
+
+This is a misunderstanding.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, November 01, 2000 10:05 PM
+
+<<Our implementation implements implicit inlines "as if" there was
+an explicit inline in the source code, taking advantage of the
+permission to remove units with out-of-date inlined code from the
+library.
+
+Are you saying our implementation violates the standard?>>
+
+Yes, I consider this non-compliant
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Thursday, November 02, 2000 2:52 AM
+
+Robert wrote:
+> <<Our implementation implements implicit inlines "as if" there was
+> an explicit inline in the source code, taking advantage of the
+> permission to remove units with out-of-date inlined code from the
+> library.
+>
+> Are you saying our implementation violates the standard?>>
+>
+> Yes, I consider this non-compliant
+
+If true, surely this is an unintentional difference from Ada83
+that should be fixed.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, November 02, 2000 6:59 AM
+
+<<If true, surely this is an unintentional difference from Ada83
+that should be fixed.>>
+
+No, I think this would be a non-compliance in Ada 83 as well.
+
+If you allow arbitrary obsoleting of this kind, then an implementation
+can do all kinds of horrible things, and indeed you can easily create
+a situation where it is impossible to build some programs.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 02, 2000 2:07 PM
+
+> <<If true, surely this is an unintentional difference from Ada83
+> that should be fixed.>>
+>
+> No, I think this would be a non-compliance in Ada 83 as well.
+>
+> If you allow arbitrary obsoleting of this kind, then an implementation
+> can do all kinds of horrible things, and indeed you can easily create
+> a situation where it is impossible to build some programs.
+
+Right. But keep in mind this only applies to the standard (ACATS compliant)
+mode. Certainly an implementation can have a mode that does something else
+useful for their customers (as per 1.1.5(11)).
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, November 02, 2000 8:04 PM
+
+A compiler can do anything it likes in non-standard mode, including for
+example compiling C++ instead of Ada :-)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Thursday, November 02, 2000 10:12 AM
+To: ADA-COMMENT@ACM.ORG; ada-comment@ada-auth.org
+Subject: Re: [Ada-Comment] consistency of inlined calls
+
+<<If you allow arbitrary obsoleting of this kind, then an implementation
+can do all kinds of horrible things, and indeed you can easily create
+a situation where it is impossible to build some programs.
+>>
+
+Note that this is only a problem if it is visible, or more accurately if
+there is no way to make it transparent.
+
+For example, with GNAT, our "official" 100% RM-compliant compilation model
+looks like this:
+
+1. Compilation is done by first using gnatchop (to deal with compilations
+and also with compiling configuration pragmas on their own), followed
+by compilations using gcc -c -gnatC, which diagnoses all illegalities
+and inserts the unit into the compilation environment (i.e. the ALI file).
+
+2. Binding is done using gnatmake, which also happens to perform some
+code generation activity :-) Of course the RM has nothing to say about
+whether "code generation" (whatever that is, the term is not comprehensible
+in formal RM terms) takes place at "compile" time or "link" time.
+
+As long as implicit inlining and its necessary recompilations are hidden
+under the covers in a similar manner, then of course there is no issue
+of non-conformance with the compilation model in the RM.
+
+****************************************************************
+
+From: Erhard Ploedereder
+Sent: Thursday, November 02, 2000 9:11 AM
+
+This issue (of dependents of generic units or of inline-caused dependencies)
+has been gone over for Ada87, by the 95 DRs and many others.
+
+In the end, the only consensus that was able to be achieved is one that
+no program shall reach execution with an inconsistent set of compilation
+units as the basis for the executed code.  This is the AXIOM, basically
+stated in Note 10.1.4(8), to which the rules of the language are geared.
+
+And yes, implicit recompilation for implicit inlines and implicit
+recompilation of dependents of a generic, whose body has changed, are
+the most user-friendly behavior. The words in the manual indicate that
+intent.
+
+But, because of the many implementation-defined aspects of the
+compilation process, there are enough loopholes that other
+compile-time behavior can be equally argued to be "conforming", as long
+as the AXIOM is preserved.
+
+Explicitly mentioning all the possible compiler behaviors in 10.1.4(7)
+would really be counterproductive. In that sense DR108 is right in saying
+"10.1.4(7) is intended to be complete". The next sentence in DR108
+acknowledges the leeway that implementations have anyway. In a way,
+10.1.4(7) cannot be complete, ever, with so much implementation-dependence
+involved.
+
+What made this liberal implementation-definedness acceptable to the vast
+majority (including the then ACVC95-writers) is the fact that these issues
+have no way of endangering portability of Ada software, which is the main
+objective of having a rigorous language standard and conformance
+enforcement.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Thursday, November 02, 2000 6:54 PM
+
+Randy wrote:
+> > <<If true, surely this is an unintentional difference from Ada83
+> > that should be fixed.>>
+> >
+> > No, I think this would be a non-compliance in Ada 83 as well.
+> >
+> > If you allow arbitrary obsoleting of this kind, then an implementation
+> > can do all kinds of horrible things, and indeed you can easily create
+> > a situation where it is impossible to build some programs.
+>
+> Right. But keep in mind this only applies to the standard (ACATS compliant)
+> mode. Certainly an implementation can have a mode that does something else
+> useful for their customers (as per 1.1.5(11)).
+
+We do "as if" inlining in our standard mode.
+As Erhard notes, it is user friendly to have a way to do
+automatic recompilations.  We of course have an "ada make"
+tool that will do such automatic recompilations, but we
+don't invoke this tool during validations, either as
+part of the compiler or as part of the linker.  Nor do
+we believe it is reasonable or necessary to do so.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, November 02, 2000 8:17 PM
+
+Do you pass all of the ACATS tests that way? If so, no problem (even if it
+might be technically non-conforming). Otherwise, it is "necessary"
+("reasonable" is just an opinion). (Of course, you could raise a dispute
+against particular tests -- I'll be happy to run those through the dispute
+process.)
+
+****************************************************************
 

Questions? Ask the ACAA Technical Agent