Bug 26642 - order of multiple assignments to array-values handled differently from gcc 3.3.5
Summary: order of multiple assignments to array-values handled differently from gcc 3.3.5
Status: RESOLVED DUPLICATE of bug 11751
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.0.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-03-11 12:25 UTC by Emil Obermayr
Modified: 2006-03-11 15:09 UTC (History)
46 users (show)

See Also:
Host: x86
Target: x86
Build: x86
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 Emil Obermayr 2006-03-11 12:25:09 UTC
Following code gives different results between version 4.0.2 and 3.3.5. The 'fun' thing is: There is a warning about the part that still behaves the same (with normale variables k and l). But the array-variables behave differently w/o any warnings. It works when putting the XOR-operations in separate lines of code. So I guess its a matter of optimising handling arrays, but it even happens with -O0.

> g++ --version
g++ (GCC) 3.3.5 20050117 (prerelease) (SUSE Linux)
> g++ -O0 -Wall -pedantic flip2.cc
> ./a.out
a[] before: 1 2
kl  before: 1 2
a[] after:  2 1
kl  after:  2 1

> g++ --version
g++ (GCC) 4.0.2 20050901 (prerelease) (SUSE Linux)
> g++ -O0 -Wall -pedantic flip2.cc
flip2.cc: In function ‘int main()’:
flip2.cc:16: warning: operation on ‘k’ may be undefined
> ./a.out
a[] before: 1 2
kl  before: 1 2
a[] after:   1
kl  after:  2 1


#include <iostream>

int main (void){

  using namespace std;
  
  char a[]={'1','2'};

  char k='1';
  char l='2';
  
  cout << "a[] before: " << a[0] << " " << a[1] << endl;
  cout << "kl  before: " << k    << " " << l    << endl;
  
  a[0] ^= a[1] ^= a[0] ^= a[1];
  k    ^= l    ^= k    ^= l;

  cout << "a[] after:  " << a[0] << " " << a[1] << endl;
  cout << "kl  after:  " << k    << " " << l    << endl;
 
  return (0);
}
Comment 1 Neil Booth 2006-03-11 14:28:36 UTC
There is no reason the results should not change.
Comment 2 Andrew Pinski 2006-03-11 15:09:33 UTC
Note please read the warnings and actually listen to them.

Reopening to ...
Comment 3 Andrew Pinski 2006-03-11 15:09:47 UTC
Mark as a dup of bug 11751.

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