Werner's own blurbs

Identify theft by clang

10 August 2012 5:31 PM (devel | gcc)

For some time now, I receive bug reports against Libgcrypt and GnuPG where the claim is that there is a bug in the code (surprise). Given that both projects have been build on a wide range on platforms using many different C compilers, I was amazed that clang was able to still find other flaws in the code.

On closer inspection it turned out that clang pretends to be gcc! For example clang 3.1 claims to be gcc 4.2.1:

if (!LangOpts.MicrosoftMode) {
  // Currently claim to be compatible with GCC 4.2.1-5621, but only if we're
  // not compiling for MSVC compatibility
  Builder.defineMacro("__GNUC_MINOR__", "2");
  Builder.defineMacro("__GNUC_PATCHLEVEL__", "1");
  Builder.defineMacro("__GNUC__", "4");
  Builder.defineMacro("__GXX_ABI_VERSION", "1002");
}

Well, I would not complain too much about it if clang would really be compatible with that gcc version. But, it is not even compatible to more than 10 years old gcc versions. One example is that clang does not grok the gcc feature of defining extern inline functions. Certain inline asm code does not work either.

Clang is praised a lot for being able to compile all kind of stuff with better performance than gcc. However it often does this only by claiming to be gcc and hoping that it works out.

I consider this default behaviour of clang as an impolite act against the free software community. Do they really want us to change existing code to

#if defined(__GNUC__) && !defined(__clang__)

? I have been hacking C for more than a quarter of a century but can't remember compilers to steal others identity.

Clang folks, please stop defining __GNUC__ by default.

2 responses

  1. Jörg Sonnenberger says:

    People make take you more serious if you actually checked your facts. When it comes to "extern inline" Clang behaves just like GCC would IF the later is in C99 mode. Both define __GNUC_STDC_INLINE__ in that case to declare that they prefer to confirm to C99 and not the original GCCism. For inline assembler it would help to say if the problem is the stricter integrated assembler or the checking of constraints...

  2. Nick Lewycky says:

    Thanks for the comments, as a clang contributor I want to let you know that we're aware of the issues here. Unfortunately, the GCC developers didn't define one way to check for the presence of an extension and another way to check which compiler is in use. You're assuming that __GNUC__ specifies that the compiler is GCC, but I could equally claim that __GNUC__ means that the compiler supports GNU C extensions. You mention that don't know of any other compiler that does this, but both ICC (Intel) and the EDG frontend in its gcc-compatibility mode also define __GNUC__.

    And clang does support GNU C extensions. There are very few extensions we won't support (__builtin_va_arg_pack_len comes to mind) and there are always bugs, but it works out of the box codebase. Again unfortunately, gcc doesn't provide per-extension feature tests. Hopefully gcc will adopt our feature checking macros some day: http://clang.llvm.org/docs/LanguageExtensions.html#id2

    As for extern inline, I suspect the problem is that clang defaults to C99 while GCC defaults to C89. Try passing -std=gnu89 or -fgnu89-inline to clang, or better, realize that 1999 was a long time ago and start passing -std=gnu99 to gcc and update your code. See http://clang.llvm.org/compatibility.html#inline

    Inline assembly is a thornier issue, one I'd need to deal with on a case-by-case basis. In general if it isn't working with clang then either the inline asm was wrong and not guaranteed to work with future gcc's per gcc's own documentation, or you've encountered a clang bug, which is sadly more common than I'd like.

Leave a Reply