Thanks for the review.
Here's the updated patch.

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
>