Here is the ouput on our SGI server running IRIX 6.5
#include <stdio.h>
main()
{
int i=2;
int j = i++ + ++i;
printf("%d %d\n",j,i);
}
Now, you think that j would be 7 and i would be four right?
Here it is with g++/gcc (both give the same output):
elvis 586% g++ b.c
elvis 587% a.out
5 3
And now with the CC type compilers from SGI:
elvis 588% CC b.c
elvis 589% a.out
7 4
> I'll have to take a look at the rest of what you
> said because something seems a little off, but
> this behaviour is totally wrong --
>
> > while the CC compilers are incrementing i++ before the
> > addition begins.
>
> This is completely against the C standard, which
> means the post-increment is done after the assignment.
> If it does the increment before the assignment, it is
> a preincrement (++i).
>
> The reason it seems there is a preincrement on the
> first i is because the second i is preincremented.
> It doesn't surprise me that it may be a compiler-
> dependant thing on whether or not the first i sees
> the preincrement. On my gcc, both i's see the
> preincrement, and then i is postincremented due to
> the "i++".
>
> To show that this is the case, do the following
> (again probably compiler-dependant):
>
> +----snip
> #include <stdio.h>
> void main(void)
> {
> int i=2;
> int p= ++i + ++i;
> printf("p=%d, i=%d\n", p, i);
> }
> +----snip
>
> You still get the expected i = 4, but p is
> now 8 because i is preincremented twice (to 4)
> and then added together (for 8).
>
> All of this stems from both the compiler, OS,
> and machine used. It depends upon whether or
> not local copies of i are made for the addition,
> when the values are read from memory, etc.
> However, the values I have given are from
> linux gcc on an x86, and are what is expected
> from ANSI C. Pre-increment is done before
> everything, then addition, then assignment,
> then postincrement.
>
> On a UltraSparc w/ SunOS 5.5.1, you get
> j=7, i=4. This is because Sparc has local
> registers for the addition. Not to start a holy
> war, but I feel this is a bug in the hardware in
> this case. Sparc should not have cached the
> value of i after the first increment because
> it results in i == 3 == 4 when the final addition
> is made to assign to j.
>
>
> ~Patrick
>
>
>
> > From: Joseph Keen
> >
> > > Very interesting problem, and a more complete
> > > answer would be j = 6, i = 4, and this is why:
> > >
> > > i = 2;
> > > j = i++ + ++i;
> > >
> > > Obviously, the j line is more interesting, so
> > > we'll talk about sequence of operations. The
> > > preincrement operator is done before everything
> > > else, so "++i" is done, giving i the value of
> > > 3, even before the addition, so you end up
> > > with "j = 3++ + 3" which equals 6. After the
> > > line is completed, i is incremented, causing
> > > i to be 3++ = 4.
> > >
> > >
> > > ~Patrick
> >
> > On my compiler it seems to do this:
> > i = 2;
> > j = i++ + ++i;
> > It does the i = 2 just fine. So at the start of the j line i = 2.
> > Now, it does i + ++i, and *then* it increments i the second
> > time. So it
> > becomes (2 + ++i)++; Actually I just tried it with a couple different
> > compilers. g++ and gcc give me 5 for j while CC and cc both
> > give me 7 for
> > j. I assume that the GNU compilers are incrementing the i++ after then
> > assignment is done, while the CC compilers are incrementing
> > i++ before the
> > addition begins.
> >
> > --Joe
> >
>
