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