_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