Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Jan 2012 21:14:08 -0500
From:      David Schultz <das@FreeBSD.ORG>
To:        Ed Schouten <ed@80386.nl>
Cc:        svn-src-head@FreeBSD.ORG, svn-src-all@FreeBSD.ORG, src-committers@FreeBSD.ORG, Andreas Tobler <andreast@FreeBSD.ORG>, Steve Kargl <sgk@troutmask.apl.washington.edu>
Subject:   Re: svn commit: r228955 - head/include
Message-ID:  <20120102021408.GA99780@zim.MIT.EDU>
In-Reply-To: <20120101092925.GZ1895@hoeg.nl>
References:  <201112291441.pBTEfI8l060127@svn.freebsd.org> <4EFCA6A6.6080103@FreeBSD.org> <20111229183213.GK1895@hoeg.nl> <20111229184934.GA47885@troutmask.apl.washington.edu> <20111229192359.GM1895@hoeg.nl> <20120101025422.GD94452@zim.MIT.EDU> <20120101092925.GZ1895@hoeg.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jan 01, 2012, Ed Schouten wrote:
> David,
> 
> * David Schultz <das@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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120102021408.GA99780>