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.
