Re: compiler bug?

nospam_at_cristalink.com
Date: 07/13/04 

Date: Wed, 14 Jul 2004 09:47:00 +1200

I think it's a compiler bug. It goes away when InterlockedIncrement() is
inlined.

"Fabian Tillier" <FabianTillier@discussions.microsoft.com> wrote in message
news:BD941392-D7BA-4E02-A45B-3C8D30134717@microsoft.com...
> "nospam@cristalink.com" wrote:
>
>> It does look like a compiler bug, however it can be yours as well. Can
>> you
>> post the whole function code from a .COD file produced by the /FAacs
>> compiler command-line option?
>
> I simplified my code to try to minimize the amount of code while
> preserving the output.
>
> Here's what it came down to, in code:
>
> volatile LONG foo = 0;
>
> void __junk( UINT64 *p_bar );
>
> void __foobar()
> {
> UINT64 y;
>
> y = 0x123456789ABCDEF0 + InterlockedIncrement( &foo );
> y = RtlUlonglongByteSwap( y );
>
> __junk( &y );
> }
>
> Here is the listing created with the /FAcs compiler command line option:
>
> PUBLIC ___foobar@0
> EXTRN __imp_@InterlockedIncrement@4:NEAR
> EXTRN ___junk@4:NEAR
> ; Function compile flags: /Ogsy
> ; COMDAT ___foobar@0
> _TEXT SEGMENT
> _y$ = -8 ; size = 8
> ___foobar@0 PROC NEAR ; COMDAT
>
> ; 2208 : {
>
> 00000 55 push ebp
> 00001 8b ec mov ebp, esp
> 00003 51 push ecx
> 00004 51 push ecx
>
> ; 2209 : UINT64 y;
> ; 2210 :
> ; 2211 : y = 0x123456789ABCDEF0 + InterlockedIncrement( &foo );
>
> 00005 b9 00 00 00 00 mov ecx, OFFSET FLAT:_foo
> 0000a ff 15 00 00 00
> 00 call DWORD PTR __imp_@InterlockedIncrement@4
>
> ; 2212 : y = RtlUlonglongByteSwap( y );
>
> 00010 99 cdq
> 00011 05 f0 de bc 9a add eax, -1698898192 ; 9abcdef0H
> 00016 0f c8 bswap eax
> 00018 81 d2 78 56 34
> 12 adc edx, 305419896 ; 12345678H
> 0001e 89 45 fc mov DWORD PTR _y$[ebp+4], eax
>
> ; 2213 :
> ; 2214 : __junk( &y );
>
> 00021 8d 45 f8 lea eax, DWORD PTR _y$[ebp]
> 00024 0f ca bswap edx
> 00026 50 push eax
> 00027 89 4d f8 mov DWORD PTR _y$[ebp], ecx
> 0002a e8 00 00 00 00 call ___junk@4
>
> ; 2215 : }
>
> 0002f c9 leave
> 00030 c3 ret 0
> ___foobar@0 ENDP
> _TEXT ENDS
>
> The instruction at 00027 seems wrong again, with ECX being used rather
> than EDX.
>
> I'm building for x86 using the free build environment for Windows Server
> 2003.
>
> Hope that helps!
>
> - Fab
>