This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/40422] New: using optimization breaks code


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]