I've now completed builds of sed-4.3.p2 with
CC=clang LDFLAGS=--rtlib=compiler-rt
I have 68 builds where that did the trick, and another 12 where the
failure rate was low enough to allow sed to be installed (though I did
not do those installs).
However, I also have 23 builds where the ab
Paul Eggert writes today about the missing __muloti4() in clang builds
on numerous platforms:
>> Thanks, this turns out to be LLVM bug 16404, an unfixed bug I wish I'd
>> known. I installed the attached patches to Gnulib to stop using
>> integer-overflow builtins on Clang, which should work around
On 01/05/2017 04:18 PM, Nelson H. F. Beebe wrote:
> test-localename.c:(.text+0x6a): undefined reference to `uselocale'
Thanks, I installed the attached Gnulib patch, which should work around
that problem.
From d428145d71f26d67b2713d0adc8405f5388cdda2 Mon Sep 17 00:00:00 2001
From: Paul Egge
On 01/05/2017 04:18 PM, Nelson H. F. Beebe wrote:
> I want to report a clang
> issue that showed up on surprisingly many platforms, and with multiple
> versions of clang, but not with all clangs on all platforms: linking
> with lib/xmalloc.o produces this report:
>
> lib/libsed.a(xmalloc.o):
On 01/05/2017 04:18 PM, Nelson H. F. Beebe wrote:
> Compilation with native Sun compilers, both on GNU/Linux, and on the
> Solaris family, all die because of erroneous C code in sed-4.3:
>
> CC lib/dfa.o
> "lib/dfa.c", line 1592: warning: statement not reached
> "lib/dfa.c
One might want to `--update` without altering .gitegnore files
---
gnulib-tool | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/gnulib-tool b/gnulib-tool
index 5b6620e..5c5598a 100755
--- a/gnulib-tool
+++ b/gnulib-tool
@@ -278,9 +278,6 @@ Options for --import, --add/rem
On 01/06/2017 04:22 AM, Torvald Riegel wrote:
> First, are you familiar with what C++ has put out recently (eg, parallel
> algorithms in the C++17 draft?). Are you familiar with the memory model
> introduced in C11 and C++11?
I know a bit about the 2011 models, as well as the JMM. I do not know
t
Torvald Riegel wrote:
> The double-checked locking in glthread_once_multithreaded is broken. It
> has data races. Remember the conversation we had about atomics? Look
> at glibc's pthread_once to see what needs to be done.
>
> A similar problem exists regarding the (use of the) initialized fiel
On Thursday, January 5, 2017 7:51:00 PM CET Bruno Haible wrote:
> Pavel Raiskup wrote:
> > Thanks. Minor report is that gl_thread_join() is not handled properly for
> > joined thread statuses.
> >
> > This leads to situation that Koji build system tries to gently terminate
> > the build first (af
On Fri, 2017-01-06 at 15:08 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > What are the rwlock users, actually? A web search for gl_rwlock_t seems
> > to only turn up lock.h, but no users (unlike gl_lock_t, for example).
>
> You're right, there are no users so far. But there may be in the
On Fri, 2017-01-06 at 15:25 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > > The rwlock writer starvation problem is not solved by throttling to a
> > > fixed
> > > percentage of CPU time: If every reader thread spends 10% of its time
> > > with the
> > > rwlock held, it will work fine wi
On Fri, 2017-01-06 at 14:17 +0100, Bruno Haible wrote:
> I asked:
> > > So, what is the fairness-ensuring mechanism that will make use of locks
> > > starvation-free? Can it be *easily* and *portably* put in place?
>
> Textbooks from university teacher state that alternating between reader
> prefe
Torvald Riegel wrote:
> > The rwlock writer starvation problem is not solved by throttling to a fixed
> > percentage of CPU time: If every reader thread spends 10% of its time with
> > the
> > rwlock held, it will work fine with 4 CPUs, but it will hang with 24 CPUs.
>
> Well, obviously, you need
Torvald Riegel wrote:
> What are the rwlock users, actually? A web search for gl_rwlock_t seems
> to only turn up lock.h, but no users (unlike gl_lock_t, for example).
You're right, there are no users so far. But there may be in the future:
Gnulib occasionally grabs some piece of code from glibc
Torvald Riegel wrote:
> > Are you suggesting that the pthread_yield manual page is wrong? Or that
> > some warning should be added to it? I'm sure Michael Kerrisk will accept
> > inputs.
>
> I don't think it's necessarily wrong, but if there's no actual run queue
> because you have more or the sa
I asked:
> > So, what is the fairness-ensuring mechanism that will make use of locks
> > starvation-free? Can it be *easily* and *portably* put in place?
Textbooks from university teacher state that alternating between reader
preference and writer preference with solve both writer starvation and
w
On Fri, 2017-01-06 at 00:11 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > > The problem here is: it's a unit test. If it fails, I don't want to search
> > > for bugs in the condition variable subsystem, semaphore subsystem, AND the
> > > lock subsystem. I want the test to rely essentially
On Thu, 2017-01-05 at 13:19 -0800, Paul Eggert wrote:
> On 01/05/2017 12:47 PM, Torvald Riegel wrote:
> > If gnulib really wants to make concurrency simpler, than it should look
> > at higher-level abstractions first. Especially parallelism. But maybe
> > it should then just wait for what C++ spe
On Thu, 2017-01-05 at 22:20 +0100, Kamil Dudka wrote:
> On Thursday, January 05, 2017 21:13:07 Bruno Haible wrote:
> > Torvald Riegel wrote:
> > > IMO, users of reader-writer locks should treat them as a
> > > mutual-exclusion mechanism. That is, a mechanism that just ensures that
> > > two critic
On Fri, 2017-01-06 at 00:43 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > whenever you have a bounded amount of parallel
> > work, you don't care what gets executed first.
> > ...
> > You control the incoming work. ...
> >
> > Look at your unit test, for example. Typically, the transacti
On Thu, 2017-01-05 at 22:09 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > > Can you give line numbers, please? lib/glthread/lock.c and
> > > lib/glthread/cond.c
> > > are large files. If you have found bugs there, *of course* I want to have
> > > them fixed.
> >
> > I can understand both
21 matches
Mail list logo
