This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/40422] New: using optimization breaks code
- From: "yu_kalev at hotmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Jun 2009 06:53:04 -0000
- Subject: [Bug c/40422] New: using optimization breaks code
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
setting the optimization level to O3 under gcc 3.4.5 in windows (mingw32)
breaks the code. it's even worse in linux with gcc 4.3.0-8. it breaks it even
with O2. The ver. 4.3.0 code is that bad, i won't even bother to comment on it.
however in ver. 3.4.5. the problem is obvious. i shall also attach the source
and the generated assembler output for both versions.
compile with under windows:
gcc -O3 -masm=intel -march=i386 -o shaj.exe -Wa,-ahl=shaj.s shaj.c -lwinmm
under linux:
gcc -O3 -masm=intel -march=i386 -D__tune_i386__ -o shaj -Wa,-ahl=shaj.s
shaj.c
the tune_i386 macro is defined in ver 3.4.5, but not in 4.3.0...oh well
in windows the bug does not appear should the bswap version of the assembly in
the c file be used.
In general, the problem is that this code:
if (read < 56) ((long long*)w)[7] = fix_end64(len);
###################################################
unsigned long long fix_end64(unsigned long long i)
{
return (((unsigned long long)(fix_end(((unsigned int*)&i)[0])) << 32))
| (fix_end(((unsigned int*)&i)[1]));
}
###################################################
unsigned int fix_end(unsigned int i)
{
__asm__ (
"xchg %b0,%h0\n\t"
"ror %0,16\n\t"
"xchg %b0,%h0\n"
:"=q"(i)
:"0"(i)
);
return i;
}
*********************************************
translates to this (in the simplest case)
cmp ecx, 55
263 022f 7F37 jg L42
264 0231 8B55C8 mov edx, DWORD PTR [ebp-56]
265 0234 8955E8 mov DWORD PTR [ebp-24], edx
266 0237 8B45E8 mov eax, DWORD PTR [ebp-24]
267 023a 31DB xor ebx, ebx
268 /APP
269 023c 86E0 xchg al,ah
270 023e C1C810 ror eax,16
271 0241 86E0 xchg al,ah
272
273 /NO_APP
274 0243 89C2 mov edx, eax
275 0245 31C0 xor eax, eax
276 0247 8B75CC mov esi, DWORD PTR [ebp-52]
277 024a 8B4DEC mov ecx, DWORD PTR [ebp-20] !!!!nope, we
kinda forgot to save the right value here...it's in esi, not in the mem
location. see below. furthermore the code is RUBBISH as a whole
278 024d 09DA or edx, ebx
279 /APP
280 024f 86E9 xchg cl,ch
281 0251 C1C910 ror ecx,16
282 0254 86E9 xchg cl,ch
283
284 /NO_APP
285 0256 09C8 or eax, ecx
286 0258 8B0D0000 mov ecx, DWORD PTR _w
286 0000
287 025e 8975EC mov DWORD PTR [ebp-20], esi !!!!!!too late,
already used the false value
288 0261 894138 mov DWORD PTR [ecx+56], eax
should i comment on the overall code quality? not here i suppose. but it should
be obvious by now...
have fun
--
Summary: using optimization breaks code
Product: gcc
Version: 3.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yu_kalev at hotmail dot com
GCC host triplet: i386-win32 & i386-linux
GCC target triplet: i386-win32 & i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40422