This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Is this a gcc bug?


dewar@gnat.com wrote:

> <<undefined behavior: expression may modify `x' multiple times
> 
> 
> 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 <jdennett@acm.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]