From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6C26F385BF9E for ; Mon, 31 Jan 2022 15:20:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6C26F385BF9E Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-250-BSVZ9nhfOjCZGni49NEqYw-1; Mon, 31 Jan 2022 10:20:01 -0500 X-MC-Unique: BSVZ9nhfOjCZGni49NEqYw-1 Received: by mail-qv1-f69.google.com with SMTP id e14-20020a0cf34e000000b0042623ad325aso8501376qvm.16 for ; Mon, 31 Jan 2022 07:20:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=ztpO5c04PnTEgMJPgmF8euBYogOgx3Cp8DR1h9VpoNI=; b=0T82mRJfjI+nkEnKWjm4QaMs7MeDpUbNqqSiF+3ylerDbUcDjoekUioCUoX5XrhWWl 2pcH+WXcUa2hho1KHy+HHkYrJv5C74aYF/JCIw/zL8wJzDOfcg2w83neCDVEJGpedI+7 D06bF1LHUfYctm2JHNW4Vh+nHek183RcqdZLWhpsAkt/nfhO53DaaJDT65nS/ycsjBbf hsivtE1YJ1puZXS8aB/V77A1iFWjPj8XL2KCP5qMTzRgEwCqKa0tczBBLKKgWeR4kaFh s2gj2CO506rRfGzuLhU8yvu7iKvJRXuuuARYBnLboaYeyKAX/x/7qBW9gBzl6CVsSql7 v8IA== X-Gm-Message-State: AOAM532owrayX+96IIxEYIAL/Hd+aBzU09JQ1n+YOJL5GCpvmIGTv4Bf yroaREgkYDyr8Dcw0nS+kl6Qe+BOry3YncutHdUNm8s3csd3+0BR3K3yQ1BZR7hrG8MHRReRYON yo0uH9SU= X-Received: by 2002:ac8:5c05:: with SMTP id i5mr15123908qti.569.1643642400034; Mon, 31 Jan 2022 07:20:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJwshZmnzdmRNQDhlOEHSSVODBsvAiTH8wvo8UydNS59DyYME9tQ9b2F7otldiQzt0779EJenQ== X-Received: by 2002:ac8:5c05:: with SMTP id i5mr15123885qti.569.1643642399751; Mon, 31 Jan 2022 07:19:59 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.ma.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id h6sm9533066qko.7.2022.01.31.07.19.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 31 Jan 2022 07:19:59 -0800 (PST) Message-ID: <78ed3281f7beec5f37be521f04ce44a8d8690867.camel@redhat.com> Subject: Re: C++ API: Vector arguments / error detection From: David Malcolm To: Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= Cc: Marc =?ISO-8859-1?Q?Nieper-Wi=DFkirchen?= via Jit Date: Mon, 31 Jan 2022 10:19:58 -0500 In-Reply-To: References: <1e83575c7d369fa96844b551f8606922fc8e0627.camel@redhat.com> User-Agent: Evolution 3.38.4 (3.38.4-1.fc33) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, 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 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:20:06 -0000 On Mon, 2022-01-31 at 16:08 +0100, Marc Nieper-Wißkirchen wrote: > 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ßkirchen 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 = ctxt.new_param (...); > > > auto param2 = ctxt.new_param (...); > > > auto func = new_function (..., {param1, param2}, ...); > > > > > > instead of the more complicated and less convenient > > > > > > auto param1 = ...; > > > auto param2 = ...; > > > auto params = std::vector {param1, param2}; > > > auto func = 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. Yeah, that was probably it. > > 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. Sounds like a good idea to me. > > > > > (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?   That could work. > 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? I'm not sure; I think I'm erring on the side of caution. > > The C++ API could throw an error whenever there is an error in the > context > after compiling. Sounds good. > > > > 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 Indeed. I was tempted to say "patches welcome", but that can come across as rather passive-aggressive :) Out of curiosity, are you using the C++ API for something, and would you like it on the "Who's using this code?" section on https://gcc.gnu.org/wiki/JIT ? Thanks Dave