a563@mindlink.UUCP (Dave Kirsch) (07/21/90)
> 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. -- -- David Kirsch UUCP: {uunet,ubc-cs}!van-bc!rsoft!mindlink!a563 Voice: (604) 327-4404 a563@mindlink.UUCP Vancouver, British Columbia 'In-no-sense? Nonsense!' - The Art Of Noise
antoniop@cernvax.UUCP (antonio pastore) (07/23/90)
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
jdb@reef.cis.ufl.edu (Brian K. W. Hook) (01/04/91)
I was writing a simple demo program today using TC++. nothing fancy, nothing special....worked just fine when I compiled within TC. To get smaller code (read: No debug) I tend to exit then run TCC. Thus, this program, which uses graphics: TCC demo works within the environment. But I ran TCC and then tlink, tried a couple of switches (to see if it would open the graphics.lib) and guess what? It trashed GRAPHICS.LIB and about half o f my libraries, probably because of an incorrect switch (tlink has CRAPPY documentation). I did link in a .BGI and .CHR file into the .LIB after running BGIOBJ. This, to me, is not very good. Graphics.lib ended up being 2048 bytes. Oh, after adding the .BGI and .CHR file, it still worked fine. It was when I compiled and linked from the command line that my LIB directory got eaten ALIVE. anyone have any ideas? Brian
nelson@sun.soe.clarkson.edu (Russ Nelson) (01/05/91)
See Marshall Cline's monthly TC++ bug list in comp.lang.c++. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) FAX 315-268-7600 It's better to get mugged than to live a life of fear -- Freeman Dyson I joined the League for Programming Freedom, and I hope you'll join too.