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

[Hal Finkel via cfe-commits]

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

> From: "Hal Finkel via cfe-dev" <cfe-dev at lists.llvm.org>
> To: "Richard Smith" <richard at metafoo.co.uk>
> Cc: "Clang Dev" <cfe-dev at lists.llvm.org>, "cfe-commits"
> <cfe-commits at 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" <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.

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

> _______________________________________________
> 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-commits/attachments/20160629/c646ca8f/attachment.html>