From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) by sourceware.org (Postfix) with ESMTPS id 116603858D1E for ; Sun, 17 Apr 2022 11:27:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 116603858D1E Received: by mail-lf1-x12f.google.com with SMTP id b21so20501502lfb.5 for ; Sun, 17 Apr 2022 04:27:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:from :subject:to:references:content-language:in-reply-to :content-transfer-encoding; bh=B8VnY0g+AHKgdU1kPBSS7ezz7B7djc5DVt7o+sD5LI0=; b=tjr040K8J9uetxXRQKDMn4rPUOq6pjkGNZSTwUU+iAD0I6p+ufgftzIzEAq/cmJhRU xAisljBo1yWb4G+s2vQsPOiOO9hfVWej5OkgDb5YNiPqF7UtYg4vRDTQ1hVTR6AmxNUM rS5PBYwpgbCUY9ApEtFp49P50v5YrQVFjiw84dih6Z7qIc3aqxuO/2l3a0RbclQlmnAJ INrsee31Uw0DjxecwPA8SHDUzUc1EkUrK/afJtommLlNhRvBI3DHG2q/xiZ7Owny3hvL i2b8REUtpi1SnjaxpUxkJ2bRiEzyC9pB5AXLOKjaJMw5qOB9vOyBBs29pegNpqVNVWXB Lsvw== X-Gm-Message-State: AOAM530wTzl1hhSjumoQdoXdzlh1/eAC1VYW6BX6CMxQUPyYnQeGo3/R CfvKikA8dB/EYaALTXZ2a9YxHA== X-Google-Smtp-Source: ABdhPJwUGje1SzRfwUQ9gtjJkDtWGCP9Vu+A31aSPyCLyyUymhG9XGBrD1a8EnEFlrLuri1DNvkrDw== X-Received: by 2002:a05:6512:3408:b0:44f:5478:8e48 with SMTP id i8-20020a056512340800b0044f54788e48mr4795627lfr.173.1650194833240; Sun, 17 Apr 2022 04:27:13 -0700 (PDT) Received: from [192.168.100.2] ([84.214.39.134]) by smtp.gmail.com with ESMTPSA id a27-20020a19fc1b000000b004704dbac1b0sm488067lfi.14.2022.04.17.04.27.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Apr 2022 04:27:12 -0700 (PDT) Message-ID: <67e557c7-f03e-9c0b-faf1-fefbecddcac6@woven-planet.global> Date: Sun, 17 Apr 2022 13:27:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 From: =?UTF-8?Q?J=c3=b8rgen_Kvalsvik?= Subject: Re: [PATCH] Add condition coverage profiling To: Sebastian Huber , gcc-patches@gcc.gnu.org References: <1ee43d5d-9c6c-f55b-e5b1-c82a6ff5f653@embedded-brains.de> <135f1f97-9359-f3fa-7718-4384aa9a376f@woven-planet.global> <119d52c0-713a-b55b-8745-53a2307dfd9f@embedded-brains.de> Content-Language: en-US In-Reply-To: <119d52c0-713a-b55b-8745-53a2307dfd9f@embedded-brains.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SCC_5_SHORT_WORD_LINES, 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: Sun, 17 Apr 2022 11:27:17 -0000 On 06/04/2022 09:35, Sebastian Huber wrote: > Ok, for the default output this is good. The output can be explained in the > documentation. I will try to help here. Splendid, thanks! I would be perfectly happy with better and/or more intuitive messages too, but I figured it shouldn't delay the rest of the algorithm. > In theory, would it be possible to print the state of the truth table with the > information available in the gcda and gcno files? For example: > > Truth table for: a && (b || c)) && d > > 0 | 1 | 2 | 3 || covered > --+---+---+---++-------- > 0 | X | X | X || Y > 0 | X | X | X || Y > 0 | X | X | X || Y > 0 | X | X | X || Y > 0 | X | X | X || Y > 0 | X | X | X || Y > 0 | X | X | X || Y > 0 | X | X | X || Y > 1 | 0 | 0 | X || N > 1 | 0 | 0 | X || N > 1 | 0 | 1 | 0 || N > 1 | 0 | 1 | 1 || N > 1 | 1 | X | 0 || Y > 1 | 1 | X | 0 || Y > 1 | 1 | X | 1 || Y > 1 | 1 | X | 1 || Y Maybe? We would at least need to store the masking tables too, which right now are implicitly stored as in the instrumentation. It's not too bad, but it probably means the two functions should return some richer structure, which in turn means a little bit of redesign. Computing the truth table itself shouldn't be difficult. > Would it be possible to map the condition index to a source code snippet? For > example condition 1 to "b"? Not sure - I didn't find an obvious way from location, but gcc is already able to point to bad names in complex expressions so I'm sure it is doable. If it can warn about possibly-uninitialized there's no reason it shouldn't be able to figure this out. It has the basic block for the condition. - I think I have figured out the correct approach for computing masking vectors, which means I should be able to submit the updated patch next week. I have a little bit more testing to do before that, including trying out the nested-for error Sebastian found. I also went back on a decision: if (a) if (b) if (c) { ... }; // no else should be treated as if (a && b && c) {}. It is to be expected that a compiler makes some minor transformations, and it is more correct that masking works for (a && b && c) than for the (equivalent) nested-if being different expressions. The same kind of "reinterpretation" happens with branch coverage, so there is some precedence. This also means updating a few tests and figuring out how to handle the conditions inserted by destructors. Do they have some special basic block flag or property? -- Thanks, Jørgen