User account creation filtered due to spam.

Bug 51705 - [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L
Summary: [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == ...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.7.0
: P1 blocker
Target Milestone: 4.7.0
Assignee: Andreas Tobler
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-29 19:20 UTC by Ed Schouten
Modified: 2012-01-11 18:35 UTC (History)
7 users (show)

See Also:
Host:
Target: *-*-freebsd
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-01-02 00:00:00


Attachments
noreturn.diff (1.89 KB, text/x-diff)
2011-12-30 19:33 UTC, Steve Kargl
Details
patch (964 bytes, patch)
2012-01-11 07:46 UTC, Andreas Tobler
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Schouten 2011-12-29 19:20:09 UTC
FreeBSD recently added support for C11 and C++11 keywords to its sys/cdefs.h file. This header file is used by FreeBSD header files and source code to write code that is portable across different compiler versions.

GCC 4.7's build system adds -std=c++0x to the compiler to build libstdc++. This means that code is built with __cplusplus == 201103L. This is wrong, because now sys/cdefs.h starts to use C++11 constructs such as [[noreturn]]. [[noreturn]] is not supported by GCC yet.

Essentially GCC is free to announce __cplusplus == 201103L for its experimental C++11 support, but the C++11 support should not be used during its own compilation step if it's not finished yet.

Alternatively, this could be fixed by simply implementing [[noreturn]], of course, but that's a different issue altogether.
Comment 1 Jonathan Wakely 2011-12-29 19:34:31 UTC
(In reply to comment #0)
> Essentially GCC is free to announce __cplusplus == 201103L for its experimental
> C++11 support, but the C++11 support should not be used during its own
> compilation step if it's not finished yet.

How should files needed for that C++11 support be compiled then?

It needs to be used to compile e.g. src/thread.cc which defines the functions declared in the C++11 header <thread>

Until attributes are supported I think this should be dealt with by removing [[noreturn]] using fixincludes.
Comment 2 Ed Schouten 2011-12-29 19:42:12 UTC
Well, there is the difference. g++ may support C++11 constructs and libstdc++ should be able to use them, but it's wrong to announce __cplusplus == 201103L to the operating system's headers until it actually does support C++11.

But it could well be the case that changing fixincludes to do the right thing is sufficient.
Comment 3 Chris Jefferson 2011-12-29 20:56:20 UTC
Better take out C++03 support as well, seeing as there is no support for the 'export' keyword.

But seriously, the C++11 support is as complete as any other compiler, and in common usage. Further, parts of libstdc++ need to be built in C++0x mode.
Comment 4 Steve Kargl 2011-12-29 21:27:18 UTC
On Thu, Dec 29, 2011 at 08:56:20PM +0000, chris at bubblescope dot net wrote:
> Better take out C++03 support as well, seeing as there is no support for the
> 'export' keyword.
> 
> But seriously, the C++11 support is as complete as any other compiler, and in
> common usage. Further, parts of libstdc++ need to be built in C++0x mode.
> 

Please, re-read Ed's comment #2.  g++ is telling the
OS that "yes, I support C++11", when in fact it does 
not.  For me, this means I can no longer work on
gfortran until some work-around is in place to avoid
this bug in g++.
Comment 5 Jonathan Wakely 2011-12-29 21:39:12 UTC
So change component to 'bootstrap' and get a FreeBSD maintainer to update fixincludes and/or tell the FreeBSD libc team to test with esoteric third-party compilers such as the little-known GCC before making such changes
Comment 6 Ed Schouten 2011-12-29 21:59:38 UTC
(In reply to comment #5)
> So change component to 'bootstrap' and get a FreeBSD maintainer to update
> fixincludes and/or tell the FreeBSD libc team to test with esoteric third-party
> compilers such as the little-known GCC before making such changes

This problem only in combination with GCC 4.7, which is unreleased. From my point of view, an unreleased version of GCC _is_ an esoteric third-party little-known compiler.
Comment 7 Steve Kargl 2011-12-29 22:06:59 UTC
On Thu, Dec 29, 2011 at 09:39:12PM +0000, redi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-29 21:39:12 UTC ---
> So change component to 'bootstrap' and get a FreeBSD maintainer to
> update fixincludes and/or tell the FreeBSD libc team to test with
> esoteric third-party compilers such as the little-known GCC before
> making such changes

Thanks for the condescending email.  Testing with GCC is 
exactly how the problem was found.  g++ is telling the
FreeBSD libc++ developers, 'Yes, I support C++11'.  The
FreeBSD libc++ developers are using C++11 features, and
implementing the required C++11 library support.  g++ chokes.

I personally could not care less about C++; until it 
makes it much more difficult for me to work on gfortran. 

(Ed, I'm sorry I asked you to submit a bug.  I can
understand your reluctance.)
Comment 8 Chris Jefferson 2011-12-29 22:21:35 UTC
(In reply to comment #4)
> On Thu, Dec 29, 2011 at 08:56:20PM +0000, chris at bubblescope dot net wrote:
> > Better take out C++03 support as well, seeing as there is no support for the
> > 'export' keyword.
> > 
> > But seriously, the C++11 support is as complete as any other compiler, and in
> > common usage. Further, parts of libstdc++ need to be built in C++0x mode.
> > 
> 
> Please, re-read Ed's comment #2.  g++ is telling the
> OS that "yes, I support C++11", when in fact it does 
> not.  For me, this means I can no longer work on
> gfortran until some work-around is in place to avoid
> this bug in g++.

Please read my comment.

You could make the same argument that using g++ should not report as supporting C++03, as it does not support the 'export' keyword and you could use this in headers.

It is likely to be a very long time until g++ supports every single corner case of C++11. Based on our experience with C++03, it may never happen.
Comment 9 Jonathan Wakely 2011-12-29 22:26:52 UTC
(In reply to comment #7)
> Thanks for the condescending email.  Testing with GCC is 
> exactly how the problem was found.  g++ is telling the
> FreeBSD libc++ developers, 'Yes, I support C++11'.  The
> FreeBSD libc++ developers are using C++11 features, and
> implementing the required C++11 library support.  g++ chokes.

Yep, the problem exists, the problem was found by testing, and the problem
needs to be fixed, but saying the problem is that libstdc++ uses C++11 features
is silly.  Suggesting that testing should be done before updating libc headers
is not condescending. Updating libc to use features supported by what? one,
maybe two compilers?  and not even testing the latest version of GCC? that's
just sloppy engineering.  Reporting failures caused by sloppy changes by saying
"C++11 support should not be used during its own compilation step" is silly.

If you're going to add support for bleeding edge language features then test
with a bleeding edge compiler. Not doing so is just silly.

Test the changes, report problems, resolve the problem, then commit the
changes.  Just making the changes and claiming there's a bug in libstdc++...
That's sloppy.

If your issue is with the value of __cplusplus, that's not set by libstdc++, so
I've set component=bootstrap.

Please follow the bug reporting guidelines at http://gcc.gnu.org/bugs/ and
describe the problem fully (e.g. version=4.7.0, target=*-*-freebsd), so a FreeBSD maintainer has enough info to update fixincludes to fix it.
Comment 10 Steve Kargl 2011-12-29 22:29:55 UTC
On Thu, Dec 29, 2011 at 10:21:35PM +0000, chris at bubblescope dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #8 from Chris Jefferson <chris at bubblescope dot net> 2011-12-29 22:21:35 UTC ---
> (In reply to comment #4)
> > On Thu, Dec 29, 2011 at 08:56:20PM +0000, chris at bubblescope dot net wrote:
> > > Better take out C++03 support as well, seeing as there is no support for the
> > > 'export' keyword.
> > > 
> > > But seriously, the C++11 support is as complete as any other compiler, and in
> > > common usage. Further, parts of libstdc++ need to be built in C++0x mode.
> > > 
> > 
> > Please, re-read Ed's comment #2.  g++ is telling the
> > OS that "yes, I support C++11", when in fact it does 
> > not.  For me, this means I can no longer work on
> > gfortran until some work-around is in place to avoid
> > this bug in g++.
> 
> Please read my comment.

I did.

> You could make the same argument that using g++ should not report
> as supporting C++03, as it does not support the 'export' keyword
> and you could use this in headers.

I have no qualms with this.  If it does not support C++03, then
should advertise that it does.

> It is likely to be a very long time until g++ supports every
> single corner case of C++11.  Based on our experience with C++03,
> it may never happen.

If this is the case, then it definitely should not advertise
that it does support C++11.
Comment 11 Ed Schouten 2011-12-29 22:40:26 UTC
But this has nothing to do with FreeBSD specifically. It will apply to basically any operating system in the future.

Say, GCC 4.8 (late 2012?) will support [[noreturn]] properly and some OS vendor decides to start using it by the year 2016 in its header files. That will still prevent you from compiling GCC 4.7 then, in case some piece of software depends on it. In the year 2016, OS vendors will simply expect they can do the following without causing any negative side-effects.

#if defined(__STDC__) && __STDC_VERSION__ >= 201112L
_Noreturn
#if defined(__cplusplus) && __cplusplus >= 201103L
[[noreturn]]
#endif
void exit(int);

Simply because C++11 is the standard that introduced it.

I _really_ think you guys are doing a good job with C++11 and there's _nothing_ wrong with the compiler. The issue is that forcing the compiler to expose C++11 support during its own compilation phase is not conservative.
Comment 12 Steve Kargl 2011-12-29 23:05:25 UTC
On Thu, Dec 29, 2011 at 10:26:52PM +0000, redi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> (In reply to comment #7)
> > Thanks for the condescending email.  Testing with GCC is 
> > exactly how the problem was found.  g++ is telling the
> > FreeBSD libc++ developers, 'Yes, I support C++11'.  The
> > FreeBSD libc++ developers are using C++11 features, and
> > implementing the required C++11 library support.  g++ chokes.
> 
> Yep, the problem exists, the problem was found by testing, and the problem
> needs to be fixed, but saying the problem is that libstdc++ uses C++11 features
> is silly.  Suggesting that testing should be done before updating libc headers
> is not condescending. Updating libc to use features supported by what? one,
> maybe two compilers?  and not even testing the latest version of GCC? that's
> just sloppy engineering.  Reporting failures caused by sloppy changes by saying
> "C++11 support should not be used during its own compilation step" is silly.

I do not see how one can draw the conclusion that it is sloppy
engineering, when an OS vendor writes code that is properly
protected:

#if defined(__cplusplus) && __cplusplus >= 201103L
#define _Noreturn               [[noreturn]]
#endif

Building libstdc++ is using -std=c++11 ... 

> If your issue is with the value of __cplusplus, that's not set by libstdc++, so
> I've set component=bootstrap.

which is causing __cplusplus to become defined.  This, then is, causing
bootstrap to die in libstdc++ because the well-written code above has
been decieved by the compiler.
Comment 13 Jonathan Wakely 2011-12-29 23:12:39 UTC
(In reply to comment #10)
> I have no qualms with this.  If it does not support C++03, then
> should advertise that it does.

(Assuming you meant should *not*) that's not very useful in practice.  If no
headers anywhere in existence actually use 'export' then do you seriously argue
that no compiler should ever define __cplusplus == 199711L?

> If this is the case, then it definitely should not advertise
> that it does support C++11.

But pragmatically, it helps more users to do the Right Thing for what users use
and want.  Clearly we have a real problem here for FreeBSD, and should be fixed
by not defining __cplusplus==201103L or via fixincludes, but I maintain it was
pretty silly to update headers to use bleeding edge features before checking if
they work with bleeding edge compilers.  Yes, GCC 4.7 might be bleeding edge,
but so is [[noreturn]] support so not checking it works before using it is just
sloppy.

(In reply to comment #11)
> But this has nothing to do with FreeBSD specifically. It will apply to
> basically any operating system in the future.
> 
> Say, GCC 4.8 (late 2012?) will support [[noreturn]] properly and some OS vendor
> decides to start using it by the year 2016 in its header files. That will still
> prevent you from compiling GCC 4.7 then, in case some piece of software depends
> on it.

*ahem* It will prevent you using 4.7.0 20111229 (experimental) - this problem
doesn't exist with any released version. We can get it fixed (FreeBSD is a
primary platform after all, so this should be P2 or even P1) if we identify the
problem correctly.  I believe the right fix is fixincludes.  Feel free to keep
arguing otherwise, but wherever the problem lies, it's not that libstdc++ uses
C++11 features (note that libstdc++ only ever checks __GXX_EXPERIMENTAL_CXX0X__
so is agnostic about the value of __cplusplus)

(In reply to comment #12)
> I do not see how one can draw the conclusion that it is sloppy
> engineering, when an OS vendor writes code that is properly
> protected:
> 
> #if defined(__cplusplus) && __cplusplus >= 201103L
> #define _Noreturn               [[noreturn]]
> #endif

Without testing if it actually works on relevant compilers? That's very sloppy.

Writing code based purely on (very recently published) specs without testing that code is poor engineering.
 
> Building libstdc++ is using -std=c++11 ... 
> 
> > If your issue is with the value of __cplusplus, that's not set by libstdc++, so
> > I've set component=bootstrap.
> 
> which is causing __cplusplus to become defined.  This, then is, causing
> bootstrap to die in libstdc++ because the well-written code above has
> been decieved by the compiler.

As I said above, libstdc++ doesn't set or test the value of __cplusplus, so it's not a libstdc++ problem.
Comment 14 Ed Schouten 2011-12-29 23:30:19 UTC
(In reply to comment #13)
> Feel free to keep
> arguing otherwise, but wherever the problem lies, it's not that libstdc++ uses
> C++11 features

Steve and I merely have our doubts about the current value of __cplusplus during the compilation of libstdc++ -- not whether C++11 features are used inside libstdc++.

But this discussion starts to turn into an infinite loop. Doesn't Bugzilla allow a bug reporter to unsubscribe? I trust you folks will get it sorted out eventually.
Comment 15 Steve Kargl 2011-12-29 23:55:20 UTC
On Thu, Dec 29, 2011 at 11:30:19PM +0000, ed at 80386 dot nl wrote:
> 
> But this discussion starts to turn into an infinite loop. Doesn't Bugzilla
> allow a bug reporter to unsubscribe? I trust you folks will get it sorted out
> eventually.
> 

Unfortunately, I believe as the original submitter of the bug
report, you cannot unsubscribe.   If this is the case, I'll
close this report and re-open a new report so that you are
subjected to the audit trail.

This appears to be a chicken-and-egg problem.  libstdc++ 
uses some portion of the subset of C++11 features supported
by g++, so it uses -std=c++11 during building.  This then
forces g++ to define __cplusplus, where upon any vendor with
more advance support for C++11 in their system headers will
be bitten.
Comment 16 Steve Kargl 2011-12-30 04:01:52 UTC
On Thu, Dec 29, 2011 at 11:12:39PM +0000, redi at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-29 23:12:39 UTC ---
> (In reply to comment #10)
> > I have no qualms with this.  If it does not support C++03, then
> > should advertise that it does.
> 
> (Assuming you meant should *not*) that's not very useful in practice.  If no
> headers anywhere in existence actually use 'export' then do you seriously argue
> that no compiler should ever define __cplusplus == 199711L?

Yes, I meant 'not'.

Yes, if 'export' is not support, then __cplusplus should not be defined 
to indicate that g++ supports that standard.

I have no problem with -std=c++11 enabling C++11 features and evening
trying to apply a strict interpretation of C++11.  But, if g++ does
not support the entire language at 201103L, then it should not advertise
that it does.  
 
> > If this is the case, then it definitely should not advertise
> > that it does support C++11.
> 
> But pragmatically, it helps more users to do the Right Thing for what users use
> and want.  Clearly we have a real problem here for FreeBSD, and should be fixed
> by not defining __cplusplus==201103L or via fixincludes, but I maintain it was
> pretty silly to update headers to use bleeding edge features before checking if
> they work with bleeding edge compilers.  Yes, GCC 4.7 might be bleeding edge,
> but so is [[noreturn]] support so not checking it works before using it is just
> sloppy.

Given the area FreeBSD that Ed works on, I suspect it is supported by
at least one compiler.  

> (In reply to comment #11)
> > But this has nothing to do with FreeBSD specifically. It will apply to
> > basically any operating system in the future.
> > 
> > Say, GCC 4.8 (late 2012?) will support [[noreturn]] properly and some OS vendor
> > decides to start using it by the year 2016 in its header files. That will still
> > prevent you from compiling GCC 4.7 then, in case some piece of software depends
> > on it.
> 
> *ahem* It will prevent you using 4.7.0 20111229 (experimental) - this problem
> doesn't exist with any released version. We can get it fixed (FreeBSD is a
> primary platform after all, so this should be P2 or even P1) if we identify the
> problem correctly.  I believe the right fix is fixincludes.  Feel free to keep
> arguing otherwise, but wherever the problem lies, it's not that libstdc++ uses
> C++11 features (note that libstdc++ only ever checks __GXX_EXPERIMENTAL_CXX0X__
> so is agnostic about the value of __cplusplus)

Well, the correct fix is for g++ not to define __cplusplus as 201103L.
Or, the correct fix is for the g++ developers to implement [[noreturn]].
But, common sense, here a hack to make it work on FreeBSD.

2011-12-29  Steven G. Kargl  <kargl@gcc.gnu.org>

	* inclhack.def:  Disgusting hack to workaround brain damage of
	defining __cplusplus as 201103L with -std=c++11 when g++ does
	not support c++11.
	* fixincl.x: regenerated.
	* genfixes: Fix a version test.

Index: inclhack.def
===================================================================
--- inclhack.def	(revision 182738)
+++ inclhack.def	(working copy)
@@ -20,6 +20,21 @@ autogen definitions fixincl;
 FIXINC_DEBUG = yes;
 #endif
 
+/*
+ * g++ -std=c++11 defines __cplusplus to 201103L, which lies about
+ * the level of support g++ has for the C++11 standard.
+ */
+fix = {
+    hackname  = cdef_cplusplus;
+    mach      = "*-*-freebsd10.*";
+    files     = sys/cdefs.h;
+    select    = "\\\\[\\\\[noreturn\\\\]\\\\]";
+    sed       = "s/\\\\[\\\\[noreturn\\\\]\\\\]/__dead2/";
+    test_text = "#include <sys/cdefs.h>";
+};
+
+
+
 /* On AIX when _LARGE_FILES is defined stdio.h defines fopen to
  * fopen64 etc. and this causes problems when building with g++
  * because cstdio udefs everything from stdio.h, leaving us with
Index: fixincl.x
===================================================================
--- fixincl.x	(revision 182738)
+++ fixincl.x	(working copy)
@@ -2,11 +2,11 @@
  * 
  * DO NOT EDIT THIS FILE   (fixincl.x)
  * 
- * It has been AutoGen-ed  November  7, 2011 at 01:16:39 PM by AutoGen 5.10
+ * It has been AutoGen-ed  December 29, 2011 at 06:29:22 PM by AutoGen 5.12
  * From the definitions    inclhack.def
  * and the template file   fixincl
  */
-/* DO NOT SVN-MERGE THIS FILE, EITHER Mon Nov  7 13:16:39 EST 2011
+/* DO NOT SVN-MERGE THIS FILE, EITHER Thu Dec 29 18:29:22 PST 2011
  *
  * You must regenerate it.  Use the ./genfixes script.
  *
@@ -15,7 +15,7 @@
  * certain ANSI-incompatible system header files which are fixed to work
  * correctly with ANSI C and placed in a directory that GNU C will search.
  *
- * This file contains 222 fixup descriptions.
+ * This file contains 223 fixup descriptions.
  *
  * See README for more information.
  *
@@ -43,6 +43,42 @@ static char const sed_cmd_z[] = SED_PROG
 
 /* * * * * * * * * * * * * * * * * * * * * * * * * *
  *
+ *  Description of Cdef_Cplusplus fix
+ */
+tSCC zCdef_CplusplusName[] =
+     "cdef_cplusplus";
+
+/*
+ *  File name selection pattern
+ */
+tSCC zCdef_CplusplusList[] =
+  "sys/cdefs.h\0";
+/*
+ *  Machine/OS name selection pattern
+ */
+tSCC* apzCdef_CplusplusMachs[] = {
+        "*-*-freebsd10.*",
+        (const char*)NULL };
+
+/*
+ *  content selection pattern - do fix if pattern found
+ */
+tSCC zCdef_CplusplusSelect0[] =
+       "\\\\[\\\\[noreturn\\\\]\\\\]";
+
+#define    CDEF_CPLUSPLUS_TEST_CT  1
+static tTestDesc aCdef_CplusplusTests[] = {
+  { TT_EGREP,    zCdef_CplusplusSelect0, (regex_t*)NULL }, };
+
+/*
+ *  Fix Command Arguments for Cdef_Cplusplus
+ */
+static const char* apzCdef_CplusplusPatch[] = { sed_cmd_z,
+    "-e", "s/\\\\[\\\\[noreturn\\\\]\\\\]/__dead2/",
+    (char*)NULL };
+
+/* * * * * * * * * * * * * * * * * * * * * * * * * *
+ *
  *  Description of Aab_Aix_Stdio fix
  */
 tSCC zAab_Aix_StdioName[] =
@@ -9034,14 +9070,15 @@ static const char* apzX11_SprintfPatch[]
  *
  *  List of all fixes
  */
-#define REGEX_COUNT          264
+#define REGEX_COUNT          265
 #define MACH_LIST_SIZE_LIMIT 181
-#define FIX_COUNT            222
+#define FIX_COUNT            223
 
 /*
  *  Enumerate the fixes
  */
 typedef enum {
+    CDEF_CPLUSPLUS_FIXIDX,
     AAB_AIX_STDIO_FIXIDX,
     AAB_DARWIN7_9_LONG_DOUBLE_FUNCS_FIXIDX,
     AAB_DARWIN7_9_LONG_DOUBLE_FUNCS_2_FIXIDX,
@@ -9267,6 +9304,11 @@ typedef enum {
 } t_fixinc_idx;
 
 tFixDesc fixDescList[ FIX_COUNT ] = {
+  {  zCdef_CplusplusName,    zCdef_CplusplusList,
+     apzCdef_CplusplusMachs,
+     CDEF_CPLUSPLUS_TEST_CT, FD_MACH_ONLY,
+     aCdef_CplusplusTests,   apzCdef_CplusplusPatch, 0 },
+
   {  zAab_Aix_StdioName,    zAab_Aix_StdioList,
      apzAab_Aix_StdioMachs,
      AAB_AIX_STDIO_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
Index: genfixes
===================================================================
--- genfixes	(revision 182738)
+++ genfixes	(working copy)
@@ -62,7 +62,7 @@ fi
 AG="autogen $AG"
 set -e
 
-if [ -z "`${AG} -v | fgrep 'Ver. 5.'`" ]
+if [ -z "`${AG} -v | fgrep '5.'`" ]
 then
   echo "AutoGen appears to be out of date or not correctly installed."
   echo "Please download and install:"
Comment 17 Andreas Tobler 2011-12-30 10:45:38 UTC
With the below 'hack' I'm able to bootstrap on x86_64-*-freebsd10.0.
I'm not sure why my system does not like the original four escape backslashes in the select and sed line.

The diff between the sys/cdefs.h and the fixed sys/cdefs.h looks like this:

-#define        _Noreturn               [[noreturn]]
+#define        _Noreturn               __dead2

+ * g++ -std=c++11 defines __cplusplus to 201103L, which lies about
+ * the level of support g++ has for the C++11 standard.
+ */
+fix = {
+    hackname  = cdef_cplusplus;
+    mach      = "*-*-freebsd10.*";
+    files     = sys/cdefs.h;
+    select    = "\\[\\[noreturn\\]\\]";
+    sed       = "s/\\[\\[noreturn\\]\\]/__dead2/";
+    test_text = "#define _Noreturn     __dead2";
+};
+/*
Comment 18 Ed Schouten 2011-12-30 10:47:25 UTC
Though there's nothing wrong with using __dead2, wouldn't it be better to use __attribute__((__noreturn__) directly?
Comment 19 Andreas Tobler 2011-12-30 10:59:03 UTC
Works too:

+    sed       = "s/\\[\\[noreturn\\]\\]/__attribute__((__noreturn__))/";
+    test_text = "#define _Noreturn     __attribute__((__noreturn__))";

Looks less cryptic, iow, I do not need to look for __dead2 to understand what is meant.
Comment 20 Steve Kargl 2011-12-30 17:26:30 UTC
On Fri, Dec 30, 2011 at 10:45:38AM +0000, andreast at gcc dot gnu.org wrote:
> With the below 'hack' I'm able to bootstrap on x86_64-*-freebsd10.0.
> I'm not sure why my system does not like the original four escape backslashes
> in the select and sed line.
> 
> The diff between the sys/cdefs.h and the fixed sys/cdefs.h looks like this:
> 
> -#define        _Noreturn               [[noreturn]]
> +#define        _Noreturn               __dead2
> 
> + * g++ -std=c++11 defines __cplusplus to 201103L, which lies about
> + * the level of support g++ has for the C++11 standard.
> + */
> +fix = {
> +    hackname  = cdef_cplusplus;
> +    mach      = "*-*-freebsd10.*";
> +    files     = sys/cdefs.h;
> +    select    = "\\[\\[noreturn\\]\\]";
> +    sed       = "s/\\[\\[noreturn\\]\\]/__dead2/";

Are you using bash and GNU sed instead of FreeBSD's sh
and sed?  When I used the above patterns, the changed
file contained

#define        _Noreturn               [[noreturn__dead2]
Comment 21 Andreas Tobler 2011-12-30 18:06:27 UTC
Neither bash nor GNU sed is installed on this machine.
Comment 22 Andreas Tobler 2011-12-30 18:54:53 UTC
Created attachment 26207 [details]
noreturn.diff

On another machine:

egrep "SED|SHELL" *
config.log:SED='/usr/local/bin/gsed'
config.log:SHELL='/bin/sh'

Works too.
Comment 23 Steve Kargl 2011-12-30 19:33:57 UTC
On Fri, Dec 30, 2011 at 06:54:53PM +0000, andreast at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #22 from Andreas Tobler <andreast at gcc dot gnu.org> 2011-12-30 18:54:53 UTC ---
> On another machine:
> 
> egrep "SED|SHELL" *
> config.log:SED='/usr/local/bin/gsed'
> config.log:SHELL='/bin/sh'
> 
> Works too.
> 

I just finished a bootstrap with this updated patch.
I have no idea why I needed four \ instead of two
last night.  Anyway, I've included Ed suggested change.
Comment 24 Jason Merrill 2012-01-06 14:10:51 UTC
(In reply to comment #16)
> I have no problem with -std=c++11 enabling C++11 features and evening
> trying to apply a strict interpretation of C++11.  But, if g++ does
> not support the entire language at 201103L, then it should not advertise
> that it does.  

I sympathize with this position, and put off changing the value for that reason.  But other compilers have started to define __cplusplus to the 201103L as well even though they don't implement the whole standard either, since there is no other portable way to distinguish between which standard is being targeted.  So we decided to follow suit.  I think fixincludes is the right answer here.

Adding FreeBSD and fixincludes maintainers to CC.
Comment 25 Bruce Korb 2012-01-06 15:09:46 UTC
RE: Comment #16 through Comment #23 -- Do not use sed.  There is no compelling reason to do so.  Please read the fixincludes README, wherein "sed" is disparaged.  I'll add to that the fact that BSD has some non-POSIX treatments of multi-line commands.  I think this is what you want (not specific to BSD):

+/*
+ * g++ -std=c++11 defines __cplusplus to 201103L, but does not
+ * properly support [[noreturn]].
+ */
+fix = {
+    hackname  = cdef_cplusplus;
+    files     = sys/cdefs.h;
+    select    = '\[\[noreturn\]\]';
+    c_fix     = format;
+    c_fix_arg = "/* noreturn */";
+    test_text = "#define _Noreturn     [[noreturn]]";
+};

Note to self (Bruce): devise a way to compile this fix out
once GCC++ properly supports "[[noreturn]]".
Comment 26 Steve Kargl 2012-01-06 15:22:09 UTC
On Fri, Jan 06, 2012 at 03:09:46PM +0000, bkorb at gnu dot org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #25 from bkorb at gnu dot org 2012-01-06 15:09:46 UTC ---
> RE: Comment #16 through Comment #23 -- Do not use sed.  There is no compelling
> reason to do so.  Please read the fixincludes README, wherein "sed" is
> disparaged.  I'll add to that the fact that BSD has some non-POSIX treatments
> of multi-line commands.  I think this is what you want (not specific to BSD):
> 
> +/*
> + * g++ -std=c++11 defines __cplusplus to 201103L, but does not
> + * properly support [[noreturn]].
> + */
> +fix = {
> +    hackname  = cdef_cplusplus;
> +    files     = sys/cdefs.h;
> +    select    = '\[\[noreturn\]\]';
> +    c_fix     = format;
> +    c_fix_arg = "/* noreturn */";
> +    test_text = "#define _Noreturn     [[noreturn]]";
> +};
> 
> Note to self (Bruce): devise a way to compile this fix out
> once GCC++ properly supports "[[noreturn]]".
> 

I can test this tomorrow.
Comment 27 Jakub Jelinek 2012-01-06 15:30:23 UTC
I'd say:
  c_fix_arg = "__attribute__((__noreturn__))";
would be better.  Thanks for writing a comment that has just the important facts in it and no emotions.
Comment 28 Jonathan Wakely 2012-01-06 15:34:07 UTC
(In reply to comment #25)
> Note to self (Bruce): devise a way to compile this fix out
> once GCC++ properly supports "[[noreturn]]".

I'll remember to add a comment to this PR once it's supported, to prod the CC list
Comment 29 Andreas Tobler 2012-01-06 15:57:51 UTC
Bootstrap in progress with the below.

Additions:

- Jakub's recent comment on c_fix_arg.
- extend mach to match FreeBSD10.* to FreeBSD19.* (Should give some time...)

+ * g++ -std=c++11 defines __cplusplus to 201103L, which lies about
+ * the level of support g++ has for the C++11 standard.
+ */
+fix = {
+    hackname  = cdef_cplusplus;
+    mach      = "*-*-freebsd1[0-9].*";
+    files     = sys/cdefs.h;
+    select    = '\[\[noreturn\]\]';
+    c_fix     = format;
+    c_fix_arg = "__attribute__\(\(__noreturn__\)\)";
+    test_text = "#define _Noreturn     [[noreturn]]";
+};
+/*
Comment 30 Bruce Korb 2012-01-06 16:10:33 UTC
(In reply to comment #28)
> I'll remember to add a comment to this PR once ...
I fully intend to remember, too.
Probably the appropriate thing is a new bug #51776
Comment 31 Steve Kargl 2012-01-06 16:11:08 UTC
On Fri, Jan 06, 2012 at 03:30:23PM +0000, jakub at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-06 15:30:23 UTC ---
> I'd say:
>   c_fix_arg = "__attribute__((__noreturn__))";
> would be better.  Thanks for writing a comment that has just the important
> facts in it and no emotions.
> 

Apparently, you did not read my 2nd patch. 
There was no emotion in the comment.  Just
the facts.  I suppose the truth hurts sometime.

+/*
+ * 'g++ -std=c++11' defines __cplusplus to 201103L, which suggests
+ * that 'g++ -std=c++11' is a compiler conforming to the C++ programming
+ * language defined by ISO/IEC 14882:2011.  Setting __cplusplus to 
+ * 201103L appears to be a direct violation of ISO/IEC 14882:2011
+ * [as inferred from Secs. 1.4 and 16.8 in n3242.pdf (I'm not interested
+ * in spending CHF 352.00 for the actual standard)].  The standard
+ * conforming sys/cdefs.h header file on FreeBSD 10 (and above) needs be
+ * (un)damaged, so GCC can use 'g++ -std=c++11' to build libstdc++v3 
+ * during bootstrap. 
+ */
Comment 32 Bruce Korb 2012-01-06 16:14:08 UTC
(In reply to comment #29)
> +    c_fix_arg = "__attribute__\(\(__noreturn__\)\)";

In a double quoted string, the backslash quotes always quote
the character that follows.  Here, it yields a noop, which
is fine because the "c-fix-arg" is scanned for "%1" type markers,
not regular expressions.
Comment 33 Steve Kargl 2012-01-09 20:13:08 UTC
On Fri, Jan 06, 2012 at 04:14:08PM +0000, bkorb at gnu dot org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #32 from bkorb at gnu dot org 2012-01-06 16:14:08 UTC ---
> (In reply to comment #29)
> > +    c_fix_arg = "__attribute__\(\(__noreturn__\)\)";
> 
> In a double quoted string, the backslash quotes always quote
> the character that follows.  Here, it yields a noop, which
> is fine because the "c-fix-arg" is scanned for "%1" type markers,
> not regular expressions.
> 

I used your patch with the above __attribute__ line.  I was
able to boostrap GCC on FreeBSD 10 without a hitch.  Can you
please commit your patch with the above change?
Comment 34 Andreas Tobler 2012-01-09 20:32:00 UTC
Just to double check, shall I leave the backslash in this line?

c_fix_arg = "__attribute__\(\(__noreturn__\)\)";

And more important, do we have an ok for a commit of this patch?
Comment 35 Steve Kargl 2012-01-09 21:33:23 UTC
On Mon, Jan 09, 2012 at 08:32:00PM +0000, andreast at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
> 
> --- Comment #34 from Andreas Tobler <andreast at gcc dot gnu.org> 2012-01-09 20:32:00 UTC ---
> Just to double check, shall I leave the backslash in this line?
> 
> c_fix_arg = "__attribute__\(\(__noreturn__\)\)";
> 

This is the line I tested.  Note, Bruce's patch does not
have a mach= field, so the patch should apply to any OS
with a cdefs.h with [[noreturn]].  I'll also defer to 
Bruce on whether to keep the escaped ( and ) characters.

> And more important, do we have an ok for a commit of this patch?

That's a good question.
Comment 36 Chris Jefferson 2012-01-09 21:45:10 UTC
By your reasoning, FreeBSD really may as well take out code which requires __cplusplus == 201103L , as no compiler will support all of C++11 for several years I am sure. I would be happy to help work on a patch for that if you like.
Comment 37 Bruce Korb 2012-01-09 22:11:09 UTC
It is getting too confusing.

+/*
+ * 'g++ -std=c++11' defines __cplusplus to 201103L, which suggests
+ * that it conforms to ISO/IEC 14882:2011.  Until G++ fully conforms,
+ * it should not set __cplusplus to that value.  It currently does
+ * not support the [[noreturn]] procedure attribute.
+ * When it does, this hack should be removed.
+ * SEE:  gcc.gnu.org/bugzilla/show_bug.cgi?id=51776
+ */
+fix = {
+    hackname  = cdef_cplusplus;
+    files     = sys/cdefs.h;
+    select    = '\[\[noreturn\]\]';
+    c_fix     = format;
+    c_fix_arg = '__attribute__((__noreturn__))';
+    test_text = "#define _Noreturn     [[noreturn]]";
+};

This is the fix/hack that should be used.
There will also be a change required for tests/base/sys/cdefs.h.

The following is also correct, since I read a more recent GNU Coding
standards that makes it clear to not use "Ver." in the version.

This is approved.  Regards, Bruce

Index: genfixes
===================================================================
--- genfixes    (revision 182738)
+++ genfixes    (working copy)
@@ -62,7 +62,7 @@ fi
 AG="autogen $AG"
 set -e

-if [ -z "`${AG} -v | fgrep 'Ver. 5.'`" ]
+if [ -z "`${AG} -v | fgrep ' 5.'`" ]
 then
   echo "AutoGen appears to be out of date or not correctly installed."
   echo "Please download and install:"
Comment 38 Steve Kargl 2012-01-09 22:31:03 UTC
On Mon, Jan 09, 2012 at 09:45:10PM +0000, chris at bubblescope dot net wrote:
>
> By your reasoning, FreeBSD really may as well take out code which
> requires __cplusplus == 201103L , as no compiler will support all
> of C++11 for several years I am sure. I would be happy to help work
> on a patch for that if you like.
>

That's not what I wrote in comment #16, and see Jason's
reply in comment #24.  

I have no problem with g++ growing feature towards full
support of c++11.

I have no problems with libstdc++v3 using the limited set
of c++11 that are already available.

I do, however, have a problem with g++ defining
__cplusplus == 201103L in violation of ISO/IEC 14882:2011
Secs. 1.4 and 16.8 (note I only have n3242.pdf, so the
section numbers may be wrong in comparison to the ratified 
standard).

If you want to help and want to keep __cplusplus == 201103L,
please supply appropriate recipes for fixincludes to catch all
of the currently unimplemented c++11 features, which g++
currently claims to support.
Comment 39 Ed Schouten 2012-01-09 22:37:41 UTC
(In reply to comment #36)
> By your reasoning, FreeBSD really may as well take out code which requires
> __cplusplus == 201103L , as no compiler will support all of C++11 for several
> years I am sure. I would be happy to help work on a patch for that if you like.

Chris,

You do realize [[noreturn]] is one of the most basic features one could imagine, right? As you mentioned, no compiler will support all of C++11 for several years, but the Clang shipped with FreeBSD 9 (released 1.5 months ago) does support [[noreturn]], so I assume there is little or no interest to remove the use of [[noreturn]].
Comment 40 Chris Jefferson 2012-01-09 22:45:32 UTC
There are several C++11 features which clang does not support, which g++ does. clang also defines __cplusplus == 201103L, despite not implementing large parts of the C++11 standard.

Worse, clang does not have an equivalent of fixincludes, so if these g++-only features were used, with clang you would be stuck with uncompilable code.

Perhaps the change to c++11 should have been done differently, but if we did what you suggest we would be no better off, as no compiler (not g++, not clang, not visual studio, not icc) would define __cplusplus == 201103L for several years. In fact, no open source compiler would yet have defined it for C++03!

However, I can see this conversation is going around in circles.
Comment 41 Ed Schouten 2012-01-09 22:48:35 UTC
(In reply to comment #40)
> There are several C++11 features which clang does not support, which g++ does.
> clang also defines __cplusplus == 201103L, despite not implementing large parts
> of the C++11 standard.
> 
> Worse, clang does not have an equivalent of fixincludes, so if these g++-only
> features were used, with clang you would be stuck with uncompilable code.
> 
> Perhaps the change to c++11 should have been done differently, but if we did
> what you suggest we would be no better off, as no compiler (not g++, not clang,
> not visual studio, not icc) would define __cplusplus == 201103L for several
> years. In fact, no open source compiler would yet have defined it for C++03!
> 
> However, I can see this conversation is going around in circles.

But this is where you completely miss the point: Clang does not invoke itself with -std=c++11 during its own build procedure.
Comment 42 joseph@codesourcery.com 2012-01-09 22:51:04 UTC
The obvious issue with C++11 attributes (such as [[noreturn]]) is that the 
syntactic bindings are (or were when I last looked at a draft) 
incompatible with the syntactic bindings for GNU __attribute__, so meaning 
that C++11 attribute support in GCC will need to deal with different 
syntactic forms of attributes in the same place binding differently.
Comment 43 Chris Jefferson 2012-01-09 22:59:49 UTC
g++ only does this while compiling the C++ standard library. clang doesn't come (by default) with a C++ standard library, so you have to use either libstdc++ (from g++) or libc++. While compiling libc++ (which is clang's implementation of the standard library), clang is invoked with -std=c++0x. So clang is in exactly the same state as g++ it seems to me.
Comment 44 Jason Merrill 2012-01-10 13:44:22 UTC
There is a conflict between the FreeBSD headers and G++, and we can fix it with fixincludes.  Let's do that and move on.
Comment 45 Andreas Tobler 2012-01-11 07:46:27 UTC
Created attachment 26297 [details]
patch
Comment 46 Andreas Tobler 2012-01-11 07:49:41 UTC
I'm going to apply the patch from comment #45 this evening.

Bootstraped several times, make check in fixincludes successful.

This is the CL I prepared:

2012-01-11  Bruce Korb <bkorb@gnu.org>
	    Steven G. Kargl  <kargl@gcc.gnu.org>
	    Andreas Tobler  <andreast@fgznet.ch>

	PR bootstrap/57105
	PR preprocessor/51776
	* inclhack.def (cdef_cplusplus): Add a replacement for [[noreturn]].
	* fixincl.x: Regenerate.
	* tests/base/sys/cdefs.h: Update.

	* genfixes: Remove the 'Ver.' from the version check.
Comment 47 Bruce Korb 2012-01-11 14:31:15 UTC
To eliminate any possible ambiguity, the patch is "approved"

On 01/10/12 23:49, andreast at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705
>
> Andreas Tobler<andreast at gcc dot gnu.org>  changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|NEW                         |ASSIGNED
>
> --- Comment #46 from Andreas Tobler<andreast at gcc dot gnu.org>  2012-01-11 07:49:41 UTC ---
> I'm going to apply the patch from comment #45 this evening.
>
> Bootstraped several times, make check in fixincludes successful.
>
> This is the CL I prepared:
>
> 2012-01-11  Bruce Korb<bkorb@gnu.org>
>          Steven G. Kargl<kargl@gcc.gnu.org>
>          Andreas Tobler<andreast@fgznet.ch>
>
>      PR bootstrap/57105
>      PR preprocessor/51776
>      * inclhack.def (cdef_cplusplus): Add a replacement for [[noreturn]].
>      * fixincl.x: Regenerate.
>      * tests/base/sys/cdefs.h: Update.
>
>      * genfixes: Remove the 'Ver.' from the version check.
>

Index: inclhack.def
===================================================================
--- inclhack.def	(revision 183089)
+++ inclhack.def	(working copy)
@@ -20,6 +20,7 @@
  FIXINC_DEBUG = yes;
  #endif

+
  /* On AIX when _LARGE_FILES is defined stdio.h defines fopen to
   * fopen64 etc. and this causes problems when building with g++
   * because cstdio udefs everything from stdio.h, leaving us with
@@ -1028,6 +1029,22 @@
      test_text = '#define  vfscanf	__svfscanf';
  };

+/*
+ * 'g++ -std=c++11' defines __cplusplus to 201103L, which suggests
+ * that it conforms to ISO/IEC 14882:2011.  Until G++ fully conforms,
+ * it should not set __cplusplus to that value.  It currently does
+ * not support the [[noreturn]] procedure attribute.
+ * When it does, this hack should be removed.
+ * SEE:  gcc.gnu.org/bugzilla/show_bug.cgi?id=51776
+ */
+fix = {
+    hackname  = cdef_cplusplus;
+    files     = sys/cdefs.h;
+    select    = '\[\[noreturn\]\]';
+    c_fix     = format;
+    c_fix_arg = '__attribute__((__noreturn__))';
+    test_text = "#define _Noreturn	[[noreturn]]";
+};

  /*
   *  Fix various macros used to define ioctl numbers.
Index: tests/base/sys/cdefs.h
===================================================================
--- tests/base/sys/cdefs.h	(revision 183089)
+++ tests/base/sys/cdefs.h	(working copy)
@@ -9,6 +9,11 @@



+#if defined( CDEF_CPLUSPLUS_CHECK )
+#define _Noreturn	__attribute__((__noreturn__))
+#endif  /* CDEF_CPLUSPLUS_CHECK */
+
+
  #if defined( FREEBSD_GCC3_BREAKAGE_CHECK )
  #if __GNUC__ == 2 && __GNUC_MINOR__ >= 7
  #endif  /* FREEBSD_GCC3_BREAKAGE_CHECK */
Index: genfixes
===================================================================
--- genfixes	(revision 183089)
+++ genfixes	(working copy)
@@ -62,7 +62,7 @@
  AG="autogen $AG"
  set -e

-if [ -z "`${AG} -v | fgrep 'Ver. 5.'`" ]
+if [ -z "`${AG} -v | fgrep ' 5.'`" ]
  then
    echo "AutoGen appears to be out of date or not correctly installed."
    echo "Please download and install:"
Comment 48 Steve Kargl 2012-01-11 16:23:14 UTC
On Wed, Jan 11, 2012 at 07:49:41AM +0000, andreast at gcc dot gnu.org wrote:
> 
> This is the CL I prepared:
> 
> 2012-01-11  Bruce Korb <bkorb@gnu.org>
>         Steven G. Kargl  <kargl@gcc.gnu.org>
>         Andreas Tobler  <andreast@fgznet.ch>
> 
This is ok with me.  In general, I'm more concerned
with fixing bugs than attribution for a patch.
Comment 49 Andreas Tobler 2012-01-11 18:35:12 UTC
Hmmmm, I managed to put a wrong PR number into the CL....

Here the commit:

http://gcc.gnu.org/ml/gcc-cvs/2012-01/msg00341.html