[PATCH] Correct language options from the driver

Eli Bendersky eliben at google.com
Fri May 30 14:53:57 PDT 2014


On Fri, May 30, 2014 at 2:43 PM, Richard Smith <richard at metafoo.co.uk>
wrote:

> On Thu, May 29, 2014 at 6:33 AM, Aaron Ballman <aaron at aaronballman.com>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140530/be72ac88/attachment.html>


More information about the cfe-commits mailing list