Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!eru!luth!sunic!mcsun!cernvax!antoniop
From: antoniop@cernvax.UUCP (antonio pastore)
Newsgroups: comp.os.msdos.programmer
Subject: Re: TC++ bug
Message-ID: <2111@cernvax.UUCP>
Date: 23 Jul 90 11:15:31 GMT
References: <2557@mindlink.UUCP>
Organization: CERN, European Laboratory for Particle Physics
Lines: 57

In article <2557@mindlink.UUCP> a563@mindlink.UUCP (Dave Kirsch) writes:
>> aviv@discus.technion.ac.il writes:
>>    The only conclusion for us was : DON'T USE JUMP OPTIMIZATION !
>>    (or may be any other optimization ??)
>>    It can INSERT BUGS into your code.
>> 
>>    Until now, we did not find other bugs.
>> 
>>    And you ???
>
>If you look in the manual (and this appears on both TC and MSC manuals), there
>are warnings that optimizations will cause some code to break.  Specificly, in
>the TC 2.0 manual, there is a whole section on warning about use register
>optimization (not register variables).  This problem would seem to be related
>to register optimization, not jump optimization.  Does -O indicate to TC++ that
>it should do register optimization as well?
>
>Any optimizations will cause code to "break".  I assume somehow you didn't have
>register optimization on in TC 2.0 (you probably just had jump optimization).
>I suppose that if you took this same code to TC 2.0 and turned ON register
>optimization (O/C/O/R in the IDE or -Z on the command line) this code would
>probably not function; as you have indicated.
>
>It's not a bug, it's due to optimization, which any compiler warns you about
>when you read about enabling optimizations.

Sorry, but I don't agree with you. Although there are cases in which
a poorly written code can lead to an incorrect optimization (mainly in
code that has ALIASING), the optimization in a compiler is supposed to
improve code quality (object size or execution speed or both) not to
break working code. There are some programs that cannot be tested
estensively (i.e. doing number crunching, with a number as output: one
cannot certainly try them for all the possible input values) but
nevertless written in a plain, not tricky constructs of the language. If
the optimizer breaks this code (just because the manual warns about
"problems" in optimization) I think that the optimizer is generally useless.

I want to use (supposed bug free) programs which work, not that might work
if the optimizer is not too bad.
This does not mean that the compiler cannot be bugged (almost all programs
have bugs or problems), but I don't agree to assume that optimization leads
or can leads to bugged code. A good optimizer is like a good compiler: it
produce good output (=not bugged) code when compiling well written
input code (=no tricks, no aliasing, ...).

It is clear that if in TC one tries to use built-in register variables
(= _Ax, _BX, ..) and on the same time optimize register usage (= -z
option) there are very good chances that the output code is bugged. But,
again, this is tricky code, and, in addition, outside of the standard of
the language. Same applies while interfacing C to assembler, if the latter
does not follow the TC convention about register saving, etc.

In conclusion, optimization in a compiler, if provided, must produce as good
code as the main part of the compiler, otherwise it is useless.

antonio pastore
antoniop@cernvax.cern.ch