This is an archive of the discontinued LLVM Phabricator instance.

[FrontEnd] Allow overriding the default C/C++ -std via CMake vars

Authored by mgorny on Jun 19 2017, 2:06 PM.



Provide two new CMake cache variables -- CLANG_DEFAULT_STD_C
and CLANG_DEFAULT_STD_CXX -- that can be used to override the default
C/ObjC and C++/ObjC++ standards appropriately. They can be set to one of
the identifiers from LangStandards.def, or left unset (the default) to
respect the current platform default.

This option is mostly intended for compiler vendors that do not wish to
continue defaulting to C++98. We are preparing a new Gentoo release that
requires GCC 6, and therefore defaults to -std=gnu++14. Since we want to
maintain as much compatibility between GCC and clang by default, we
would like to adjust the default for clang appropriately.

The code relies on explicit identifiers rather than the string aliases
for simplicity. This saves us from the necessity of parsing aliases at
build-time or adding additional processing at runtime. For the latter
case, it also adds trivial value check -- if incorrect value is passed,
the code simply fails to compile through referencing an undefined

If the variable is used to redefine the default standard, the explicit
value overrides the special case for PS4. It is done this way mostly
following other kinds of variables where 'platform defaults' are

I'm going to submit more test fixes that add explicit -std=
whenever necessary once this is approved.

Diff Detail


Event Timeline

mgorny created this revision.Jun 19 2017, 2:06 PM

Ping again.

Ping for the third time.

clang 6.0 defaults to C++14, BTW.

Is there a need for this given the changes for 6.0?

rnk accepted this revision.Mar 6 2018, 10:22 AM

Let's do this. I thought we'd already have a higher C++ standard version by now, but apparently not.

This revision is now accepted and ready to land.Mar 6 2018, 10:22 AM
mgorny updated this revision to Diff 137227.Mar 6 2018, 10:38 AM

@rnk, could you confirm the rebased patch? I'm not sure if I should override InputKind::RenderScript as well.

rnk added a comment.Mar 6 2018, 11:39 AM

Yep, looks good. I'd leave renderscript alone. I think it's deprecated.

This revision was automatically updated to reflect the committed changes.