On 2023-11-10 10:55, Sevan Janiyan wrote:
Apologies, I make a terrible compiler, I was parsing right to left.
No problem, I installed the attached.From 96b7ae248368db70dba27ee12f36f7b810a46af0 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Fri, 10 Nov 2023 22:33:49 -0800
Subject: [PATCH] std
I wrote:
> Results: OK on all platforms, except
>
> FreeBSD 13.2 Expected value #7504 not found in multithreaded results. (4
> failures among 100 runs)
> macOS 12.5Expected value #31 not found in multithreaded results.
> Solaris 10Expected value #95981 not found in multithreaded results.
Hi Bruno,
On Fri, Nov 10, 2023 at 2:03 PM Bruno Haible wrote:>
> rand() is not required to be multithread-safe. So, it's not a bug when rand()
> is not MT-safe on some platforms; it's merely a portability problem worth
> documenting.
>
> The attached program tests the MT-safety. Results: OK on al
On 10/11/2023 19:36, Bruno Haible wrote:
Can you try to install this handler for SIGFPE?
static void
my_sigfpe_handler (int sig)
{
signal (SIGFPE, SIG_DFL);
raise (sig);
}
This would be much easier than a Mach exception handler.
Ok, I need a few days. I'll get back to this next week.
> I would guess that the problem is that on PowerPC, enabling these traps
> requires OS support (in order to set the bits FE0 and FE1 of the MSR
> (= Machine State Register), which can only be done through privileged
> instructions), and Mac OS X 10.4 does not provide that support, or
> we don't kn
On 10/11/2023 19:25, Bruno Haible wrote:
That's the same as without these gl_cv_* overrides. This means,
the system function feraiseexcept is most likely working right,
and the problem is that the Gnulib code does not know how to
enforce traps on floating-point exceptions.
I see.
I would gues
Sevan Janiyan wrote:
> > The first step is to take note of the values of the gl_cv_func_fe*
> > variables in config.cache. (Pass the option '-C' to configure.)
>
> gl_cv_func_feenableexcept_in_libm=${gl_cv_func_feenableexcept_in_libm=no}
> gl_cv_func_feenableexcept_no_libm=${gl_cv_func_feenableexc
rand() is not required to be multithread-safe. So, it's not a bug when rand()
is not MT-safe on some platforms; it's merely a portability problem worth
documenting.
The attached program tests the MT-safety. Results: OK on all platforms, except
FreeBSD 13.2 Expected value #7504 not found in multi
On 10/11/2023 08:39, Sevan Janiyan wrote:
No because that matches 12 and prior, right? where as you want it to
apply to 14 which is the current version of macOS (14, Sonoma).
Apologies, I make a terrible compiler, I was parsing right to left.
Sevan
On 09/11/2023 23:36, Bruno Haible wrote:
All three failures occur in situations where the code expects a trap from
a floating-point exception, but a trap is not occurring.
Understood.
The first step is to take note of the values of the gl_cv_func_fe*
variables in config.cache. (Pass the optio
While POSIX mandates that random() is multithread-safe [1][2], rand() is not
required to be multithread-safe [3].
Therefore, in tests where multiple threads fetch pseudo-random numbers,
we better use rand(), even if that requires extra code on native Windows.
[1] https://pubs.opengroup.org/online
Since CheriBSD is derived from FreeBSD, it sounds likely that FreeBSD's random()
function is equally not multithread-safe.
To verify this hypothesis, I wrote a MT-safety test for random(). The result
(with a REPEAT_COUNT of 100):
glibc OK
musl libc OK
FreeBSD 11.0 Expected value
On 10/11/2023 05:47, Paul Eggert wrote:
If the #if should fire when it's 13 and above, shouldn't that be:
# if (defined MAC_OS_X_VERSION_MIN_REQUIRED \
&& 13 <= MAC_OS_X_VERSION_MIN_REQUIRED)
No because that matches 12 and prior, right? where as you want it to
apply to 140
13 matches
Mail list logo
