[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: Making Debian compiler agnostic

On Tue, Aug 28, 2012 at 10:26:37AM -0700, Russ Allbery wrote:
> Paul Tagliamonte <paultag@debian.org> writes:
> > On Tue, Aug 28, 2012 at 09:27:23AM -0700, Ben Hutchings wrote:
> >> Are all alternate compilers expected to implement gcc extensions?  Must
> >> the code be changed to use appropriate '#ifdef __GNUC__' guards?  (And
> >> what happens the next time gcc adds a new extension...?)

clang #defines __GNUC__ but isn't completely compatible.  In order to
test if it's really GCC, you have to check that __clang__ isn't defined.
As you can see, this quickly becomes problematic if one must check all
the things that the compiler is not to see what the compiler is.

> > clang does a fairly OK job with some of gcc's extentions.
> "Fairly OK" is a good way of putting it.  It's not reached the level of
> "good," but it's probably workable for most practical purposes.  You will
> get spurious warnings about some things, such as some of the __attribute__
> tags, but I don't think I've seen a case where it flatly refuses to
> compile something or miscompiles it.  That said, I've not used some of the
> hairier gcc extensions.

I have some code that uses the __builtin_ia32_* functions for intrinsics
that clang refuses to compile because it has different, incompatible
intrinsics (#653256).  Since clang insists on using __GNUC__, it's
difficult to detect whether the compiler really is GCC or whether it's a
broken clone (which could be clang or something entirely different).
clang upstream does not consider this incompatibility a bug; I do.

brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature

Reply to: