[Bug tree-optimization/28364] poor optimization choices when iterating over a std::string (probably not c++-specific)

["zackw at panix dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #7 from zackw at panix dot com  2006-07-12 23:19 -------
Created an attachment (id=11875)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11875&action=view)
C test case (with interesting implications)

I've found a plain C test case.  In the process, I've found that the way
libstdc++ <string> is coded interacts interestingly with the optimizer.

In the attached file, has_bad_chars_bad is a literal translation to C of the
code seen by the optimizers after inlining for the original C++ test case. 
Yes, libstdc++ <string> does the moral equivalent of ((struct
rep*)path)[-1].len.  This function compiles to the same bad code as my original
test case.

has_bad_chars_good, on the other hand, is how I naively thought <string> worked
on the first read-through.  That one compiles to code which looks optimal to
me.  I suspect some optimizer or other is not smart enough to see through this
particular construct ... it would be good to make it do so, since we want
libstdc++ <string> to generate good code.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28364