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,gmane.comp.lib.gnulib.bugs Subject: bug#36370: 27.0.50; XFIXNAT called on negative numbers Date: Fri, 28 Jun 2019 19:15:06 +0000 Message-ID: References: <2715311.ceefYqj39C@omega> <8979488.cRkkfcT1mV@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="239321"; 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 Fri Jun 28 21:39:23 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 1hgwiQ-001066-Me for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 21:39:22 +0200 Original-Received: from localhost ([::1]:35828 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgwiP-000487-Hz for geb-bug-gnu-emacs@m.gmane.org; Fri, 28 Jun 2019 15:39:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51750) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgwM6-0005YC-9A for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:16:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgwM1-0006nG-D2 for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:16:16 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57706) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgwLp-0006gR-VS for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:16:07 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hgwLp-00063q-NR for bug-gnu-emacs@gnu.org; Fri, 28 Jun 2019 15:16:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 28 Jun 2019 19:16:01 +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.156174935322813 (code B ref 36370); Fri, 28 Jun 2019 19:16:01 +0000 Original-Received: (at 36370) by debbugs.gnu.org; 28 Jun 2019 19:15:53 +0000 Original-Received: from localhost ([127.0.0.1]:43017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgwLg-0005vV-K1 for submit@debbugs.gnu.org; Fri, 28 Jun 2019 15:15:53 -0400 Original-Received: from mail-oi1-f169.google.com ([209.85.167.169]:41920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hgwLc-0005lv-Ik for 36370@debbugs.gnu.org; Fri, 28 Jun 2019 15:15:49 -0400 Original-Received: by mail-oi1-f169.google.com with SMTP id g7so5049005oia.8 for <36370@debbugs.gnu.org>; Fri, 28 Jun 2019 12:15:48 -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=iRNuL0n5Vl2Y0LzIlmkphK3bo/ZzekQWktdItiI9OHo=; b=TINWKQmxFGFpr/w8NeJKqdHz1v/tpD1ZbSiUQ4HHsNDTrsGiyVKsa865IJW5l1m7Di xKqL7YKzaE20O6qtYTLmUXRomYRO2eNZLHBfXQj3EU5/Xltl5SixiptPIp/DTHVDI66q tQ9Y9whHwgSYgjmY+lsk2CwY2eWKJO1tMdJZgZCZwEhTRMkDb6FwZLF2mzp6o07m/J8p tbqkE4ZcEpzYr1ekSNcX0S9zyep4H1He+WB9xnl10ZXfj6EX3hQAL+Iytq6Zo1w1OhGK nITC+4HmJc4NuS4gp2Ymu+6g8cO84GI4XMCqG+ZMeET28nQQVhVJpWMBsVqO8LADoA4t Q8BA== 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=iRNuL0n5Vl2Y0LzIlmkphK3bo/ZzekQWktdItiI9OHo=; b=hhi2XoWPuH8HaDs3uKyMox/C54loOybG82/iS0u9k13bDFUMQxF39Vb2K0rzQ0zHV0 sz6xwrf9mANtmpuavxOkNjIbum8Jq5yKc+9XnNhjL5r9fio41g7qcxnMFq1UlLwHOSyD 6MXw8r5RWBDFXm075NVFjOftaHJ4+Qxepx3YIwttnIsP0JtYjj03wUwXDBBNc6cXniJ5 HbXhZy1tzEcgtKuNBcDR1WI5aMulvIX6a6ORyhdojKDxJU0sqy/Hm2cTqxqn4IkwFieo sbpeWCYPjb9nfrz1GEo2jZBSnN57Cvm4AQ4x/pwdWY08UVtKlMJo8qma4P8LrlX5NOva MNhg== X-Gm-Message-State: APjAAAWue6qLpO60n/wPi3Pi/syrqtOec0jU64SmK84yjPHhBH5w3pFj GO1Mz+LgrnST+c/fJgXhYfe5pOQ3QqXg68wpq3Q= X-Google-Smtp-Source: APXvYqyit9XlgDW+7sEC8RjfCVfZxjYQXiogdaUm9hkYQLSZeciIr2pmRJxRjq8BuNiHuRFXcdC3HlkdIldpqCwuRRU= X-Received: by 2002:aca:2303:: with SMTP id e3mr2418739oie.112.1561749342475; Fri, 28 Jun 2019 12:15:42 -0700 (PDT) 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:161761 gmane.comp.lib.gnulib.bugs:40581 Archived-At: On Fri, Jun 28, 2019 at 5:46 PM Paul Eggert wrote: > Pip Cet wrote: > > 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)); > > These mean the same thing. I'm really convinced they don't. Can you humor me and explain why they're equivalent? I'm considering this test case: ==== int global; extern int f(void); #define eassume0(cond) ((cond) ? (void) 0 : __builtin_unreachable ()) #ifdef ASSUME_GNULIB #define eassume eassume0 #else #define eassume(cond) (__builtin_constant_p (!(cond) == !(cond)) ? eassume0(cond) : (void) 0) #endif int main(void) { #ifdef TWO_ASSUMES eassume (global == 0); eassume (f ()); #else eassume (global == 0 && f ()); #endif global++; } ==== with this external function: ==== extern int global; int f(void) { return ++global; } ==== I believe, and that is what my patch is based on, that the compiler should be free to "use" the first eassume and ignore the second one, resulting in this machine code: movl $1, global(%rip) xorl %eax, %eax ret No call to f, it just sets global. Without -DTWO_ASSUMES, the compiler cannot split the assumption. > Both tell the compiler that a certain condition (A && > B) is known to be true, and that behavior is undefined if (A && B) is false. Again, no. The split eassumes tell the compiler that A, B, and A && B would all evaluate to true or fail to evaluate. The single eassume() only covers the last of those three cases. > The > fact that Gnulib+GCC implements them differently is a quality-of-implementation > issue, not a semantics issue. Are you really saying that the single-assume case is equivalent to the single-instruction program? > > I'm saying that the programmer is > > allowed to assume that the expression passed to assume either has been > > evaluated, or hasn't been, with no in-between interpretations allowed > > to the compiler. > > I don't see why that assumption is valid. It's OK if GCC partially evaluates the > expression. As a silly example, eassume (0 * dump_core () + getchar ()) is not > required to call dump_core, even if the compiler generates a call to getchar. That's because && implies a sequence point, and * doesn't. > Perhaps we should change the comments in verify.h to make this point clearer. I'm sorry to be selfish, but I'd really rather understand where I've gone wrong, first.