Conversion of pointers to integers and vice versa; pointer tagging

[Marc Nieper-Wißkirchen]

Please excuse the noise. It was too late yesterday evening and so I missed
the API function gcc_jit_context_get_int_type. :)

Am Do., 2. Dez. 2021 um 22:10 Uhr schrieb Marc Nieper-Wißkirchen <
marc.nieper+gnu@gmail.com>:

> Am Mi., 2. Jan. 2019 um 17:56 Uhr schrieb David Malcolm <
> dmalcolm@redhat.com>:
>
>> On Tue, 2019-01-01 at 12:00 +0100, Marc Nieper-Wißkirchen wrote:
>> > Implementations of languages with garbage collection and dynamic
>> > typing often employ the concept of tagged pointers. Unused bits of a
>> > pointer representation are used to distinguish between pointers to
>> > different types or between pointers and immediate values.
>> >
>> > Implementing such a language with libgccjit raises a couple of
>> > questions:
>> >
>> > 1) libgccjit has currently only a limited set of type-casting
>> > expressions. In particular, there is no type-casting expression
>> > between an integer type (e.g. uintptr_t) and a pointer type defined.
>> >
>> > Are there technical reasons for that or is that just an area where
>> > libgccjit still has to be complemented?
>>
>> In general, I've chosen to require the user to explicitly supply any
>> casting that's needed, out of a desire to catch problems early.
>>
>> gcc_jit_context_new_cast only supports a few conversions.  IIRC this
>> was to simplify the internal implementation; perhaps more conversions
>> could be allowed.
>>
>> > I guess, a workaround could be to use union types à la
>> >
>> > union {
>> >   uintptr_t i;
>> >   void *p;
>> > }
>> >
>> > everywhere.
>>
>> That ought to work.
>>
>
> Please excuse resurrecting this thread, but it has occurred to me that I
> don't know how to create an integer type whose width is exactly the same as
> the one of a pointer using libgccjit. Wouldn't it make sense to add
> something like GCC_JIT_TYPE_UINTPTR_T or similar? Or am I supposed to use,
> say, Autoconf, to check the sizes of the provided types and choose one
> accordingly?
>
> Thanks,
>
> Marc
>
>