GNU bug report logs - #61880
Native compilation fails to generate trampolines on certain scenarios

Previous Next

Package: emacs;

Reported by: Sergio Durigan Junior <sergiodj <at> sergiodj.net>

Date: Wed, 1 Mar 2023 00:15:02 UTC

Severity: normal

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: rms <at> gnu.org
Cc: sergiodj <at> sergiodj.net, 61880 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: bug#61880: Native compilation fails to generate trampolines on certain scenarios
Date: Sun, 05 Mar 2023 08:28:36 +0200
> From: Richard Stallman <rms <at> gnu.org>
> Cc: akrl <at> sdf.org, sergiodj <at> sergiodj.net, 61880 <at> debbugs.gnu.org
> Date: Sat, 04 Mar 2023 23:03:57 -0500
> 
>   > > To a quick look into the trampoline machinery in comp.el I see we rely
>   > > on:
>   > > 
>   > > null, memq, gethash, and, subrp, not, subr-native-elisp-p,
>   > > comp--install-trampoline, concat, if, symbolp, symbol-name, make-string,
>   > > length, aset, aref, length>, mapcar, expand-file-name,
>   > > file-name-as-directory, file-exists-p, native-elisp-load.
> 
> There is nothing wrong with ignoring the return value of `aset'.  That
> is normal.  We use it like `setq'.  Do not make warnings for that.

This is a misunderstanding, I think: this particular discussion is not
about ignoring the return values, it is about redefining primitives
while natively-compiling trampolines.

I think you mixed this up with another discussion.




This bug report was last modified 2 years and 64 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.