----- Original Message ----- > From: "Hal Finkel via cfe-dev" <cfe-...@lists.llvm.org> > To: "Richard Smith" <rich...@metafoo.co.uk> > Cc: "Clang Dev" <cfe-...@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
> ----- 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. 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 > 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-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
