[m-dev.] Compiling with LLVM-GCC

Mark Brown mark at csse.unimelb.edu.au
Mon Aug 8 01:48:48 AEST 2011


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.  ;-)

Cheers,
Mark.

--------------------------------------------------------------------------
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
--------------------------------------------------------------------------



More information about the developers mailing list