Bug 15103 - postincrement precedence lower than assignment
Summary: postincrement precedence lower than assignment
Status: RESOLVED DUPLICATE of bug 11751
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 3.3.3
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-23 18:13 UTC by Mark
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: i486-slackware-linux
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark 2004-04-23 18:13:35 UTC
In the following program:
==========================================
#include <stdio.h>
 
int main(int argc, char *argv[]) {
  int x = 20, y = 35;
  x = x++ + y++;
  y = ++x + ++y;
  printf("x=%d y=%d\n", x, y);
  return 0;
}
==========================================

In the first assignment line "x = x++ + y++;", the code emitted by the i386
compiler processes the post-increment operators after the assignment, so that
the addition result gets incremented in "x".

1. Shouldn't "x++" be semantically equivalent to "(x += 1, x - 1)"? The first
assignment produced assembly that behaved more like:
x = x + y;
x++;
y++;
I tried to use parentheses around the increment expressions to force the
precedence, but they were ignored.

2. Don't the increment and decrement operators have a much higher precedence
than assignment?

I'll admit, any coder working for me who wrote code like the above, would be
fired on the spot. This is a very small corner case. However, it may point to a
larger issue that needs to be resolved, so I'm filing it "just in case".
Comment 1 Falk Hueffner 2004-04-23 18:57:49 UTC
Invalid, since you're modifying variables twice without a sequence point in
between. Please read the documentation on -Wsequence-point.
Comment 2 Wolfgang Bangerth 2004-08-05 14:57:10 UTC
Reopen these bugs... 
Comment 3 Wolfgang Bangerth 2004-08-05 15:01:23 UTC
...mark as duplicate of PR 11751. 

*** This bug has been marked as a duplicate of 11751 ***