As compilers evolve, new features appear, older features become deprecated, and workarounds for strange compiler behaviour become necessary or no longer so. Ideally, the tester should do as much of the legwork as to working this out as possible.
Tracking the version of a particular compiler in its configuration will be useful in this regard, because:
filters can be set to trigger only on a certain version (I think the filter format might even already have this set up);
certain m-opts can be tied to certain versions, meaning we don't need to pretend that each compiler targets a different subarchitecture in the config;
same with optimisation levels;
eventually we might want to target compilers that don't support stdatomic (or transactions, or things like that), and version tracking would make it easier for the tester to disable bits of the fuzzer that don't work on certain compilers.
As compilers evolve, new features appear, older features become deprecated, and workarounds for strange compiler behaviour become necessary or no longer so. Ideally, the tester should do as much of the legwork as to working this out as possible.
Tracking the version of a particular compiler in its configuration will be useful in this regard, because: