https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
sshannin at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #7 from Martin Liška ---
(In reply to sshannin from comment #6)
> Since we all agree that the current behavior is undesirable and since Jakub
> proposes a possible solution, would it be reasonable to reopen this?
>
> For large (multi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #6 from sshannin at gmail dot com ---
Since we all agree that the current behavior is undesirable and since Jakub
proposes a possible solution, would it be reasonable to reopen this?
For large (multi-hour) test suites, it would be mea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #5 from Jakub Jelinek ---
There is a way out of this. Defer building those conditionals till the sanopt
pass, before that have new IFN_UBSAN_* internal calls in the IL like we already
do with IFN_UBSAN_{NULL,BOUNDS,OBJECT_SIZE,PTR,VP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #4 from Martin Liška ---
> No, it's not desirable, but the current gcov can't distinguish between read
> code and the instrumented one.
>
* real code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #3 from Martin Liška ---
(In reply to sshannin from comment #2)
> Thanks for such a quick reply. I just wanted to make sure I'm understanding
> you correctly about what you mean when you say this is expected.
>
> Are you indicating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
--- Comment #2 from sshannin at gmail dot com ---
Thanks for such a quick reply. I just wanted to make sure I'm understanding
you correctly about what you mean when you say this is expected.
Are you indicating that it's desirable that the ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90865
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
