GCC 4.1.2 generates different pentium instructions
Hi all, I noticed that G++ 4.1.2 (on a Pentium 4) generates different instructions for lea0x0(%esi),%esi or lea0x0(%edi),%edi with the same meaning but different encoding depending on the switch "-momit-leaf-frame-pointer". If I compile and "objdump" a short function with "-O2" I get <_ZN18errorbintestentityptEv>: 55push %ebp 89 e5 mov%esp,%ebp 83 ec 18 sub$0x18,%esp 89 75 fc mov%esi,0xfffc(%ebp) 8b 75 08 mov0x8(%ebp),%esi 89 5d f8 mov%ebx,0xfff8(%ebp) 8b 5e 08 mov0x8(%esi),%ebx 85 db test %ebx,%ebx 74 1a je cd0 <_ZN18errorbintestentityptEv+0x30> 89 d8 mov%ebx,%eax 8b 75 fc mov0xfffc(%ebp),%esi 8b 5d f8 mov0xfff8(%ebp),%ebx 89 ec mov%ebp,%esp 5dpop%ebp c3ret 8d b4 26 00 00 00 00 lea0x0(%esi),%esi 8d bc 27 00 00 00 00 lea0x0(%edi),%edi c7 04 24 24 00 00 00 movl $0x24,(%esp) e8 fc ff ff ffcall cd8 <_ZN18errorbintestentityptEv+0x38> 85 c0 test %eax,%eax 89 c3 mov%eax,%ebx 74 08 je cea <_ZN18errorbintestentityptEv+0x4a> 89 04 24 mov%eax,(%esp) e8 fc ff ff ffcall ce6 <_ZN18errorbintestentityptEv+0x46> ff 43 04 incl 0x4(%ebx) 89 d8 mov%ebx,%eax 89 5e 08 mov%ebx,0x8(%esi) 8b 5d f8 mov0xfff8(%ebp),%ebx 8b 75 fc mov0xfffc(%ebp),%esi 89 ec mov%ebp,%esp 5dpop%ebp c3ret If I additionally set "-momit-leaf-frame-pointer" I get <_ZN18errorbintestentityptEv>: 83 ec 0c sub$0xc,%esp 89 74 24 08 mov%esi,0x8(%esp) 8b 74 24 10 mov0x10(%esp),%esi 89 5c 24 04 mov%ebx,0x4(%esp) 8b 5e 08 mov0x8(%esi),%ebx 85 db test %ebx,%ebx 74 1a je d20 <_ZN18errorbintestentityptEv+0x30> 89 d8 mov%ebx,%eax 8b 74 24 08 mov0x8(%esp),%esi 8b 5c 24 04 mov0x4(%esp),%ebx 83 c4 0c add$0xc,%esp c3ret 8d b6 00 00 00 00 lea0x0(%esi),%esi ; <--- DIFFERENT 8d bf 00 00 00 00 lea0x0(%edi),%edi ; <--- DIFFERENT c7 04 24 24 00 00 00 movl $0x24,(%esp) e8 fc ff ff ffcall d28 <_ZN18errorbintestentityptEv+0x38> 85 c0 test %eax,%eax 89 c3 mov%eax,%ebx 74 08 je d3a <_ZN18errorbintestentityptEv+0x4a> 89 04 24 mov%eax,(%esp) e8 fc ff ff ffcall d36 <_ZN18errorbintestentityptEv+0x46> ff 43 04 incl 0x4(%ebx) 89 d8 mov%ebx,%eax 89 5e 08 mov%ebx,0x8(%esi) 8b 5c 24 04 mov0x4(%esp),%ebx 8b 74 24 08 mov0x8(%esp),%esi 83 c4 0c add$0xc,%esp c3ret In the first case I get instructions with an SIB byte 8d b4 26 00 00 00 00 lea0x0(%esi),%esi 8d bc 27 00 00 00 00 lea0x0(%edi),%edi in the second without SIB byte 8d b6 00 00 00 00 lea0x0(%esi),%esi 8d bf 00 00 00 00 lea0x0(%edi),%edi Identical function but different length (according to my pentium manual). Why ? Cheers Maett Eugster
Re: GCC 4.1.2 generates different pentium instructions
Am 21.03.2007, 23:38 Uhr, schrieb Ian Lance Taylor <[EMAIL PROTECTED]>: "H. J. Lu" <[EMAIL PROTECTED]> writes: On Wed, Mar 21, 2007 at 09:19:44PM +0100, fafa wrote: > Hi all, > > I noticed that G++ 4.1.2 (on a Pentium 4) generates different instructions > for > lea0x0(%esi),%esi > or > lea0x0(%edi),%edi > with the same meaning but different encoding depending on the switch > "-momit-leaf-frame-pointer". > They are generated by assembler for different alignment adjustments. To expand on that, note that those instructions do nothing. They are nops inserted for alignment purposes. The size of the instruction varies depending upon how many bytes it has to take up. Ian I see. But why not simple "nop" instructions ? Is it just for the compactness of the listing, or does it optimize the instruction prefetching of the CPU ? Maett
missing "std::move"
Hi all, I tried to compile some rvalue reference examples by (from H.Hinnant at http://home.twcny.rr.com/hinnant/cpp_extensions/rvalue_ref_rationale.html) with one of the latest GCC 4.3 snapshots, but I'm getting error: 'move' is not a member of 'std' What can I do to get this working ? Cheers Maett Eugster
Inconsistent use of __GTHREAD_HAS_COND
Hi. I tried to build gcc from the latest snapshot (gcc-4.3-20071005), but I undefined the symbol "__GTHREAD_HAS_COND" which is desribed in libstdc++-v3\ChangeLog as follows: ... [!__GTHREAD_HAS_COND] Fall back to the old code, which deadlocks. ... But libstdc++-v3\libsupc++\guard.cc uses the class __guard from libstdc++-v3\include\ext\concurrence.h which depends on the symbol __GTHREAD_HAS_COND and is undefined now. It seems to me that the two files are not consistent. What should I do ? Cheers Maett
Re: Inconsistent use of __GTHREAD_HAS_COND
Jason Merrill wrote: fafa wrote: I tried to build gcc from the latest snapshot (gcc-4.3-20071005), but I undefined the symbol "__GTHREAD_HAS_COND" which is desribed in libstdc++-v3\ChangeLog as follows: ... [!__GTHREAD_HAS_COND] Fall back to the old code, which deadlocks. ... But libstdc++-v3\libsupc++\guard.cc uses the class __guard from libstdc++-v3\include\ext\concurrence.h which depends on the symbol __GTHREAD_HAS_COND and is undefined now. Hmm? __guard is a typedef in cxxabi-tweaks.h and doesn't depend on __GTHREAD_HAS_COND. Jason Sorry, my bad; i meant __cond instead of __guard ! But libstdc++-v3\libsupc++\guard.cc uses the class __cond from libstdc++-v3\include\ext\concurrence.h which depends on the symbol __GTHREAD_HAS_COND and is undefined now. in the static variable static __gnu_cxx::__cond* static_cond; in line 68 of guard.cc. So class __cond is unknown when I link with the above built version. Maett
