Re: notes on current atomics config and usage

[Paolo Carlini <pcarlini at suse dot de>]

Mark Mitchell wrote:

> Joe Buck wrote:
>
> > > I don't think we need to automatically generate multilibs.  If you need
> > > special multilibs, add your own -t file. :-)  (I do still think that we
> > > need a way to specify multilibs at configure time, but that's a separate
> > > project.)
> > >      
> > We would need some way of allowing mere mortals to build the
> > needed multilibs.  
> >    
> In general, or for x86?  I don't see why we can't just change gcc to
> default to -march=i486, and let that be that.
A remark (you can already find traces of it in a couple of confusing 
messages I sent earlier today): if I understand correctly what Ian 
proposed a few days ago, ideally the compiler should not just default to 
i486 but, in fact, should be completely prevented from targeting vanilla 
386 (unless one passes at build time --enable-i386, or something like 
that). Something stronger.

In fact, ideally, from the library point of view, we would like to 
*inline* in the headers the builtin atomics and the user should not be 
allowed to pass -march=i386 and obtain unresolved symbols at link time 
too easily!

Note, that would be very useful not only for the traditional facilities, 
but also for new things, tr1::shared_ptr, lockfree things, etc...

If we cannot have the above, a changed default would be useful anyway: 
for instance we could very easily remove the config/cpu/i486 assembly 
and have the traditional __exchange_and_add and __atomic_add as out of 
line atomics in the library but using the builtins in the 
implementation. Likewise for Sparc, if we can default to v8.

I'm thinking that if we cannot have the first improvement above, we 
could obtain most of it by way of: 1- Changed default + 2- 
__GCC_ATOMIC_BUILTINS. Probably, people may find such a preprocessor 
builtin useful anyway...

Paolo.