From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb30.google.com (mail-yb1-xb30.google.com [IPv6:2607:f8b0:4864:20::b30]) by sourceware.org (Postfix) with ESMTPS id 97AC6385802D for ; Mon, 31 Jan 2022 15:09:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 97AC6385802D Received: by mail-yb1-xb30.google.com with SMTP id i10so41330288ybt.10 for ; Mon, 31 Jan 2022 07:09:03 -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=wTJzpeKFTcmj4a3wVlfwn9JQcYip8ck8nKnHwRvrLrs=; b=pjnH7IHzijGZIQkaJPV/slf1vtxnLP+sCKclDAgHcKnC/VDJxfHxJnSpZQ7qHHYm9c 79wsOACsGS0kla9UQxlvNvUsdmmOo/bhKaqVXta4UXoIEB9dAB6Sv3ThioQbsRIUQmvp 2Twr81/vwVI8U0OD6/sdtdZDx+aUiv7PRj5qPC1NlZgThYr3jKo73hc4oVsVIMqU7US+ finksBrPQj2OI0id3tOV8apu786rtTdVbXjhCQOf34fbxQysyPtfCThzugn/+98cdYKl FseVPbhEU20V37EdXzEmHdnNucFfll515AiPEzzEHJjIH6uVNQM0dd7sSytD0S0BH7G3 VMDQ== X-Gm-Message-State: AOAM532jMeUj5IaBocN1gSmxoJUuOlAgKe/B73Oc4AqAiS9Tkgpjq6IJ iJT55x6uD3brdYp/mSk7U360R/yU/K2Z94j4suk= X-Google-Smtp-Source: ABdhPJzOpmRpl2wQgXz+AMA4HC0DchyNxC8Mc5JKn2il/Ftze3vBFZN5v+/rw45z/VrrOenDh9u+QAXEK/El5pPutMQ= X-Received: by 2002:a05:6902:565:: with SMTP id a5mr18606635ybt.211.1643641742958; Mon, 31 Jan 2022 07:09:02 -0800 (PST) MIME-Version: 1.0 References: <1e83575c7d369fa96844b551f8606922fc8e0627.camel@redhat.com> In-Reply-To: <1e83575c7d369fa96844b551f8606922fc8e0627.camel@redhat.com> From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Mon, 31 Jan 2022 16:08:51 +0100 Message-ID: Subject: Re: C++ API: Vector arguments / error detection To: David Malcolm Cc: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= , =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen_via_Jit?= X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Mon, 31 Jan 2022 15:09:05 -0000 Am Mo., 31. Jan. 2022 um 15:49 Uhr schrieb David Malcolm < dmalcolm@redhat.com>: > On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wi=C3=9Fkirchen via Jit > wrote: > > This is about two unrelated issues regarding the C++ API: > > > > (1) At the moment, a lot of API functions like new_function take non- > > const > > referenced to vectors, e.g. std::vector ¶ms; > > > > Can we change this into const references? This way, one can write > > > > auto param1 =3D ctxt.new_param (...); > > auto param2 =3D ctxt.new_param (...); > > auto func =3D new_function (..., {param1, param2}, ...); > > > > instead of the more complicated and less convenient > > > > auto param1 =3D ...; > > auto param2 =3D ...; > > auto params =3D std::vector {param1, param2}; > > auto func =3D new_function (..., params, ...); > > I wonder why they're not const already - maybe I just forgot? > > Making the refs const sounds like a good idea to me. > The reason why you didn't make them const may be that the C API that is called takes non-const arrays of pointers. The latter is probably a good idea because of the const model in C and the const-cast restrictions. But when the C API doesn't change the arrays, all that is needed is a const_cast <...> (...) in the C++ API implementation. If you can confirm the former, I can do the latter. > > > > (2) When using gccjit::context::compile_to_file, how can I check > > whether > > the compilation succeeded without errors or not? In libgccjit++.h no > > error > > is checked and no exception thrown. > > Looks like I forgot to: > (a) give a return value to gcc_jit_context_compile_to_file, and > (b) add C++ bindings for gcc_jit_context_get_first_error and > gcc_jit_context_get_last_error. > > Looks like fixing (a) would be an ABI break, bother (perhaps we could > add a revised gcc_jit_context_compile_to_file symbol and do it with > symbol versioning) > A workaround would be to check that the context is without an error before the context to gcc_jit_context_compile_to_file and then to check afterward again, right? If this is true, a return value (while nice) is not absolutely necessary and an ABI break would not be needed. (By the way, is changing the return type from void to int, say, an ABI break on any platform? The C++ API could throw an error whenever there is an error in the context after compiling. > With those in place, it looks like either the client code needs to > check gcc::jit::context::get_last_error on failure, or, better, it > should probably change to look something like this (untested): > > inline void > context::compile_to_file (enum gcc_jit_output_kind output_kind, > const char *output_path) > { > if (gcc_jit_context_compile_to_file (m_inner_ctxt, > output_kind, > output_path)) > throw error (m_inner_ctxt); > } > > where error's ctor should call gcc::jit::context::get_last_error on the > ctxt, or something similar to this. > > > Sorry about the C++ API being much less polished that the C API. > There absolutely no need to excuse :). libgccjit is a great idea and piece of software. That's the nice thing about free software that people who need a more polished API can contribute. Marc