On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > 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.
That works, if only code playing well (or failing with SIGILL) with either locking scheme is ever inlined. I.e. for x86 you cannot inline the i386 variant. If such simple rule is possible on other architectures affected is beyond my knowledge. And of course currently libgcc is not clever enough in the sense of Uli. Richard.
