This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/26642] New: order of multiple assignments to array-values handled differently from gcc 3.3.5
- From: "nobs at tigress dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 11 Mar 2006 12:25:09 -0000
- Subject: [Bug c/26642] New: order of multiple assignments to array-values handled differently from gcc 3.3.5
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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);
}
--
Summary: order of multiple assignments to array-values handled
differently from gcc 3.3.5
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nobs at tigress dot com
GCC build triplet: x86
GCC host triplet: x86
GCC target triplet: x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26642