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 #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
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=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=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=120086
--- Comment #15 from Jørgen Kvalsvik ---
I don't know why it's only defined for rtems, but I would imagine it's either
an oversight, or that it's the only target with libatomic support without
hardware atomics. Is there a libatomic for hppa, or
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=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=120086
--- Comment #13 from Jørgen Kvalsvik ---
(In reply to John David Anglin from comment #12)
> With patch, gcov-29 now passes. But gcov-30 fails with excess errors
>
> FAIL: gcc.misc-tests/gcov-30.c (test for excess errors)
> Excess errors:
> /ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #18 from Jørgen Kvalsvik ---
Ok, thanks, I pushed a fix for the gcov %zu prints, at least for gcov.
To recap:
* gcov-pr86536.c sporadically fails? (which has to be unrelated to these
prints)
* -fprofile-update=atomic warns (and fai
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120086
--- Comment #21 from Jørgen Kvalsvik ---
Does that mean that the feature detection of atomics, leading to the use
BUILT_IN_ATOMIC_FETCH_* is wrong? We use the BUILT_IN for emitting
instructions. It could be that it's the detection itself that ne
13 matches
Mail list logo
