Re: Apex vs GNAT on solaris

[rracine@myremarq.com (Roger Racine)]

On Wed, 8 Dec 1999 15:39:22 GMT, kilgallen@eisner.decus.org (Larry
Kilgallen) wrote:

>In article <384e52db.779218947@newsnew.draper.com>, rracine@myremarq.com (Roger Racine) writes:
>> On Wed, 08 Dec 1999 06:35:08 GMT, Robert Dewar <dewar@gnat.com> wrote:
>> 
>>>In article <384cfdb3.691883075@newsnew.draper.com>,
>>>  rracine@myremarq.com (Roger Racine) wrote:
>>>> Many people will assume that the default options are the most
>>>> reliable options.
>>>
>>>They will assume wrong. For example, in the case of GNAT,
>>>we let -O0 be the default because that is traditional in
>>>all gcc compilers. We make inlining off the default, because
>>>that seems more compatible with -O0 as the default.
>>>
>> 
>> That is a pretty questionable reason for creating a default.  Perhaps
>> compiler documentation should state reasons for using the various
>> options.  Of course, a given vendor might not want to say "turn
>> optimization on only as a last resort, since it is not well tested",
>> but certainly ACT (from what you say) should tell their users to turn
>> it on.
>
>Certainly compiler documentation should state the purpose of various
>options.  I don't understand how, absent such a statement, one would
>know that such an option exists.  Are there vendors whose documentation
>says "we have an option called /FOOBAR, but we won't tell you what it
>does" ?
>

For example, the GNAT documentation simply states that you get no
optimization with -O0, "normal optimization" with -O1, "extensive
optimization" with -O2, and automatic inlining with -O3.  It does not
say anything about the speed of compilation difference, any debugger
deficiency with the various options, or any other reason one might
want to use one vs the other.  Is everyone supposed to have to check
the compile time for each option?

>>>They will assume wrong, there is no "best options", there is
>>>only the appropriate options for your particular use.
>>>
>> 
>> I do not know about your experience, but for me, with embedded system
>> compilers (which tend to have comparatively few users compared to
>> workstation compilers), for numerous languages over the years, it has
>> always been dangerous to change the default optimization options.  ACT
>> might want to reconsider their default.
>
>I would believe Ada programmers to be a more discriminating bunch,
>expecting features to have been tested, making incidents where an
>adjustment to optimization options introduces "danger" to be less
>frequent.  Furthermore, I would believe Ada programmers to expect
>the vendor would fix anomolies encountered in this fashion.  Most
>of all, I expect Ada programmers to test their resulting programs.
>ACT might change their default, but misbehavior by other compilers
>would be a silly reason to do so.
>

It is difficult to be discriminating when -all- compilers have bugs.
It is the natural result of compilers being big, complex software
systems.  No vendor will give you any sort of guarantee that their
code generator is perfect for all legal Ada programs.  And Ada is no
better or worse than any other language in this respect.

Of course the vendor is going to fix the bug (in the next release for
some vendors; in a patched version for others), but the problem comes
in the determination that there is a bug.  Remembering back to an Ada
83 program back in the early 1990s, some strange behavior took 2
people at least 2 full days to find the problem (at least 1 of those
days lasting until 2:00 in the morning).  This is not ancient history.
Now my first experience with a compiler bug might be considered by
some to be ancient (mid 1970s; in a programming course at college; the
computer consultants did not believe me at first, thinking I simply
wanted them to help me find a bug in my code), and my next (late
1970s), but it has been continuous throughout the 1980s and 1990s that
my colleagues and I have found bugs.  Most of these were found using
options that were other than the defaults.

Of course the resulting programs will be tested.  But I can only
assume you have never tracked down a compiler bug if you say that as a
reason not to worry about such problems.

ACT can do what they like, but they had better understand that there
are a lot of people with similar experiences to mine, at least in the
embedded world.  My general assumption (and I checked with a couple
colleagues today and got agreement) is that if the vendor has the
default optimization set to a given value, any lower value is OK, but
any higher value is dangerous and should be used with great care.  GCC
is a special case where the compiler build script can be examined.  If
the compiler itself is built with an optimization higher than the
default, I trust that value.

One more piece of history.  For the Space Shuttle, the primary
computer system and the backup system both use the HAL/S language.
However, the backup compiler is different from the primary compiler.
One of the differences was that the optimizer put in the primary
compiler was not allowed to be put in the backup version.  The
optimizer was considered an unnecessary risk factor.  Bugs were indeed
found in the primary compiler optimizer, but only, to my pre-1982
knowledge, in testing.

Roger Racine