Compiler records track a style ID that specifies how the tester should invoke the compiler. At time of writing, there is only one style: GCC, which supports both GCC and Clang. Many further compilers (#52, #55) support at least a GCC compatibility mode, and so this style is surprisingly versatile.
While some compilers (eg #53, and Intel on Windows) will need an entirely separate compiler style, it would be nice to have a way to deal with the specific nuances of other compilers. For example, icc supports several extended machine optimisation profiles that gcc doesn't, and Apple clang has optimisation modes that normal clang doesn't. Further, if we implement #54, different compiler families have different versions.
This issue suggests having a hierarchy of compiler families in a similar vein to the hierarchy of the architecture family, with compiler drivers being able to support various additional flows based on minor compiler sub-families. I haven't thought specifically how this will work, as I'm contemplating possibly making the compiler invocation more data-driven, but this issue tracks the general idea of doing so.
Compiler records track a
styleID that specifies how the tester should invoke the compiler. At time of writing, there is only onestyle: GCC, which supports both GCC and Clang. Many further compilers (#52, #55) support at least a GCC compatibility mode, and so this style is surprisingly versatile.While some compilers (eg #53, and Intel on Windows) will need an entirely separate compiler style, it would be nice to have a way to deal with the specific nuances of other compilers. For example,
iccsupports several extended machine optimisation profiles thatgccdoesn't, and Apple clang has optimisation modes that normal clang doesn't. Further, if we implement #54, different compiler families have different versions.This issue suggests having a hierarchy of compiler families in a similar vein to the hierarchy of the architecture family, with compiler drivers being able to support various additional flows based on minor compiler sub-families. I haven't thought specifically how this will work, as I'm contemplating possibly making the compiler invocation more data-driven, but this issue tracks the general idea of doing so.