Paolo Carlini wrote: >Richard Guenther wrote: > >>ou are screwed, because if you pass a std::vector (assuming it needs >>locking) to kdelibs to mungle with and in a separate thread mungle with >>it in the -march=i686 application you're using two different types of locking >>which surely won't play well with each other. A smart libgcc cannot fix any >>inlined locking primitives. >> >locking is not inlined. > > A few more words: I suppose by "locking" you mean fall back for atomic operations on old arches, because otherwise some mutexes around have nothing to do with the case at issue. Now, that kind of locking can only take place inside libgcc and the libgcc uses atomic operations on that machine, of course, because the application that you are running is compiled with -march=i686.
Paolo.
