CI: mismatch between gcov and compiler version for Windows builds?

[fingolfin]

In the "testinstall -- windows-latest" CI jobs, code coverage reporting prints many warnings looking like this:

D:/a/gap/gap/build/obj/src/.libs/ariths.c.gcno:version 'B12*', prefer 'A81*'
D:/a/gap/gap/build/obj/src/.libs/ariths.c.gcda:version 'B12*', prefer version 'A81*'
D:/a/gap/gap/build/obj/src/.libs/ariths.c.gcno:'PostRestore' has arcs to entry block
D:/a/gap/gap/build/obj/src/.libs/ariths.c.gcno:'PostRestore' has arcs from exit block

According to https://stackoverflow.com/a/41247820 this suggests a mismatch between the GCC version which produced those files, and the version of gcov used to produce them. We should audit this.

[wilfwilson]

Thanks for raising this issue. These are the thoughts off the top of my head:

• The Action gap-actions/setup-cygwin could have a problem with installing inconsistent versions, meaning it needs to be updated
• The Action gap-actions/setup-cygwin might need to be called with some custom arguments
• With the Windows CI setup, there is always a tension between the Runner-provided chopped-down version of Cygwin, and the more full-featured version of Cygwin that we install ourselves. We often need to be careful about running the correct version of bash as our shell; sometimes we need the built-in one, sometimes we need our special one. They're basically incompatible.
  • It could be that the Action codecov/codecov-action changed in such a way that it no longer plays nicely with respect to this distinction. E.g. perhaps it is using 'our' gcc but the Runner-provided gcov - something weird like that.
  • This could be resolved by using custom code for uploading the data, or rolling back to a previous version of this Action, or trying to fix codecov/codecov-action directly with a PR.

[ChrisJefferson]

fixed at some point -- not sure exactly what fixed it, but looks good from the output to me