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.
(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.
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.
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.
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++.
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
(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.
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.)
(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.
(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.
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.
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.
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.
(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.
(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.
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.
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:"
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"; +}; +/*
Though there's nothing wrong with using __dead2, wouldn't it be better to use __attribute__((__noreturn__) directly?
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.
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]
Neither bash nor GNU sed is installed on this machine.
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.
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.
(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.
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]]".
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.
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.
(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
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]]"; +}; +/*
(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
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. + */
(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.
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?
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?
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.
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.
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:"
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.
(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]].
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.
(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.
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.
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.
There is a conflict between the FreeBSD headers and G++, and we can fix it with fixincludes. Let's do that and move on.
Created attachment 26297 [details] patch
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.
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:"
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.
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