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.7 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 B97831F461 for ; Fri, 28 Jun 2019 12:32:28 +0000 (UTC) Received: from localhost ([::1]:59294 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgq3H-0000dY-Og for normalperson@yhbt.net; Fri, 28 Jun 2019 08:32:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35153) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgq3D-0000Yq-4h for bug-gnulib@gnu.org; Fri, 28 Jun 2019 08:32:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgq3C-0003m9-0s for bug-gnulib@gnu.org; Fri, 28 Jun 2019 08:32:23 -0400 Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::1]:16795) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hgq3B-0003lC-PS for bug-gnulib@gnu.org; Fri, 28 Jun 2019 08:32:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1561725139; 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=cVrvP86fVI4HbdtgdDoi57Pb+3PlWDZrJVaoYWNwDeg=; b=ARhI+HppimXfWjGzzRE7OK9Tfuiu4ZmcAH5g+EanOUKLdEehMR+XrnJCNc4Bu9dKkh KpZWm/TW1WW0cYKuJg8izN89R7iU+IdYD4V8Sm3rgn3eoqIYXyumv2EGJ9+aveQ+G2uC F69PzQVzhFBQfOOTAqdclU3oogzU7wmRcd65bcYPG5VjhhryNenXvDBmn1QnCO3g7Xsr rCtFOfSgPNU54Pn7ltWqqJJ3Nyw/MbbKZIzzcFhpmWC1N2OllCq6G/bEIrv4eaNEwa8D LWB/9L4Dz4lyNHX+Q18XVpaYwYYpMC3O5YU+m73V2xcZtJ30ppuDaSEDEK7Gjq6Hupud VA9A== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOGaf0zJZW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 44.24 DYNA|AUTH) with ESMTPSA id v018bcv5SCEFhnF (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 14:14:15 +0200 (CEST) From: Bruno Haible To: Pip Cet Subject: Re: bug#36370: 27.0.50; XFIXNAT called on negative numbers Date: Fri, 28 Jun 2019 14:14:14 +0200 Message-ID: <8979488.cRkkfcT1mV@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-151-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <2715311.ceefYqj39C@omega> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::1 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" Pip Cet wrote: > Or, more realistically: > > extern int potentially_inlined_function(int i); > > int main(void) > { > ... > eassume(potentially_inlined_function(i)); > return i >= 0; > } OK, I see... > This makes it safe to use function expressions in eassume, whether the > function is inlined or not. By "safe" you mean that you want the function call to not be evaluated. You are mentioning a limitation: > eassume(i >= 0 && i < complicated_function ()); > > will not "split" the && expression, so it'll behave differently from > > eassume(i >= 0); > eassume(i < complicated_function ()); And I would mention a regression: When -flto is in use and the expression invokes an external potentially-inlined function, the old 'assume' would work fine, i.e. do optimizations across compilation-unit boundaries. Whereas the new 'assume' does not. Test case: ================================ foo.c ================================= #include #define assume(R) ((R) ? (void) 0 : __builtin_unreachable ()) //#define assume(R) (!__builtin_constant_p (!(R) == !(R)) || (R) ? (void) 0 : __builtin_unreachable ()) extern int complicated (int i); extern int nonnegative (int i); int f_generic (int i) { printf("%d\n", i & 0x80000000); return 0; } int f_condition (int i) { if (complicated (i) && i >= 0) printf("%d\n", i & 0x80000000); return 0; } int f_assume (int i) { assume (complicated (i) && i >= 0); printf("%d\n", i & 0x80000000); return 0; } ================================= bar.c ================================ int complicated (int i) { return (i & 7) == 3; } int nonnegative (int i) { return i >= 0; } ======================================================================== $ gcc -O2 -m32 -flto foo.c bar.c -shared -o libfoo.so && objdump --disassemble libfoo.so With the old 'assume': 000005f0 : 5f0: 83 ec 10 sub $0x10,%esp 5f3: 6a 00 push $0x0 5f5: 68 74 06 00 00 push $0x674 5fa: 6a 01 push $0x1 5fc: e8 fc ff ff ff call 5fd 601: 31 c0 xor %eax,%eax 603: 83 c4 1c add $0x1c,%esp 606: c3 ret 607: 89 f6 mov %esi,%esi 609: 8d bc 27 00 00 00 00 lea 0x0(%edi,%eiz,1),%edi With the new 'assume': 00000610 : 610: 83 ec 10 sub $0x10,%esp 613: 8b 44 24 14 mov 0x14(%esp),%eax 617: 25 00 00 00 80 and $0x80000000,%eax 61c: 50 push %eax 61d: 68 48 06 00 00 push $0x648 622: 6a 01 push $0x1 624: e8 fc ff ff ff call 625 629: 31 c0 xor %eax,%eax 62b: 83 c4 1c add $0x1c,%esp 62e: c3 ret 62f: 90 nop 00000630 : 630: eb de jmp 610 > But even in those cases, this approach is better than the old approach > of actually evaluating complicated_function. I disagree that it is better: 1. The new 'assume' is worse when -flto is in use. 2. You recommend to users to split assume(A && B) into assume(A); assume(B); which is unnatural. > 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. No. At GCC level, it could have a "make the maximum of inferences - across all optimization phases -, but evaluate none of it" semantics. Bruno