Make CI use a variety of versions of GCC

[hartwork]

No description provided.

[henry2cox]

Unless I am really forgetting something, each testcase cleans any remaining shrapnel before starting the test (so no need to explicitly make clean), and they also unconditionally build and run whatever executables - so all the data should be from the current test execution, and should be consistent.

It is interesting that the tests pass with gcc/13 - and only with gcc/13.
Several of them are failing on an unexpected gcov version number, and a couple are failing with unexpected hit counts.
The former looks like a configuration issue - picking up wrong tool version.
The latter might be a real issue - if that version of gcc is instrumenting more or fewer lines/branches (need to take a detailed look at the test log/shrapnel for the failing tests - to see if it offers clues).

There appears to be a bug such that all the artifacted files have the same name (so I think only the first one gets stored and the others are skipped - which is why those steps appear greyed out).
If the one I looked at is the one I think it is, it contains valid coverage data - but for whatever reason, the 'criteria' callback thinks that it sees zero covered lines (whereas the coverage DB file shows a lot of them hit)...so maybe they don't line up the way I thought.

[hartwork]

@henry2cox I have one idea left, I'll report back in few minutes, trying it out…

[hartwork]

@henry2cox the idea I had is working now, I just wasn't covering all involved binaries, earlier. The key questions to me now are:

• Are you on board with this approach for a short-term GCC matrix, in general?
• Are GCC 7 and 8 expected to work or can they be ignored and dropped? (not meaning top suggest anything like that) — [Git HEAD] Tests seen fail with GCC 7 and 8 — what is the oldest supported version of GCC? #367
• What's a robust and economic way to live-detect compiler support for -fcoverage-mcdc from within the test suite?
• (Are there any of these versions that you want to exclude in particular, to reduce use of CI resources a bit?)

What do you think?

[henry2cox]

Generally: more testing is better than less - but there is also much point in testing (or supporting) some version that nobody is using. I don't know how to figure out what any particular user is doing, though.

The gcc/7 and 8 failures appear to be related to perl version (newer/more picky than in the past) rather than to gcc.
I think I fixed the regexp in question - so this PR will need to be rebased.

Version-wise: testing with gcc between [4:8] should be equivalent: same path in the lcov code.
gcc/9 is slightly different (intermediate 'text' output)
Then [10:14.2) should be equivalent again.

To detect MC/DC support: one way to detect is to execute gcov --help - then parse the result to see if the --conditiions flag is supported or not. For LLVM: not sure.

[hartwork]

@henry2cox that's helpful — thanks! —, let's see…

[hartwork]

@henry2cox to my surprise, CI is passing now after the rebase even for versions of GCC without MCDC support. I did not expect that — does it make sense to you? Could this be related to issue #368?

[henry2cox]

There is only one testcase that depends on mc/dc -: and that one does an explicit check for version>=14.

Might be better if I hack the detector to ask gov if it supports, though.

[hartwork]

@henry2cox I checked for the failing past output…

lcov/mcdc/mcdc.sh ................. [fail] (time 3.9s, mem 66.6MB)
    Skipping 54 previous lines (see /home/runner/work/lcov-fork/lcov-fork/tests//test.log)
    ...
           --mcdc-coverage --branch-coverage myExe.json
        # and generate a genhtml-format coverage report:
      $ genhtml -o html_report myExe.info ...
    
    Unknown option: unknown_arg
    argparse failedJSON file argument required at /home/runner/work/lcov-fork/lcov-fork/bin/llvm2lcov line 119.
    SKIPPING MC/DC tests:  ancient compiler
    clang: error: unknown argument: '-fcoverage-mcdc'
    ERROR from clang++ clangTest1
  EXITCODE ...: 1
make[3]: *** [../../common.mak:115: check] Error 1
make[2]: *** [../common.mak:115: check] Error 1
28 tests executed, 27 passed, 1 failed, 0 skipped (time 54.4s, mem 1233.1MB)

…and found that I missed the "clang" bit in there. I still don't understand which commit had a changing affect here.

Also: How do you feel about status quo of the pull request?