On 11/7/05, Paolo Carlini <[EMAIL PROTECTED]> wrote: > Richard Guenther wrote: > > >Richard is right - it's enough that the inlined version doesn't agree with > >whatever smartness is in libgcc. > > > 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. Inlining and transparently handling different sub-architecture just does not play together well. > In principle I can see now that you can do absolutely new things wrt > atomic operations in the application and keep around an old libgcc, not > even able to deal with the newer machine (which supports the former), > but I'd like to see something less theoretical. The solution with the same amount of problems like the libgcc solution, but localized to libstdc++ would be to support installing a libstdc++ with support for i386 disabled (and thus inlining using the builtins would be possible). Richard.
