----- Original Message ----- > From: "Reid Kleckner via cfe-commits" <cfe-commits@lists.llvm.org> > To: "David Blaikie" <dblai...@gmail.com> > Cc: "cfe-commits" <cfe-commits@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@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
