From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Bruno Haible Newsgroups: gmane.emacs.bugs Subject: bug#36370: 27.0.50; XFIXNAT called on negative numbers Date: Fri, 28 Jun 2019 21:11:11 +0200 Message-ID: <11002295.LrvMqknVDZ__5762.59353417612$1561750976$gmane$org@omega> References: <8979488.cRkkfcT1mV@omega> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="253238"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: KMail/5.1.3 (Linux/4.4.0-151-generic; KDE/5.18.0; x86_64; ; ) Cc: 36370@debbugs.gnu.org, Paul Eggert , bug-gnulib@gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 28 21:42:47 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 1hgwlh-0013fh-HC for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 21:42:47 +0200 Original-Received: from localhost ([::1]:35876 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgwlg-0006se-IV for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 15:42:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49010) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgwI2-0002jy-9E for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:12:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgwHy-0003Ml-Po for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:12:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57702) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgwHy-0003MN-Jt for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgwHy-00053d-AZ for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Bruno Haible Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jun 2019 19:12: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.156174908219384 (code B ref 36370); Fri, 28 Jun 2019 19:12:02 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 28 Jun 2019 19:11:22 +0000 Original-Received: from localhost ([127.0.0.1]:43013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgwHJ-00052a-UM for submit@debbugs.gnu.org; Fri, 28 Jun 2019 15:11:22 -0400 Original-Received: from mo4-p00-ob.smtp.rzone.de ([81.169.146.160]:34580) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgwHG-00052N-2u for 36370@debbugs.gnu.org; Fri, 28 Jun 2019 15:11:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1561749076; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=mtWVzqbnP43E/Sg/vARE9UyxgC96tN57kEw1cX+jNOQ=; b=sRcbbjjkXxbyhbcj5rKHjSTnZJ7SwJvIwxx0wPjV2+WJ5riF/vr/P0i8lMz1S/71Ts jW7S4bMwso+iuABN4RXfwttMjIXmygi+31FvqrlclOBlRb3bsJ5VtU0uRhuJSLCkdeyB ZsmkfHujCSJ5z71iDT15wrUsW382E3xXmOy5fau9dFFcoiW84IoTswmHLTC7cl6hYSlW qHEYhYpkcUs1Z84w3yoHkoN5WXPSuqanoCOgMvmShWlP9K6CroOu4Iiross1zCCZfqWt 49aMtLDAhkxFpMefXeCnma1UuwZzYtKO9G7858js9+11Evrk5KSuvYHfOoeMaiM8owTP tB3Q== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGaf0zJZW" X-RZG-CLASS-ID: mo00 Original-Received: from bruno.haible.de by smtp.strato.de (RZmta 44.24 DYNA|AUTH) with ESMTPSA id v018bcv5SJBBjvh (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 28 Jun 2019 21:11:11 +0200 (CEST) In-Reply-To: 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:161764 Archived-At: Pip Cet wrote: > Sorry, can't reproduce that here. I'm sure the changes I need to make > are obvious once I've found them, but can you let me know your gcc > version? I reproduce this with GCC versions 5.4.0, 6.5.0, 7.4.0, 8.3.0, and 9.1.0. 1. Take the files foo.c and bar.c from 2. Compile and disassemble: gcc -O2 -m32 -flto foo.c bar.c -shared -o libfoo.so && objdump --disassemble libfoo.so Observe that f_assume pushes an immediate $0 argument on the stack for the function call. 3. Enable the second 'assume' definition instead of the first one. 4. Compile and disassemble: gcc -O2 -m32 -flto foo.c bar.c -shared -o libfoo.so && objdump --disassemble libfoo.so Observe that f_assume is now an alias of f_generic, that pushes a computed value as argument on the stack for the function call (push %eax). > Sorry to be pedantic, but do you disagree that it is better in these > cases, or in general? I disagree that it is better in general. You're apparently setting out a high goal for the 'assume' macro: (1) that the programmer may call it with an expression that involves function calls, (2) that the generated code will never include these function calls, because the generated code with the 'assume' invocation should be optimized at least as well as the generated code without the 'assume' invocation. I'm adding certain quality criteria: - It is not "good" if a construct behaves unpredictably, that is, if it hard to document precisely how it will behave. (*) - It is not "good" if the behaviour with no LTO is different from the behaviour with LTO. The implementation with the __builtin_constant, while attaining the goals (1) and (2), does not satisfy the two quality criteria. I believe the only way to attain the goals and the quality criteria is, as you suggested, to ask the GCC people to add a __builtin_assume built-in. > > 1. The new 'assume' is worse when -flto is in use. > > Maybe. Even if it is, though, that's a GCC limitation which I consider > likely to be fixable Yes, *maybe* the GCC people can change the semantics of __builtin_constant_p so that it is effectively computed at link-time, rather than when a single compilation unit gets compiled. Or maybe not. I don't know... > It's way too easy to do something like > > eassume(ptr->field >= 0 && f(ptr)); > > when what you mean is > > eassume(ptr->field >= 0); > eassume(f(ptr)); I argue that it's unnatural if the two don't behave exactly the same. Like everyone expects that x = foo ? yes : no; is equivalent to if (foo) x = yes; else x = no; And everyone expects that if (A && B) { ... } is equivalent to if (A) if (B) { ... } Bruno (*) My favourite example of this principle is tail-recursion elimination.