RFC: Default language standard mode policy

Clang Frontend
1

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.

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?

2

For clang-cl, we should follow cl’s model of selecting a standard. Before C++17, this was “use newest language the compiler knows about” (keyed off -fmsc-version; clang-cl detects the system msvc version by default if that’s not passed in). After C++17, there’s an explicit language flag, and we use the same default as cl.

Last I checked (which was a while ago), libstdc++ didn’t parse with -std=c++14, at least at some version. I don’t remember which version of libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not parsing standard library headers by default on Linux seems like a somewhat suboptimal user experience.

3

For clang-cl, we should follow cl's model of selecting a standard. Before
C++17, this was "use newest language the compiler knows about" (keyed off
-fmsc-version; clang-cl detects the system msvc version by default if
that's not passed in). After C++17, there's an explicit language flag, and
we use the same default as cl.

Is that default something other than "the newest one"?

Last I checked (which was a while ago), libstdc++ didn't parse with

-std=c++14, at least at some version. I don't remember which version of
libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
parsing standard library headers by default on Linux seems like a somewhat
suboptimal user experience.

Last time I looked into this, I saw only one problem with version 4.9: libc
doesn't provide ::gets to C++14, and earlier versions of libstdc++ assume
it's there and do "namespace std { using ::gets; }". We can add a
compatibility hack to clang to work around this.

Note that at this point I'd like to mainly focus on what our policy should
be; there are certainly technical challenges involved in actually applying
the policy (another one is that clang's test suite still has some failures
when the default is changed, but Charles Li has made tremendous headway on
this), and if we can't actually prepare for the transition in the C++
default in time for 3.9, then so be it.

4

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

5

For clang-cl, we should follow cl's model of selecting a standard. Before
C++17, this was "use newest language the compiler knows about" (keyed off
-fmsc-version; clang-cl detects the system msvc version by default if
that's not passed in). After C++17, there's an explicit language flag, and
we use the same default as cl.

Is that default something other than "the newest one"?

It looks like the next MSVC (which adds that flag) defaults to C++14. (See
majnemer's r273841 which implemented this in clang-cl, and

)

Last I checked (which was a while ago), libstdc++ didn't parse with

-std=c++14, at least at some version. I don't remember which version of
libstdc++ I tried (maybe 4.9?). Should that factor into the decision? Not
parsing standard library headers by default on Linux seems like a somewhat
suboptimal user experience.

Last time I looked into this, I saw only one problem with version 4.9:
libc doesn't provide ::gets to C++14, and earlier versions of libstdc++
assume it's there and do "namespace std { using ::gets; }". We can add a
compatibility hack to clang to work around this.

Note that at this point I'd like to mainly focus on what our policy should
be;

Fair enough. I don't have a strong opinion on that; your proposal makes
sense to me. (Except for clang-cl, which I think needs to mirror what cl
does.)

6

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).

OK. Out of interest, is it the GNU keywords that you need, or some other
effect of the difference between modes?

7

+1 to both.

8

From: "Richard Smith via cfe-commits" <cfe-commits@lists.llvm.org>
To: "cfe-commits" <cfe-commits@lists.llvm.org>, "Clang Dev"
<cfe-dev@lists.llvm.org>
Sent: Wednesday, June 29, 2016 2:09:37 PM
Subject: RFC: Default language standard mode policy

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 think that we need to include libc++ in this criteria as well. I think we'll also need some CMake flags to adjust the default for builds for systems on which this won't work.

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.

Unfortunately, on many systems, some standard system headers won't even parse without GNU extensions enabled. I think we'll need to leave the GNU extensions on by default (at least for parsing system headers).

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).

+1

-Hal

9

------------------------------

*From: *"Richard Smith via cfe-commits" <cfe-commits@lists.llvm.org>
*To: *"cfe-commits" <cfe-commits@lists.llvm.org>, "Clang Dev" <
cfe-dev@lists.llvm.org>
*Sent: *Wednesday, June 29, 2016 2:09:37 PM
*Subject: *RFC: Default language standard mode policy

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 think that we need to include libc++ in this criteria as well. I think
we'll also need some CMake flags to adjust the default for builds for
systems on which this won't work.

Right, it doesn't make sense to change our default in a way that breaks use
of the same version of libc++, or a supported version of libstdc++ (and we
should establish how old a version of libstdc++ we support here).

However, I don't immediately see that we need to wait for libc++ to be
feature-complete before we enable the new standard in Clang. If that's what
you're suggesting, can you expand on why? We already have the SD-6 feature
test macros to test for implementation of specific features.

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.

Unfortunately, on many systems, some standard system headers won't even
parse without GNU extensions enabled. I think we'll need to leave the GNU
extensions on by default (at least for parsing system headers).

Can you give an example? -std=c++11 works fine on a broad range of systems.
Note that this is not about GNU *extensions*, which are enabled in both
modes; it's about GNU *keywords* (and a small number of non-conforming
extensions) -- in particular, the 'typeof' GNU keyword, and support for the
asm keyword in C and the inline keyword in C89 (without __decoration__).

10

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).

OK. Out of interest, is it the GNU keywords that you need, or some other
effect of the difference between modes?

A quick check of two titles I have at hand shows that at least `typeof` is
in use.

-- Sean Silva

11

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).

OK. Out of interest, is it the GNU keywords that you need, or some other
effect of the difference between modes?

A quick check of two titles I have at hand shows that at least `typeof` is
in use.

(this check consisted of using -std=c++11 instead of -std=gnu++11 and
seeing what breaks)

-- Sean Silva

12

From: "Richard Smith" <richard@metafoo.co.uk>
To: "Hal Finkel" <hfinkel@anl.gov>
Cc: "Clang Dev" <cfe-dev@lists.llvm.org>, "cfe-commits"
<cfe-commits@lists.llvm.org>
Sent: Wednesday, June 29, 2016 3:01:46 PM
Subject: Re: [cfe-dev] RFC: Default language standard mode policy

> > From: "Richard Smith via cfe-commits" <
> > cfe-commits@lists.llvm.org
> > >
>

> > To: "cfe-commits" < cfe-commits@lists.llvm.org >, "Clang Dev" <
> > cfe-dev@lists.llvm.org >
>

> > Sent: Wednesday, June 29, 2016 2:09:37 PM
>

> > Subject: RFC: Default language standard mode policy
>

> > 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 think that we need to include libc++ in this criteria as well. I
> think we'll also need some CMake flags to adjust the default for
> builds for systems on which this won't work.

Right, it doesn't make sense to change our default in a way that
breaks use of the same version of libc++, or a supported version of
libstdc++ (and we should establish how old a version of libstdc++ we
support here).

However, I don't immediately see that we need to wait for libc++ to
be feature-complete before we enable the new standard in Clang. If
that's what you're suggesting, can you expand on why? We already
have the SD-6 feature test macros to test for implementation of
specific features.

I think it is completely reasonable for an application to test __cplusplus for both language and library features. There are plenty of reasons why this won't always work on all systems, but I think we should endeavor to make this possible. I think that the SD-6 macros are useful is many circumstances, but I think it is unreasonable to expect users to detect all of the features they're using separately using SD-6 macros.

We can't control what libstdc++ and others do, but if we can't even provide a complete implementation (including the library), I don't think we should switch the default.

> > 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.
>

> Unfortunately, on many systems, some standard system headers won't
> even parse without GNU extensions enabled. I think we'll need to
> leave the GNU extensions on by default (at least for parsing system
> headers).

Can you give an example? -std=c++11 works fine on a broad range of
systems. Note that this is not about GNU *extensions*, which are
enabled in both modes; it's about GNU *keywords* (and a small number
of non-conforming extensions) -- in particular, the 'typeof' GNU
keyword, and support for the asm keyword in C and the inline keyword
in C89 (without __decoration__).

I recall having problems with this with fenv.h on various systems. They might just be older systems, however. We should check the current state of the world.

Thanks again,
Hal

13

You might find it useful to read this:

http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10214

Thanks,

Steve.

14

I don't have a problem with the C11 default, because the language impact
is minimal. That's quite different from C++ though and I am very
reluctant to update the default language even to C++11. There is a lot
of code in the wild that doesn't compile anymore due to stupid changes
like user-defined string literals or the narrowing (warning) changes.
Even worse are the nothrow changes for destructors, which silently break
valid C++03 code.

Joerg

15

From: "Hal Finkel via cfe-dev" <cfe-dev@lists.llvm.org>
To: "Richard Smith" <richard@metafoo.co.uk>
Cc: "Clang Dev" <cfe-dev@lists.llvm.org>, "cfe-commits"
<cfe-commits@lists.llvm.org>
Sent: Wednesday, June 29, 2016 4:17:18 PM
Subject: Re: [cfe-dev] RFC: Default language standard mode policy

> From: "Richard Smith" <richard@metafoo.co.uk>

> To: "Hal Finkel" <hfinkel@anl.gov>

> Cc: "Clang Dev" <cfe-dev@lists.llvm.org>, "cfe-commits"
> <cfe-commits@lists.llvm.org>

> Sent: Wednesday, June 29, 2016 3:01:46 PM

> Subject: Re: [cfe-dev] RFC: Default language standard mode policy

> > > From: "Richard Smith via cfe-commits" <
> > > cfe-commits@lists.llvm.org
> > > >
> >
>

> > > To: "cfe-commits" < cfe-commits@lists.llvm.org >, "Clang Dev" <
> > > cfe-dev@lists.llvm.org >
> >
>

> > > Sent: Wednesday, June 29, 2016 2:09:37 PM
> >
>

> > > Subject: RFC: Default language standard mode policy
> >
>

> > > 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 think that we need to include libc++ in this criteria as well.
> > I
> > think we'll also need some CMake flags to adjust the default for
> > builds for systems on which this won't work.
>

> Right, it doesn't make sense to change our default in a way that
> breaks use of the same version of libc++, or a supported version of
> libstdc++ (and we should establish how old a version of libstdc++
> we
> support here).

> However, I don't immediately see that we need to wait for libc++ to
> be feature-complete before we enable the new standard in Clang. If
> that's what you're suggesting, can you expand on why? We already
> have the SD-6 feature test macros to test for implementation of
> specific features.

I think it is completely reasonable for an application to test
__cplusplus for both language and library features. There are plenty
of reasons why this won't always work on all systems, but I think we
should endeavor to make this possible. I think that the SD-6 macros
are useful is many circumstances, but I think it is unreasonable to
expect users to detect all of the features they're using separately
using SD-6 macros.

We can't control what libstdc++ and others do, but if we can't even
provide a complete implementation (including the library), I don't
think we should switch the default.

> > > 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.
> >
>

> > Unfortunately, on many systems, some standard system headers
> > won't
> > even parse without GNU extensions enabled. I think we'll need to
> > leave the GNU extensions on by default (at least for parsing
> > system
> > headers).
>

> Can you give an example? -std=c++11 works fine on a broad range of
> systems. Note that this is not about GNU *extensions*, which are
> enabled in both modes; it's about GNU *keywords* (and a small
> number
> of non-conforming extensions) -- in particular, the 'typeof' GNU
> keyword, and support for the asm keyword in C and the inline
> keyword
> in C89 (without __decoration__).

I recall having problems with this with fenv.h on various systems.
They might just be older systems, however. We should check the
current state of the world.

A quick data point:

$ rpm -q --whatprovides /usr/include/aio.h
glibc-headers-2.12-1.166.el6_7.7.ppc64
$ clang -fsyntax-only -std=c11 -w /usr/include/aio.h
/usr/include/aio.h:42:19: error: field has incomplete type 'struct sigevent'
struct sigevent aio_sigevent; /* Signal number and value. */
^
/usr/include/aio.h:42:10: note: forward declaration of 'struct sigevent'
struct sigevent aio_sigevent; /* Signal number and value. */
^
1 error generated.
$ clang -fsyntax-only -std=gnu11 -w /usr/include/aio.h
(works)

$ rpm -q --whatprovides /usr/include/aio.h
glibc-headers-2.17-106.el7_2.4.x86_64
$ clang -fsyntax-only -std=c11 -w /usr/include/aio.h
(works)
$ clang -fsyntax-only -std=gnu11 -w /usr/include/aio.h
(works)

So I might have problems with a c11 default on my older systems, but hopefully not on the newer ones.

-Hal

16

Yes, those are real problems, but it's not reasonable for us to keep the
default at C++98/03 forever. GCC has already taken the plunge here, so a
lot of open-source code that doesn't work in C++11 onwards already
explicitly specifies an appropriate -std= flag.

17

As usual with many decisions in GNUland, they are not the ones to pay
the price. Frankly, I don't understand your argument either. I find it
perfectly reasonable to demand that software specifies which of multiple
incompatible language versions it wants. This is even more important as
the default environment of clang+libc++ allows a good majority of C++11
anyway.

Joerg

18

Hi all,

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.

As Sean pointed out, he did some tests and found we’d need to enable the GNU

keywords on PS4. Having a PS4-specific patch for this wouldn’t be a problem

for us, though. So if the related issues mentioned in this thread for other

platforms (e.g., standard system headers needing GNU extensions enabled just

to parse them without error) are easily resolved, and so the default behavior

becomes to disable GNU keywords, it’s easy enough for us to enable what we

need in this area for PS4.

Note that at this point I’d like to mainly focus on what our policy should

be; there are certainly technical challenges involved in actually applying

the policy (another one is that clang’s test suite still has some failures

when the default is changed, but Charles Li has made tremendous headway on

this), and if we can’t actually prepare for the transition in the C++

default in time for 3.9, then so be it.

Internally on PS4, we default to C++11. FTR, the biggest issues we’ve had

on that point (by far) were clang’s tests. That’s much less of a headache

today, due to Charles’ work on this, but as you said, some failures remain.

I’d expect those could be dealt with in time for 3.9 without too much

difficulty if there was a strong desire to change the default that quickly.

That said, independent of what default is selected at 3.9, for PS4 we will

most likely prefer to stay with our current default (gnu++11) at 3.9. We’ll

revisit switching to 14 later, and consider future language dialect changes on

a case by case basis.

-Warren Ristow

19

What Warren said. We’ve been carrying the private patch for 4 years or so, and now that we’re getting the test changes upstream it will be progressively less of a problem for us. (And thanks Sean for actually trying it on a couple of titles! You read my mind.)

I also wanted to add that I agree with Hal, it would be weird for the compiler and library to be defaulting to different dialects, particularly when their features are defined in the same document. But that’s something of an abstract point; PS4 isn’t using either libc++ or libstdc++ which are the primary libraries that Clang should care about, so we’ll probably continue having our own target-specific default anyway.

–paulr

20

Could you clarify exactly what the issue is? Currently, if I have some legacy C++98 code, the odds are that it just compiles with ${CXX}. If I have new C++11 or C++14 code, then its build system likely sticks on the required -std= flag and it builds independent of what the compiler default is.

What code would be broken by keeping the default at the language version accepted by code that didn’t know about newer standards? As long as we’re keeping support for C++98 in the front end, keeping the default there doesn’t seem particularly arduous for us and will avoid breaking third-party code.

David