From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,325a055bed62c230 X-Google-Attributes: gid103376,public From: rracine@myremarq.com (Roger Racine) Subject: Re: Apex vs GNAT on solaris Date: 1999/12/08 Message-ID: <384ea194.799371745@newsnew.draper.com> X-Deja-AN: 558245827 References: <82hiuj$74o$1@nnrp1.deja.com> <82hnll$ahu$1@nnrp1.deja.com> <384cfdb3.691883075@newsnew.draper.com> <82ku6s$jhi$1@nnrp1.deja.com> <384e52db.779218947@newsnew.draper.com> <1999Dec8.103922.1@eisner> X-Complaints-To: abuse@draper.com X-Trace: newsnew.draper.com 944680095 22384 140.102.40.31 (8 Dec 1999 19:08:15 GMT) NNTP-Posting-Date: 8 Dec 1999 19:08:15 GMT Newsgroups: comp.lang.ada Date: 1999-12-08T19:08:15+00:00 List-Id: 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 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