public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Jørgen Kvalsvik" <jorgen.kvalsvik@woven-planet.global>
To: Sebastian Huber <sebastian.huber@embedded-brains.de>,
	gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Add condition coverage profiling
Date: Tue, 2 Aug 2022 09:58:08 +0200	[thread overview]
Message-ID: <451bb5f5-ed93-b0ae-237c-9b5d893592a7@woven-planet.global> (raw)
In-Reply-To: <371c5653-59a8-6ca5-819b-76ab74e86625@woven-planet.global>

On 15/07/2022 15:47, Jørgen Kvalsvik wrote:
> On 15/07/2022 15:31, Sebastian Huber wrote:
>> On 15.07.22 13:47, Jørgen Kvalsvik via Gcc-patches wrote:
>>> 2. New vocabulary for the output - decisions for, well, the decisions. It also
>>> writes at most one line per condition:
>>>
>>>     decisions covered 1/4
>>>     condition  0 not covered (true false)
>>>     condition  1 not covered (true)
>>
>> Do we really have multiple decisions? I think we have only one decision composed
>> of conditions and zero or more boolean operators. We have variants of condition
>> outcomes.
>>
> 
> Maybe, I'm not sure - you could argue that since a fixture of boolean
> "dominates" the outcome (either by short circuiting subsequent terms or masking
> preceding terms) then that fixture is a decision which leads to one of two
> outcomes.  The other parameters may change but they wouldn't change the
> decision. You have 2^N inputs but only N+1 decisions. Personally the "variants"
> phrasing doesn't feel right to me.
> 
> That being said I'm open to making this whatever the maintainers feel is
> appropriate.

Coming back to this, this is the terms + definitions gracefully borrowed from
wiki [1]:

Condition
    A condition is a leaf-level Boolean expression (it cannot be broken down
into simpler Boolean expressions).

Decision
    A Boolean expression composed of conditions and zero or more Boolean
operators. A decision without a Boolean operator is a condition.

Condition coverage
    Every condition in a decision in the program has taken all possible outcomes
at least once.

Decision coverage
    Every point of entry and exit in the program has been invoked at least once,
and every decision in the program has taken all possible outcomes at least once.



I agree that decisions n/m, based on these definitions, is not the best output
unless it is specifically overloaded to mean "the family of bit vectors that
cover some conditions". Not great.

Based on this established terminology I can think of a few good candidates:

condition outcomes covered n/m
outcomes covered n/m

What do you think?

[1] https://en.wikipedia.org/wiki/Modified_condition/decision_coverage

  reply	other threads:[~2022-08-02  7:58 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-15 11:39 Jørgen Kvalsvik
2022-07-15 11:47 ` Jørgen Kvalsvik
2022-07-15 13:31   ` Sebastian Huber
2022-07-15 13:47     ` Jørgen Kvalsvik
2022-08-02  7:58       ` Jørgen Kvalsvik [this message]
2022-08-04  7:43         ` Sebastian Huber
2022-08-04  9:13           ` Jørgen Kvalsvik
  -- strict thread matches above, loose matches on Subject: below --
2022-10-12 10:16 Jørgen Kvalsvik
2022-10-18  0:17 ` Hans-Peter Nilsson
2022-10-18 10:13   ` Jørgen Kvalsvik
2022-07-11 10:02 Jørgen Kvalsvik
2022-07-12 14:05 ` Sebastian Huber
2022-07-13  2:04   ` Jørgen Kvalsvik
2022-03-21 11:55 Jørgen Kvalsvik
2022-03-24 16:08 ` Martin Liška
2022-03-25 19:44   ` Jørgen Kvalsvik
2022-03-28 13:39     ` Martin Liška
2022-03-28 13:52     ` Jørgen Kvalsvik
2022-03-28 14:40       ` Jørgen Kvalsvik
2022-04-07 12:04         ` Martin Liška
2022-04-19 14:22           ` Jørgen Kvalsvik
2022-04-07 16:53         ` Sebastian Huber
2022-04-08  7:28           ` Jørgen Kvalsvik
2022-04-08  7:33             ` Jørgen Kvalsvik
2022-04-08  8:50               ` Sebastian Huber
2022-04-04  8:14 ` Sebastian Huber
2022-04-05  7:04   ` Sebastian Huber
2022-04-05 20:07   ` Jørgen Kvalsvik
2022-04-06  7:35     ` Sebastian Huber
2022-04-17 11:27       ` Jørgen Kvalsvik
2022-04-22  5:37         ` Sebastian Huber
2022-04-22 10:13           ` Jørgen Kvalsvik
2022-07-08 13:45 ` Sebastian Huber
2022-07-11  7:26   ` Jørgen Kvalsvik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=451bb5f5-ed93-b0ae-237c-9b5d893592a7@woven-planet.global \
    --to=jorgen.kvalsvik@woven-planet.global \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=sebastian.huber@embedded-brains.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).