Compiler bug, surfacing in a map?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Hello,

I am currently writing a tool which employs a rather large map in one
central part. The keys are of a custom type, basically 4 wrapped ints,
combined with some additional logic. Changing the storage from a map would
break a lot of things, but performance was still crucial. This got me
started on experimenting with the SSE2 intrinsics in various places.

My "key" class currently begins like this:
class word_sequence

{

public:

int data[4];

word_sequence()

{

for (int x = 0; x < 4; x++)

{

data[x] = -1;

}

}

word_sequence(const word_sequence& source)

{

__m128i dataval = _mm_loadu_si128((__m128i*) source.data);

_mm_storeu_si128((__m128i*) data, dataval);

}



Note the copy constructor. The map itself uses the Boost pool allocator,
with a very large initial size:

typedef map<word_sequence, pair<int, partvector >, less<word_sequence>,

fast_pool_allocator<pair<word_sequence, pair<int, partvector > >,

default_user_allocator_new_delete,

details::pool::null_mutex,

131072> > DATATYPE;



Now, this has worked fine all until I introduced this copy constructor. I
can change by hand so that I use this constructor for assignments in my
code, but not for the map. Then it works. I can also make the initial pool
size even larger. Then it also works. BUT; when the boost pool needs to
reallocate, I'll end up with an access violation a bit down the road, when
the insert method in the map rearranges the tree to satisfy the colouring
requirements. When debugging, it seems like the register that should
containt a pointer to the current node does not containt that pointer at
all, so I get a stray reference down to 0x00000064.

This only happens in a release build. I've tried some different optimization
settings, while still getting it. A pure debug build runs fine.

Is anyone aware of some special requirement on copy constructors in the
context of a STL map? Or a bug in boost::pool? (Or conditions when you're
not allowed to use SIMD intrinsics?) I know that hash_map could be better
and that I should create my own storage if I'm that picky about performance,
but that's not an option right now.

This happens with the Visual C++.NET 2003 compiler. Going to a debug build,
or removing the copy constructor (replacing it with a boiler-plate
member-by-member copy) fixes the problem.

Any insights would be welcome.

/Carl




.

Relevant Pages

  • Re: Use the accessor! Was: Copy Constructor Usage
    ... I think you are getting too hung up on the copy constructor bit. ... accessor fns on some bogus efficiency argument. ... a field 'leng' might map onto an accessor 'size'; ... No style or design rules give us a free lunch. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: std::map<> with optional keys
    ... A copy constructor occurs when inserting an element into the ... >map but that is it. ... The keys would change. ...
    (microsoft.public.vc.stl)
  • Re: confusing delete problem
    ... Joerg Toellner wrote: ... > thx for your replies. ... > Can't understand your comments about copy constructor. ... > definitely ONE instance/object of type class map. ...
    (comp.lang.cpp)
  • Re: confusing delete problem
    ... Of course x is defined in the real code destructor. ... Can't understand your comments about copy constructor. ... definitely ONE instance/object of type class map. ...
    (comp.lang.cpp)
  • Re: Get list of unique words in a string
    ... may declare/define the same identifiers. ... additional "namespace" for all libraries of PointedEars' JavaScript ... Why do you declare functions in Map which don't use any of map ... _Value.isInstance and few others could all be taken out of constructor ...
    (comp.lang.javascript)