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. 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 > > >
