This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc
- From: "potswa at mac dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 30 Sep 2010 09:52:48 +0000
- Subject: [Bug libstdc++/45841] [4.6 Regression]: r164529 cris-elf libstdc++ 27_io/basic_filebuf/seekoff/char/2-io.cc
- Auto-submitted: auto-generated
- References: <bug-45841-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45841
--- Comment #4 from David Krauss <potswa at mac dot com> 2010-09-30 09:52:48 UTC ---
Ah, I didn't even notice the target line before.
This is unbuffered I/O, which can be challenging to the codecvt. But this isn't
a failure I would anticipate. If the codecvt fails, there should be an
exception; if it succeeds, the result is cached so the second sgetc() returns
the same result. (Thus, it's not *really* unbuffered.)
I don't see how the patch could change this particular behavior. Definitely
need that trace. And I presume I'll need to upgrade gdb to use it. Which
entails building GDB for that architecture from source, on my machine?
Or do you guys happen to have a setup I can ssh into? :v)