On 6 April 2018 at 12:22, Richard Biener wrote: > On Fri, 6 Apr 2018, Jonathan Wakely wrote: > >> On 6 April 2018 at 10:39, Richard Biener wrote: >> > >> > The following allows people configuring the gcc-4 compatible ABI >> > as the default ABI to retain compatibility with old programs >> > catching ios_base::failure by matching the abi version thrown >> > to the configured default ABI. >> > >> > This doesn't really fix the PR but it makes behavior between >> > the dual-ABI with default gcc-4 compatible consistent with that >> > of the non-dual-ABI which is what I had expected. >> > >> > Whether an ABI break is really desired for the case of a c++11 >> > default ABI is still questionable and any programs that differ >> > from the default ABI choice will now be broken (compared to >> > those differing from c++11). >> > >> > Bootstrapped on x86_64-unknown-linux-gnu, ok for trunk? Ok for >> > the GCC 7 branch? >> >> Thinking about this further, I seem to recall we decided *not* to do >> this. Currently the --with-default-libstdcxx-abi flag only affects the >> default value of a macro in the headers, it doesn't affect the library >> ABI. The header macro can be overriden per translation unit, but the >> library ABI is always the same (it always throws the new ios::failure >> type). With this change the option would affect the library ABI and so >> --with-default-libstdcxx-abi would cause a new effect on libstdc++.so > > But --disable-libstdcxx-dual-abi does so as well.
Right, but that one (obviously) alters the library ABI, by disabling all the duplicated symbols. Currently --with-default-libstdcxx-abi doesn't alter the ABI of the shared lib when the dual-abi is enabled, just whether the initial value of the macro is 0 or 1. All the symbols in the library, and the type of exception thrown, are the same for every dual-abi build of the library. Sure, we _can_ change that, but should we? We could add yet another option, so you can set the initial value of the macro to 0 but still have it throw the new exception type, or vice versa. I don't really like that option either. > Currently the > behavior with that compared to > --with-default-libstdcxx-abi=gcc4-compatible is inconsistent with > respect to whether the following testcase works or not (note it > doesn't explicitely specify the ABI version to use) > > #include <iostream> > #include <fstream> > using namespace std; > int main () > { > std::ifstream pstats; > pstats.exceptions(ifstream::failbit | ifstream::badbit | > ifstream::eofbit); > try { > printf("\n Opening file : /proc/0/stat "); > pstats.open("/proc/0/stat"); > } > catch(ifstream::failure e) > { > printf("\n!!Caught ifstream exception!!\n"); > if(pstats.is_open()) { > pstats.close(); > } > } > return 0; > } > > I call that a bug. Yes, we talked about ways to eventually fix that. > But is anybody working on that? Not for GCC 8.1, but then we already shipped 7.x with the current behaviour anyway.