This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: libstdc++/4150: catastrophic performance decrease in C++ code

From: Benjamin Kosnik <bkoz at redhat dot com>
To: Jason Merrill <jason at redhat dot com>
Cc: rittle at latour dot rsch dot comm dot mot dot com, libstdc++ at gcc dot gnu dot org
Date: Mon, 22 Apr 2002 09:13:42 -0700
Subject: Re: libstdc++/4150: catastrophic performance decrease in C++ code
Organization: Red Hat/San Francisco
References: <wvl7kn8vtvj.fsf@prospero.cambridge.redhat.com><200204181158.g3IBwMN00580@latour.rsch.comm.mot.com><20020419020746.0bb2f926.bkoz@redhat.com><wvl1yd9ea9t.fsf@prospero.cambridge.redhat.com>
Reply-to: bkoz at redhat dot com


> No, it turns out to be the equal but opposite bug; with my patch, if
> you do a sputc followed by an sungetc, _M_out_cur is unchanged, and no
> write is done.  So if you always write from _M_out_beg to _M_out_end,
> you get spurious writes, and if you don't, you lose writes.  Both
> because read operations have confused things.

After looking at this last night, I have to agree. Your patch as it
stands breaks expected behavior.

-benjamin

Follow-Ups:
- Re: libstdc++/4150: catastrophic performance decrease in C++ code
  - From: Jason Merrill

References:
- Re: libstdc++/4150: catastrophic performance decrease in C++ code
  - From: Jason Merrill
- Re: libstdc++/4150: catastrophic performance decrease in C++ code
  - From: Loren James Rittle
- Re: libstdc++/4150: catastrophic performance decrease in C++ code
  - From: Benjamin Kosnik
- Re: libstdc++/4150: catastrophic performance decrease in C++ code
  - From: Jason Merrill

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]