This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] c++0x <mutex> and <condition_variable>
On Tue, Sep 2, 2008 at 6:09 PM, Paolo Carlini <paolo.carlini@oracle.com> wrote:
> Paolo Carlini wrote:
>>
>> Paolo Carlini wrote:
>>>
>>> + in case the test relies on the new gthread support, we need a new
>>> dg-require very similar to the one I added for the atomic builtins (look for
>>> check_v3_target_atomic_builtins) checking that <bits/c++config.h> defines
>>> _GLIBCXX_HAS_GTHREADS. Likewise for any other feature required for the
>>> correct build and run of the test (__GTHREAD_HAS_COND?!?). Really rather
>>> mechanical additions.
>>
>> Also, careful with int64_t, must be protected by the dg-require-cstdint...
>
> And remember that the whole <chrono> itself essentially doesn't exist if
> _GLIBCXX_USE_C99_STDINT_TR1 is undefined. Thus careful not just including it
> and using its facilities...
>
> Paolo.
>
OK, so, all testcases need require-cstdint.
I can change this check:
#ifdef _GLIBCXX_HAS_GTHREADS
to
#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)
in the headers.
As for _GTHREAD_HAS_COND, since its basically a subset of
_GLIBCXX_HAS_GTHREADS, is there any point checking for it in
<condition_variable>? Thus far I've been assuming that a platform
either provides the entire gthread backend for all c++0x thread
library requirements or it simply doesn't get to use the library so an
all-or-nothing _GLIBCXX_HAS_GTHREADS (along with a
dg-requires-gthreads for testcases) seems sufficient.
End of the day, there should never be a case where
_GLIBCXX_HAS_GTHREADS is defined but not _GTHREAD_HAS_COND.
Chris