Re: Crosspost: Help wanted from comp.compilers

["John R. Strohm" <strohm@airmail.net>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:2OERa.4718$0F4.3216@nwrdny02.gnilink.net...
> Preben Randhol wrote:
> > Actually you are not listening. He just showed you why it needed to be
> > recompiled.
>
> How did he do that? He was talking about needing to recompile
> after making a change.

Where we seem to disagree is that you seem to be believe that only changes
to source code can produce changes to semantics, and that those changes
should only propagate through one level of inheritance ('with').  You have
explicitly stated, repeatedly, that recompiling a unit whose source code has
not changed, with ONLY a change in compiler options, should NOT trigger
recompilation of dependent units.

Consider a contrived example.  First, postulate a compiler option, that
suppresses generation of type'image information for enumerated types.  This
is a fairly obvious space optimization, that does no harm at all if the rest
of the code does not use type'image.  Consider a package spec that declares
an enumerated type, that is used by a module that uses that type'image, say,
to display symbology labels.

Compile the spec with type'image generated.  Compile the using module.
Recompile the spec with type'image suppressed.  Link.

Oops.

If you are REALLY lucky, the error will be detected at link time, because
type'image data is hooked up through a special external symbol, and the
symbol isn't there, because type'image was suppressed.  If you are lucky,
you will spot it when you take the build into the lab and wonder why the
frap your symbology labels are missing.  If your luck is run-of-the-mill,
what you will be doing is wondering why the $#&^$#^ your build crashes and
burns before it even brings up the symbology.

Observe that forcing recompilation of the using module will bring the error
to light.  In this strawman scenario, it will also force you to recompile
the spec, then recompile the using module.

Alternatively, consider a compiler that has an option that will force it to
generate some extra debugging entry points if a certain compiler switch is
set.  Consider a runtime design that uses a transfer table.  Recompiling the
spec after changing the switch setting may reorder the transfer table, and
dependent modules that were compiled prior to the changing of the switch may
not know about the change.  Result: when you try to call the routine that
emergency jettison's all external stores, you instead call the routine that
fires the ejection seat squib.  This kind of error is guaranteed to make you
unpopular with the test pilot community.  (Incidentally, this is not far
from the example that Jean Ichbiah himself gave when asked why Ada required
recompilation of all dependents if a spec that had not changed was
recompiled.)