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 15:30:51 +0000 Message-ID: References: <2067160.1HRgjLhtDS@omega> <2515002.Q0mBYvUW8C@omega> 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="227986"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36370@debbugs.gnu.org, Paul Eggert , bug-gnulib@gnu.org To: Bruno Haible Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jun 30 17:32:19 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 1hhboQ-000xDC-26 for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Jun 2019 17:32:18 +0200 Original-Received: from localhost ([::1]:45262 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhboO-0006tK-Nj for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Jun 2019 11:32:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37311) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hhboE-0006t8-61 for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 11:32:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hhboC-0004Cb-Sz for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 11:32:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33602) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hhboA-0004AU-6v for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 11:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hhboA-0007qs-2l for bug-gnu-emacs@gnu.org; Sun, 30 Jun 2019 11:32: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 15:32: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.156190869628967 (code B ref 36370); Sun, 30 Jun 2019 15:32:02 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 30 Jun 2019 15:31:36 +0000 Original-Received: from localhost ([127.0.0.1]:47146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hhbnj-0007Wi-FU for submit@debbugs.gnu.org; Sun, 30 Jun 2019 11:31:35 -0400 Original-Received: from mail-ot1-f45.google.com ([209.85.210.45]:43021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hhbnh-0007RC-Hy for 36370@debbugs.gnu.org; Sun, 30 Jun 2019 11:31:34 -0400 Original-Received: by mail-ot1-f45.google.com with SMTP id q10so961703otk.10 for <36370@debbugs.gnu.org>; Sun, 30 Jun 2019 08:31:33 -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=hOtmnfP+RJE3PdINDxXV0EyMNi2emzrPpyvycAZLdxw=; b=KRttlW3A0u6k7lZzY/CalO34I79pXzOEuPJhOITarrz9EhfqbYMMnWSf7JEIy29WNY 4yiIYugBMxvMmjoVyjEetQcd64qH1jT3t82zq7BmxgOjPtr4J4Nh8GveI2yj4iKNyrzB xPMeJipdOH67XAPyxYBz7WVBfS8vjUzFMUy5fnHKlzb4HukTHPd5vSpIAubrn1xm9K44 arQKJKYpUMLGnht+d+5vl/6NU06Ff4NqhvBKV6hQcvZR0bkesJaCGH1Gf5axhtBchMD4 feUS9JEK6qw2rGSNXGjPSq6PStAzSl9cgw/g5V49087/VhMXfOCsGYwoUq48gYPCg9uz vHuA== 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=hOtmnfP+RJE3PdINDxXV0EyMNi2emzrPpyvycAZLdxw=; b=tnK+y+v9pC7JwpSFUPHgcxys3H+3cqbgF5B62esC5/keKgsvlc3rIM6rYb/H18q9Zy pb8WBPQ4cSUUZfTiFFu3ti5TR39Xfi6rO9kL6wIXpEPF4j8yzgVFNNSbILffHb/2vh5c TXYH+/xt4hesvncoA/ghJR2nqfzK7azieTDh3W3s3BLLdI5WWesf0mJv0N1kgRMHBT42 aBKZM8aw4PMLGf0eoMVvltVmMQiTFW873x1d5kLlwhQshmKcaBtwODeiOyWcAaRdkasQ Kv7YjBEEWovWTgdxznDyiJM8YDRW8GHK4GaLreKkh2z2J63/2UxNNe8W1HIqDhgeKU28 3fAw== X-Gm-Message-State: APjAAAW0sXxttAWhIgWpjI0U6g44HS1gbaCbgD29ucn0zAtFrW2kWDxZ egFxWXdQK34EBfI4hd+GlYOWjUb3PZKTPApnTBU= X-Google-Smtp-Source: APXvYqz5pQT1iMdmaQ47zRHTUl4PivBtKRtFAxEs7AeFbsNf0dpACUY8KSlomsCYueCZUz+ap9/vzQ8gFcobzbQqEGk= X-Received: by 2002:a9d:664c:: with SMTP id q12mr14928630otm.175.1561908687983; Sun, 30 Jun 2019 08:31:27 -0700 (PDT) In-Reply-To: <2515002.Q0mBYvUW8C@omega> 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:161892 Archived-At: On Sat, Jun 29, 2019 at 10:31 AM Bruno Haible wrote: > Pip Cet wrote: > > I would like to state that the current assume does > > behave very badly when combined with -fno-inline-small-functions > > -fno-inline. > > Since we can't address this limitation through an acceptable change > to the 'assume' macro, we need to address it through documentation. I agree. There's a limitation bad enough for me to consider it a bug in current GCC, and even if that's lifted tomorrow, it wouldn't be backported so it would be quite a while until I'd ask you to reconsider the matter. > > marking it > > as __attribute__((always_inline)) is problematic because it might > > directly contradict what the programmer was trying to achieve by > > passing -fno-inline. > > __attribute__((always_inline)) exists precisely to make a distinction > between functions where inlining is usually desirable vs. functions > where inlining is essential. Indeed. In this case, it's usually desirable but not essential for the correctness of the program, IMHO. I understand you disagree. > We don't need to warn against the uses > of __attribute__((always_inline)) -- confusing behaviour in the debugger > etc. -- becauses these drawbacks are already well-known. I disagree completely. There's no warning in the GCC documentation for the attribute. > As a user of the 'assume' macro, I want a definitive statement about what > I need to provide so that the macro works in the sense of improved performance. > A statement about "often" is too vague. I agree. > How about this proposed patch? > > diff --git a/lib/verify.h b/lib/verify.h > index f8e4eff..ed1ba19 100644 > --- a/lib/verify.h > +++ b/lib/verify.h > @@ -261,7 +261,10 @@ template > > /* Assume that R always holds. This lets the compiler optimize > accordingly. R should not have side-effects; it may or may not be > - evaluated. Behavior is undefined if R is false. */ > + evaluated. The behavior is undefined if R is false. > + If you want the use of this macro to improve, not deteriorate, > + performance, R should not contain function calls except to functions > + that are declared 'inline __attribute__((__always_inline__))'. */ My suggestion would be "Assume that R always holds. This lets the compiler optimize accordingly. Behavior is undefined if R is false, fails to evaluate, or has side effects. Performance will suffer if R contains function calls that are not inlined at compile time." That would describe the API as I understand you and Paul think it always has been; I think it describes a drastically stricter API than what the old comment did. As a reminder, my starting point was that I wanted to make the API more lenient. So, obviously, I disagree with the API change but it is more important that there's consensus on what the API actually is than it is to have a good API.