From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69148 invoked by alias); 8 Jan 2019 21:31:15 -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 68544 invoked by uid 89); 8 Jan 2019 21:30:42 -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,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_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: mail-wr1-f51.google.com Received: from mail-wr1-f51.google.com (HELO mail-wr1-f51.google.com) (209.85.221.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 08 Jan 2019 21:30:34 +0000 Received: by mail-wr1-f51.google.com with SMTP id u4so5569774wrp.3 for ; Tue, 08 Jan 2019 13:30:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=dYONL8XBm7qClW6mPm2QycDK7GPV01K83xX3InznHuQ=; b=Bd41nffebslRnbQlYABf3A/0uU8OuXKvinB2FWcmDdKA6h9gowSHe9TDzMF/P9omVY 3NxgfVcbk5dFOEgwfPf0wUr5KS6DjKG5YsmQlonl/QMmBo4gvOnylK+4u8fG3U02yOYr YJER2DlqG40rD1BQGEkQgiHhwCeTRoYLz3WEyeEGuuy/gYZ4ablTq5LfQKR9OjHXEKYC HZ50iLSBF2YTm20+vMtCZYf1E1Qwo2Kjgh55ATiNkSHrFubD/iaCkiFGYMff5V1ubMrs L8J7frrFMToDg2az/TckKA0tvItp7RKRholYReFxH5Z1mLLY4Pdo7Ocz9FS1pDLqJqg9 ClZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dYONL8XBm7qClW6mPm2QycDK7GPV01K83xX3InznHuQ=; b=fYe7jyTJ9Eh7uCBvFqy/YUIhRT9HlngQYfuvKV1Y6Hud+gWQYADm39fF/CUpR64mfm 23HVAoeKUezcGMTVqdev3OndA+r2x3dBr4GMdKEOZr+vWBPx5DzOObSpzay0HQEXNHpv rlfYfuqdbeLxRsdTo5NETELjutgaHZ6jMqZV+3eNJNhMeX53/xMozp3EgEMHPsqcReAl zukuZ3x0ouUeZ1tC6xuX0vaQDh5NevffD4gS8YICLHZbQ2oQHufnP3bSJtgw09zYvEdM Pz/IKy1GQXKcO73YrLKKpOvAkZRKA25CmVl29/BTDbuaN7WQY2DsBFNmO2m4gan1OURl Qyag== X-Gm-Message-State: AJcUukf1jozT8l4lxh0oRQEJ0FOLxZcElQleTISvSuhzpk9snywDrrqt Vm4encF99kALwx3duTyIhqMOvd+AEVY= X-Google-Smtp-Source: ALg8bN4IyFf38TPoKIh4ajMkh9BpT4Uzbdp6yf+2y60RKYCYuss0cYrx1hTjilfWm2/rBME9jWdDGg== X-Received: by 2002:adf:c505:: with SMTP id q5mr2680881wrf.84.1546983031601; Tue, 08 Jan 2019 13:30:31 -0800 (PST) Received: from ?IPv6:2a02:810d:340:25f8:46d:f2b2:3936:4d0a? ([2a02:810d:340:25f8:46d:f2b2:3936:4d0a]) by smtp.gmail.com with ESMTPSA id m193sm12000039wmb.26.2019.01.08.13.30.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Jan 2019 13:30:30 -0800 (PST) Subject: Re: about header file parsing To: Basile Starynkevitch , akrl@sdf.org, jit@gcc.gnu.org References: <0511991f924b445cad0467ad28fc8f45.squirrel@mx.sdf.org> From: =?UTF-8?Q?Marc_Nieper-Wi=c3=9fkirchen?= Message-ID: Date: Tue, 01 Jan 2019 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00013.txt.bz2 Am 08.01.19 um 22:15 schrieb Basile Starynkevitch: > > On 1/8/19 11:50 AM, akrl@sdf.org wrote: >> Hi all, >> I have a basic question. >> Is there a way to ask libgccjit to parse a conventional .h file? > > I have asked a very similar question in > https://gcc.gnu.org/ml/jit/2015-q2/msg00093.html > >> Or alternatively is there a way to have an header file parsed and >> converted in the equivalent libgccjit api calls? >> I ask this because I noticed that, if you jit some code that have to >> inter-operate with non jitted code, maintaining two duplicated >> definitions >> of all data structures can be quite painful if these are not trivial. >> Alternatively what's the suggested work flow? > > I am not sure there is one yet, in practice. > > A possible work-around (not entirely trivial) might be to do the > "opposite": use GCC itself to parse the header file, and write your GCC > plugin extracting all the relevant information for your particular usage > of libgccjit. I have no idea how easy that can be for you. > > I am not even sure if all the features of C (including some common > extensions accepted by GCC) are usable from libgccjit. Perhaps bit > fields and computed gotos like `goto *ptr` and statement expressions > like `({int x=0; while (y>0) x+=f(y--); x;})` are not easily achievable > in libgccjit. > > > Still another thing could be to use LTO: you'll compile your C file with > GCC using -flto, you'll do LIBGCCJIT things, and the final executable > sould be compiled and linked with -flto. What would you do with macros defined in the header file that form part of the API? They won't be visible after compiling (already after preprocessing). -- Marc > > Cheers. >