llvm dev - Nov 2008 - [LLVMdev] Question about SPARC target status

On Nov 11, 2008, at 3:51 PM, Peter Shugalev wrote:
> Owen Anderson wrote:
>> If you configure it as a cross-compiler for 64-bit x86 Linux and  
>> feed it
>> the appropriate header files, it will produce the same output on any
>> platform.  However, that output will not be executable on most
>> platforms, just on 64-bit x86 Linux.  The problems go beyond pointer
>> size.  The size of int is implementation dependent, etc.  The  
>> layout and
>> padding of structs is implementation dependent.  While all
>> implementations on a given target-triple will generally agree to  
>> ensure
>> binary compatibility, there is no guarantee of things being the same
>> once you go to another target-triple.
>
> Do you mean that cross-target execution CAN break on examples like  
> this
> one? [eventually on this example it doesn't]
>
>   struct X {
>     void *a;
>     int b;
>   } x;
>
>   *(int *) ((char *)&x + sizeof(void*)) = 1;
>
What about something much simpler: memcpy'ing an array of structs  
around.  The number of bytes to be memcpy'd is dependent on the  
padding of the struct.

--Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2624 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20081111/1c65ef3d/attachment.bin>

Owen Anderson wrote:
> What about something much simpler: memcpy'ing an array of structs 
> around.  The number of bytes to be memcpy'd is dependent on the padding
> of the struct.
Anyway, I've got your point. sizeof() constant expression is calculated 
during wrong stage of compilation process. Thanks for pointing it out!


-- 
Best Regards
Peter Shugalev

On Nov 11, 2008, at 5:11 PM, Peter Shugalev wrote:
> Owen Anderson wrote:
>> What about something much simpler: memcpy'ing an array of structs
>> around.  The number of bytes to be memcpy'd is dependent on the  
>> padding
>> of the struct.
>
> Anyway, I've got your point. sizeof() constant expression is  
> calculated
> during wrong stage of compilation process. Thanks for pointing it out!
Yes, not to mention stuff like:

#ifdef __i386__

or:
  case sizeof(foo):

This is addressed here:
http://llvm.org/docs/tutorial/LangImpl8.html#targetindep

Note that this doesn't affect cross compilation: you just need to  
configure llvm-gcc as a proper cross compiler.  This just means that  
llvm won't magically make your C code portable for you.  Real portable  
languages don't suffer from these problems.

-Chris