----- Original Message ----- > From: "Richard Smith" <rich...@metafoo.co.uk> > To: "Hal Finkel" <hfin...@anl.gov> > Cc: "Clang Dev" <cfe-...@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
> On Wed, Jun 29, 2016 at 12:55 PM, Hal Finkel via cfe-dev < > cfe-...@lists.llvm.org > wrote: > > > From: "Richard Smith via cfe-commits" < > > > cfe-commits@lists.llvm.org > > > > > > > > > > To: "cfe-commits" < cfe-commits@lists.llvm.org >, "Clang Dev" < > > > cfe-...@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@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-...@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev > -- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
