Re: [PATCH] remove target dependency for atomicity.h on ix86

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

In article <16040 dot 53464 dot 970983 dot 7584 at gargle dot gargle dot HOWL>,
Matthias Klose<doko at cs dot tu-berlin dot de> writes:

> Thanks for the explanation. Please could you outline a possible
> solution, not sure if I am able to do it then, but IMO it should be
> fixed for 3.3.

See below.

> The ABI changes from 3.2 to 3.3 (because 3.2 didn't have the generic
> implementation for i386). Does this count as a regression?

I am afraid not.  The implementation labeled as claiming support for
i386 was in fact really i486 and above only.  It is a bug fix but
either way, libstdc++-v3 had reserved the right to make such ABI
changes when the minor number changes.

> I'm asking, because i386-linux is listed as a primary evaluation
> platform. On the other side I try to find out, if switching from
> i386 to i486 as the default for Debian is possible/wanted.

For the record, i386-*-freebsd* has the exact same issue.

You asked about possible solutions.  C++ encourages implementation in
the headers exposed directly to users.  One possible global fix (note
this is an ABI change): All traces of use of atomicity.h would have to
be removed from said exposed headers.  Of course, C++ encourages
implementation in headers because of the speed advantages of inlining.

Next idea, local port fix (probably also an ABI change; but I would
strongly encourage you not to remove the link error in whatever change
you make, the silent mixing of incompatible code is far worse in terms
of user trust) does Debian itself offer a stable interface to atomic
operations suitable to the requirements?  If the exact same API was
offered for all CPUs, then you might consider adding:

libstdc++-v3/config/os/gnu-linux/atomicity.h 

AIX and IRIX offer that API from the OS (granted they target fewer
CPUs than Debian), and they use the technique I describe.

I investigated the second technique for FreeBSD, but came up empty.
FreeBSD offers a set of atomic operations but the API it didn't seem
to match our requirements.

Regards,
Loren