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 EA4153857806 for ; Tue, 12 Apr 2022 21:48:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EA4153857806 Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-422-HxLZAnNWPbWI-eE_TyW5Jg-1; Tue, 12 Apr 2022 17:48:08 -0400 X-MC-Unique: HxLZAnNWPbWI-eE_TyW5Jg-1 Received: by mail-qt1-f197.google.com with SMTP id s17-20020a05622a1a9100b002ed3cb8acb3so71049qtc.10 for ; Tue, 12 Apr 2022 14:48:08 -0700 (PDT) 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=xVtfjx+nGcB+445/5KrPKEUbyfNXBDT4WfHWkwkr4hM=; b=2nkVBK7Tn5UU+zRCkbz6UdYRzowkWbLnqAKGtOPXajEo0Lz/Hc75OjzW6rTwTuZIAx ALr2W+0w5sUQE5nHHzzSmVneUs/rn455l4KQDZC5vDb+w4F5h5vRu7syAPOzK3nFDgza MZONIqnqQEtvKz2QQiXDsuROZngsC7ewhN6eGFhOforPOpGj3KsIVJK3EzFq0VAzjDBm ffR8kJ007bm+BbSUGyeDiMUh7cOQfRnT2jsSCK2ZkNGq5CkTKYkDW16prfWY0KyeocdX OEul5aQqsO4uRw+vz6Z+lDbyjNUtYWSLaknm6XT117ddDB9L+jcFSDI9wdfe97zSBlen b1fA== X-Gm-Message-State: AOAM531/AJvxVnaMVAgS2VmW8vxrXhnolXLMK5RjHndOGoIQHi/KFOqJ HHwUdixd9cnfA6PG2xN/gl9DQnZ83NM2QORosFOWRnDKAQA6pgNIswgIfEv7xBZlQp5CQEH/JUY ym80itxU= X-Received: by 2002:ad4:4832:0:b0:444:2d0d:6fa6 with SMTP id h18-20020ad44832000000b004442d0d6fa6mr16949601qvy.70.1649800087817; Tue, 12 Apr 2022 14:48:07 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMU7TEmhUmlYb7oKq2iR+Jik5iFZmlhxnNaNwfyNtLyIFiLQeBPTWOqBKD5OocpMJQ/E/W4g== X-Received: by 2002:ad4:4832:0:b0:444:2d0d:6fa6 with SMTP id h18-20020ad44832000000b004442d0d6fa6mr16949594qvy.70.1649800087577; Tue, 12 Apr 2022 14:48:07 -0700 (PDT) Received: from t14s.localdomain (c-73-69-212-193.hsd1.nh.comcast.net. [73.69.212.193]) by smtp.gmail.com with ESMTPSA id y7-20020a05620a0e0700b00699a30d6d10sm19911123qkm.111.2022.04.12.14.48.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 14:48:07 -0700 (PDT) Message-ID: <93c7aabf5c294d4deef1847dcddf53d590a6d028.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: Tue, 12 Apr 2022 17:48:05 -0400 In-Reply-To: <03e2dd0e58fb432f879cb6e76adf169a3ff2201e.camel@redhat.com> References: <26928da47b7f5cbcef6c9db31221fe59a83ef4b2.camel@zoho.com> <0138b8a2502e17b43b66915015147ec9f9594ff4.camel@redhat.com> <03e2dd0e58fb432f879cb6e76adf169a3ff2201e.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, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, 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: Tue, 12 Apr 2022 21:48:11 -0000 On Mon, 2022-01-24 at 17:55 -0500, David Malcolm wrote: > 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. I updated the patch slightly: * fixed a copy&paste typo in the comment for LIBGCCJIT_HAVE_gcc_jit_context_set_bool_print_errors_to_stderr * regenerated .texinfo from .rst Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. I've pushed the patch to trunk for GCC 12 as r12-8119-g79e1a6fb9babb3. https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=79e1a6fb9babb34dfcb99964c37d3c4f8bb619ca Thanks again for the patch Dave > > 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 > > > > > > >