On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >>Like? If you are inlining atomic operations this means that you are > >>passing -march=i686, therefore in order to run the code in the first > >>place the machine has to be an i686, and libgcc certainly knows that. > >> > >> > >You build like kdelibs for -march=i386, it gets the ool version. Now you > >compile application foobar with -march=i686 and link against kdelibs. > >You're screwed. You cannot possibly catch all these cases. Also, libgcc > >does _not_ know the machine - it only knows the -march it was compiled > >for. > > > No! You didn't read yesterday's Mark and Uli messages! The idea is > having a "smart" version of libgcc which *knows* the machine. glibc is > already doing that and Mark knows the idea and would also like to have > that for other reasons. Please read yesterday messages. > > In your example, for instance, you are not screwed at all because > kdelibs ends up using out-of-line atomic operations.
You 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. Richard.
