[m-dev.] Compiling with LLVM-GCC

[Magnus Holm]

On Sun, Aug 7, 2011 at 17:48, Mark Brown <mark at csse.unimelb.edu.au> wrote:
> Hi Magnus,
>
> On 07-Aug-2011, Magnus Holm <judofyr at gmail.com> wrote:
>> I'm trying to build Mercury with LLVM-GCC (which ships with Xcode 4):
>>
>>   gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)
>>
>> The beta fixes one problem with Boehm GC, but now I'm getting other errors:
>>
>>   tree234.c:598: error: initializer element is not constant
>>   tree234.c:598: error: (near initialization for ?mercury_common_1[0].f2?)
>>   ?
>>
>> This seems to be related with the definition of MR_mkword in
>> runtime/mercury_tags.h:
>>
>>   #define    MR_mkword(t, p) ((MR_Word *)((char *)(p) + (t)))
>>
>> Both p and t are integers here, and therefore (char *)(p) is
>> implementation-defined behaviour.
>
> Yes.  The configure script performs tests to determine which variants of the
> operations in question are safe for a given implementation (or it should).
> If you search for tag_bits in configure.in you should find the relevant parts.
>
>> I tried to change it to ((MR_Word *)((p) +
>> (t))) which makes it compile fine, but then I'm getting segfaults at runtime
>> (I assume this is because the MR_word points to the wrong address). What
>> exactly are you trying to do here?
>
> Despite what the C compiler is told, p is an aligned pointer.  This
> generally means there are 2 or 3 low bits that are always 0, and t
> is a tag value that occupies these bits when added to p.  It is cast
> to a byte-sized pointer (char *) so that the pointer addition works
> like normal addition.
>
> The approach, and the mkword operation, are described in this paper:
>
> <http://www.mercury.csse.unimelb.edu.au/information/papers.html#jlp>
>
>> Any way to do it without casting integers
>> to pointers (which is implementation-defined behaviour)?
>
> According to the comment just above the definition, no.  It will eventually
> be cast to (MR_Word *).  And it's naturally going to be implementation-
> defined, since the point of it is to generate code that is appropriate
> for the particular target platform.  ;-)

Hm… So it's not possible to compile Mercury with LLVM-GCC at all?

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at csse.unimelb.edu.au
Administrative Queries: owner-mercury-developers at csse.unimelb.edu.au
Subscriptions:          mercury-developers-request at csse.unimelb.edu.au
--------------------------------------------------------------------------