On 30/04/2024 13:43, Jan Hubicka wrote:
The problem is testing. If gcc would re-number the basic blocks then
tests comparing hard-coded test paths would break, even though the path
coverage itself would be just fine (and presumably the change to the
basic block indices), which would add an unreas
On 30/04/2024 13:43, Jan Hubicka wrote:
The problem is testing. If gcc would re-number the basic blocks then
tests comparing hard-coded test paths would break, even though the path
coverage itself would be just fine (and presumably the change to the
basic block indices), which would add an unreas
> > The problem is testing. If gcc would re-number the basic blocks then
> > tests comparing hard-coded test paths would break, even though the path
> > coverage itself would be just fine (and presumably the change to the
> > basic block indices), which would add an unreasonable maintenance
> > bur
On 30/04/2024 12:45, Richard Biener wrote:
On Tue, Apr 30, 2024 at 11:45 AM Jørgen Kvalsvik wrote:
Hi,
I am working on adding path coverage support to gcc/gcov and need to
develop a good testing strategy.
So far I can reasonably well report on the uncovered path as such:
paths covered 6 of
On Tue, Apr 30, 2024 at 11:45 AM Jørgen Kvalsvik wrote:
>
> Hi,
>
> I am working on adding path coverage support to gcc/gcov and need to
> develop a good testing strategy.
>
> So far I can reasonably well report on the uncovered path as such:
>
> paths covered 6 of 17
> path not covered: 2 8 3 4
>
Hi,
I am working on adding path coverage support to gcc/gcov and need to
develop a good testing strategy.
So far I can reasonably well report on the uncovered path as such:
paths covered 6 of 17
path not covered: 2 8 3 4
path not covered: 2 8 3 5 6
path not covered: 2 8 3 5 7 10
...
where th