From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47672 invoked by alias); 9 Jan 2019 15:43:19 -0000 Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: jit-owner@gcc.gnu.org Received: (qmail 47653 invoked by uid 89); 9 Jan 2019 15:43:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1544, admit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 09 Jan 2019 15:43:17 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 16C99A8BB; Wed, 9 Jan 2019 15:43:16 +0000 (UTC) Received: from ovpn-116-42.phx2.redhat.com (ovpn-116-42.phx2.redhat.com [10.3.116.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7B4265D9D1; Wed, 9 Jan 2019 15:43:15 +0000 (UTC) Message-ID: <1547048594.7788.120.camel@redhat.com> Subject: Re: about header file parsing From: David Malcolm To: Basile Starynkevitch , akrl Cc: jit@gcc.gnu.org Date: Tue, 01 Jan 2019 00:00:00 -0000 In-Reply-To: <85568212-cec8-f8c8-2941-8db5d19e2989@starynkevitch.net> References: <85568212-cec8-f8c8-2941-8db5d19e2989@starynkevitch.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 09 Jan 2019 15:43:16 +0000 (UTC) X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00023.txt.bz2 On Wed, 2019-01-09 at 16:13 +0100, Basile Starynkevitch wrote: > On 1/9/19 4:03 PM, akrl wrote: > > Sorry I try to explain it better. > > I was thinking to a gcc plugin (or potentially something else) > > that > > given a C file produce the libgccjit code necessary to fill a > > context > > with what is in the source file. > > That could not work in general, because C has macros (think of the > `EOF` > macro constant in ``) that have no equivalent in libgccjit. Although possibly not working "in general" I think it could work for most important cases. A macro in C typically can be handled as either a client-side function invocation in libgccjit, or as a libgccjit function. For example, CPython has various reference-counting macros: #define Py_XDECREF(op) do { if ((op) == NULL) ; else Py_DECREF(op); } while (0) and in my "coconut" JIT-compiler for CPython I implement this as a libgccjit function: https://github.com/davidmalcolm/coconut/blob/master/coconut/compiler.py #L501 (effectively treating it as a static inline function). > And > in practice C macros are very important (and a lot of API for C are > using macros, see also macros such as WIFEXITED in wait(2) on some > Linux > system). > > We have to admit that C and libgccjit are different "languages" (even > if > conceptually very close). And a C API is not exactly a set of > "objects" > that libgccjit can handle. They're not the same, but it is important that libgccjit be able to interoperate well with C APIs. Dave