https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #14 from Jonathan Wakely ---
Author: redi
Date: Tue Jul 18 23:39:34 2017
New Revision: 250328
URL: https://gcc.gnu.org/viewcvs?rev=250328&root=gcc&view=rev
Log:
PR libstdc++/81395 fix crash when write follows large read
PR l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #13 from Paolo Carlini ---
Hi,
> It looks strange, because usually _M_set_buffer(-1) is used for uncommitted
> mode, but what it's actually doing is nuking the buffers. The next read
> would need to do an underflow to refill the get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #12 from Jonathan Wakely ---
Hmm, except that if we *do* have a pending output sequence there (i.e. data in
the put area), we'd discard it, losing data. I'll try to verify that with a
testcase.
So we want to avoid getting into a stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #11 from Jonathan Wakely ---
I don't think uncommitted mode is correct there, because stdio requires a seek
on the underlying FILE before writing to it. Setting _M_reading ensures that
will happen before the next write. Uncommitted mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #10 from Paolo Carlini ---
Yes, I agree with your analysis, something seems wrong. I suspsect going to a
normal uncommitted mode, thus not setting _M_reading would largely work, but I
fear performance implications, etc. I would strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #9 from Jonathan Wakely ---
(In reply to Paolo Carlini from comment #4)
> Seems weird: -1 means uncommitted (per the comment before _M_set_buffer) and
> we also set _M_reading? I don't think we do that anywhere else.
But we also don'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #8 from Jonathan Wakely ---
(In reply to Paolo Carlini from comment #6)
> The relevant xsgetn code essentially is an optimization, right? Shouldn't be
> too difficult to figure out what would happen in the slow, correct case...
> What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #7 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #3)
> This started in 4.6.0 with r87453
It did start with 4.6.0 but that commit was already in 4.5.4 so it can't have
been that one. It seems to be the change to o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #6 from Paolo Carlini ---
The relevant xsgetn code essentially is an optimization, right? Shouldn't be
too difficult to figure out what would happen in the slow, correct case...
What's wrong with a normal uncommitted case, thus _M_rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #5 from Jonathan Wakely ---
PR 45708 suggested that _M_reading and _M_writing aren't needed. I haven't
found a patch to implement that, but I haven't looked too hard.
You make a good point that going into uncommitted mode with _M_rea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
--- Comment #4 from Paolo Carlini ---
Seems weird: -1 means uncommitted (per the comment before _M_set_buffer) and we
also set _M_reading? I don't think we do that anywhere else. But it's a long
time... Note that I clearly remember somebody sugge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81395
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
13 matches
Mail list logo
