Question related to MS's CL and GCC

[Aldhard Oswine]

I'm learning how C/C++ codes are translated into the assembly language by different compilers.
I have following code:

#include <cstdio>

class Pie {
    double z;
};

int main(){
      Pie a = Pie();
      Pie v = Pie();
      Pie d = a;
      Pie b = Pie();
}

Following is generated by GCC -m32 without optimization:
 

main:
        push    ebp
        mov     ebp, esp
        push    ecx
        sub     esp, 32
        lea     ecx, [ebp+8]
        fldz
        fstp    QWORD PTR [ebp-12]
        fldz
        fstp    QWORD PTR [ebp-20]
        fld     QWORD PTR [ebp-12]
        fstp    QWORD PTR [ebp-28]
        fldz
        fstp    QWORD PTR [ebp-36]
        mov     eax, 0
        add     esp, 32
        pop     ecx
        pop     ebp
        ret

 

GCC aligns 16 bytes for 1 double, 16 bytes for 2 doubles, 32 bytes for 3 double and 32 bytes for 4 double. The pattern is clear, but why compiler need such behavior?

Following is generated by MS's CL 19 without optimization:

 

_b$ = -56                                         ; size = 8
_d$ = -48                                         ; size = 8
_v$ = -40                                         ; size = 8
$T1 = -32                                         ; size = 8
_a$ = -24                                         ; size = 8
$T2 = -16                                         ; size = 8
$T3 = -8                                                ; size = 8
_main   PROC
        push     ebp
        mov      ebp, esp
        sub      esp, 56              ; 00000038H
        xor      eax, eax
        mov      DWORD PTR $T3[ebp], eax
        mov      DWORD PTR $T3[ebp+4], eax
        mov      ecx, DWORD PTR $T3[ebp]
        mov      DWORD PTR _a$[ebp], ecx
        mov      edx, DWORD PTR $T3[ebp+4]
        mov      DWORD PTR _a$[ebp+4], edx
        xor      eax, eax
        mov      DWORD PTR $T2[ebp], eax
        mov      DWORD PTR $T2[ebp+4], eax
        mov      ecx, DWORD PTR $T2[ebp]
        mov      DWORD PTR _v$[ebp], ecx
        mov      edx, DWORD PTR $T2[ebp+4]
        mov      DWORD PTR _v$[ebp+4], edx
        mov      eax, DWORD PTR _a$[ebp]
        mov      DWORD PTR _d$[ebp], eax
        mov      ecx, DWORD PTR _a$[ebp+4]
        mov      DWORD PTR _d$[ebp+4], ecx
        xor      edx, edx
        mov      DWORD PTR $T1[ebp], edx
        mov      DWORD PTR $T1[ebp+4], edx
        mov      eax, DWORD PTR $T1[ebp]
        mov      DWORD PTR _b$[ebp], eax
        mov      ecx, DWORD PTR $T1[ebp+4]
        mov      DWORD PTR _b$[ebp+4], ecx
        xor      eax, eax
        mov      esp, ebp
        pop      ebp
        ret      0
_main   ENDP

 

This is more intuitive, it aligns as many as it needs, but why compiler use T_ ?

[SmilingWolf]

-snip

Edited December 14, 2016 by SmilingWolf
Need to read more

[SmilingWolf]

-snip

[atom0s]

I would say that you should probably decompile the program(s) with various decompilers and compare the results. Whatever one you used to generate the output from the MSCL looks weird and not standard for the type of code it generates.