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 :-)

I don't think that even a brilliant optimizer can make any conclusion 
about j's value, based on the assumption that j!=4 is the only situation 
where the expression is well defined.  

From logic:  undefined ==> anything,  not undefined ==> something

At best, the compiler could determine that the value of the expression
is not defined under some circumstances.

> So the question is, should an error message like this try to educate,
> or just take the simple minded non-determinstic viewpoint.

My preference is for messages which succinctly say what the problem
is, without trying to guess too much about what the code is doing.
The more guessing, in my opinion, the less clear the message.

My sugguestion:  

	undefined behavior:  value of expression using 'x' is undefined 

> 
> 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.

-- 

Michael Eager
Senior Tools Developer	  Phone: (408) 328-8426
MontaVista Software, Inc.   Fax: (408) 328-9204
1237 E. Arques Avenue	    Web: www.hardhatlinux.com
Sunnyvale, CA 94085	  Email: eager@mvista.com

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