From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) by sourceware.org (Postfix) with ESMTPS id 5FE263858C52 for ; Mon, 4 Apr 2022 08:14:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5FE263858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embedded-brains.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embedded-brains.de Received: from sslproxy02.your-server.de ([78.47.166.47]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nbHrN-000Dz4-9H; Mon, 04 Apr 2022 10:14:49 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy02.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbHrN-000R02-62; Mon, 04 Apr 2022 10:14:49 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id DC4FA4800E9; Mon, 4 Apr 2022 10:14:48 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 20n2p6LlOt_Q; Mon, 4 Apr 2022 10:14:48 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 9177B48010B; Mon, 4 Apr 2022 10:14:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id eGABnMpQqVKy; Mon, 4 Apr 2022 10:14:48 +0200 (CEST) Received: from [10.10.171.14] (unknown [10.10.171.14]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 567674800E9; Mon, 4 Apr 2022 10:14:48 +0200 (CEST) Message-ID: <1ee43d5d-9c6c-f55b-e5b1-c82a6ff5f653@embedded-brains.de> Date: Mon, 4 Apr 2022 10:14:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: [PATCH] Add condition coverage profiling Content-Language: en-US To: =?UTF-8?Q?J=c3=b8rgen_Kvalsvik?= , gcc-patches@gcc.gnu.org References: From: Sebastian Huber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.103.5/26501/Sun Apr 3 10:27:13 2022) X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2022 08:14:53 -0000 Hello J=C3=B8rgen, having support for MC/DC coverage in GCC would be really nice. I tried=20 out your latest patch on an arm cross-compiler with Newlib (inhibit_libc=20 is defined). Could you please add the following fix to your patch: diff --git a/libgcc/libgcov-merge.c b/libgcc/libgcov-merge.c index 89741f637e1..9e3e8ee5657 100644 --- a/libgcc/libgcov-merge.c +++ b/libgcc/libgcov-merge.c @@ -33,6 +33,11 @@ void __gcov_merge_add (gcov_type *counters=20 __attribute__ ((unused)), unsigned n_counters __attribute__ ((unused))) {} #endif +#ifdef L_gcov_merge_ior +void __gcov_merge_ior (gcov_type *counters __attribute__ ((unused)), + unsigned n_counters __attribute__ ((unused))) {} +#endif + #ifdef L_gcov_merge_topn void __gcov_merge_topn (gcov_type *counters __attribute__ ((unused)), unsigned n_counters __attribute__ ((unused))) {} It seems that support for the new GCOV_TAG_CONDS is missing in gcov-tool=20 and gcov-dump, see "tag_table" in gcc/gcov-dump.c and libgcc/libgcov-util= .c. On 21/03/2022 12:55, J=C3=B8rgen Kvalsvik via Gcc-patches wrote: [...] > Like Wahlen et al this implementation uses bitsets to store conditions, > which gcov later interprets. This is very fast, but introduces an max > limit for the number of terms in a single boolean expression. This limi= t > is the number of bits in a gcov_unsigned_type (which is typedef'd to > uint64_t), so for most practical purposes this would be acceptable. > limitation can be relaxed with a more sophisticated way of storing and > updating bitsets (for example length-encoding). For multi-threaded applications using -fprofile-update=3Datomic is quite=20 important. Unfortunately, not all 32-bit targets support 64-bit atomic=20 operations in hardware. There is a target hook to select the size of=20 gcov_type. Maybe a dedicated 64-bit type should be used for the bitfield=20 using two 32-bit atomic OR if necessary. >=20 > In action it looks pretty similar to the branch coverage. The -g short > opt carries no significance, but was chosen because it was an available > option with the upper-case free too. >=20 > gcov --conditions: >=20 > 3: 17:void fn (int a, int b, int c, int d) { > 3: 18: if ((a && (b || c)) && d) > conditions covered 5/8 > condition 1 not covered (false) > condition 2 not covered (true) > condition 2 not covered (false) > 1: 19: x =3D 1; > -: 20: else > 2: 21: x =3D 2; > 3: 22:} I have some trouble to understand the output. Would 8/8 mean that we=20 have 100% MC/DC coverage? What does "not covered (false)" or "not=20 covered (true)" mean? --=20 embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.huber@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht M=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/