* Should it be reported as a bug? (-O2 and cmpxchg instruction)
@ 2008-02-15 10:56 Martin Sustrik
2008-02-15 11:00 ` Andrew Haley
0 siblings, 1 reply; 9+ messages in thread
From: Martin Sustrik @ 2008-02-15 10:56 UTC (permalink / raw)
To: gcc-help
Hi all,
I've encountered a problem with gcc inline assembly.
Following code, when optimised with -O2 gives following machine code:
__asm__ volatile (
"lock; cmpxchgl %1, %3\n\t"
"jz 1f\n\t"
"mov %2, %%eax\n\t"
"lock; xchgl %%eax, %3\n\t"
"1:\n\t"
: "=a" (oldval)
: "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
: "memory", "cc");
4031a0: 31 c0 xor %eax,%eax
4031a2: f0 0f b1 55 40 lock cmpxchg %edx,0x40(%rbp)
4031a7: 74 06 je 4031af
4031a9: 89 c0 mov %eax,%eax
4031ab: f0 87 45 40 lock xchg %eax,0x40(%rbp)
Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This
shouldn't happen given that cmpxchg modifies the value of %%eax.
Any idea whether this should be considered a bug and reported as such?
GCC version info:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
Martin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 10:56 Should it be reported as a bug? (-O2 and cmpxchg instruction) Martin Sustrik
@ 2008-02-15 11:00 ` Andrew Haley
2008-02-15 11:21 ` Martin Sustrik
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Haley @ 2008-02-15 11:00 UTC (permalink / raw)
To: Martin Sustrik; +Cc: gcc-help
Martin Sustrik wrote:
> Hi all,
>
> I've encountered a problem with gcc inline assembly.
>
> Following code, when optimised with -O2 gives following machine code:
>
> __asm__ volatile (
> "lock; cmpxchgl %1, %3\n\t"
> "jz 1f\n\t"
> "mov %2, %%eax\n\t"
> "lock; xchgl %%eax, %3\n\t"
> "1:\n\t"
> : "=a" (oldval)
> : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
> : "memory", "cc");
>
> 4031a0: 31 c0 xor %eax,%eax
> 4031a2: f0 0f b1 55 40 lock cmpxchg %edx,0x40(%rbp)
> 4031a7: 74 06 je 4031af
> 4031a9: 89 c0 mov %eax,%eax
> 4031ab: f0 87 45 40 lock xchg %eax,0x40(%rbp)
>
> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This
> shouldn't happen given that cmpxchg modifies the value of %%eax.
>
> Any idea whether this should be considered a bug and reported as such?
Look for "earlyclobber" in the section Constraint Modifier Characters
Andrew.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 11:00 ` Andrew Haley
@ 2008-02-15 11:21 ` Martin Sustrik
2008-02-15 11:22 ` Andrew Haley
0 siblings, 1 reply; 9+ messages in thread
From: Martin Sustrik @ 2008-02-15 11:21 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc-help
Andrew,
Thanks for prompt response. However, I am not sure how to use the
earlyclobber modifier - this is actually the first gcc inline asembly
code I've ever written.
Do you mean that I should add '&' sign to every operand in input operand
list, or should I add the sign when using the operands or what?
The problem, AFAICS, is that cmpxchg modifies eax although eax is not an
explicit operand of the instruction. Therefore optimiser has no idea
that it is modified and acts as if it was unchanged :(
Martin
Andrew Haley wrote:
> Martin Sustrik wrote:
>> Hi all,
>>
>> I've encountered a problem with gcc inline assembly.
>>
>> Following code, when optimised with -O2 gives following machine code:
>>
>> __asm__ volatile (
>> "lock; cmpxchgl %1, %3\n\t"
>> "jz 1f\n\t"
>> "mov %2, %%eax\n\t"
>> "lock; xchgl %%eax, %3\n\t"
>> "1:\n\t"
>> : "=a" (oldval)
>> : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
>> : "memory", "cc");
>>
>> 4031a0: 31 c0 xor %eax,%eax
>> 4031a2: f0 0f b1 55 40 lock cmpxchg %edx,0x40(%rbp)
>> 4031a7: 74 06 je 4031af
>> 4031a9: 89 c0 mov %eax,%eax
>> 4031ab: f0 87 45 40 lock xchg %eax,0x40(%rbp)
>>
>> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This
>> shouldn't happen given that cmpxchg modifies the value of %%eax.
>>
>> Any idea whether this should be considered a bug and reported as such?
>
> Look for "earlyclobber" in the section Constraint Modifier Characters
>
> Andrew.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 11:21 ` Martin Sustrik
@ 2008-02-15 11:22 ` Andrew Haley
2008-02-15 11:31 ` Martin Sustrik
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Haley @ 2008-02-15 11:22 UTC (permalink / raw)
To: Martin Sustrik; +Cc: gcc-help
Please don't top-post.
Martin Sustrik wrote:
> Andrew,
>
> Thanks for prompt response. However, I am not sure how to use the
> earlyclobber modifier - this is actually the first gcc inline asembly
> code I've ever written.
>
> Do you mean that I should add '&' sign to every operand in input operand
> list, or should I add the sign when using the operands or what?
Use "=&a" on the first operand.
>
> The problem, AFAICS, is that cmpxchg modifies eax although eax is not an
> explicit operand of the instruction. Therefore optimiser has no idea
> that it is modified and acts as if it was unchanged :(
>
> Martin
>
> Andrew Haley wrote:
>> Martin Sustrik wrote:
>>> Hi all,
>>>
>>> I've encountered a problem with gcc inline assembly.
>>>
>>> Following code, when optimised with -O2 gives following machine code:
>>>
>>> __asm__ volatile (
>>> "lock; cmpxchgl %1, %3\n\t"
>>> "jz 1f\n\t"
>>> "mov %2, %%eax\n\t"
>>> "lock; xchgl %%eax, %3\n\t"
>>> "1:\n\t"
>>> : "=a" (oldval)
>>> : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
>>> : "memory", "cc");
>>>
>>> 4031a0: 31 c0 xor %eax,%eax
>>> 4031a2: f0 0f b1 55 40 lock cmpxchg %edx,0x40(%rbp)
>>> 4031a7: 74 06 je 4031af
>>> 4031a9: 89 c0 mov %eax,%eax
>>> 4031ab: f0 87 45 40 lock xchg %eax,0x40(%rbp)
>>>
>>> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This
>>> shouldn't happen given that cmpxchg modifies the value of %%eax.
>>>
>>> Any idea whether this should be considered a bug and reported as such?
>>
>> Look for "earlyclobber" in the section Constraint Modifier Characters
>>
>> Andrew.
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 11:22 ` Andrew Haley
@ 2008-02-15 11:31 ` Martin Sustrik
2008-02-15 11:44 ` Andrew Haley
0 siblings, 1 reply; 9+ messages in thread
From: Martin Sustrik @ 2008-02-15 11:31 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc-help
Andrew Haley wrote:
> Please don't top-post.
>
> Martin Sustrik wrote:
>> Andrew,
>>
>> Thanks for prompt response. However, I am not sure how to use the
>> earlyclobber modifier - this is actually the first gcc inline asembly
>> code I've ever written.
>>
>> Do you mean that I should add '&' sign to every operand in input
>> operand list, or should I add the sign when using the operands or what?
>
> Use "=&a" on the first operand.
Ok, I've modified the code this way:
__asm__ volatile (
"lock; cmpxchgl %1, %3\n\t"
"jz 1f\n\t"
"mov %2, %%eax\n\t"
"lock; xchgl %%eax, %3\n\t"
"1:\n\t"
: "=&a" (oldval)
: "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
: "memory", "cc");
However, the generated code is exactly the same as before.
>
>>
>> The problem, AFAICS, is that cmpxchg modifies eax although eax is not
>> an explicit operand of the instruction. Therefore optimiser has no
>> idea that it is modified and acts as if it was unchanged :(
>>
>> Martin
>>
>> Andrew Haley wrote:
>>> Martin Sustrik wrote:
>>>> Hi all,
>>>>
>>>> I've encountered a problem with gcc inline assembly.
>>>>
>>>> Following code, when optimised with -O2 gives following machine code:
>>>>
>>>> __asm__ volatile (
>>>> "lock; cmpxchgl %1, %3\n\t"
>>>> "jz 1f\n\t"
>>>> "mov %2, %%eax\n\t"
>>>> "lock; xchgl %%eax, %3\n\t"
>>>> "1:\n\t"
>>>> : "=a" (oldval)
>>>> : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
>>>> : "memory", "cc");
>>>>
>>>> 4031a0: 31 c0 xor %eax,%eax
>>>> 4031a2: f0 0f b1 55 40 lock cmpxchg %edx,0x40(%rbp)
>>>> 4031a7: 74 06 je 4031af
>>>> 4031a9: 89 c0 mov %eax,%eax
>>>> 4031ab: f0 87 45 40 lock xchg %eax,0x40(%rbp)
>>>>
>>>> Note that %2 maps to %%eax (mov %2, %%eax --> mov %eax,%eax). This
>>>> shouldn't happen given that cmpxchg modifies the value of %%eax.
>>>>
>>>> Any idea whether this should be considered a bug and reported as such?
>>>
>>> Look for "earlyclobber" in the section Constraint Modifier Characters
>>>
>>> Andrew.
>>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 11:31 ` Martin Sustrik
@ 2008-02-15 11:44 ` Andrew Haley
2008-02-15 12:05 ` Martin Sustrik
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Haley @ 2008-02-15 11:44 UTC (permalink / raw)
To: Martin Sustrik; +Cc: gcc-help
Martin Sustrik wrote:
> Andrew Haley wrote:
>> Please don't top-post.
>>
>> Martin Sustrik wrote:
>>> Andrew,
>>>
>>> Thanks for prompt response. However, I am not sure how to use the
>>> earlyclobber modifier - this is actually the first gcc inline asembly
>>> code I've ever written.
>>>
>>> Do you mean that I should add '&' sign to every operand in input
>>> operand list, or should I add the sign when using the operands or what?
>>
>> Use "=&a" on the first operand.
> Ok, I've modified the code this way:
>
> __asm__ volatile (
> "lock; cmpxchgl %1, %3\n\t"
> "jz 1f\n\t"
> "mov %2, %%eax\n\t"
> "lock; xchgl %%eax, %3\n\t"
> "1:\n\t"
> : "=&a" (oldval)
> : "r" (thenval_), "r" (elseval_), "m" (value), "0" (0)
Ah, maybe I told you wrong: I see that Opernad 0 is also an input. Sorry.
> : "memory", "cc");
>
> However, the generated code is exactly the same as before.
I certainly don't get that. Please post a complete test case, with
assembly output. We also need to know exactly your version of gcc.
Andrew.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 11:44 ` Andrew Haley
@ 2008-02-15 12:05 ` Martin Sustrik
2008-02-15 13:45 ` Andrew Haley
0 siblings, 1 reply; 9+ messages in thread
From: Martin Sustrik @ 2008-02-15 12:05 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc-help
>
> I certainly don't get that. Please post a complete test case, with
> assembly output. We also need to know exactly your version of gcc.
>
Sorry, I am not able to make a simple test case as I don't know how to
force gcc to inline the function that gets inlined in our product.
Without the inlining everything looks to compile without problems. Is
there any way to force inline?
Martin
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 12:05 ` Martin Sustrik
@ 2008-02-15 13:45 ` Andrew Haley
2008-02-15 14:37 ` Martin Sustrik
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Haley @ 2008-02-15 13:45 UTC (permalink / raw)
To: Martin Sustrik; +Cc: gcc-help
Martin Sustrik wrote:
>
>>
>> I certainly don't get that. Please post a complete test case, with
>> assembly output. We also need to know exactly your version of gcc.
>>
> Sorry, I am not able to make a simple test case as I don't know how to
> force gcc to inline the function that gets inlined in our product.
> Without the inlining everything looks to compile without problems. Is
> there any way to force inline?
Declare it inline and compile with -O ought to do it. GCC does not inline
any functions when not optimizing unless you specify the `always_inline'
attribute.
Andrew.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Should it be reported as a bug? (-O2 and cmpxchg instruction)
2008-02-15 13:45 ` Andrew Haley
@ 2008-02-15 14:37 ` Martin Sustrik
0 siblings, 0 replies; 9+ messages in thread
From: Martin Sustrik @ 2008-02-15 14:37 UTC (permalink / raw)
To: Andrew Haley; +Cc: gcc-help
Andrew,
Looks like earlyclobber solves the problem. I must have miscompiled the
thing before when testing it.
Thanks for your help!
Martin
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-02-15 14:37 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-15 10:56 Should it be reported as a bug? (-O2 and cmpxchg instruction) Martin Sustrik
2008-02-15 11:00 ` Andrew Haley
2008-02-15 11:21 ` Martin Sustrik
2008-02-15 11:22 ` Andrew Haley
2008-02-15 11:31 ` Martin Sustrik
2008-02-15 11:44 ` Andrew Haley
2008-02-15 12:05 ` Martin Sustrik
2008-02-15 13:45 ` Andrew Haley
2008-02-15 14:37 ` Martin Sustrik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).