On 4/21/21 9:15 PM, Jakub Jelinek wrote:
> On Wed, Apr 21, 2021 at 08:28:55PM +0200, Jakub Jelinek via Gcc-patches wrote:
>>> There's a patch attempt for the problem with
>>> std::thread::hardware_concurrency where
>>> it's used only if _GLIBCXX_HAS_GTHREADS is set.
>>>
>>> Does it help?
>>> Thanks,
>>> Martin
>>>
>>> gcc/ChangeLog:
>>>
>>> PR bootstrap/100186
>>> * lto-wrapper.c: Use hardware_concurrency only if
>>> _GLIBCXX_HAS_GTHREADS.
>>> ---
>>> gcc/lto-wrapper.c | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
>>> index 6ba401007f6..8a85b3e93a8 100644
>>> --- a/gcc/lto-wrapper.c
>>> +++ b/gcc/lto-wrapper.c
>>> @@ -1285,7 +1285,11 @@ run_gcc (unsigned argc, char *argv[])
>>> static char current_dir[] = { '.', DIR_SEPARATOR, '\0' };
>>>
>>> /* Number of CPUs that can be used for parallel LTRANS phase. */
>>> - unsigned long nthreads_var = std::thread::hardware_concurrency ();
>>> + unsigned long nthreads_var = 0;
>>> +
>>> +#ifdef _GLIBCXX_HAS_GTHREADS
>>> + nthreads_var = std::thread::hardware_concurrency ();
>>> +#endif
>>
>> _GLIBCXX_HAS_GTHREADS is a libstdc++ internal macro, it shouldn't be used
>> outside of libstdc++.
>> And, when using some other compiler or standard C++ library, nthreads_var
>> will be always 0. That isn't an improvement.
>
> What would be IMHO a good idea would be to use configure test for
> #include <thread>
> int t = std::thread::hardware_concurrency ();
> and in that case use that as a fallback to the previous implementation,
> that will be strictly an improvement.
That does not make sense to me. Original motivation was removal of the
complicated
implementation with a C++ standard function.
@Jonathan:
What standard says about usage of std::thread::hardware_concurrency() [1]?
The function is defined in C++11, how can one detect if threading is enabled
in the C++ library and use it?
[1] https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency
>
> Jakub
>
