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.5 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 CC1201F461 for ; Fri, 28 Jun 2019 13:25:58 +0000 (UTC) Received: from localhost ([::1]:59858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgqt2-0002Hj-Fj for normalperson@yhbt.net; Fri, 28 Jun 2019 09:25:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44724) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgqNC-00046C-Mr for bug-gnulib@gnu.org; Fri, 28 Jun 2019 08:53:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgqNA-0005wR-EK for bug-gnulib@gnu.org; Fri, 28 Jun 2019 08:53:02 -0400 Received: from mail-ot1-x344.google.com ([2607:f8b0:4864:20::344]:37968) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hgqNA-0005u0-5h for bug-gnulib@gnu.org; Fri, 28 Jun 2019 08:53:00 -0400 Received: by mail-ot1-x344.google.com with SMTP id d17so5844673oth.5 for ; Fri, 28 Jun 2019 05:52:56 -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=L1AUz6qMyj8pe+GdE5yXyzrhcez2ctK3qa5IFH+lBR0=; b=D/oTevX7Hb44nkZVLYfWmk0LbEGA3gP0Zz6BN2yQfxFYh9jNm2kflW+gq8bTmJVHZV 86f5UqkGu4ijJtFZn5B/7821qd4l7GHKtk/g1JGG0RiCY9ZdEqZao/JxsBY464tQPbrP R75GYEnlbSbklN/jNc6YYGDhnbugcj990+mj59eAAXf/aWRtLl89EFp7+k0Hlmjf9WxC qQbI7AyLttIeUoVplTvenxsIepMait1iE0aZb2w2B2gtFm/b3V86jFS3cQMG5SZ1jYMT ebbml+fzVAlGUiWFYx4A2UNsheLlXja4bW7OtJQMZn5hr5uTsoPliz+mbvKl4KUJWFki q5dQ== 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=L1AUz6qMyj8pe+GdE5yXyzrhcez2ctK3qa5IFH+lBR0=; b=tZ4CWPROqyIJtUOzkH9d9hB4PQkHHLLgZxVlfxWcvO6q+tYXJR38Ixat2QMUIx5SsO WOPV9amPwxeCMV/7UCzRXAop8mI5ixNPrsNa9Von4rDkcGnrjDQAr/Lf2Z+uMmNeR7Jh Rei9UeVw9wzN770CihMo3lvi/4VuSzGefpTv0imWW21NqejiyYXDtbez9fRqpsyFVbUJ 8B7lqtqrlti2SqrDjTRvN6Oj+lP5l4NQ5nZLfs81x+SX4iOlkDsnB3PrXoPbTpI0yMee rSYLVvTUXkNwRh+v2X3dsM9Gr4ak8D6UzHzBMAKzUP6InN1o56TjHVyU31iibBwNZhfZ sfNQ== X-Gm-Message-State: APjAAAXZ4B8NOPqgNU2N8mFKdtyU3o4u0p9ogK85JtZo5unljwu2g3PR B1gMU+8j6VeyjflbaRA5B/4gOK8rOU2abUXR6V+sJEUWZKM= X-Google-Smtp-Source: APXvYqyjcxCDM8hMl9kUTZTLZ1SkJ6SrwuSHb4c0xF/ORDe83Q/EY0nO8EqRHrR0NdPWIHVkPot7rjfTJZ0qm2eUSII= X-Received: by 2002:a9d:664c:: with SMTP id q12mr6891215otm.175.1561720011882; Fri, 28 Jun 2019 04:06:51 -0700 (PDT) MIME-Version: 1.0 References: <5284eb58-3560-da42-d1d1-3bdb930eae49@cs.ucla.edu> <2715311.ceefYqj39C@omega> In-Reply-To: <2715311.ceefYqj39C@omega> From: Pip Cet Date: Fri, 28 Jun 2019 11:06:15 +0000 Message-ID: Subject: Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers To: Bruno Haible 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::344 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, Paul Eggert , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Thu, Jun 27, 2019 at 11:45 PM Bruno Haible wrote: > Can you please show an example code on which the change makes a difference? int main(void) { eassume (printf("hi\n")); return 0; } Or, more realistically: extern int potentially_inlined_function(int i); int main(void) { ... eassume(potentially_inlined_function(i)); return i >= 0; } With the old gnulib eassume, the programmer has to know whether potentially_inlined_function is inlined (in which case the eassume appears to be treated as a nop) or not (in which case a potentially expensive external function call is generated). With the new eassume, these cases are distinguished by the compiler. This makes it safe to use function expressions in eassume, whether the function is inlined or not. (That GCC doesn't actually do very much with this information is a separate issue). This approach does fail for certain compound expressions passed as arguments to eassume: eassume(i >= 0 && i < complicated_function ()); will not "split" the && expression, so it'll behave differently from eassume(i >= 0); eassume(i < complicated_function ()); But even in those cases, this approach is better than the old approach of actually evaluating complicated_function. At first, I thought it would be better to have a __builtin_assume expression at the GCC level, but even that would have to have "either evaluate the entire condition expression, or evaluate none of it" semantics. We'll just have to get used to splitting our eassumes, I think.