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 <1051331346 dot 28271 dot 9123 dot camel at mccallum dot corsepiu dot faw dot uni-ulm dot de>,
Ralf Corsepius<corsepiu at faw dot uni-ulm dot de> writes:

>> > 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.
> Why? I think we already do.

> Given the gcc-3.2.2/3 implementation of atomicity.h works sufficiently,
> all we need to do is to detect such cases which do not support the xadd
> instruction. 

> Then, AFAIS, #ifdef'ing on __tune_i386__ is sufficient. This is what I
> try to exploit in my rtems-gcc-3.2.2-patch below.

What you have proposed is known as an ODR violation in C++.  ODR
covers the internal implementation in addition to the ABI itself.  Had
this header file only been used in library implementation and not been
seen directly by application code (and random command line switches
provided by the user), then we could make a patch as you suggest.

This is the aspect of the current architecture I refer to.

>> 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.
> I don't agree on this (cf. to my patch below). You just must not change
> the ABI and API if ifdefs get encountered.

Since there is no locking on your __tune_i386__ path, it will not
function as required (I think you might be looking at very old
generic/atomicity.h code).  I understand how your change makes the
i386 version look similar to some other CPU atomicity.h files but I
must reject it on principle.  I much rather prefer the patch that Joel
posted (this is where we find a spin lock implementation that works on
i386 and all architectures which claim compatibility with i386/IA32).

Regards,
Loren