clang : not gcc compatibility mode

[llvmbot]

Bugzilla Link	3993
Resolution	LATER
Resolved on	Jun 13, 2012 13:23
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@efriedma-quic

Extended Description

Hi,

it could be great to have a mode where clang doesn't act like gcc, ie it doesn't define the GNUC & co [1] macro, and doesn't recognized any gcc extension (asm, attribute, ...).

[1] http://gcc.gnu.org/onlinedocs/gcc-4.3.3/cpp/Common-Predefined-Macros.html#Common-Predefined-Macros

[efriedma-quic]

What exactly is the intent here? Having a mode which rejects gcc extensions that are normally accepted with "-std=c99 -pedantic" doesn't seem to be generally useful: it would only catch extensions that were intentionally written into the code.

[llvmbot]

The sort version :
the intent here is to build/test portable code made for c99/(c89) compliant compiler.

The long version :
When you write portable code you use c processor macro to identify the compiler and enable (or not) some extension (for example using gcc attribute only is GNUC is defined).
How could you test this code and make sure it is ISO compliant if available compiler don't allow you to take this code path ?
Only testing that the syntax is compliant won't work, because you want to test the runtime.

Always defining GNUC doesn't help to test this code path.

Always enabling extension doesn't help to identify abuse of them.

A first step could be to extend what is in place for std=c99 and pedantic mode :

• only reconized C token in this mode (for example by extending ./include/clang/Basic/TokenKinds.def flags). This will filter most gnu extension (attribute, asm, typeof, '...').
• filter by diagnostic (like it is done for pedantic).
• c preprocessor define less macro

[efriedma-quic]

Not defining GNUC and refusing to recognize gcc-specific tokens is infeasible because it would screw up system headers. If you want to do testing for alternate codepaths, I'd suggest adding a define like USE_GCC_EXTENSIONS to your code, and use it instead of using GNUC directly.

We could add a flag that would warn on directly using any compiler pre-define, non-standard keyword, or builtin, I guess; would that help?

[llvmbot]

Not defining GNUC work well under Linux (glibc 2.9).

Not recognize gcc-specific tokens mostly works. Some are needed by clang implementation :

• offsetof need __builtin_offsetof
• va_arg need __builtin_va_arg
• clang header need typeof to define system types
  [- linux need signed (but can be easily emulated with -D__signed__=signed)]

With that I was able to build ffmpeg with alsa, v4l, zlib libraries.

PS : I didn't try to remove preprocessor gnu extensions
PS2 : filtering __builtin stuff can be a mess because some are used by clang

[llvmbot]

quick I did to test build without gcc extension

[efriedma-quic]

Hmm, well, I guess it might not actually break, but it'll subtly do nasty stuff to the headers, like not inlining some math functions, removing attributes which lead to better warnings/faster code, including an incorrect definition for alloca, etc.

[llvmbot]

Well the goal is not performance. It is to testing code conformance.

For stuff depending of builtin (like alloca) I think it is fragile to rely on system header made for gcc.
Why clang doesn't provide its own alloca.h in lib/Headers or recognize alloca as a special function ?
alloca is present in ./include/clang/AST/Builtins.def, doesn't it already works even without the "# define alloca(size) __builtin_alloca (size)" ?

[chandlerc]

No updates for a few years, so resolving this old bug.

I think we are already doing quite well here with warnings and a pedantic mode
that warns on all manner of extensions. I'm not sure it is productive to try to
build a Clang compilation mode that ensures a portable path exists through the
preprocessor #if guards...