https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #37 from Jonathan Wakely ---
Author: redi
Date: Wed Aug 8 15:40:11 2018
New Revision: 263414
URL: https://gcc.gnu.org/viewcvs?rev=263414=gcc=rev
Log:
PR libstdc++/66145 allow catching iostream errors as cxx11 ios::failure
Define a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Bug 66145 depends on bug 85222, which changed state.
Bug 85222 Summary: [7 Regression] ABI breakage of __throw_ios_failure by r244498
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85222
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #36 from Jonathan Wakely ---
(In reply to Richard Biener from comment #35)
> I have opened a new bug for the ABI regression.
That's PR 85222 and is now fixed on trunk, so comment 32 works again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #35 from Richard Biener ---
(In reply to Jonathan Wakely from comment #34)
> (In reply to Richard Biener from comment #33)
> > Probably impossible to fix without breaking the ABI again, but there should
> > have been two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #34 from Jonathan Wakely ---
(In reply to Richard Biener from comment #33)
> Probably impossible to fix without breaking the ABI again, but there should
> have been two __throw_ios_failure entries (and callers be "versioned" as
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #33 from Richard Biener ---
(In reply to Richard Biener from comment #32)
> Now the reverse fails - a program compiled with a GCC defaulting to the old
> ABI
> (like GCC 4.8) now fails to run with a dual-ABI libstdc++:
>
> #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #32 from Richard Biener ---
Now the reverse fails - a program compiled with a GCC defaulting to the old ABI
(like GCC 4.8) now fails to run with a dual-ABI libstdc++:
#include
#include
using namespace std;
int main ()
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #31 from Jonathan Wakely ---
Author: redi
Date: Fri Feb 3 19:26:51 2017
New Revision: 245167
URL: https://gcc.gnu.org/viewcvs?rev=245167=gcc=rev
Log:
PR libstdc++/66145 ensure new ABI for ios::failure tests
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #30 from Jonathan Wakely ---
I don't plan to change this for gcc 5 and gcc 6, because changing the type of
exception thrown by the library doesn't seem appropriate for a minor release
within the 5.x or 6.x series.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #28 from Jonathan Wakely ---
Author: redi
Date: Mon Jan 16 15:58:06 2017
New Revision: 244498
URL: https://gcc.gnu.org/viewcvs?rev=244498=gcc=rev
Log:
PR66145 use new ABI for std::ios::failure exceptions
PR libstdc++/66145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Davin McCall changed:
What|Removed |Added
CC||davmac at davmac dot org
--- Comment #27
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #26 from Boris Kolpackov ---
> If breaking the old ABI was an option we wouldn't be in this situation in the
> first place.
By throwing the new version you are breaking the ABI. The point I was trying to
make is that maybe in this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #24 from Boris Kolpackov ---
Some more speculation/crazy ideas about the potential fix:
If just throwing the new version and forgetting about the old one is an option,
then perhaps we could "de-inherit" old from std::exception and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #25 from Jonathan Wakely ---
(In reply to Boris Kolpackov from comment #24)
> Some more speculation/crazy ideas about the potential fix:
>
> If just throwing the new version and forgetting about the old one is an
> option, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #23 from Jonathan Wakely ---
(In reply to Boris Kolpackov from comment #21)
> Speaking of possible fixes, I had this crazy idea, not sure if it is
> technically possible though: what if libstdc++ throws some custom exception
> that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Shital Shah changed:
What|Removed |Added
CC||sytelus at gmail dot com
--- Comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #21 from Boris Kolpackov ---
Speaking of possible fixes, I had this crazy idea, not sure if it is
technically possible though: what if libstdc++ throws some custom exception
that derives from both version of ios::failure? This way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #20 from Victor Mataré ---
(In reply to Victor Mataré from comment #19)
> > I'm not suggesting anything radical or novel, just the standard way to use
> > iostreams.
> [...]
> Maybe anyone with more insight into the standardization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #19 from Victor Mataré ---
> I'm not suggesting anything radical or novel, just the standard way to use
> iostreams.
I'd call that "the legacy way" or the "C-like pattern". Call it "predominant"
or "established" if you wish.
But
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #18 from Jonathan Wakely ---
(In reply to Boris Kolpackov from comment #17)
> > if (is >> x >> y >> z)
>
> And what should happen in the else part of such statements?
>
> if (is >> x >> y >> z)
> ...
> else
> throw something();
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #17 from Boris Kolpackov ---
> if (is >> x >> y >> z)
And what should happen in the else part of such statements?
if (is >> x >> y >> z)
...
else
throw something();
Also note that if the 'is >> x' call in the above chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #16 from Jonathan Wakely ---
(In reply to Boris Kolpackov from comment #15)
> I am interested to hear what is your recommendation to do instead, call
> good()
> after every IO operation?
The normal way that iostreams are designed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #15 from Boris Kolpackov ---
> And I still think using exceptions in iostreams is dumb in the first place.
I am interested to hear what is your recommendation to do instead, call good()
after every IO operation?
In fact, I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
--- Comment #14 from Jonathan Wakely ---
Yes, and I'm still planning to fix it.
(And I still think using exceptions in iostreams is dumb in the first place).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Boris Kolpackov changed:
What|Removed |Added
CC||boris at kolpackov dot net
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145
Richard Biener changed:
What|Removed |Added
Target Milestone|5.4 |5.5
--- Comment #12 from Richard
27 matches
Mail list logo
