From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.4 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A5E9D1F461 for ; Sat, 29 Jun 2019 06:49:16 +0000 (UTC) Received: from localhost ([::1]:38054 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hh7Ag-00043d-AT for normalperson@yhbt.net; Sat, 29 Jun 2019 02:49:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36714) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hh7Ab-00043J-C6 for bug-gnulib@gnu.org; Sat, 29 Jun 2019 02:49:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hh7AZ-000596-Fg for bug-gnulib@gnu.org; Sat, 29 Jun 2019 02:49:08 -0400 Received: from mail-ot1-x32d.google.com ([2607:f8b0:4864:20::32d]:34352) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hh7AW-00051Q-3T for bug-gnulib@gnu.org; Sat, 29 Jun 2019 02:49:05 -0400 Received: by mail-ot1-x32d.google.com with SMTP id n5so8335130otk.1 for ; Fri, 28 Jun 2019 23:49:02 -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=jdOaqBfUb3ttFnar3ybSs/L3ZG+Lpu6hJ9UK3uCacnVySV5o0mDW5Tf4aXV/3I3DDw MBhUOSVLohdw12ylOzxGmuZ3DDYQq+eUO8LMEP+NZQ/4nAQEBHbVOFMtx3QlebjP+Ujs XJzjAp1lPc03QOrCdOtS3Q50EVjLa6K/cvyeRKncbxiyZjNEXZaHJA6ibvFfiqI22JRd 7EJxm8BdVSeyp+ocE2fZTngQeSdeOOdgKeptkS+/gs6Y504KGi3zOo9Eb1dVS+hcT8/l jBTC9fCXRZpdPz0HyrEqGCuvJD/qXqu6hZU0XA7BE7pvThqS8Goi/JgBEfH79pZYXBg6 YFSw== X-Gm-Message-State: APjAAAV6+mQ9sq6GI4WdXyUK1hk8BhlViZF4rxFUagBOJFqCSNCuF5yK nNXh3vswQZOJ8XgdcJFFS5a2P4TmK9PIiM0KXD4= 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) MIME-Version: 1.0 References: <2715311.ceefYqj39C@omega> <8979488.cRkkfcT1mV@omega> <87168b28-192b-6666-e9b6-9cdc2ed3917a@cs.ucla.edu> In-Reply-To: <87168b28-192b-6666-e9b6-9cdc2ed3917a@cs.ucla.edu> From: Pip Cet Date: Sat, 29 Jun 2019 06:48:24 +0000 Message-ID: Subject: Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers To: Paul Eggert Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::32d X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 36370@debbugs.gnu.org, bug-gnulib@gnu.org, Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" 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.