On 31/05/2014 00:53, Eli Bendersky wrote:
On Fri, May 30, 2014 at 2:43 PM, Richard Smith <[email protected]
<mailto:[email protected]>> wrote:
On Thu, May 29, 2014 at 6:33 AM, Aaron Ballman
<[email protected] <mailto:[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
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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
http://www.nuanti.com
the browser experts
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
