Atomic::cmpxchg_ptr code duplication

[Paul Hohensee]

Wow.  That's a C/C++ language violation for 64-bit.  How does anything 
using intptr_t work?

Paul

Xiaobin Lu wrote:
> On Mac OS X, I believe intptr_t is typedefed as "int" on both 32 & 64 
> bit. So, sizeof(intptr_t) on 64 bit Mac OS is still 4 and size(void*) 
> is 8.
>
> -Xiaobin
> John Coomes wrote:
>> Paul Hohensee (Paul.Hohensee at Sun.COM) wrote:
>>  
>>> Sometimes compilers don't inline all the way through a call stack,
>>> i.e., they may have limits on inlining depth.  It's not a matter for
>>> the preprocessor, since we're talking methods, not macros.
>>>
>>> Assembly code template are things like gcc asm statements or
>>> .il functions.  Doesn't matter which.  What matters is whether the
>>> compiler actually inlines the asm code where you want it.
>>>     
>>
>> That's the kind of thing I was actually wondering about, along with
>> portability--consolidating them only works if sizeof(void*) ==
>> sizeof(intptr_t) on every platform.  They're the same on the platforms
>> SE supports, but maybe there are some oddball embedded platforms
>> around.
>>
>> -John
>>
>>  
>>> Christian Thalinger wrote:
>>>    
>>>> On Thu, 2009-04-02 at 09:54 -0400, Paul Hohensee wrote:
>>>>        
>>>>> If the platform-dependent versions are assembly code templates, then
>>>>> it's likely at some point that the C++ compiler(s) didn't inline
>>>>> properly
>>>>> using your suggested code.  I haven't looked in awhile, but I'm 
>>>>> pretty
>>>>> sure there
>>>>> are some places that use your style of code and others that don't for
>>>>> because of that.
>>>>>             
>>>> Hmm, not sure I understand.  AFAIK it makes no difference for inlining
>>>> in what header file the inline is defined, as long as both are 
>>>> included
>>>> and the compiler (preprocessor) finds it.  Or do you mean something
>>>> different by "assembly code templates", like .il files?
>>>>
>>>> -- Christian
>>>>
>>>>         
>>
>>   
>