You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@pv correctly notes that a few C source files are missing from our coverage report.
Digging through a recent master branch build log, I can see some "warning" style output for gcov of this nature:
./_configtest.gcda:stamp mismatch with notes file
./build/temp.linux-x86_64-3.6/numpy/core/src/dummymodule.gcda:cannot open data file, assuming not executed
./build/temp.linux-x86_64-3.6/numpy/core/src/private/mem_overlap.gcda:stamp mismatch with notes file
./build/temp.linux-x86_64-3.6/numpy/core/src/private/npy_longdouble.gcda:stamp mismatch with notes file
./build/temp.linux-x86_64-3.6/numpy/core/src/private/ufunc_override.gcda:stamp mismatch with notes file
./empty/_configtest.gcda:cannot open data file, assuming not executed
Possible solutions to this issue have been discussed elsewhere & appear related to build / machine time stamps relative to tests.
When I test locally, this is not reproduced; my current idea is to first open a PR that tries one of the simpler solutions -- i.e., using find to recursively touch the generated *.gcda files. I'll first see if I can reproduce the issue locally by touching the *.c and *.gcno files before running gcov recursively so that the timestamps are messed up. It looks like one user reports that touch may not suffice because the timestamp is actually embedded in the gcda files -- I'll have to check this.
Activity
pv commentedon Aug 21, 2018
Maybe it's related to the fact that some files are compiled twice (included both in umath and multiarray).
If so, gh-10915 should fix it.
tylerjereddy commentedon Aug 21, 2018
The issue for
npy_longdoubleandufunc_overrideis apparently resolved by that PR, butmem_overlapproblem persists even after that refactor.tylerjereddy commentedon Aug 21, 2018
Redundant include / compilations does seem likely given the partial resolution above though, so that's a hint I can perhaps use to track this down.
mattip commentedon Aug 21, 2018
mem_overlap.cappears in two places innumpy/core/setup.py, in the merged_multiarray_umathand in_multiarray_teststylerjereddy commentedon Aug 21, 2018
Yeah, I noticed that
tylerjereddy commentedon Aug 21, 2018
Ok, proposed a fix that works locally in that PR for
mem_overlap