From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx.kolabnow.com (mx.kolabnow.com [212.103.80.154]) by sourceware.org (Postfix) with ESMTPS id 0A1023858438 for ; Wed, 3 Aug 2022 13:26:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0A1023858438 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=lambda.is Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=lambda.is Received: from localhost (unknown [127.0.0.1]) by mx.kolabnow.com (Postfix) with ESMTP id A15D84369A for ; Wed, 3 Aug 2022 15:26:00 +0200 (CEST) Authentication-Results: ext-mx-out003.mykolab.com (amavisd-new); dkim=pass (4096-bit key) reason="pass (just generated, assumed good)" header.d=kolabnow.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h= content-transfer-encoding:content-type:content-type:subject :subject:from:from:content-language:mime-version:date:date :message-id:received:received:received; s=dkim20160331; t= 1659533160; x=1661347561; bh=XsSJhkjHmGGd3UfVZfUqlxMicxFSnM5rcek X7wbCFrw=; b=GoUeO3hlbAU5d/FmpMvHobQY+ATxpr8xpp5j4cg+kMhrkka1uR0 cSkXnjf7qCSB4mn7H3jjOXvVgqGXWvXFtdANVA9rr6h5/+T8r3W6WuRJoY2TWXVU +db/Df5cTMuG9PYjd68XZ74G+9MvqDi6ENCL8vy+DHBMo33KmdFID2vnduhPRfAW hORy+ygQfnGU1TP2syM9iwQ0/Qspv84SUHS3pIl4xTZMn8PnX/RwYRq1EmzuLjRW W8R/BE5pJKBbK/fIWVXRf5A1rBUXf2NbUprq8CPUGsthx5EUyQHZTi62U11T24GT B2PWvxp4DYNyANATw4aAxGTZW3yYYG2BuXxvYhSyNkhMn6E490k80XH8FltL3NMh JWX5eHVH7UyDtAZRieqwbZ+ai5Nc1Fu+osevlSIXojUCtZmuif7FktHKkfYKcFo9 5uh/2Z/tiCP/D2V9sowQCetNZySAqCEiMrKS3ZcrIDgjWSG2DnhJe1TnC8yMmDvB 4OOOtdhKG7CGZfjgxmSyXajNcB3A4Ycov6EV2pfg3pF0MWn08sJyh4fu4nUx1wsZ nvHO6b/3JdhQkh59cRlIV9xR0f+Qb696jcu6bGYbCeOjGD20a0j6gegWDNXey751 xRNUKLIl2gOaq52FsgYPUp/QV4OXpMAwgcQ1rnbFbNlJ+U0bRQFY6x9g= X-Virus-Scanned: amavisd-new at mykolab.com X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, KAM_SHORT, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out003.mykolab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6sKuGLNvVoV for ; Wed, 3 Aug 2022 15:26:00 +0200 (CEST) Received: from int-mx003.mykolab.com (unknown [10.9.13.3]) by mx.kolabnow.com (Postfix) with ESMTPS id 5981E43676 for ; Wed, 3 Aug 2022 15:25:59 +0200 (CEST) Received: from ext-subm002.mykolab.com (unknown [10.9.6.2]) by int-mx003.mykolab.com (Postfix) with ESMTPS id 0F226AB8 for ; Wed, 3 Aug 2022 15:25:59 +0200 (CEST) Message-ID: <4ba7b262-ee0b-905f-ba0a-611ee6749184@lambda.is> Date: Wed, 3 Aug 2022 15:25:57 +0200 MIME-Version: 1.0 Content-Language: en-US From: j Subject: gccgo emits GIMPLE with temporaries for boolean expressions unlike gcc, gdc To: gcc@gcc.gnu.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2022 13:26:04 -0000 Hello, I've proposed a patch [1] for condition coverage profiling in gcc, implemented in the middle-end alongside the branch coverage. I've written most of the tests for C and a few for C++ and finally got around to try it with a toy example for D and go and noticed something odd about Go's CFG construction. abc.c: int fn (int a, int b, int c) { if (a && (b || c)) return a; else return b * c; } abc.d: int fn (int a, int b, int c) { if (a && (b || c)) return a; else return b * c; } abc.go: func fn (a int, b int, c int) int { a_ := a != 0; b_ := b != 0; c_ := c != 0; if a_ && (b_ || c_) { return 1; } else { return 0; } } All were built with gcc --coverage -fprofile-conditions (my patch, but it does not affect this) and no optimization. The C and D programs behaved as expected: gcov --conditions abc.d: 3: 3:int fn (int a, int b, int c) { 3*: 4: if (a && (b || c)) conditions outcomes covered 3/6 condition 1 not covered (false) condition 2 not covered (true) condition 2 not covered (false) 1: 5: return a; -: 6: else 2: 7: return b * c; gcov --conditions abc.go: 3: 5:func fn (a int, b int, c int) int { 3: 6: a_ := a != 0; 3: 7: b_ := b != 0; 3: 8: c_ := c != 0; -: 9: 3*: 10: if a_ && (b_ || c_) { condition outcomes covered 2/2 condition outcomes covered 1/2 condition 0 not covered (true) condition outcomes covered 2/2 1: 11: return 1; -: 12: } else { 2: 13: return 0; -: 14: } -: 15:} So I dumped the gimple gcc -fdump-tree-gimple abc.go: int main.fn (int a, int b, int c) { int D.2725; int $ret0; $ret0 = 0; { bool a_; bool b_; bool c_; a_ = a != 0; b_ = b != 0; c_ = c != 0; { { GOTMP.0 = a_; if (GOTMP.0 != 0) goto ; else goto ; : { { GOTMP.1 = b_; _1 = ~GOTMP.1; if (_1 != 0) goto ; else goto ; : { GOTMP.1 = c_; } : } GOTMP.2 = GOTMP.1; GOTMP.0 = GOTMP.2; } : } if (GOTMP.0 != 0) goto ; else goto ; : { { $ret0 = 1; D.2725 = $ret0; // predicted unlikely by early return (on trees) predictor. return D.2725; } } : { { $ret0 = 0; D.2725 = $ret0; // predicted unlikely by early return (on trees) predictor. return D.2725; } } } } } Where as D (and C) is more-or-less as you would expect: int fn (int a, int b, int c) { int D.7895; if (a != 0) goto ; else goto ; : if (b != 0) goto ; else goto ; : if (c != 0) goto ; else goto ; : D.7895 = a; // predicted unlikely by early return (on trees) predictor. return D.7895; : D.7895 = b * c; // predicted unlikely by early return (on trees) predictor. return D.7895; } Clearly the decision inference algorithm is unable to properly instrument to Go program for condition coverage because of the use of temporaries in the emitted GIMPLE. The question is: is this intentional and/or required from Go's semantics or could it be considered a defect? Is emitting the GIMPLE without the use of temporaries feasible at all? Thanks, Jørgen [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598165.html