Dealing with compilers that pretend to be GCC

[Duncan Sands]

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’.