From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: [feature/native-comp] breakage on build Date: Mon, 08 Feb 2021 15:14:50 +0000 Message-ID: References: <87lfca7lsb.fsf@russet.org.uk> <831rdy5i2r.fsf@gnu.org> <87y2g5p0q8.fsf@russet.org.uk> <87im7799s9.fsf@russet.org.uk> <87wnvn5yoz.fsf@russet.org.uk> <87eehuomn2.fsf@russet.org.uk> <83lfc2px16.fsf@gnu.org> <87czxe45f8.fsf@russet.org.uk> <8335yap6p8.fsf@gnu.org> <87wnvm2nhb.fsf@russet.org.uk> <83wnvlod0k.fsf@gnu.org> <87wnvlmjxo.fsf@russet.org.uk> <83ft29nwc0.fsf@gnu.org> <87y2fzr8ve.fsf@russet.org.uk> <87ft26pxra.fsf@russet.org.uk> <877dnipqfh.fsf@russet.org.uk> Reply-To: Andrea Corallo Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9440"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 08 22:26:09 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l9E2q-0002M5-Tk for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Feb 2021 22:26:08 +0100 Original-Received: from localhost ([::1]:47782 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9E2p-0007xM-WA for ged-emacs-devel@m.gmane-mx.org; Mon, 08 Feb 2021 16:26:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38702) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l98Fi-0005RS-08 for emacs-devel@gnu.org; Mon, 08 Feb 2021 10:15:02 -0500 Original-Received: from mx.sdf.org ([205.166.94.24]:65346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l98Fd-0007Qk-OJ; Mon, 08 Feb 2021 10:15:01 -0500 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 118FEo2u026655 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 8 Feb 2021 15:14:51 GMT In-Reply-To: <877dnipqfh.fsf@russet.org.uk> (Phillip Lord's message of "Mon, 08 Feb 2021 14:47:14 +0000") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:264178 Archived-At: Phillip Lord writes: > Andrea Corallo writes: > >> Phillip Lord writes: >> >>> Andrea Corallo writes: >>> >>>> Phillip Lord writes: >>>> >>>> Yes, libgccjit is not needed for loading elns. There might be some minors to >>>> look at as I've never tested this configuration but should be no >>>> problem. >>> >>> >>> For an Emacs compiled --with-nativecomp, how do I stop it attempting to >>> native compile? >> >> `comp-deferred-compilation' >> >> But I was wrong there's another issue. If we can't compile we cannot >> synthesize trampolines, as a consequence we can't redefine or advice >> primitive functions reliably... Sorry > > > I didn't think we could do this anyway. I guess this means that > native-compiled lisp to primitive adviced functions will skip the > advice? So, that would be a change from the current situation where > C calls to C functions don't get adviced, but lisp calls to C functions > do. Apologies let me be more precise. - Advising C to C primitives is not possible in both implementations - With bytecode you can effectively redefine primitives with _no_ dedicated op-bytecode. - With native code you can redefine all of these except for the (very few) primitives we open-code directly in the generated code. This is a smaller set than the previous one but still not perfect. Anyway, we can do this but relying on this trampoline syntheses mechanism. Removing this mechanism is therfore ATM not possible, unless we precompile all trampolines AOT bug#44238. This should be rather easy tho, we lack only some integration into the build system lets say. Andrea