From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86680 invoked by alias); 18 Jan 2019 20:10:12 -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 86637 invoked by uid 89); 18 Jan 2019 20:10:11 -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=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=minimizing, H*r:8.14.5, H*Ad:U*jit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mx.sdf.org Received: from mx.sdf.org (HELO mx.sdf.org) (205.166.94.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Jan 2019 20:10:10 +0000 Received: from sdf.org (IDENT:akrl@sverige.freeshell.org [205.166.94.5]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id x0IK9tRT008641 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits) verified NO); Fri, 18 Jan 2019 20:09:56 GMT Received: (from akrl@localhost) by sdf.org (8.15.2/8.12.8/Submit) id x0IK9tZQ025074; Fri, 18 Jan 2019 20:09:55 GMT From: akrl To: Marc =?utf-8?Q?Nieper-Wi=C3=9Fkirchen?= Cc: dmalcolm@redhat.com, basile@starynkevitch.net, jit@gcc.gnu.org Subject: Re: about header file parsing In-Reply-To: (message from Marc =?utf-8?Q?Nieper-Wi=C3=9Fkirchen?= on Sun, 13 Jan 2019 21:24:35 +0100) Date: Tue, 01 Jan 2019 00:00:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2019-q1/txt/msg00045.txt.bz2 Marc Nieper-Wi=C3=9Fkirchen writes: > Am So., 13. Jan. 2019 um 20:56 Uhr schrieb akrl : > > [...] > >> Hi Marc, >> there's no technical problem into including these into the patch. >> But unless we have some special reason for that (like minimizing >> LIBGCCJIT_ABI changes) I would rather prefer to have this changes as a >> following patch. >> But I guess is good to have Dave's opinion on all of these points. > > Indeed. What is the general policy with respect to the ABI version? > One version bump per patch/feature or one version bump per release > cycle? > > [...] > > Best, > > Marc > Okay I've submitted the patch for exposing gcc_jit_context_add_driver_optio= n. If Dave's agree on the idea of the modification I'll have a following patch for exposing invoke_embedded_driver and invoke_external_driver after the review process of the first is done. Bests Andrea --=20 akrl@sdf.org