Hi Ludo,
A number of compilers claim to be GCC, without actually being GCC. This has come to a point where they can hardly be distinguished–until one actually tries to use them.
this suggests that you shouldn't be testing for GCC, and instead should be testing for support for particular features. For example, to know if nested functions are supported you would have your configure script compile a mini program that uses nested functions. Ciao, Duncan.
I had the following macro to determine whether plug-in support is available: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?view=markup&revision=5169&root=starpu&pathrev=5202 The macro is fairly elaborate. Yet, ICC 12.0.1 and Clang 3.4 both pass the test, because: - They support ‘--version’; - They define ‘__GNUC__’, which defeats Autoconf’s ‘_AC_LANG_COMPILER_GNU’. - They support ‘-print-file-name’, and have ‘-print-file-name=plugin’ return GCC’s (!) plug-in header directory. To that end, ICC simply runs ‘gcc -print-file-name=plugin’, while Clang appears to be doing some guesswork. It turns out that ICC manages to build a working GCC plug-in, so after all, it may be “entitled” to define ‘__GNUC__’, in a broad sense. Conversely, Clang doesn’t support several GNU extensions, such as nested functions, so it quickly fails to compile code. Based on that, I modified my feature test like this: https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203 I don’t see what can be done on “our” side (perhaps Autoconf’s feature test could be strengthened, but how?), but I wanted to document this state of affairs. Thanks, Ludo’.
