Re: [External] : emacs-28 windows binaries available from alpha

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> Ping!
>
> Andrea, can you please look into this?

Hi Eli,

sorry if I missed this, this thread triggered numerous score rules in my
gnus since the beginning but after a while I assumed it did not required
my attention...

>> Date: Sat, 05 Feb 2022 12:10:34 +0200
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, drew.adams@oracle.com,
>>  emacs-devel@gnu.org
>> 
>> > Date: Sat, 05 Feb 2022 09:25:56 +0200
>> > From: Eli Zaretskii <eliz@gnu.org>
>> > Cc: dieter@duenenhof-wilhelm.de, corwin@bru.st, emacs-devel@gnu.org
>> > 
>> > > Debugger entered--Lisp error: (error "Cannot find libgccjit library")
>> > >                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > >   error("Cannot find libgccjit library")
>> > >   comp-ensure-native-compiler()
>> > >   comp--native-compile((lambda (arg0 &optional arg1 arg2 arg3) (let ((f #'read-buffer)) (funcall f arg0 arg1 arg2 arg3))) nil "d:/usr/drew/.emacs.d/eln-cache/28.0.91-bfc49136/su...")
>> > >   comp-trampoline-compile(read-buffer)
>> > >   comp-subr-trampoline-install(read-buffer)
>> > >   defalias(read-buffer #f(compiled-function (prompt &optional default require-match predicate) #<bytecode 0x1283e7579f6aadb2>))
>> > >   load-file("~/drews-lisp-20/strings.elc")
>> > >   funcall-interactively(load-file "~/drews-lisp-20/strings.elc")
>> > >   command-execute(load-file record)
>> > >   execute-extended-command(nil "load-file" "load-f")
>> > >   funcall-interactively(execute-extended-command nil "load-file" "load-f")
>> > >   command-execute(execute-extended-command)
>> > 
>> > Andrea, is this expected on a machine that lacks libgccjit?

ATM yes I think so.

>> > Under
>> > what conditions would loading a .elc file trigger native-compilation
>> > of a trampoline?

A trampoline compilation is triggered every time a primitive function is
redefined or advised.  So yeah if a primitive function is redefined in a
.elc being loaded this will trigger the trampoline machinery.

>> > If this is expected, I'd prefer that we detected the unavailability of
>> > libgccjit earlier, and avoided the attempt to compile a trampoline in
>> > the first place.

I see, but note that if we cannot compile a trampoline (and this is not
available already) indeed we cannot install it.  As a consequence we
cannot guarantee that the primitive function being redefined will take
effect in other Lisp code previously native compiled (in C code it will
not take effect anyway).

>> > Can this be done safely enough to make the change on
>> > the release branch?
>> 
>> Andrea, how about the following patch (which assumes
>> comp-enable-subr-trampolines enables and disables only generation of
>> new trampolines, but doesn't affect the use of existing trampolines)?
>> Is this safe for the release branch, in your opinion?
>> 
>> diff --git a/src/comp.c b/src/comp.c
>> index 188dc6e..ba65837 100644
>> --- a/src/comp.c
>> +++ b/src/comp.c
>> @@ -434,6 +434,13 @@ load_gccjit_if_necessary (bool mandatory)
>>        gccjit_initialized = init_gccjit_functions ();
>>        status = gccjit_initialized ? Qt : Qnil;
>>        Vlibrary_cache = Fcons (Fcons (Qgccjit, status), Vlibrary_cache);
>> +      /* Disable deferred async compilation and trampoline synthesis
>> +	 in this session, since libgccjit is not available.  */
>> +      if (!gccjit_initialized)
>> +	{
>> +	  native_comp_deferred_compilation = false;
>> +	  comp_enable_subr_trampolines = false;
>> +	}
>>      }
>>  
>>    if (mandatory && !gccjit_initialized)

I'm wondering if doing this here is not too late.  Say loading we try to
redefine a primitive:

- In `fset' we trigger `comp-subr-trampoline-install'

- In `comp-subr-trampoline-install' we call `comp-trampoline-compile'

- This is using `comp--native-compile'

- This is calling `comp-ensure-native-compiler'

- This will call `native-comp-available-p' that will set
  'native_comp_deferred_compilation' and
  'native_comp_deferred_compilation'.  But at this point we will still
  raise the error because of `native-comp-available-p' return value.

This assuming I'm not missing something and `native-comp-available-p'
doesn't gets called earlier during the stratup process.

Wouldn't be better to call explicitly `native-comp-available-p' from
startup.el and set the two variables from there?

Best Regards

  Andrea