https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #9 from Jørgen Kvalsvik ---
Created attachment 61335
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61335&action=edit
Patch: fix, printf properly on systems without %zu
I just posted this on gcc-patches. It should fix the issu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #5 from Jørgen Kvalsvik ---
Does the pretty-print.cc test fail, too?
Anyway, the fix is simple, in a way -- we don't really need the full size_t
width (probably), so I'd wager it's harmless to change it to %u. It's not the
nicest ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #2 from Jørgen Kvalsvik ---
Interesting. I looked at the attach'd .gcov file and it is filled with these:
paths covered 1 of zu
Does the target not support size_t with printf("%zu")?
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
