This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Call for compiler help/advice: atomic builtins for v3
On 11/7/05, Paolo Carlini <pcarlini@suse.de> 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.