From: dontmailme AT iname DOT com (Steamer) Newsgroups: comp.os.msdos.djgpp Subject: Re: inefficiency of GCC output code & -O problem Date: Thu, 13 Apr 2000 20:56:12 GMT Organization: always disorganized Lines: 34 Message-ID: <38f6342c.52524603@news.freeserve.net> References: <38F6137B DOT 47481761 AT mtu-net DOT ru> NNTP-Posting-Host: modem-44.new-york.dialup.pol.co.uk X-Trace: news8.svr.pol.co.uk 955659394 6153 62.137.83.44 (13 Apr 2000 20:56:34 GMT) NNTP-Posting-Date: 13 Apr 2000 20:56:34 GMT X-Complaints-To: abuse AT theplanet DOT net X-Newsreader: Forte Free Agent 1.11/32.235 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Alexei A. Frounze wrote: >But I can't understand why you talk me that my code is buggy, but it compiles >w/o optimizations switches and works as I wanted to. Buggy code often compiles and runs correctly. E.g., a program may incorrectly rely on the value of an uninitialized variable being 0, and this may happen to work when the program is compiled in a particular way. But the code is still buggy (although the program it compiles to may not be). >I think, it's either compiler or assembler problem because they must not accept >faulty source code (just as point this out to me). But the source code is valid. You can't expect the compiler to determine whether or not it does what you intended it to do. >I didn't figured inline ASM myself. I learnt it from this manual. And everything >worked with it for me until the day i wanted to use the -O2 switch. You should have used -O2 from the start, because gcc produces awful code if you don't ask it to optimize. Also, if you use -O2 you'll find that a lot of inline assembler is unnecessary, because gcc actually does pretty good optimization (even if it perhaps isn't as good as Watcom) - and if you do need assembler it can often be written in a separate file and assembled with NASM, which is very easy. By contrast, inline assembler in gcc is quite complicated, and someone has already pointed out that the manual you were using has mistakes in it. The bugs in your code are in the interface between the C and the inline assembly. They may not cause a problem if you don't use -O2, but they surely will as soon as the optimizer starts trying to rearrange things, remove redundant instructions, avoid unnecessary memory access, etc. S.