RFC: Default language standard mode policy

Sean Silva via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 29 12:30:33 PDT 2016

On Wed, Jun 29, 2016 at 12:09 PM, Richard Smith via cfe-commits <
cfe-commits at lists.llvm.org> wrote:

> Hi all!
> I'd like to establish a policy for Clang's default language standard (if
> none is specified with -std), as follows:
>   Clang defaults to the most recent published standard for the selected
> language that it fully implements.
> The practical impact of this is that clang++ will default to C++14 for C++
> compilations (for version 3.9 onwards) and will default to C++17 once our
> implementation support is complete and the standard is published (whichever
> happens later).
> I'd suggest that we apply the same policy for clang-cl, but if it's
> important that we enable a not-yet-fully-implemented standard for cl
> compatibility, that seems reasonable.
> The question of whether the default mode for the GCC-compatible driver
> should be -std=gnuXXX or -std=cXXX is separate, but also likely worth
> discussing. Enabling GNU keywords by default is a very odd choice, and if
> we believe we can change our defaults without breaking the world then this
> seems like a good time to do so.

Using cXXX instead of gnuXXX would break the world on PS4. So for sure with
`-std=c++latest` we would end up proposing a patch to change this for the
PS4 target to gnu++latest (or gnu++11 if gnu++latest is not feasible).
(As I'm sure you're aware, we have pending to upstream a patch that makes
-std=gnu++11 the default C++ language mode on PS4 (just blocked on fixing
tests to not assume the existing std)).

It may be feasible for us to use a "-std=gnu++latest" behavior and not have
to have a PS4-specific default; CC'ing Warren and Paul.

-- Sean Silva

> I also intend to make explicit in our documentation that our -std=XXX flag
> enables the selected standard, *plus all relevant issues in Defect Report
> status from the relevant language committee* (it doesn't make sense to
> support a language without its bugfixes).
> Thoughts?
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20160629/3a03288b/attachment-0001.html>

More information about the cfe-commits mailing list