Re: Dealing with compilers that pretend to be GCC

[Duncan Sands <baldrick at free dot fr>]

Hi Ludo, I didn't really get it.  Why do you want to know whether the compiler
is GCC or not?  Presumably because you have several versions of your code,
one version using GCC feature XYZ and the other not using XYZ.  If so, the
logically correct (but maybe impractical) approach is to test if the compiler
supports XYZ, and switch between the two code versions depending on that.
For example if XYZ is "nested functions", do you have a version of your code
that uses nested functions and another that does not?  If you don't have a
version that works with compilers like clang that don't support nested
functions, then why bother testing for nested function support?  You will
discover the lack of nested function support when your code fails to compile.

Ciao, Duncan.

On 19/01/12 15:39, Ludovic CourtÃs wrote:
> Hi Ducan,
>
> Duncan Sands<baldrick@free.fr>  skribis:
>
> > > 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.
>
> Yes.  The macro I posted is a feature test: it tests for plug-in header
> availability, and the availability of several GCC internal types and
> declarations.
>
> When I noticed that Clang doesnât support nested functions, I added that
> to the test:
>
>    https://gforge.inria.fr/scm/viewvc.php/trunk/m4/gcc.m4?root=starpu&r1=5169&r2=5203
>
> Yet, I canât reasonably add a feature test for each GNU extension that
> GCCâs headers or my own code use.  Maybe tomorrow Clang will support
> nested functions, while still lacking support for some other extension
> thatâs needed.
>
> Thanks,
> Ludoâ.