From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: inefficiency of GCC output code & -O problem Date: 14 Apr 2000 13:28:20 GMT Organization: Aachen University of Technology (RWTH) Lines: 57 Message-ID: <8d76dk$dg5$1@nets3.rz.RWTH-Aachen.DE> References: <38F6137B DOT 47481761 AT mtu-net DOT ru> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 955718900 13829 137.226.32.75 (14 Apr 2000 13:28:20 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 14 Apr 2000 13:28:20 GMT Originator: broeker@ 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. For explanation what makes it buggy, see the other posts (including the othe one I wrote a few minutes ago). > I think, it's either compiler or assembler problem because they must > not accept faulty source code (just as point this out to me). Code so subtly incorrect as yours cannot be detected by the compiler, as it doesn't really read or understand your assembly code. It just looks at your input/output/clobber lists and uses them to set up the registers your code needs, by replacing the %0 and other placeholders in the assembly with generated register names and/or memory references. gcc only writes, but never reads assembly code. The assembler, OTOH, only sees what the compiler made of the whole thing. I.e. if the compiler managed not to trip over some of the booby-traps contained in your code, the assembler has no chance to notice it. Wether or not the compiler triggers the bugs in your code depends on seemingly random details, as shown by the fact that an older gcc version didn't even accept it in -O0 mode, which your version did. Technically spoken, I think we're in the regime of 'undefined behaviour', here, i.e. with your example code, absolutely anything can happen, from 'it works as expected' all the way to a crash of the compiler, or even worse things. > They must not because they are not VB like programs and they are > programs for a computer but not people that can operate with > abstract things. Inline assembly is definitely expert-level stuff. This implies that gcc has to assume the programmer knows what (s)he's doing, there. It cannot check this code itself, in all cases, so it's up to you to check it. Please don't take this as an offence, but I think this discussion has shown that you do not have all the necessary expertise yet, in that area. That's the aspect in your messages that made (some of) us so furious, probably: you blame other peoples' work in strong wording, without having checked your own code properly, first. It took three postings back and forth before you ever showed us some hard info (i.e. a source code example) about your problem, which should usually have been the very first thing to do. Your reaction upon us calling your code 'buggy' didn't improve the impression you gave, either. Anyway: I didn't take offence in your shouting and hope you don't feel offended by this either, so let's try and get down to the business, again. Dieter Buerssner has shown you quite clearly how your code should be changed to make it work, so please try out his suggestions. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.