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.129.124]) by sourceware.org (Postfix) with ESMTPS id 570C43858037 for ; Tue, 18 Jan 2022 23:22:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 570C43858037 Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-5-ehg7XVZHOsyZBrBMrIy5wA-1; Tue, 18 Jan 2022 18:22:46 -0500 X-MC-Unique: ehg7XVZHOsyZBrBMrIy5wA-1 Received: by mail-qk1-f198.google.com with SMTP id b189-20020a3780c6000000b0047b06f34f4cso513904qkd.17 for ; Tue, 18 Jan 2022 15:22:46 -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=mHZBcGWS+SksEFp4Do2a5kmIA+ITntNAKqOl5VFmvac=; b=TKqsItNzoka3N0+eyBX7UJ5SakCpmwsXYKdvztPLLJ+KrQgCaWAV0qTs6XyxG+gnn/ luFx14cvlsX6z042afwJqLib2CYhos85f4a3dvbKmDXmFY7G1nYbFsVja5G6cT4ZJB6c OuzXQhQL3iIQDuYNpx3NY5V0NGMOuf8aXDgKyFmL7R/If1pFsBBLTk5T9wv1mY037Xv9 P89lP+u4pHmUdOKVEfUmUmlsuq2d/EnN5LgQ1Sita+QvI7cN7nOFLzGE3hv4rjzejKTU zq2kjEUS+xgvzJcBFBSfsYPpoeRBKgTBCUQXcEKjSektuFB3C0evE0sxISxLc+/0iQCo XbLw== X-Gm-Message-State: AOAM5302GtYrF0H7VsU1VzUeLJfwnuPjcHXvbLrs0oC+njLGFh3CqAh4 xHU572439wsAGzBqlNbS6z4wSwyW5WRAnP5lRFiQZk/qGkG7/PuxjUrz0QkmZSErNx6bdrceFr6 O0NzNXlQ= X-Received: by 2002:a05:622a:178e:: with SMTP id s14mr22370929qtk.302.1642548165783; Tue, 18 Jan 2022 15:22:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwjDlWBTPuIgKDgR9oRN9OliDpC8Eq2W60YYny3G3+8K1C1PNJJHwxWZFEHNFvBln0XJRkVRg== X-Received: by 2002:a05:622a:178e:: with SMTP id s14mr22370920qtk.302.1642548165600; Tue, 18 Jan 2022 15:22:45 -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 k3sm3430045qta.64.2022.01.18.15.22.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 18 Jan 2022 15:22:44 -0800 (PST) Message-ID: <0138b8a2502e17b43b66915015147ec9f9594ff4.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, 18 Jan 2022 18:22:43 -0500 In-Reply-To: <26928da47b7f5cbcef6c9db31221fe59a83ef4b2.camel@zoho.com> References: <26928da47b7f5cbcef6c9db31221fe59a83ef4b2.camel@zoho.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: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, 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: Tue, 18 Jan 2022 23:22:51 -0000 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