You can use the configure option --enable-cxx-flags=-fno-exceptions to create a C++ compiler without exceptions for the standard C++ library and the built in new/delete operators. In some cases you want this to save code space. Unfortunately this goal cannot be achieved. In guard.cc the class __gnu_cxx::recursive_init_error is defined which pulls in pure.cc via std::exception which depends on the IO libary.
Created attachment 20468 [details] Proposed changes. An alternative is to define this class in a separate file.
In Bug 43852 I thought you meant building with -fno-exceptions fails, but it works for me ... do you just mean the resulting library is not as small as it could be?
(In reply to comment #2) > In Bug 43852 I thought you meant building with -fno-exceptions fails, but it > works for me ... do you just mean the resulting library is not as small as it > could be? > Sorry for the misunderstanding. The build works fine, but the library is not as small as it could be. This is due to the inclusion of the unused __gnu_cxx::recursive_init_error class. For small target systems this is dramatic.
confirmed as an enhancement request
Simply removing this class now would break the ABI, which is not acceptable. If Bug 43852 was resolved by adding a "quiet" mode, would that make this enhancement unnecessary? That mode would also change the ABI, but would have to be explicitly requested by users, and would be documented as changing the ABI. Am I right in thinking that putting recursive_init_error in a separate file would only help when using static linking?
(In reply to comment #5) > Simply removing this class now would break the ABI, which is not acceptable. > If Bug 43852 was resolved by adding a "quiet" mode, would that make this > enhancement unnecessary? That mode would also change the ABI, but would have > to be explicitly requested by users, and would be documented as changing the > ABI. > > Am I right in thinking that putting recursive_init_error in a separate file > would only help when using static linking? > Yes, it helps only if you use static linking. From my point of view moving this class implementation into a separate compilation unit would help in case size really matters. In these situations you likely use static linking, because otherwise you need a runtime infrastructure for dynamic linking which is also not that trivial. If you suppose that users who care about size always choose the "quiet" mode then this change is virtually unnecessary, but not optimal.
I'll get this done asap ...
Author: redi Date: Wed Feb 9 23:22:27 2011 New Revision: 169989 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169989 Log: 2011-02-09 Jonathan Wakely <jwakely.gcc@gmail.com> PR libstdc++/43863 * libsupc++/guard.cc (recursive_init_error::~recursive_init_error): Move to ... * libsupc++/guard_error.cc: ... new file. * libsupc++/Makefile.am: Update. * libsupc++/Makefile.in: Regenerate. Added: trunk/libstdc++-v3/libsupc++/guard_error.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/libsupc++/Makefile.am trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/libsupc++/guard.cc
Sorry for taking so long - this is done for 4.6.0