Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!uwm.edu!rpi!zaphod.mps.ohio-state.edu!usc!apple!mips!servitude.mips.com!rogerk
From: rogerk@servitude.mips.com (Roger B.A. Klorese)
Newsgroups: comp.sys.mips
Subject: Re: compiler bug
Message-ID: <36884@mips.mips.COM>
Date: 9 Mar 90 22:24:35 GMT
References: <36721@mips.mips.COM> <18302@shamash.cdc.com>
Sender: news@mips.COM
Lines: 71

(I've been asked by Frank Yellin to post this reply, since his followup
hasn't made it off Lucid's machines.)
-----
Newsgroups: comp.sys.mips
Subject: Re: compiler bug
Summary: 
Expires: 
References: <18302@shamash.cdc.com> <36721@mips.mips.COM>
Sender: 
Reply-To: fy@sunvalleymall.UUCP (Frank Yellin)
Followup-To: 
Distribution: 
Organization: Lucid, Inc., Menlo Park, CA
Keywords: 

In article <18302@shamash.cdc.com> dwl@mercury.udev.cdc.com (Daren W Latham)
writes that the following doesn't compile correctly.
>#define  PushArg(n)              argStack[argStackP++] = n
>#define  PopArg()                argStack[--argStackP]
>
>main()
>{
>  int  argStack[10];
>  int  argStackP = 0;
>  int  temp;
>
>  PushArg(5);
>  PushArg(8);
>
>  temp = PopArg() + PopArg();
> }

and in article <36721@mips.mips.COM> rex@mips.COM (Rex Di Bona) replies


> The compiler has decided to do the two decrements first
> (this is legal) and has then removed the second lookup
> in the array to save a multiply. It has finally done the addition.

In the Second Edition of "C: A Reference Manual" by Harbison and Steele,
they write (p. 190), 

    When evaluating the actual arguments in a function call, the order in
    which the arguments are evaluated is not specified; but the program
    must behave as if it chose one argument, evaluated it fully, then chose
    another argument, evaluated it fully, and so on. . . .

    A similar restring holds for binary operators:  The two operands may be
    evaluated in either order, but the program must behave as if one of the
    two operands were evaluated completely before commencement of the 
    evaluation of the second operand.

    [In] the original description of C. . . . the matter of interleaving
    was not discussed. . . .  We advise implementors to adhere rigidly to
    the restrictions outlined here (which actually are quite sensible and
    not terribly restrictive).   We also advice programmers not to exploit
    these restrictions too cleverly. . . .  The entire purpose of the
    restrictions is to make the behavior of the program more understandable.

I don't know whether Harbison and Steele is considered authoritative, but
they certainly would consider the MIPS implementation to be incorrect.

-- Frank Yellin
   fy@lucid.com
   
  
---
ROGER B.A. KLORESE      MIPS Computer Systems, Inc.      phone: +1 408 720-2939
MS 4-02    928 E. Arques Ave.  Sunnyvale, CA  94086             rogerk@mips.COM
{ames,decwrl,pyramid}!mips!rogerk                                 "I'm the NLA"
"Two guys, one cart, fresh pasta... *you* figure it out." -- Suzanne Sugarbaker