Note, the following is in reference to this Debian version of GCC: gcc version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10) However, it also occurs under a version I have built myself: Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc-4.1 --enable-languages=c,c++,java Thread model: posix gcc version 4.1.1 My C++ knowledge isn't extensive enough to give further details of this other than it's related to string handling, or guess if it's already been reported, but the following preprocessed code reproduces the problem under -O3, but not -O2. The code performs correctly under GCC 3.4.6 and -O3 Here is the expected output: op [0]: "A" op [1]: "B" op [2]: "C" op [3]: "D" op [4]: "E" op [5]: "F" Here is a crash caught by GDB: CfgSchema (this=0xbfd0a400, schema_str=@0xbfd0a40c) at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:260 260 if (__pred(*__first)) (gdb) bt #0 CfgSchema (this=0xbfd0a400, schema_str=@0xbfd0a40c) at /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/stl_algo.h:260 #1 0x08048ebe in main () at cfgtblopt.cpp:36
Created attachment 11981 [details] Preprocessed C++ demonstrating problem
The problem cannot be reproduced in mainline, only in 4_1-branch. Seems an rtl-optimization bug: for the below slightly reduced testcase t97.final_cleanup is identical in mainline and 4_1-branch: #include <string> #include <algorithm> template<typename InputIter, typename SplitPred> inline void SplitTo(InputIter b, InputIter e, SplitPred sp) { InputIter p = std::find_if(b, e, sp); while (p != e) { b = p; p = std::find_if(b, e, sp); } } template<typename InputIter> inline void SplitTo(InputIter b, InputIter e) { SplitTo(b, e, std::bind2nd(std::equal_to<char>(), ';')); } int main(void) { const std::string& src = ""; SplitTo(src.begin(), src.end()); }
-O2 -finline-functions is sufficient to reproduce the problem on the branch, or if you mark CfgSchema::CfgSchema(const std::string &) 'inline'.
Paolo has already confirmed this one.
I cannot reproduce this with 4.1.2 20061024 anymore.
Can the original submitter still reproduce this problem?
I can confirm that this is fixed with the GCC 4.1 now in Debian unstable.
And it's back, at least in this version: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc-4.1 --enable-languages=c,c++,java Thread model: posix gcc version 4.1.2 20061204 (prerelease)
Closing 4.1 branch.