Our productizing of llvm+clang is named and branded as hexagon-clang. We are producing a hexagon targeted compiler which does not rely on GNU libc. The product engineers did not want the output of -dumpversion to be 4.2.1 for our product, as this would imply some degree of compatibility with GNU libc. This change provides us with a mechanism to rebrand and change/enhance the product name, as well as emit a different sequence of digits for -dumpversion.
I realize that the predefines for __GNUC_MINOR__ and its variants are unchanged. It was simply the -dumpversion output we wanted modified. The changes as submitted allow for the 4.2.1 to be emitted by default. Ron. -----Original Message----- From: Rafael Espíndola [mailto:[email protected]] Sent: Monday, August 27, 2012 1:05 PM To: [email protected] Cc: [email protected]; [email protected]; Chandler Carruth Subject: Re: [cfe-commits] [PATCH] Add configuration of CLANG_VENDOR, VENDOR_GCC_VERISON > Note: > Two patches associated with this commit, first for llvm, second for clang. > The clang patch > 0002-Add-configuration-of-CLANG_VENDOR-VENDOR_GCC_VERISON.patch > depends on the llvm patch > 0001-Add-configuration-of-CLANG_VENDOR-VENDOR_GCC_VERISON.patch Changing the gcc version in only some places is strange. It would still define __GNUC_MINOR__ to be 2 for example. Some time ago Chandler convinced me that we should keep pretending to be 4.2 and ask users to check for clang directly when they want to detect if a new feature is supported. Is there a reason why you need clang to claim to be another version of gcc? Cheers, Rafael _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
