public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "Ting.Wang.SH at ibm dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/106248] New: operator>>std::basic_istream at boundary condition behave differently in different opt levels Date: Mon, 11 Jul 2022 01:39:49 +0000 [thread overview] Message-ID: <bug-106248-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106248 Bug ID: 106248 Summary: operator>>std::basic_istream at boundary condition behave differently in different opt levels Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: Ting.Wang.SH at ibm dot com Target Milestone: --- SYMPTOM: Saw operator>>std::basic_istream set ios_base::eofbit differently when buffer size equals to stream content size under different optimization levels. This is observed on gcc version 11.2.0 with libstdc++.so.6.0.30, and not observed on gcc version 9.4.0 with libstdc++.so.6.0.28. This might not be a bug, however the behavior change under different optimization levels is a little bit annoying. An example C++ program is $ cat a.cc #include <istream> #include <sstream> #include <iostream> char a_[10]; int main(int argc, char *argv[]) { std::basic_string<char, std::char_traits<char>, std::allocator<char> > input((const char *)" abcdefghi"); std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> > sbuf(input); std::basic_istream<char, std::char_traits<char> > istr(&sbuf); istr >> a_; std::cout << "istr.rdstate: " << istr.rdstate() << std::endl; return 0; } $ g++ -O0 -o a.O0 a.cc $ ./a.O0 istr.rdstate: 2 $ g++ -O3 -o a.O3 a.cc $ ./a.O3 istr.rdstate: 0
next reply other threads:[~2022-07-11 1:39 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-07-11 1:39 Ting.Wang.SH at ibm dot com [this message] 2022-07-11 6:11 ` [Bug libstdc++/106248] " pinskia at gcc dot gnu.org 2022-07-11 11:07 ` redi at gcc dot gnu.org 2022-07-11 11:20 ` [Bug libstdc++/106248] [11/12/13 Regression] " redi at gcc dot gnu.org 2022-07-11 11:34 ` redi at gcc dot gnu.org 2022-07-11 11:36 ` redi at gcc dot gnu.org 2022-07-11 11:46 ` redi at gcc dot gnu.org 2022-07-11 12:38 ` redi at gcc dot gnu.org 2022-07-11 13:32 ` redi at gcc dot gnu.org 2022-07-12 22:40 ` cvs-commit at gcc dot gnu.org 2022-07-12 22:41 ` [Bug libstdc++/106248] [11/12 " redi at gcc dot gnu.org 2022-07-25 15:05 ` rguenth at gcc dot gnu.org 2022-08-03 13:47 ` cvs-commit at gcc dot gnu.org 2022-08-03 13:48 ` [Bug libstdc++/106248] [11 " redi at gcc dot gnu.org 2022-09-07 17:49 ` cvs-commit at gcc dot gnu.org 2022-09-07 17:53 ` redi at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-106248-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).