Hi David!
With your last patch, it will now silently ignore the target buitins
that have an unsupported type.
Would you be OK that I add a boolean option that, if set to true, would
instead abort to show the error?
I would find this useful to add the support for new types when there are
new bu
Le 2025-01-23 à 13 h 13, David Malcolm a écrit :
On Wed, 2025-01-22 at 08:47 -0500, Antoni Boucher wrote:
Hi David.
Hi Antoni
I went ahead and pushed this patch since without it even simple unit
tests like test-factorial.c were failing for me on aarch64; in
particular, the build of emacs w
On Wed, 2025-01-22 at 08:47 -0500, Antoni Boucher wrote:
> Hi David.
Hi Antoni
I went ahead and pushed this patch since without it even simple unit
tests like test-factorial.c were failing for me on aarch64; in
particular, the build of emacs was failing in Fedora's mass rebuild
with gcc 15, and t
Hi David.
I had a patch for this here: https://github.com/antoyo/libgccjit/pull/20
The fact that you removed the debug_tree (and abort) will make it harder
to figure out what the missing types to handle are.
This will also probably make it hard for people to understand why they
get a type error
libgccjit fails on startup on aarch64 (and probably other archs).
The issues are that
(a) within jit_langhook_init the call to
targetm.init_builtins can use types that aren't representable
via jit::recording::type, and
(b) targetm.init_builtins can call lang_hooks.decls.pushdecl, which
although
