r264205 - [CUDA] Don't define __NVCC__.

[David Blaikie via cfe-commits]

Fair enough - 'preciate your perspectives/further details.

On Thu, Mar 24, 2016 at 8:44 AM, Hal Finkel <hfinkel at anl.gov> wrote:

>
> ------------------------------
>
> *From: *"Reid Kleckner via cfe-commits" <cfe-commits at lists.llvm.org>
> *To: *"David Blaikie" <dblaikie at gmail.com>
> *Cc: *"cfe-commits" <cfe-commits at lists.llvm.org>
> *Sent: *Thursday, March 24, 2016 10:39:18 AM
> *Subject: *Re: r264205 - [CUDA] Don't define __NVCC__.
>
> On Thu, Mar 24, 2016 at 8:30 AM, David Blaikie via cfe-commits <
> cfe-commits at lists.llvm.org> wrote:
>>
>> This seems like a different tradeoff from the one Clang made for GCC
>> compatibility (we define all the GCC macros, but then also define others so
>> people can detect Clang). If people were just disabling features that NVCC
>> didn't support, that seems fairly harmless - what sort of
>> problems/difficulties did this create?
>>
>
> I think Clang is aiming for less bug-for-bug compatibility with NVCC than
> with GCC or Clang, so it makes less sense to pretend to be them. I also
> expect that there are fewer checks in the wild for __NVCC__ than for
> _MSC_VER and __GNUC__. If we didn't *have* to define these macros to build
> the world, we wouldn't, and if we can get away without defining __NVCC__,
> that's great.
>
> +1
>
> I don't yet think there is a precedent for other compilers to pretend to
> be nvcc, and I don't think we should start one if it is not necessary. I'm
> sure we have some checks for __NVCC__ witin DOE applications, but I'm happy
> to tell those users to migrate them to __CUDACC__ as appropriate as part of
> transitioning to supporting Clang as a CUDA compiler.
>
>  -Hal
>
>
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
>
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160324/de074e2e/attachment.html>