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: Sat, 29 Jun 2019 06:48:24 +0000 Message-ID: References: <2715311.ceefYqj39C@omega> <8979488.cRkkfcT1mV@omega> <87168b28-192b-6666-e9b6-9cdc2ed3917a@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="145533"; 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 Sat Jun 29 08:50:34 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 1hh7Bx-000blH-MF for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Jun 2019 08:50:33 +0200 Original-Received: from localhost ([::1]:38058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hh7Bu-0004J0-PK for geb-bug-gnu-emacs@m.gmane.org; Sat, 29 Jun 2019 02:50:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36859) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hh7BU-0004Fy-Bu for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 02:50:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hh7BT-0006BU-3l for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 02:50:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58014) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hh7BS-0006B1-Ax for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 02:50:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hh7BS-0002EG-7T for bug-gnu-emacs@gnu.org; Sat, 29 Jun 2019 02:50: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: Sat, 29 Jun 2019 06:50: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.15617909498507 (code B ref 36370); Sat, 29 Jun 2019 06:50:02 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 29 Jun 2019 06:49:09 +0000 Original-Received: from localhost ([127.0.0.1]:43325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hh7Ab-0002D9-BN for submit@debbugs.gnu.org; Sat, 29 Jun 2019 02:49:09 -0400 Original-Received: from mail-ot1-f53.google.com ([209.85.210.53]:47013) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hh7AZ-0002Cj-17 for 36370@debbugs.gnu.org; Sat, 29 Jun 2019 02:49:07 -0400 Original-Received: by mail-ot1-f53.google.com with SMTP id z23so8277936ote.13 for <36370@debbugs.gnu.org>; Fri, 28 Jun 2019 23:49:06 -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=hD3ut1+pbXdOV0ycwQ29ox85TCsAAAFashPhxHw5mYA=; b=HkpJVVSFM9IOCealP27mHRdy3D279zU4R+3tDJpY1j9rivYXxkJOY660l8G4OSROON yE4aTjq/v3o8woU56u1DrS6wCFHMMz5SV1mfD5qpYQ+BkeKCENIn7v/dtonp22kupLux gkk+H1JVkSQJYomj3AVntM/xmGU6m8AEuPP22c/qscrdxa6nWXS0idQ9CrLec9vY+MoR iY32a3r9nVV47vdAkonlAtulK6MWzm1xDaSmFgo3sVQ9Fg8hY9SmPR6Y1V6cOldBo08x WwAOd2t/EzO38Py+0c01PELz/Fx0dM1EGhKsKJvMJa6OF+GgzWtaXAVB4ykVqyRfxSqn u5uQ== 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=hD3ut1+pbXdOV0ycwQ29ox85TCsAAAFashPhxHw5mYA=; b=F3jhBjTpiyZKHu+4tjnHNmOG5J0chZHWyqD5kTSCMiGOti9Ork5m1rCrgC4eaN5Xiu SKcFah24mrLMdsSsqnXQ859QEcPL1WXDOgmHV9WfLBpyhOasrEV8XHSQNvvUTDoogCCe s6IWtQGgfzadzwJ3fpGAIxv+eTvDftpTTM5m26T4rlFiTKO1Rp0q0w/bbnC9e8EcIizK 6BPdtl/U6Y7lno2NL9sVPBdD4eMTb8NEr2/9DnkWXvnG4IIF+QEBWX3IV6YVSOoe+IzJ dMhz1leFKJNwxUZHo/rOW+xu+ayKxQ/fKNvqepM79fuVvYS3CSmoKYV5EZp2cpTd0FfQ RmTg== X-Gm-Message-State: APjAAAVuqxJhHeqVxBvXnCGGpVDHpBcoi6r++oSitLxvPwr2amqQAbjb Wposgw4LAOGZjmt/zbT1oEGhjcjhCDTd+NOd5xc= X-Google-Smtp-Source: APXvYqzp2b9dcMMY9wYKOeIgxSJCpohkv1UZa1gotXg87XDrUJDNzYVX5AWyGajjNJ3u0QAv8XfhfXFzFWzjqS67UVA= X-Received: by 2002:a9d:664c:: with SMTP id q12mr10363945otm.175.1561790941372; Fri, 28 Jun 2019 23:49:01 -0700 (PDT) In-Reply-To: <87168b28-192b-6666-e9b6-9cdc2ed3917a@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:161794 Archived-At: On Sat, Jun 29, 2019 at 5:41 AM Paul Eggert wrote: > Pip Cet wrote: > > eassume (global == 0); > > eassume (f ()); > > #else > > eassume (global == 0 && f ()); > > ... > > extern int global; > > > > int f(void) > > { > > return ++global; > > } > > > 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, so it cannot optimize assume(i >= 0 && f()), (where i is a global or a non-const pointer to i has potentially leaked) unless f happens to be available at optimization time. I think this is an interesting point: 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. However, if I'm not too confused, we're discussing whether assume(SIMPLE_CONDITION && COMPLICATED_CONDITION) is ever a good idea. With the old assume, it's harmful. With the new assume, it's pointless. Is assume(SIMPLE_CONDITION); assume(COMPLICATED_CONDITION); a good idea? With the old assume, it's harmful. With the new assume, it's a more verbose way of simply assuming SIMPLE_CONDITION, so it might be a good idea. Also, "should" doesn't mean "must", does it? I'd prefer rewording that sentence as "R may or may not be evaluated: it should not normally have side-effects". > It would be nice if 'assume (R)' reported an error if R has side effects, and > generated a warning unless the compiler can verify that R is free of side > effects. However, these niceties would require better support from the compiler. But if we had that support from the compiler, wouldn't it be even nicer to give up (most of) the distinction between assert and assume and just tell people to use assume? That idea was my starting point, and I'm still convinced it would result in better code overall. Except someone would have to grep a little once in a while and replace most eassume (A && B) expressions with eassume (A); eassume (B); However, there are a few tricks we can use to verify this in special debug builds. ------ Putting inner functions into sections: #define assume(C) ({ auto void inner (void) __attribute__((section("only_trivial_functions_go_here"), used)); void inner(void) { (void)(C); } (void) 0; }) Then verify that the section contains only trivial function definitions. (For the record, for Emacs, it does). Another approach for detecting when (C) has "global" side effects (such as calling an external function) is to do this: ------- #include int global; extern void dummy(void (*)(void)) __attribute__((warning ("assume might have side effects"))); #define C printf("3") int main(void) { auto void inner(void) __attribute__((used)); void inner(void) { if (global) __builtin_unreachable (); (void)(C); if (global) dummy(inner); } } ----- A third possibility is to use __builtin_constant_p(!(C)!=!(C)), as the patch does. That doesn't state precisely that C has no side effects, but it does come fairly close in practice ... except for the inline function problem. > > If you want your program to behave predictably, in the strict sense, > > you cannot ever use the current assume() API. > > I'm not sure what you mean by "in the strict sense". It's true that programs can > misuse 'assume' and get undefined behavior, but that's kind of the point.... Precisely what I meant.