Re: Call for compiler help/advice: atomic builtins for v3

[Richard Guenther <richard dot guenther at gmail dot com>]

On 11/7/05, Paolo Carlini <pcarlini@suse.de> 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.