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 28BCA3858034 for ; Mon, 24 Jan 2022 22:56:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 28BCA3858034 Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-632-vMQmtzDmM7aMLRdI6Zso_A-1; Mon, 24 Jan 2022 17:56:00 -0500 X-MC-Unique: vMQmtzDmM7aMLRdI6Zso_A-1 Received: by mail-qk1-f200.google.com with SMTP id q5-20020a05620a0d8500b004738c1b48beso13420390qkl.7 for ; Mon, 24 Jan 2022 14:56: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:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=moyVKHV4A2lDhUgRhhxLcFd4yKGxGa+wC+i6W/ywUEk=; b=ILWqFymDDLyBejhCeSul0rcpQJwsa8TR1Wy8kVrphqY9rGp5O37jbQGp0xAcbnFwSp cEWzEhuyO0tTYKZxszQ6uO6y4TP/5BIHNUqq/8V/qRMOqAE1XZT8LuFUy19N017sMhZt Tg0X2wdnRgcPKwiltOruB7lWRLfohaehBFxtHxzQUB8QLus2EKxwqyERcjhTu+4YHoIf Fxw0/SIwYnVpSfdQE+hrm6z1c0O8rD0/ZHAB3mP7rDtYiczsKAmBn/55glq2Ww0DAkiY UNON4A8jU/pkQUQpgMdBVYzif+hQ16naM+kPmeZImqBnzrahm+amqPkl8X+jWtwETQju jriw== X-Gm-Message-State: AOAM533MML9NZHRX//50+PErqdg7iZzRhD/8PLjb4MUssZf0F8HzWirZ nfx0bNm/dpK1qo+jrzI+c6XcZnrN0Qr9y0CyMhP6k5fdRZDE1xYGC6c8Lf8msqdXCxLESyqgvle 9Bj75CXA= X-Received: by 2002:a05:6214:e6e:: with SMTP id jz14mr17055793qvb.4.1643064959785; Mon, 24 Jan 2022 14:55:59 -0800 (PST) X-Google-Smtp-Source: ABdhPJxWvzb3u4R4Pecl5MFyUN6XWkOTr7dVP78ym84h/5EBUYCVP0RdkTWi/2UQulBJ7uY8QiG04w== X-Received: by 2002:a05:6214:e6e:: with SMTP id jz14mr17055781qvb.4.1643064959520; Mon, 24 Jan 2022 14:55:59 -0800 (PST) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id k6sm481880qko.68.2022.01.24.14.55.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Jan 2022 14:55:58 -0800 (PST) Message-ID: <03e2dd0e58fb432f879cb6e76adf169a3ff2201e.camel@redhat.com> Subject: Re: [PATCH] libgccjit: Add option to hide stderr logs [PR104073] From: David Malcolm To: Antoni Boucher , gcc-patches@gcc.gnu.org, jit@gcc.gnu.org Date: Mon, 24 Jan 2022 17:55:57 -0500 In-Reply-To: References: <26928da47b7f5cbcef6c9db31221fe59a83ef4b2.camel@zoho.com> <0138b8a2502e17b43b66915015147ec9f9594ff4.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.5 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable 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, 24 Jan 2022 22:56:04 -0000 On Sun, 2022-01-23 at 12:34 -0500, Antoni Boucher wrote: > Thanks for the review. > Here's the updated patch. Tnanks. The updated patch looks good to me, but we need to get release manager approval for adding stuff in stage 4; I'll email them when I've looked at the other pending patches. Dave > > Le mardi 18 janvier 2022 à 18:22 -0500, David Malcolm a écrit : > > On Mon, 2022-01-17 at 21:02 -0500, Antoni Boucher via Gcc-patches > > wrote: > > > Hi. > > > This option will be useful for rustc_codegen_gcc to hide the > > > error > > > about unsupported 128-bit integer types. > > > > > > David, if you know of a better way to check if these types are > > > supported than creating such a type and checking if it causes an > > > error, > > > I will not need this patch. > > > > Off the top of my head I don't know of such a way. > > > > That said, this seems to be vaguely analogous to a test in a > > "configure" script, attempting a compile and seeing if it succeeds. > > > > This seems like a useful pattern for libgccjit to support, so that > > client code can query the capabilities of the host, so I think the > > idea > > of this patch is sound. > > > > As for the details of the patch, I don't like adding new members to > > the > > enums in libgccjit.h; I prefer adding new entrypoints, as the > > latter > > gives a way to tell if client code uses the new entrypoint as part > > of > > the ELF metadata, so that we can tell directly that client code is > > incompatible with an older libgccjit.so from the symbol metadata in > > the > > built binary. > > > > So I'd prefer something like: > > > >   extern void > >   gcc_jit_context_set_bool_print_errors_to_stderr (gcc_jit_context > > *ctxt, > >                                                    int enabled); > > > > where gcc_jit_context_set_bool_print_errors_to_stderr defaults to > > true, > > but client code can use: > > > >   gcc_jit_context_set_bool_print_errors_to_stderr (ctxt, false); > > > > Or maybe have a way to specify the FILE * for errors to be printed > > to, > > defaulting to stderr, but settable to NULL if you want to suppress > > the > > printing?  That might be more flexible. > > > > Thoughts? > > Dave > > >