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'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 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 > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
