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
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
> > 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
> >
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
