public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Michael Eager <eager@mvista.com>
To: dewar@gnat.com
Cc: Anshil@gmx.net, aoliva@redhat.com, gcc@gcc.gnu.org
Subject: Re: Is this a gcc bug?
Date: Tue, 16 Jan 2001 17:01:00 -0000	[thread overview]
Message-ID: <3A64EDD6.76B11021@mvista.com> (raw)
In-Reply-To: <20010113022149.AFA5534D80@nile.gnat.com>

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

  parent reply	other threads:[~2001-01-16 17:01 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-01-12 18:21 dewar
2001-01-12 18:29 ` Joseph S. Myers
2001-01-12 18:49 ` Alexandre Oliva
2001-01-12 18:58 ` Fergus Henderson
2001-01-13 10:34 ` James Dennett
2001-01-16 17:01 ` Michael Eager [this message]
2001-01-17  3:21   ` Falk Hueffner
2001-01-17 14:57     ` Michael Eager
  -- strict thread matches above, loose matches on Subject: below --
2008-06-16 13:01 Is this a GCC bug? Bingfeng Mei
2008-06-16 13:33 ` Bingfeng Mei
2001-01-17 23:30 Is this a gcc bug? Axel Kittenberger
2001-01-16 17:06 dewar
2001-01-14 16:14 dewar
2001-01-14 16:53 ` Dave Korn
2001-01-14  5:31 dewar
2001-01-14 15:51 ` Geoff Keating
2001-01-12 19:15 dewar
2001-01-12 19:29 ` Fergus Henderson
2001-01-12 19:14 dewar
2001-01-12 19:36 ` Alexandre Oliva
2001-01-12  1:18 Axel Kittenberger
2001-01-12 18:14 ` Alexandre Oliva
2001-01-12 19:11   ` Fergus Henderson
2001-01-13  3:21   ` Richard Earnshaw
2001-01-11 10:38 dewar
2001-01-11 10:30 dewar
2001-01-11 10:05 dewar
2001-01-11 10:00 David Korn
2001-01-11 21:36 ` Andy Walker
2001-01-13 18:45   ` Joern Rennecke
2001-01-14  2:21     ` Geoff Keating
2001-01-11  7:07 dewar
2001-01-11  5:53 dewar
2001-01-11  6:06 ` Bernd Schmidt
2001-01-11  8:40   ` Per Bothner
2001-01-11  9:03     ` Richard Earnshaw
2001-01-11  9:27       ` Alexandre Oliva
2001-01-11  9:33       ` Joe Buck
2001-01-11  9:38         ` Bernd Schmidt
2001-01-11  9:44           ` Richard Earnshaw
2001-01-11 10:57     ` Neil Booth
2001-01-11  5:49 dewar
2001-01-11  3:04 David Korn
2001-01-11  2:11 Uros Bizjak
2001-01-11  3:04 ` Alexandre Oliva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3A64EDD6.76B11021@mvista.com \
    --to=eager@mvista.com \
    --cc=Anshil@gmx.net \
    --cc=aoliva@redhat.com \
    --cc=dewar@gnat.com \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).