[cfe-commits] [PATCH] Add configuration of CLANG_VENDOR, VENDOR_GCC_VERISON

[ronl]

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:rafael.espindola at gmail.com] 
Sent: Monday, August 27, 2012 1:05 PM
To: ronl at codeaurora.org
Cc: llvm-commits at cs.uiuc.edu; cfe-commits at cs.uiuc.edu; 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