The following code produces possibly wrong-code with -O2 on Apple's g++-3.3,
but I'm not sure if this is reproducible on other platforms.  First, I'm
pasting the unpreprocessed source, will attach .ii momentarily.  (Yes, I
realize 3.3 is closed, but I'd like to know if this is a known problem, or I'm
just wrong in my test case.)

--------- begin un-preprocessed source ----------
#include <iostream>
#include <ext/hash_map>
using std::cerr;
using std::endl;
using __gnu_cxx::hash_map;

struct foo {
        typedef hash_map<int, int>                      map_type;
        typedef map_type::iterator                      iterator;

        map_type                                        _map;

        foo();

        void
        bar(void);
};

foo::foo() : _map() {
        _map[1] = 11;
        _map[2] = 22;
}

void
foo::bar(void) {
        const iterator b(_map.begin()), e(_map.end());
        // cerr << _map.size() << endl;
{
        iterator i(b);
        for ( ; i!=e; ++i) {
           cerr << i->first << " -> " << i->second << endl;
        }
}
}

int
main(int argc, char* argv[]) {
        foo f;
        f.bar();
        return 0;
}

---------- end un-preprocessed source -----------

compilation: g++-3.3 -O2 O2bug.cc -o O2bug

run: O2bug

expected result:
1 -> 11
2 -> 22

got:
1 -> 11
Bus Error

remarks: 
1) g++-3.3 using -O0 (no optimization) results in the expected output.
2) replacing "iterator i(b)" with "iterator i(_map.begin())" results in the
expected output.
3) uncommenting "cerr << _map.size() << endl" results in the expected output,
following '2'.  This baffles me.

known to fail: (Apple) g++-3.3 (builds 1640, 1819)
known to work: (Apple) g++-4.0.1 (build 5247) -O2, (FSF) g++-4.1.0
(powerpc-apple-darwin8)

Q: (STL) is there something incorrect about my use of the hash_map iterator?  I
expect the substitution in Remark 2 to be equivalent to the original source,
since hashtable::iterator is default copy-constructible.

If this is an Apple-only problem, I'll send this to Apple, of course.


-- 
           Summary: optimization on hashtable iterator produces bad code
           Product: gcc
           Version: 3.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: fang at csl dot cornell dot edu
  GCC host triplet: powerpc-apple-darwin7


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

Reply via email to