| Summary: | Code generation bug for aliased long long with -mpentium-m | ||
|---|---|---|---|
| Product: | gcc | Reporter: | gcc2eran |
| Component: | c | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | CC: | cdfrey, chiabaut, gcc-bugs, gcc2eran, sorenj, takahisa.yokota |
| Priority: | P3 | ||
| Version: | 4.1.1 | ||
| Target Milestone: | --- | ||
| Host: | Target: | i686-pc-linux-gnu | |
| Build: | 4.1.1 | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
You are violating C aliasing rules. You are accessing a character array via something other than a character type which is undefined. The opposite way would have been defined in that accessing an long long array (or a short array) via a character type. *** This bug has been marked as a duplicate of 21920 *** |
The following C program gives incorrect results with vanilla gcc 4.1.1 (default ./configure options except --prefix, compiled on Fedora Core 5) and specific compile options. ---------------------------- #include <stdio.h> char buf[8] = {1,1,1,1,1,1,1,1}; char zero=0; int main() { int i; *(long long*)buf = 0; *(short*)buf ^= (zero) ^ (zero<<1); for (i=0; i<8; i++) printf("%x,", buf[i]); return 0; } ---------------------------- The buffer should contain all zeros after the two assignments, but it doesn't: $ ~/gcc-4.1.1/bin/gcc -W -Wall -Wno-long-long -pedantic \ -march=pentium-m -O2 -o gcc-bug gcc-bug.c $ ./gcc-bug 1,1,0,0,0,0,0,0, Looks like some sort of aliasing issue for long longs; I don't see it happening with ints. Twiddling compile options and further code simplification tends to make the problem disappear. The above is a (painfully) reduced version of useful code which exhibited the problem, so it's actually something you can bump into.