https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119553
--- Comment #3 from Jørgen Kvalsvik ---
Created attachment 60933
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60933&action=edit
Proof of concept fix
I could reproduce it on my system, and this patch fixed the crash.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119553
--- Comment #1 from Jørgen Kvalsvik ---
Thanks for the report. I think I know what's wrong. When -fpath-coverage (and
really -fprofile-arcs, -fcondition-coverage) is used without -ftest-coverage,
some file output is not enabled. There is a guard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117415
--- Comment #3 from Jørgen Kvalsvik ---
>From a quick look it seems like the problem is fundamentally the difference in
how gcc counts executions (on the basic block) and how that is mapped to lines.
I don't know if there a complete fix if the e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115047
--- Comment #4 from Jørgen Kvalsvik ---
> I guess it would be desirable to (1) let LLVM support masking MC/DC and (2)
> let
gcov support unique-cause MC/DC. The first seems easier and I might try
implementing a prototype.
There is room for bot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115047
--- Comment #2 from Jørgen Kvalsvik ---
> f(1, 0, 0) = false, while f(1, 0, 1) = true
Sorry, I meant:
f(0, 0, 1) = true
f(0, 0, 0) = false
and
f(1, 0, 1) = true
f(1, 0, 0) = false
It does not take away from the conclusion when doing masking M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115047
--- Comment #1 from Jørgen Kvalsvik ---
gcc is not wrong here - f(1, 0, 0) = false, while f(1, 0, 1) = true so clearly
c has an independent effect on the outcome here, and both its values has been
observed.
I think clang measures unique-cause a
