This is the mail archive of the
mailing list for the GCC project.
Re: Dealing with compilers that pretend to be GCC
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.
On 19/01/12 15:39, Ludovic CourtÃs wrote:
Duncan Sands<firstname.lastname@example.org> 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
When I noticed that Clang doesnât support nested functions, I added that
to the test:
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