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 "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#42360: [feature/native-comp] miscompilation(?) of functions with non local exits Date: Wed, 15 Jul 2020 21:19:37 +0000 Message-ID: References: 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="16207"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cc: 42360@debbugs.gnu.org, eliz@gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 15 23:21:05 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jvops-000465-Sk for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Jul 2020 23:21:04 +0200 Original-Received: from localhost ([::1]:51266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jvopr-00070z-Re for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Jul 2020 17:21:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57312) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvoos-0006Xh-U0 for bug-gnu-emacs@gnu.org; Wed, 15 Jul 2020 17:20:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42236) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jvoos-0008NZ-KD for bug-gnu-emacs@gnu.org; Wed, 15 Jul 2020 17:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jvoos-0004SE-GP for bug-gnu-emacs@gnu.org; Wed, 15 Jul 2020 17:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Jul 2020 21:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 42360 X-GNU-PR-Package: emacs X-Debbugs-Original-Cc: bug-gnu-emacs@gnu.org, Eli Zaretskii Original-Received: via spool by submit@debbugs.gnu.org id=B.159484798517094 (code B ref -1); Wed, 15 Jul 2020 21:20:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 15 Jul 2020 21:19:45 +0000 Original-Received: from localhost ([127.0.0.1]:53782 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jvooa-0004Re-VS for submit@debbugs.gnu.org; Wed, 15 Jul 2020 17:19:45 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:37360) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jvooZ-0004RX-Je for submit@debbugs.gnu.org; Wed, 15 Jul 2020 17:19:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57262) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvooZ-0006Ib-CY for bug-gnu-emacs@gnu.org; Wed, 15 Jul 2020 17:19:43 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:63295) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jvooW-0008HF-Bw; Wed, 15 Jul 2020 17:19:43 -0400 Original-Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTP id 06FLJbOY015184; Wed, 15 Jul 2020 21:19:37 GMT In-Reply-To: (Stefan Monnier's message of "Wed, 15 Jul 2020 15:17:27 -0400") Received-SPF: pass client-ip=205.166.94.24; envelope-from=akrl@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/15 17:19:38 X-ACL-Warn: Detected OS = ??? 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: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:183029 Archived-At: Stefan Monnier writes: >> Three options: >> >> 1- Because setq is evaluated the expression should always evaluate to >> t. >> >> 2- Unwinding the original state of the stack is restored, when it was >> saved 'x' was nil so the expression should evaluate to nil. >> >> 3- This is unspecified. > > Very definitely (1)! All right, I pushed a fix that restores behavior 1. >> FYI 1 implies C register variables cannot be used to implement Lisp >> local variable if non local exits are present. > > IIUC, the problem only occurs for those vars which have > a `condition-case` (or `unwind-protect` or `catch`) in their scope and > where the var is modified within that construct and that a non-local > exit can jump to the end of that construct after the var was thus > modified, and that the var is used after the construct. Correct. If the compiler keep these variables in the stack then it's all fine because setjump will restore SP and inside the stack you'll find the most updated value. On the contrary if the variable was kept in a register then its updated value may be lost if the reg is callee saved. > This should be fairly rare (not sure if those cases can easily be > written differently, OTOH). The case I've encountered is `truncate-string-to-width'. > The compiler could replace those vars > by boxing them inside a cons-cell (so the register-stored C var is > immutable and contains a pointer to a cons cell which holds the real > value in the `car`), just like we do with mutated Elisp vars captured > by closures. What I pushed now is (for functions with non locals) just to keep stored all local vars in an array (as the bytecompiler does). I added note and we should be able to implement something more selective as suggested. Either adding an indirection or marking the sensitive variables as volatile. Thanks both for the feedback. Andrea -- akrl@sdf.org