Re: svn commit: r228955 - head/include
David, * David Schultz d...@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. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpboXRFImVs0.pgp Description: PGP signature
Re: svn commit: r228955 - head/include
On Sun, Jan 01, 2012, Ed Schouten wrote: David, * David Schultz d...@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. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228955 - head/include
On Thu, Dec 29, 2011, Ed Schouten wrote: Hi Steve, * Steve Kargl s...@troutmask.apl.washington.edu, 20111229 19:49: Are you going to submit a bug report to GCC? Because, as of now, you've broken my ability to do development work on bleeding edge freebsd and bleeding edge gcc. Here you go: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 In the future, could you write such bug reports yourself? I am really not that interested in GCC's development process. 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... ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228955 - head/include
On Sat, Dec 31, 2011 at 09:54:22PM -0500, David Schultz wrote: On Thu, Dec 29, 2011, Ed Schouten wrote: Hi Steve, * Steve Kargl s...@troutmask.apl.washington.edu, 20111229 19:49: Are you going to submit a bug report to GCC? Because, as of now, you've broken my ability to do development work on bleeding edge freebsd and bleeding edge gcc. Here you go: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 In the future, could you write such bug reports yourself? I am really not that interested in GCC's development process. 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... I've already sent a patch to GCC to work around the problem. FreeBSD is still considered to be a primary platform for GCC, so problem is a P1 issue in bugzilla. Unfortunately, I think that there are no active FreeBSD gcc maintainer. This means the patch may linger in bugzilla for awhile. -- Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228955 - head/include
On Thu, Dec 29, 2011 at 07:32:13PM +0100, Ed Schouten wrote: Hi Andreas, * Andreas Tobler andre...@freebsd.org, 20111229 18:43: Thank you Ed! gcc-4.6 bootstrap successful. But it seems GCC 4.7 is still broken. I am not planning to fix that, because it's a shortcoming of GCC. As soon as the GNU folks implement C++11 [[noreturn]], it should work again. Are you going to submit a bug report to GCC? Because, as of now, you've broken my ability to do development work on bleeding edge freebsd and bleeding edge gcc. -- Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228955 - head/include
Hi Steve, * Steve Kargl s...@troutmask.apl.washington.edu, 20111229 19:49: Are you going to submit a bug report to GCC? Because, as of now, you've broken my ability to do development work on bleeding edge freebsd and bleeding edge gcc. Here you go: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 In the future, could you write such bug reports yourself? I am really not that interested in GCC's development process. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgph1SaQdSq96.pgp Description: PGP signature
Re: svn commit: r228955 - head/include
On 29.12.11 15:41, Ed Schouten wrote: Author: ed Date: Thu Dec 29 14:41:17 2011 New Revision: 228955 URL: http://svn.freebsd.org/changeset/base/228955 Log: Don't define static_assert for C++. Even though _Static_assert() is pretty robust for C code, it cannot work correctly with C++ code. This is due to the fact that C++ template parameters may contain commas that are not enclosed in parentheses. For example: static_assert(fooint, int::bar == baz, ...); This causes _Static_assert to be called with an excessive number of parameters. If you want to use static_assert in C++, just use a C++11 compiler. Reported on: current@, ports@ Thank you Ed! gcc-4.6 bootstrap successful. Andreas ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228955 - head/include
Hi Ed, On 29.12.11 19:32, Ed Schouten wrote: * Andreas Toblerandre...@freebsd.org, 20111229 18:43: Thank you Ed! gcc-4.6 bootstrap successful. But it seems GCC 4.7 is still broken. I am not planning to fix that, because it's a shortcoming of GCC. As soon as the GNU folks implement C++11 [[noreturn]], it should work again. Yep, gcc-trunk is still broken. I help(ed) myself with a !defined(__GNUC__) with this I can continue hacking on trunk... Well, I possibly do not understand all/everything regarding this [[noreturn]]. But I do not see an activity in this direction on the gcc side. They implemented the _Noreturn for STDC but the double-square-bracket notation for noreturn C++ I do not see. As said, I might simply do not see it. Thanks again, Andreas ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
Re: svn commit: r228955 - head/include
Hi Andreas, * Andreas Tobler andre...@freebsd.org, 20111229 18:43: Thank you Ed! gcc-4.6 bootstrap successful. But it seems GCC 4.7 is still broken. I am not planning to fix that, because it's a shortcoming of GCC. As soon as the GNU folks implement C++11 [[noreturn]], it should work again. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpoVMqDaK6lw.pgp Description: PGP signature
Re: svn commit: r228955 - head/include
On Thu, Dec 29, 2011 at 08:23:59PM +0100, Ed Schouten wrote: Hi Steve, * Steve Kargl s...@troutmask.apl.washington.edu, 20111229 19:49: Are you going to submit a bug report to GCC? Because, as of now, you've broken my ability to do development work on bleeding edge freebsd and bleeding edge gcc. Here you go: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 Thanks. In the future, could you write such bug reports yourself? I am really not that interested in GCC's development process. I'll try, but I don't know C11 or C++11. While you may have no interest in GCC developement, the ports collection uses GCC. I can also see this type of problem leading to 3rd part software developer dropping support for FreeBSD because they need to work around issues with FreeBSD headers. -- Steve ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org
