We (me, @mbyzhang and others) have put some work into making CIL work with Clang in addition to GCC. The changes are not huge but do require modelling the slightly different dialects of C that each recognises, especially in the lexer where it is important to recognise built-in typenames as such.
Might these changes be of interest? We'd like to contribute them if so.
In turn, these changes motivate overhauling the Machdep module in CIL, which of course is generated by probing at configure time a compiler found on the host system. The problem is that GCC and Clang probe slightly differently, so you get a CIL binary that is specialized to either GCC or Clang but cannot work with both (except by using the CIL_MACHINE variable to override things).
We have an approach for avoiding this problem by largely dispensing with Machdep (and dropping much of its associated build-time complexity!). Instead, CIL is changed to:
- expect input code that has been preprocessed with the
-dD option, and so embeds all used macro definitions as #define lines in the preprocessor output
- use these built-in macros to understand the machine/implementation, since they contain definitions for things like
__SIZEOF_WCHAR_T__ and so on, i.e. we can do without the probed values found in the generated Machdep module. (To see these built-in macros: cc -E -o - -Wp,-dD - </dev/null)
I suspect that this approach was not taken initially because (at a guess) MSVC does not have this -dD preprocessor option. In fairness, nor do some other compilers that are sometimes of interest, like pcc or tcc. However, GCC and Clang both do support it. And as a fallback, it is still possible to probe at configure time and have this provide the "default answers" i.e. the values used when no #define lines are found in the input file.
Any thoughts? We have this implemented already, although there is some minor tidying up to do.
We (me, @mbyzhang and others) have put some work into making CIL work with Clang in addition to GCC. The changes are not huge but do require modelling the slightly different dialects of C that each recognises, especially in the lexer where it is important to recognise built-in typenames as such.
Might these changes be of interest? We'd like to contribute them if so.
In turn, these changes motivate overhauling the
Machdepmodule in CIL, which of course is generated by probing at configure time a compiler found on the host system. The problem is that GCC and Clang probe slightly differently, so you get a CIL binary that is specialized to either GCC or Clang but cannot work with both (except by using theCIL_MACHINEvariable to override things).We have an approach for avoiding this problem by largely dispensing with
Machdep(and dropping much of its associated build-time complexity!). Instead, CIL is changed to:-dDoption, and so embeds all used macro definitions as#definelines in the preprocessor output__SIZEOF_WCHAR_T__and so on, i.e. we can do without the probed values found in the generatedMachdepmodule. (To see these built-in macros:cc -E -o - -Wp,-dD - </dev/null)I suspect that this approach was not taken initially because (at a guess) MSVC does not have this
-dDpreprocessor option. In fairness, nor do some other compilers that are sometimes of interest, likepccortcc. However, GCC and Clang both do support it. And as a fallback, it is still possible to probe at configure time and have this provide the "default answers" i.e. the values used when no#definelines are found in the input file.Any thoughts? We have this implemented already, although there is some minor tidying up to do.