[Bug libstdc++/51705] New: Build infrastructure should not use -std=c++0x until g++ properly supports it

[Bug libstdc++/51705] New: Build infrastructure should not use -std=c++0x until g++ properly supports it

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

             Bug #: 51705
           Summary: Build infrastructure should not use -std=c++0x until
                    g++ properly supports it
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ed@80386.nl


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.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 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.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #2 from Ed Schouten <ed at 80386 dot nl> 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.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[chris at bubblescope dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Chris Jefferson <chris at bubblescope dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chris at bubblescope dot
                   |                            |net

--- Comment #3 from Chris Jefferson <chris at bubblescope dot net> 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.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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++.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[redi at gcc dot gnu.org]

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

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #6 from Ed Schouten <ed at 80386 dot nl> 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.

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.)

[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it

[chris at bubblescope dot net]

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.

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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |*-*-freebsd
          Component|libstdc++                   |bootstrap
            Version|unknown                     |4.7.0
            Summary|Build infrastructure should |FreeBSD uses unsupported
                   |not use -std=c++0x until    |C++11 features when
                   |g++ properly supports it    |__cplusplus == 201103L

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> 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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #11 from Ed Schouten <ed at 80386 dot nl> 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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #12 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[redi at gcc dot gnu.org]

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?

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

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #14 from Ed Schouten <ed at 80386 dot nl> 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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #15 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
           Severity|normal                      |blocker

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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:"

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Andreas Tobler <andreast at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andreast at gcc dot gnu.org

--- Comment #17 from Andreas Tobler <andreast at gcc dot gnu.org> 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";
+};
+/*

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #18 from Ed Schouten <ed at 80386 dot nl> 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?

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #19 from Andreas Tobler <andreast at gcc dot gnu.org> 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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #20 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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]

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #21 from Andreas Tobler <andreast at gcc dot gnu.org> 2011-12-30 18:06:27 UTC ---
Neither bash nor GNU sed is installed on this machine.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

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.

[Bug bootstrap/51705] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #23 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-02
   Target Milestone|---                         |4.7.0
            Summary|FreeBSD uses unsupported    |[4.7 Regression] FreeBSD
                   |C++11 features when         |uses unsupported C++11
                   |__cplusplus == 201103L      |features when __cplusplus
                   |                            |== 201103L
     Ever Confirmed|0                           |1

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkorb at gnu dot org, jason
                   |                            |at gcc dot gnu.org,
                   |                            |ljrittle at acm dot org

--- Comment #24 from Jason Merrill <jason at gcc dot gnu.org> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[bkorb at gnu dot org]

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]]".

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #26 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[jakub at gcc dot gnu.org]

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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu.org

--- Comment #28 from Jonathan Wakely <redi at gcc dot gnu.org> 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

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #29 from Andreas Tobler <andreast at gcc dot gnu.org> 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]]";
+};
+/*

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[bkorb at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #30 from bkorb at gnu dot org 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

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[bkorb at gnu dot org]

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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #31 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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. 
+ */

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #33 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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?

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

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__\)\)";

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

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #35 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[chris at bubblescope dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #36 from Chris Jefferson <chris at bubblescope dot net> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[bkorb at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #37 from bkorb at gnu dot org 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:"

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #38 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #39 from Ed Schouten <ed at 80386 dot nl> 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]].

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[chris at bubblescope dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #40 from Chris Jefferson <chris at bubblescope dot net> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[ed at 80386 dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #41 from Ed Schouten <ed at 80386 dot nl> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #42 from joseph at codesourcery dot com <joseph at codesourcery dot 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[chris at bubblescope dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #43 from Chris Jefferson <chris at bubblescope dot net> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[jason at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #44 from Jason Merrill <jason at gcc dot gnu.org> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Andreas Tobler <andreast at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #26207|0                           |1
        is obsolete|                            |
         AssignedTo|unassigned at gcc dot       |andreast at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #45 from Andreas Tobler <andreast at gcc dot gnu.org> 2012-01-11 07:46:27 UTC ---
Created attachment 26297
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26297
patch

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[bkorb at gnu dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #47 from bkorb at gnu dot org 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:"

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

--- Comment #48 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 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.

[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L

[andreast at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705

Andreas Tobler <andreast at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #49 from Andreas Tobler <andreast at gcc dot gnu.org> 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