This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: _GLIBCXX_PROFILE on non-Linux?
- From: Gerald Pfeifer <gerald at pfeifer dot com>
- To: Silvius Rus <rus at google dot com>
- Cc: Paolo Carlini <paolo dot carlini at oracle dot com>, Ian Lance Taylor <iant at google dot com>, libstdc++ at gcc dot gnu dot org
- Date: Sun, 16 Jan 2011 18:00:22 +0100 (CET)
- Subject: Re: _GLIBCXX_PROFILE on non-Linux?
- References: <alpine.LSU.1.99.1001172200160.16540@acrux.dbai.tuwien.ac.at> <4B5383A2.6060708@oracle.com> <alpine.LSU.1.99.1001172303500.16540@acrux.dbai.tuwien.ac.at> <mcrljfunmtw.fsf@dhcp-172-17-9-151.mtv.corp.google.com> <4B55CE83.7080308@oracle.com> <e90dbffc1001291344kdeca14bt30844b28dbcf781b@mail.gmail.com>
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