[PATCH] Correct language options from the driver

[Alp Toker]

On 31/05/2014 00:53, Eli Bendersky wrote:
>
>
>
> On Fri, May 30, 2014 at 2:43 PM, Richard Smith <richard at metafoo.co.uk 
> <mailto:richard at metafoo.co.uk>> wrote:
>
>     On Thu, May 29, 2014 at 6:33 AM, Aaron Ballman
>     <aaron at aaronballman.com <mailto: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

The standard may say so, but in practice there's value in allowing users 
to mix and match:

Apart from clearly useful modes like using OpenCL from C++ that nobody 
thought of, but happened to work when a user tried, there are less 
obvious benefits like early compatibility testing while new standards 
are in development.

Without that, any ambiguities or conflicts would remain theoretical 
until the relevant specifications have been standardized and enums 
updated in clang, by which time it'll be too late to specify the 
standard so that they're compatible with others.

My take on this is to treat language standards more like language 
extensions where possible (which is mostly already the case internally).

Alp.



> , 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
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

-- 
http://www.nuanti.com
the browser experts