From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Dennett To: gcc@gcc.gnu.org Subject: Re: Is this a gcc bug? Date: Sat, 13 Jan 2001 10:34:00 -0000 Message-id: <3A60B5C1.2050608@evtechnology.com> References: <20010113022149.AFA5534D80@nile.gnat.com> X-SW-Source: 2001-01/msg00868.html dewar@gnat.com wrote: > < > > That's probably OK in practice, but it is of course a lie, at least > one of omission, the sentence after the colon does represent a > possible outcome. But we could also write: > > undefined behavior: expression may not modify x at all. > > Now both are equally correct semantically, though of course the first > one is more likely to represent what the code does EXCEPT that clever > optimizers can make all sorts of assumptions that result in strange > behavior. For example: > > x = y[4]++ + y[j]++; > > the optimizer is allowed to conclude that j!=4, and to propagate this > information both forwards and backwards. The backwards propagation > can be especially surprising. Suppose that just before is the statement: > > if (j != 4) delete_system_disk(); > > then the compiler could in theory call delete system disk without > testing the value of j at all :-) Nice example of plausibility. (Can you do the same to show how the compiler can produce nasal demons?) > > So the question is, should an error message like this try to educate, > or just take the simple minded non-determinstic viewpoint. Education Good, ignorance Bad. SGI's C++ compiler, with appropriate flags, gives short sermons when code is broken according to the relevant Standards, and I have found that this goes some way > One of the things that happens as C compilers optimize more, is that people > who make improper assumptions can run into serious trouble, so I think there > is some argument for education here. My experience is that most programmers don't realize how much they are relying on non-portable features of dumb optimizers. Where possible, good (even verbose) warning/error messages are helpful. -- James Dennett