From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1df6bc3799debed X-Google-Attributes: gid103376,public From: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Not intended for use in medical, Date: 1997/05/04 Message-ID: #1/1 X-Deja-AN: 239280843 References: <3.0.32.19970423164855.00746db8@mail.4dcomm.com> <3364C8EC.4879@DIE_SPAMMER.dasd.honeywell.com> <5k5ifi$8db@bcrkh13.bnr.ca> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-05-04T00:00:00+00:00 List-Id: kaz@vision.crest.nt.com (Kaz Kylheku) writes: > int foo(int x, int y) > > { > return ((x < y) && x++) && ((x < y) && x++); > } [...] > /* > * GCC seems to illegaly optimize foo() by factoring the (x < y) > * as a common subexpression ignoring the x++ side effect, e.g: > * > * return ((x < y) && x++) && x++; > * > * A more complex version of this expression has caused a serious > * failure in some of my code. > */ This is an amazingly comon mistake, and people are always sending in bogus bug reports to the gcc list complaining about this particular case. In fact, as Simon points out, an expresson like the above one is entirely undefined, and it is quite clear from the ANSI standard that it is undefined. There is no bug in gcc here, just a bug in the program, and as usual when programmers put bugs into programs it can cause serious failures. The factoring that GCC is doing here is quite legitimate, and indeed it is *precisely* to allow this kind of optimziation that the standard declares expressions like this to have undefined semantics. One important thing that all programmers need to learn is that it is critical if you are trying to write portable code to know the language definition. The fact that something happens to work is NOT proof that your code is correct. It is possible to write completely portable code in many languages, including for example C, COBOL and Fortran, but only if you know the lanuage definition well. In practice, very few C, COBOL or Fortran programmers know the standard well (typical programmers for these languages have not even read the standard). One of the great achievments of Ada 83 was that for the first time since Algol-60, we had a language where typical professional programmers owned the standard, and used it at least as a reference work. Even in Ada 95 this tradition continues (despite the fact that the Ada 95 standard is much less accessible than the Ada 83 standard, due to a decision to attempt to be much more precise -- this is always a tough trade off) Note also that portability is extremely important in contexts that might be surprising (such as turning optimization on or off, going to a new version of the same compiler, or, as in this case, going to a different compiler on the same machine).