Re: gcc 3.2.3 config/os/bits/i386/atomicity.h broken

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <3EA97DB6 dot 8D34E964 at OARcorp dot com>,
Joel Sherrill<joel dot sherrill at OARcorp dot com> writes:

> I don't read this list very often.  Too much on my plate already.
> Angelo has been fighting this for a few months and has been stuck
> at gcc 3.2.  I just got frustrated enough to pester him into debugging
> it to the offending instruction and then homed in on that.  

OK, well, the bug is fixed in gcc 3.3.

> That's good to hear.  I had trouble finding clear documentation.  I
> really would like to be more confident that EVERY CPU model i486 and
> above has xaddl support.

I read as much as I could back when Benjamin (rightly) directed the
i386 port to generic pending additional work.

> First, I have no real easy way to ensure that the above
> implementation works at all.  By that I would want to see one thread
> spin until the other finished this operation. :)

Well, it took us many releases after gcc 3.0 to get all the MP bugs.

> But I have no opposition to having the lock;xaddl implementation
> selected if the appropriate CPU model cpp predefine is defined.

We can't to this given the current architecture.

> RTEMS uses multilibs on the i386 target so each variant could get
> teh best algorithm, not just an algorithm.

Perhaps, but libstdc++ doesn't multilib the installed headers.

>> Does it work in SMP configurations of the higher processors? 

> I think it would work better in SMP configurations since the thread that

> Not shipping code that runs on a generic i386 breaks C++ for many
> embedded targets. There are quite a few developers out there using
> CPUs like the i386 or other embedded i386 variants.

Well, under the current solution (which will ship in 3.3 unless we get
a code path that works on i386 up to SMP i686 and beyond), if you have
an OS that supports any of the gthr.h concrete implementations, you
are fine already (except perhaps slower than possible).

> I see no reason why it wouldn't work as long as that static "lock
> variable" is in shared memory.  If not, all bets are off.

OK, this is obscure.  The patch as you posted it, has a race.  C++
says that static at function scope act if-as initialized on the first
pass through.  g++ used to dynamically init non-zero values.  It appears
that mainline works like C in all constant init cases.

>> http://www.x86-64.org/lists/discuss/msg01969.html

> I don't know which part of that patch you are referring to.  I see
> ifdef's on the CMPXCHG instruction which (I think) is Pentium and
> above.  So that is an optimization.  What about that post bothers you?

The section where they comment out, with a #if 0/#endif region, the
xchgl instruction.

> The comment in semaphore.c appears to be about some other problem.

In system.h but perhaps that is an optimization only.  There are no
comments for context of why they made the change.

>> This does not fix the ABI issue raised in my response to Matthias.  In
>> fact, we need to be careful not to remove the link error, when we
>> apply your change.

> This one I do not know about.

I'd want whatever new version of i386/atomicity.h to fail at link time
when an attempt is made to mix-and-match locking protocols.  Otherwise
we get lots of PRs.

>> Joel, are you willing and able to post a complete updated version of
>> config/cpu/i386/atomicity.h?  If the code was reviewed by enough
>> people, I'd really want to see it get into 3.3.

> Sure.  Would you want it to be stright the generic version of ifdef'ed
> so when compiled for the higher level CPU models, it uses the
> lock;xaddl?

> Does this have a PR?  

No, that is the exact solution that doesn't work.  ;-)  There may be no
#ifdef regions in the header except the entire multiple inclusion
guard.  The reason is that this header is pulled into headers exposed
to users for templating purposes.

Please see:
http://gcc.gnu.org/ml/libstdc++/2003-04/msg00398.html
(which was posted moments before I saw your first post
commenting on this issue.)

Regards,
Loren