On 7/7/22 13:46, Richard Biener wrote:
> OK - that also resolves the mingw issue, correct? I suppose we need
Yes.
> to be careful to not advertise v1 API (which includes threadsafeness)
> when not HAVE_PTHREAD_LOCKING.
Will reflect that in the patch.
I'm going to push it now.
Martin
e64dc769b4bc00568395468bdf02e74f6f Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Thu, 7 Jul 2022 12:15:28 +0200
Subject: [PATCH] lto-plugin: use locking only for selected targets
For now, support locking only for linux targets that are different from
riscv* where the target depends on libatomic (an
Richard Biener via Gcc-patches writes:
>> +if test x$use_locking = xyes; then
>> + AC_DEFINE(HAVE_PTHREAD_LOCKING, 1,
>> + [Define if the system-provided pthread locking mechanism.])
This isn't even a sentence. At least I cannot parse it. Besides, it
seems to be misnamed since the t
On Thu, Jul 7, 2022 at 1:43 PM Martin Liška wrote:
>
> For now, support locking only for linux targets that are different from
> riscv* where the target depends on libatomic (and fails during
> bootstrap).
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be i
For now, support locking only for linux targets that are different from
riscv* where the target depends on libatomic (and fails during
bootstrap).
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
PR lto/106170
lto-plugin/Change
