Latest repo fails to build on OS X

[Kelly O'Hair]

I don't think anyone can assume that intptr_t will be defined to int32_t or int64_t,
it's only requirement is to be able to hold a pointer.

Seems like a nasty problem, and if the OpenJDK sources are depending on intptr_t
being the same type as int32_t or int64_t,
I have to agree that it should be treated as an OpenJDK bug.

I think this should go to the hotspot-dev at openjdk.java.net alias, make sure
you include the trace:

/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp: In member function 
'void InterpreterMacroAssembler::empty_expression_stack()':
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/interp_masm_x86_32.hpp:123: error: call of 
overloaded 'movptr(Address, int)' is ambiguous
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2010: note: candidates 
are: void MacroAssembler::movptr(Address, intptr_t)
/Users/mfranz/developer/openjdk-bsd/repos/2008-11-27/hotspot/src/cpu/x86/vm/assembler_x86.hpp:2012: note: 
   void MacroAssembler::movptr(Address, RegisterImpl*)
make[6]: *** [incls/_precompiled.incl.gch] Error 1
make[5]: *** [the_vm] Error 2
make[4]: *** [product] Error 2
make[3]: *** [generic_build2] Error 2
make[2]: *** [product] Error 2
make[1]: *** [hotspot-build] Error 2
make: *** [build_product_image] Error 2

-kto

Greg Lewis wrote:
> On Sun, Nov 30, 2008 at 08:30:06AM -0500, Michael Franz wrote:
>>> All we have since then are merges from the main OpenJDK repository.
>>>
>>> In reference to your follow ups, I can build the code on both FreeBSD/i386
>>> and FreeBSD/amd64, so that covers both 32 bit and 64 bit platforms.
>>>
>>> I also see from your followups that Mac OS X is 32 bit, so this code will
>>> end up being
>>>
>>> movl(dst, src);
>>>
>>> no matter which variant the compiler picks.  It should pick the intptr_t
>>> version though.  In fact, on FreeBSD/i386 intptr_t is typedef'ed to
>>> int32_t, so these are the same.
>>>
>>> I wonder how intptr_t is defined on Mac OS X and what version of gcc is
>>> being used?  You could try changing the cast to (intptr_t) instead of
>>> (int32_t), since it should basically be the same.
>>>
>> Based on what is in <stdint.h> int32_t is a signed int and intptr_t is an
>> signed long.  Apple is using gcc 4.0.1.
>>
>> For the original issue I did change the cast from int32_t to intptr_t and it
>> works, however, there are other issues that follow that related to the same
>> change.  I could go through and change all the places it breaks, but there
>> must be and easier fix.
> 
> I agree.  The root problem appears to be the assumption that on 32 bit
> platforms intptr_t and int32_t are typedef'ed to the same thing.  This
> is clearly not the case on Mac OS X.  This is something I'd like to take
> up on the main OpenJDK list since its not BSD specific (it just happens
> that it only breaks on one of our supported OSes).
> 
> I'll try and find time to send out an email tonight.
>