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