svn commit: r228955 - head/include

[David Schultz]

On Sun, Jan 01, 2012, Ed Schouten wrote:
> David,
> 
> * David Schultz <das at FreeBSD.ORG>, 20120101 03:54:
> > I'm out of town and don't remember the details of this, but is there a
> > reason we couldn't simply have an appropriate #ifdef that uses
> > __attribute((__noreturn__)) instead of [[noreturn]]?  We have plenty
> > of ifdefs in the tree already to work around deficiencies in various
> > compilers.  Saying "it's the compiler's fault and we're not going to
> > work around it" is a significant departure from historical precedent,
> > and it punishes the wrong people.  Easier than arguing with the GNU
> > folks about fixing it, too...
> 
> Right now GCC 4.7 is still an unreleased piece of software. If GCC 4.7
> was a released piece of software, I would of course agree that we should
> add the workaround.
> 
> The problem isn't that GCC 4.7 doesn't support [[noreturn]]. The problem
> is that GCC only implements parts of C++11, yet it forces the compiler
> into C++11 mode while bootstrapping. Even if we add a workaround for
> this in sys/cdefs.h, we can likely never ever get rid of it. Because if
> someone wants to install GCC 4.7 on a FreeBSD 14.0 box in 2020 to build
> an old piece of software, he still needs the workaround.
> 
> But there's nothing serious going on here. The issue is already
> discussed in GCC Bugzilla and there is a patch that fixes the build.
> Let's just wait to see what happens.

Since we're talking about a development version of gcc, I agree.
We should wait and see if they fix it.

It wouldn't surprise me if we wind up needing some workarounds.  After
all, after well over a decade, we still have workarounds for gcc's
(and clang's) lack of complete C99 support.  I doubt the gcc
developers are going to agree that they need to dot every "i" and
cross every "t" before they declare C++11 support and define
__cplusplus to be 201103.