Re: [PATCH] Mitigate PR85222 a bit

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

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.