From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by sourceware.org (Postfix) with ESMTPS id 7E15B3858D28 for ; Fri, 3 Dec 2021 15:47:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E15B3858D28 Received: by mail-yb1-xb33.google.com with SMTP id x32so10420547ybi.12 for ; Fri, 03 Dec 2021 07:47:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EasrYR5t5jYIjf7FE/ixkhJ208xagsj6Sle9lV/a+1w=; b=4YO4RcxoJPxP7wVVjPuA9irTF7m9ugiW1EGcb/cSDskET00vA5Jb2Yz6F0MdrG4gx8 jAzMRg0a5RMAQ6DyWIpczX8DtFAz39ANtK5a6ZsRkkx+T9GJ68Qit5eHadYpc6hRKnI5 a/57T++UKKcBETKi2sw4PsGWnZ4AVNUfW1pOM2CtHnCW3GYNwrBKWzxhqnibYxuMf0Hk tjVQmKtAhN5HSqVEXltYg/3D1pM0t9HGRSHYRQDZ2XeATQJgpnVtRoa3fxs9uw7xuW2K Xh8XlqemVd6/Klb3u71c1b3MIYnNGznTHlyZNj4uGSBDyRnO18iLD2Xdh08gGn0d9XAH oz6w== X-Gm-Message-State: AOAM530IRngvEqvOWcyB/DMkHdmm2jiOnGac1+2c9prBGRrEVPoWGwXi TDUtiZ49RfBTMeTXITx+YBijgHRomepqyK9THH0= X-Google-Smtp-Source: ABdhPJwXjkiUT+hTvXyl7exCEpFmeZS9PI5zPrNa0miwErwj9IEUdvFfQIXMQKIy1ec8tW+MEyHirgGrLk2VSKUVB+4= X-Received: by 2002:a25:2945:: with SMTP id p66mr16701401ybp.559.1638546443940; Fri, 03 Dec 2021 07:47:23 -0800 (PST) MIME-Version: 1.0 References: <1546448170.7788.10.camel@redhat.com> In-Reply-To: From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Fri, 3 Dec 2021 16:47:12 +0100 Message-ID: Subject: Re: Conversion of pointers to integers and vice versa; pointer tagging To: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Cc: David Malcolm , jit@gcc.gnu.org X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, FREEMAIL_REPLY, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2021 15:47:26 -0000 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=C3=9Fkirchen < 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=C3=9Fkirchen 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 =C3=A0 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 > >