Closed PHHargrove closed 10 years ago
It does make sense to drop GCC_UPC from the Clang UPC.
I would also add CLANG_UPC but it was pointed to me that both CLANG_UPC and GCC_UPC are probably not be needed. Definitions of GNUC and UPC has the same meaning as GCC_UPC, and clang can differentiate between GUCP and Clang UPC.
I would also add CLANG_UPC but it was pointed to me that both CLANG_UPC and GCC_UPC are probably not be needed.
I disagree since the Berkeley translator can (and will) define __UPC__
and one or both of __GNUC__
and __clang__
. That means __UPC__ && __clang__
is ambiguous (could be BUPC or clang-upc[2c]), and __UPC__ && __GNUC__
can be true for any of the three current translator/compiler choice supported by the upcc driver.
Summary, from the point of view of the guy maintaining UPCR, the test harness and the upcc driver:
__UPC__
and __BERKELEY_UPC__
, maybe defines __GNUC__
and/or __clang__
__UPC__
, __GUPC__
, and __GCC_UPC__
__UPC__
and __clang__
, maybe defines __GNUC__
The main complication is that depending on the backend compiler in use the Berkeley and upc2c translator cases may define __GNUC__
and the Berkeley translator might also define __clang__
So, the "canonical" ID formulae if one removes __GCC_UPC__
but does not add __CLANG_UPC__
:
#if defined(__BERKELEY_UPC__)
#if defined(_GCC_UPC__)
#if defined(__UPC__) && defined(__clang__) && !defined(__BERKELEY_UPC__)
I am OK with needing defined(__UPC__) && defined(__clang__)
to distinguish clang-upc2c, but really dislike the need for && !defined(__BERKELEY_UPC__)
to avoid confusion in the case of BUPC with CC=clang. On this basis, I would still like to see a definition of __CLANG_UPC__
. However, I am fully prepared to add -D__CLANG_UPC__=1
within the upcc driver if you guys would rather not make it predefined within clang-upc[2c]. Just say so and I'll use that approach and drop my request to see it predefined by clang-upc.
Not sure if you will agree this is a bug, but I consider it one....
Currently clangupc (and therefore upc2c) is pre-defining
__GCC_UPC__
. I think it would be far better to have__CLANG_UPC__
or just about anything other than an identifier that is already used to identify a different UPC compiler.FWIW: this definition had hidden upc2c issue #59