No needs to have mutable _M_sbuf in istreambuf_iterator
more.
---
libstdc++-v3/include/bits/streambuf_iterator.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h
b/libstdc++-v3/include/bits/streambuf_iterator.h
index 203da9d..e2b67
Ask associated streambuf for character when needed instead of
accumulate it in istreambuf_iterator object.
Benefits from this:
- minus one class member in istreambuf_iterator
- trivial synchronization of states of istreambuf_iterator
and associated streambuf
---
libstdc++-v3/include/bits/
This reverts commit 0dfbafdf338cc6899d146add5161e52efb02c067
(svn r253417).
---
libstdc++-v3/include/bits/streambuf_iterator.h | 59 ++
1 file changed, 33 insertions(+), 26 deletions(-)
diff --git a/libstdc++-v3/include/bits/streambuf_iterator.h
b/libstdc++-v3/include/bit
istreambuf_iterator should not forget about attached
streambuf when it reach EOF.
Checks in debug mode has no infuence more on character
extraction in istreambuf_iterator increment operators.
In this aspect behaviour in debug and non-debug mode
is similar now.
Test for detached srteambuf in istre
On Wed, 15 Nov 2017 22:31:11 +0100
Paolo Carlini wrote:
> Hi,
>
> On 15/11/2017 11:48, Petr Ovtchenkov wrote:
> > Ask associated streambuf for character when needed instead of
> > accumulate it in istreambuf_iterator object.
> >
> > Benefits from this:
&
On Mon, 6 Nov 2017 22:19:22 +0100
François Dumont wrote:
> Hi
>
> Any final decision regarding this patch ?
>
> François
https://gcc.gnu.org/ml/libstdc++/2017-11/msg00036.html
https://gcc.gnu.org/ml/libstdc++/2017-11/msg00035.html
https://gcc.gnu.org/ml/libstdc++/2017-11/msg00037.html
htt
On Thu, 16 Nov 2017 10:39:02 +0100
Paolo Carlini wrote:
> Hi,
>
> On 16/11/2017 06:31, Petr Ovtchenkov wrote:
> > Is we really worry about frozen sizeof of instantiated template?
> Yes we do. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html
> under "Pr
On Thu, 16 Nov 2017 10:56:29 +
Jonathan Wakely wrote:
> On 10/10/17 22:55 +0300, Petr Ovtchenkov wrote:
> >This reverts commit 0dfbafdf338cc6899d146add5161e52efb02c067
> >(svn r253417).
>
> I'm not even going to bother to review patches sent without any
> exp
On Thu, 16 Nov 2017 12:29:37 +0100
Paolo Carlini wrote:
> Hi,
>
> On 16/11/2017 12:03, Petr Ovtchenkov wrote:
> > On Thu, 16 Nov 2017 10:39:02 +0100
> > Paolo Carlini wrote:
> >
> >> Hi,
> >>
> >> On 16/11/2017 06:31, Petr Ovtchenkov
On Thu, 16 Nov 2017 11:39:30 +
Jonathan Wakely wrote:
> On 16/11/17 14:35 +0300, Petr Ovtchenkov wrote:
> >On Thu, 16 Nov 2017 10:56:29 +
> >Jonathan Wakely wrote:
> >
> >> On 10/10/17 22:55 +0300, Petr Ovtchenkov wrote:
> >> >This reverts commi
On Thu, 16 Nov 2017 11:46:48 +
Jonathan Wakely wrote:
> On 16/11/17 10:57 +, Jonathan Wakely wrote:
> >On 16/11/17 08:51 +0300, Petr Ovtchenkov wrote:
> >>On Mon, 6 Nov 2017 22:19:22 +0100
> >>François Dumont wrote:
> >>
> >>>Hi
> &g
On Wed, 20 Sep 2017 13:44:59 +0300
Petr Ovtchenkov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
>
> On Fri, 20 May 2016 16:10:50 +0300
> Petr Ovtchenkov wrote:
>
> > Some old ad-hoc (adding -I/usr/include to compiler
> > flags) break compilati
On Thu, 16 Nov 2017 18:40:08 +0100
François Dumont wrote:
> On 16/11/2017 12:46, Jonathan Wakely wrote:
> > On 16/11/17 10:57 +, Jonathan Wakely wrote:
> >> On 16/11/17 08:51 +0300, Petr Ovtchenkov wrote:
> >>> On Mon, 6 Nov 2017 22:19:22 +0100
> >>&g
On Thu, 16 Nov 2017 20:55:37 +0300
Petr Ovtchenkov wrote:
> On Wed, 20 Sep 2017 13:44:59 +0300
> Petr Ovtchenkov wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
> >
> > On Fri, 20 May 2016 16:10:50 +0300
> > Petr Ovtchenkov wrote:
> >
On Wed, 24 Jan 2018 17:39:59 +0100
François Dumont wrote:
> Hi
>
> I'd like to propose this new debug check. Comparing with non-eos
> istreambuf_iterator sounds like an obvious coding mistake.
>
> I propose it despite the stage 1 as it is just a new debug check,
> it doesn't impact
On Wed, 24 Jan 2018 21:34:48 +0100
François Dumont wrote:
> On 24/01/2018 18:53, Petr Ovtchenkov wrote:
> > On Wed, 24 Jan 2018 17:39:59 +0100
> > François Dumont wrote:
> >
> >> Hi
> >>
> >> I'd like to propose this new debug check. C
On Tue, 19 Dec 2017 11:37:43 +0300
Petr Ovtchenkov wrote:
ping^3
> On Thu, 16 Nov 2017 20:55:37 +0300
> Petr Ovtchenkov wrote:
>
> > On Wed, 20 Sep 2017 13:44:59 +0300
> > Petr Ovtchenkov wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
On Tue, 30 Jan 2018 12:54:21 +
Jonathan Wakely wrote:
> On 30/01/18 10:19 +0300, Petr Ovtchenkov wrote:
> >On Tue, 19 Dec 2017 11:37:43 +0300
> >Petr Ovtchenkov wrote:
> >
> >ping^3
>
>
> I don't fully understand the consequences (or need) for this
On Wed, 18 Oct 2017 16:51:37 +0200
FX wrote:
> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on
> macOS 10.13 often fail
> (failure rate for “make -j2” to “make -j8” is about 60% from my own builds
> and results reported
> by others): https://gcc.gnu.org/bugzilla/show_
On Thu, 19 Oct 2017 10:37:14 +0200
Richard Biener wrote:
> On Wed, Oct 18, 2017 at 11:58 PM, FX wrote:
> >> Could you test using .PHONY: install-headers instead?
> >> That target *is* phony, so telling make that seems sensible.
> >
> > I’ve tried adding it to the existing .PHONY list:
> >
> > In
Reword loop in copy_n specialization for input iterator.
Avoid condition check and jumps within loop.
Pay attention that input iterator incremented n - 1 times,
while output iterator incremented n times.
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50119 and
https://gcc.gnu.org/bugzilla/show_b
istream_iterator do unexpected read from stream
when initialized by istream&.
It is not required from increment operators of istream_iterator
that _M_ok will be true as precondition.
---
libstdc++-v3/include/bits/stream_iterator.h| 19 +-
.../24_iterators/istream_iterator/81964.cc
Explicit do sgetc from associated streambuf. Avoid debug-dependent
sgetc (within _M_at_eof()):
__glibcxx_requires_cond(!_M_at_eof(),
_M_message(__gnu_debug::__msg_inc_istreambuf)
._M_iterator(*this));
Increment operators not req
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81964
On Thu, 24 Aug 2017 11:55:58 +0300
Petr Ovtchenkov wrote:
> istream_iterator do unexpected read from stream
> when initialized by istream&.
>
> It is not required from increment operators of istream_iterator
> that _M
copy_n return result + n (i.e. increment OutputIterator n times) and
increment InputIterator max(0, n - 1).
This is issue 81857.
See also https://cplusplus.github.io/LWG/issue2471
---
.../testsuite/25_algorithms/copy_n/81857.cc| 83 ++
1 file changed, 83 insertions(+)
-gcc-patches
On Thu, 7 Sep 2017 23:02:15 +0200
François Dumont wrote:
> + _M_c = _M_sbuf->sgetc();
> + if (_S_at_eof(_M_c))
> + _M_sbuf = 0;
_M_sbuf = 0; <--- Is not what I axpect here.
Suggestions will be later, after we finish copyright assignment for
changes procedure (in pro
Some old ad-hoc (adding -I/usr/include to compiler
flags) break compilation of libstdc++ for foreign
target architecture (due to compiler see includes
of native).
---
libstdc++-v3/acinclude.m4 | 5 -
libstdc++-v3/configure| 22 --
libstdc++-v3/configure.ac | 14 ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71212
On Fri, 20 May 2016 16:10:50 +0300
Petr Ovtchenkov wrote:
> Some old ad-hoc (adding -I/usr/include to compiler
> flags) break compilation of libstdc++ for foreign
> target architecture (due to compiler see includes
> of native).
istreambuf_iterator should not forget about attached
streambuf when it reach EOF.
Checks in debug mode has no infuence more on character
extraction in istreambuf_iterator increment operators.
In this aspect behaviour in debug and non-debug mode
is similar now.
Test for detached srteambuf in istre
On Thu, 28 Sep 2017 11:34:25 +0100
Jonathan Wakely wrote:
> On 23/09/17 09:54 +0300, Petr Ovtchenkov wrote:
> >istreambuf_iterator should not forget about attached
> >streambuf when it reach EOF.
> >
> >Checks in debug mode has no infuence more on character
> >
On Thu, 28 Sep 2017 13:38:06 +0100
Jonathan Wakely wrote:
> On 28/09/17 15:06 +0300, Petr Ovtchenkov wrote:
> >On Thu, 28 Sep 2017 11:34:25 +0100
> >Jonathan Wakely wrote:
> >
> >> On 23/09/17 09:54 +0300, Petr Ovtchenkov wrote:
> >> >istreambuf
istreambuf_iterator should not forget about attached
streambuf when it reach EOF.
Checks in debug mode has no infuence more on character
extraction in istreambuf_iterator increment operators.
In this aspect behaviour in debug and non-debug mode
is similar now.
Test for detached srteambuf in istre
On Thu, 5 Oct 2017 12:56:36 +0200
Yvan Roux wrote:
> On 5 September 2017 at 12:04, Jakub Jelinek wrote:
> > On Tue, Sep 05, 2017 at 10:58:22AM +0200, Yvan Roux wrote:
> >> ping
> >>
> >> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01784.html
> >
> > This really needs to be reviewed by a build
On Fri, 6 Oct 2017 18:01:36 +0200
François Dumont wrote:
> ...
> >>> The test itself simulate "stop and go" istream usage.
> >>> stringstream is convenient for behaviuor illustration, but in "real life"
> >>> I can assume socket or tty on this place.
> >> At the very minimum we should have a comm
On Sun, 8 Oct 2017 16:59:39 +0200
François Dumont wrote:
> ...
> >>
> >> Consider this code:
> >>
> >> std::istringstream inf("abc");
> >> std::istreambuf_iterator j(inf), eof;
> >> std::istreambuf_iterator i = j++;
> >>
> >> assert( *i == 'a' );
> >>
> >> At this point it looks l
On Sun, 8 Oct 2017 16:59:39 +0200
François Dumont wrote:
> ...
> >>> We have three issues with istreambuf_iterator:
> >>> - debug-dependent behaviour
> >> Fixed.
> > + __glibcxx_requires_cond(_M_sbuf,
> > _M_message(__gnu_debug::__msg_inc_istreambuf)
> >
36 matches
Mail list logo
