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

[Hal Finkel via cfe-dev]

----- Original Message -----

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

> On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev <
> cfe-dev at lists.llvm.org > wrote:

> > > From: "Richard Smith via cfe-commits" <
> > > cfe-commits at lists.llvm.org
> > > >
> > 
> 
> > > To: "cfe-commits" < cfe-commits at lists.llvm.org >, "Clang Dev" <
> > > cfe-dev at 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 

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

> > > Thoughts?
> > 
> 
> > > _______________________________________________
> > 
> 
> > > cfe-commits mailing list
> > 
> 
> > > cfe-commits at lists.llvm.org
> > 
> 
> > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> > 
> 

> > --
> 

> > Hal Finkel
> 
> > Assistant Computational Scientist
> 
> > Leadership Computing Facility
> 
> > Argonne National Laboratory
> 

> > _______________________________________________
> 
> > cfe-dev mailing list
> 
> > cfe-dev at lists.llvm.org
> 
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> 

-- 

Hal Finkel 
Assistant Computational Scientist 
Leadership Computing Facility 
Argonne National Laboratory 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160629/a65fdcbf/attachment.html>