public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Antoni Boucher <bouanto@zoho.com>,
	gcc-patches@gcc.gnu.org, jit@gcc.gnu.org
Subject: Re: [PATCH] libgccjit: Add option to hide stderr logs [PR104073]
Date: Tue, 18 Jan 2022 18:22:43 -0500	[thread overview]
Message-ID: <0138b8a2502e17b43b66915015147ec9f9594ff4.camel@redhat.com> (raw)
In-Reply-To: <26928da47b7f5cbcef6c9db31221fe59a83ef4b2.camel@zoho.com>

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


  reply	other threads:[~2022-01-18 23:22 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-18  2:02 Antoni Boucher
2022-01-18 23:22 ` David Malcolm [this message]
2022-01-23 17:34   ` Antoni Boucher
2022-01-24 22:55     ` David Malcolm
2022-04-12 21:48       ` David Malcolm

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0138b8a2502e17b43b66915015147ec9f9594ff4.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=bouanto@zoho.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jit@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).