On Fri, May 30, 2014 at 2:43 PM, Richard Smith <[email protected]> wrote:
> On Thu, May 29, 2014 at 6:33 AM, Aaron Ballman <[email protected]> > wrote: > >> When setting language option defaults, -std overrides -x for CUDA and >> OpenCL when it should not. For instance, passing -x cuda -std=c++11, >> the CUDA language option would never be set, and so CUDA functionality >> would be disabled. This patch addresses that by setting the language >> option based on the -std or the input file kind. > > > I feel like we're missing some part of the design here. We only have a > single 'LangStandard' value active at once, but for (say) an OpenCL build, > we need *both* an OpenCL standard *and* a C standard. > AFAIK, for OpenCL and CUDA at least, the version of the compute language standard implies the version of the C/C++ standard it supports, so having a tuple instead of just "opencl1.2" would be superfluous, no? OTOH we don't really support sub-versions of CUDA at this point. Eli > > At the same time, we have a long-standing issue where setting up CFLAGS is > difficult: there's no nice way to say "use C11 for C, and use C++11 for > C++", because build systems usually use the C compilation flags plus some > extra C++-specific flags for C++ builds, so we cannot put -std=c11 into the > C compilation flags (that makes the C++ builds fail). > > This suggests to me that our 'language standard' should perhaps be a tuple > of all the relevant standards, so you could specify that you're using C89, > C++11, OpenCL v1.2, Blocks v<whatever>, OpenMP v<whatever> ... for builds > where those standards are relevant. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
