From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#36370: 27.0.50; XFIXNAT called on negative numbers Date: Sun, 30 Jun 2019 09:21:55 +0000 Message-ID: References: <2715311.ceefYqj39C@omega> <8979488.cRkkfcT1mV@omega> <87168b28-192b-6666-e9b6-9cdc2ed3917a@cs.ucla.edu> <791ae316-3a6f-605a-0da5-874fe3d224c5@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="115987"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36370@debbugs.gnu.org, Bruno Haible , bug-gnulib@gnu.org To: Paul Eggert Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 30 11:23:15 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hhW3H-000Tyv-18 for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Jun 2019 11:23:15 +0200 Original-Received: from localhost ([::1]:43592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhW3A-0007Mk-RB for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Jun 2019 05:23:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38182) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhW35-0007MW-TE for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 05:23:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhW34-0005UV-KE for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 05:23:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60050) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhW34-0005UH-Gw for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 05:23:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hhW34-0003N9-BY for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 05:23:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jun 2019 09:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36370 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 36370-submit@debbugs.gnu.org id=B36370.156188656012928 (code B ref 36370); Sun, 30 Jun 2019 09:23:02 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 30 Jun 2019 09:22:40 +0000 Original-Received: from localhost ([127.0.0.1]:45361 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hhW2h-0003MS-Lf for submit@debbugs.gnu.org; Sun, 30 Jun 2019 05:22:39 -0400 Original-Received: from mail-ot1-f46.google.com ([209.85.210.46]:39400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hhW2f-0003MG-Up for 36370@debbugs.gnu.org; Sun, 30 Jun 2019 05:22:38 -0400 Original-Received: by mail-ot1-f46.google.com with SMTP id r21so9775143otq.6 for <36370@debbugs.gnu.org>; Sun, 30 Jun 2019 02:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DAbu2eMK4hEG0OQXXkWrkKdZhuQJT2dldt2ueRttq2g=; b=auuh9t4Gy53z7T26827dtY7pff3ho1B7ybHzSvlMU5eKj/o9r1upPFle6iikCdpDz7 AGZzZm1EeTF2gfNAYo626JujMEVettO6NaCL1gkPGR+zwvRxaAKOALzFJzjTJ3w8FCgZ 7ZVyXe2zpEcg/xV7U0pAln4JIqNN2C4g9MVhY13onvXWoIHjtDC0GjqIL5C3UEWHZ0BU JymE/h8jI6ZtpF02wf3a/DWcTeceJqL8n98qhf/iF3w8RFya3D/r57rirV+X9UkCR77z 8r24fCSYSUZyxbhTVFu43JPqI37WzteP1Hfx2uRttUHVPIBUKAucWQO7fh0WKJ6v0xkP rQpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DAbu2eMK4hEG0OQXXkWrkKdZhuQJT2dldt2ueRttq2g=; b=rhux/DR1SOcprzmGQ8sGM7oD12uuiiMtzXq3PlWOzd3L1if+MCzAIdjSG2kVWmvKVi OieT6I56gmZqeRbdVqba2g+Q54L3655a6jjJyyogYnynlnv1RNumG+WxHAV3UCcDtDWh rbvdadYZDBcJu4uLyKIC9H2unfRXUExyOUipZFvUh+aJjLf2d34T9+DBXAumlI1Ic+hY mIMoa/CKUEXsLEQXhCj4ziB4rpPfqRrs54C9wYo5e/v2AuB9Lf8rqxxSEkkAuQPn6v5D jIY5aagu6wb6DDuvhPSvaWXaSLh1lT+moIhsWPDbVDdbFTlEMe9yrgkqOZu9kO/6mYGk RfWw== X-Gm-Message-State: APjAAAUPPt1xGHzGUuPhcG5VV6tFyc420d5EOeVZnu4EOQ+BgLBvc0O0 3nimEbGhF3hV+wFdbyR0NvVTXmuiBk2uuX0b7Gg= X-Google-Smtp-Source: APXvYqwdtFM7VRFaZSxuWppiVMOOORSZrhY8NZkpzIsZxo9FopXCN9VsnHJl5NvkhibEitzQ+xpFVG7JhZNRKa9cNjc= X-Received: by 2002:a9d:7284:: with SMTP id t4mr16343336otj.154.1561886552223; Sun, 30 Jun 2019 02:22:32 -0700 (PDT) In-Reply-To: <791ae316-3a6f-605a-0da5-874fe3d224c5@cs.ucla.edu> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:161873 Archived-At: On Sat, Jun 29, 2019 at 5:31 PM Paul Eggert wrote: > >> This is not a valid use of 'assume'. It's documented that assume's argument > >> should be free of side effects. > > > > But the compiler makes no such assumption > > Sure, but if the caller uses 'assume' contrary to its documentation, that's a > problem with the caller's code, not with 'assume'. It's merely an implementation > detail as to which pothole the problematic code runs into. I agree, for what it's worth, that the new documentation is clear on what is and isn't allowed with assume(). It's just that it's a significant API change from the previous state, and I dislike the API change. Again, this isn't about using `assume' contrary to its documentation, it's about using it in a way that the compiler cannot prove obeys the documented API, and thus handles suboptimally. > > if GCC decided to add a > > __builtin_assume() builtin, we could give it slightly different > > semantics: that the expression passed to it evaluates to true, but > > doesn't evaluate to false or fail to evaluate. Something like > > __attribute__((does_return)) might do on a function. > > Yes, the expression should return true without side effects or looping. I don't > see this as an significant difference in semantics. It's significant to GCC. It optimizes function calls that are known to return differently from ordinary function calls. > One should also not call > Gnulib assume (R) with an expression that loops forever, as this defeats the > intent of 'assume' which is to make code more efficient. No disagreement there. However, that doesn't mean the compiler is free to assume that assume()'s argument doesn't loop; it needs to prove that, whereas with the new __builtin_assume() builtin, it wouldn't have to go to that trouble. > If there's any real > confusion about this issue, we can add it to the 'assume' documentation as well. I think the new documentation is fine, in this regard. > > Also, "should" doesn't mean "must", does it? > > It's not the "should" of an Internet RFC. It's more the "should" of "you should > do this, and if you don't you're on your own". So if I add a debug print statement to an inline function that happens to be called in an eassume, I'm on my own? That's a significant API change. > > I'd prefer rewording that > > sentence as "R may or may not be evaluated: it should not normally > > have side-effects". > > Better to say that it should not have side effects at all. There's no "normally" > about that. Side effects are trouble. Except for debugging statements, other assert()s, abort()s, other assume()s, divisions by zero that happen in the eassume() code rather than after it... Again, I think there are two issues here: you want to change the API to be much more restrictive (my original patch intended to make it more lenient), and you want to document the new API. Obviously, the second point is fine. If the new requirement is that R has no side effects, we don't need the "R may or may not be evaluated". In fact, it might confuse others in the same way I was confused. I read the old documentation as: As far as side effects go, each assume(R) may decide, independently and unpredictably, whether side effects of R are visible or not: R may or may not be evaluated. This unpredictable behavior can be confusing; to avoid confusion, R RFC-SHOULD not have side effects. the new documentation, I read as: If R has any side effects, assume(R) is undefined. It can cause compilation, linking, or run-time errors. > > wouldn't it be even > > nicer to give up (most of) the distinction between assert and assume > > and just tell people to use assume? > > No, because 'assert (false)' has well-defined behavior, whereas behavior is > undefined for programs that do 'assume (false)' . This is a fundamental > difference between the two. Thus the "most of", yes.