_GLIBCXX_PROFILE on non-Linux?

Gerald Pfeifer gerald@pfeifer.com
Sun Jan 16 17:00:00 GMT 2011


Hej there,

On Fri, 29 Jan 2010, Silvius Rus wrote:
>> On 01/19/2010 04:20 PM, Ian Lance Taylor wrote:
>>> You can diagnose it at compile time via something like
>>>
>>> #ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4
>>>
>> Eh, the macros I implemented a while ago turn out to be useful ;)
>>
>> Sure, anyway, I agree with Ian, Silvius could add something like this...
>>
>> Paolo.
> Will do ASAP.

I just ran into the original issue again and remembered this thread:

  http://gcc.gnu.org/ml/libstdc++/2010-01/msg00089.html

Are you still planning to make this change and diagnose it?  Would
it help if I file a Bugzilla?

> There is also a profile mode specific _GLIBCXX_PROFILE_NO_THREADS that
> users can turn on to guarantee that programs are single-threaded.
> When it's defined, profile mode pthread lock/unlock operations become
> nops.  Unfortunately, the atomic operations are not guarded by it
> currently.  I should perhaps add preprocessor conditionals to avoid
> all calls to atomic builtins when _GLIBCXX_PROFILE_NO_THREADS is
> defined.  That way, at least sequential programs will work regardless
> of builtin support in the compiler.  Something like:
> 
> #ifdef _GLIBCXX_PROFILE_NO_THREADS
> x = x + 1;
> #else
> __sync_fetch_and_add(&x, 1);
> #endif

This sounds interesting!  I think it would be great adea to guard
atomic builtins that way; for example that would be sufficient for
the case I just ran into (but it's not the case yet it seems).

Gerald



More information about the Libstdc++ mailing list