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
