in reply to Re: [Win32] differing threads behaviour
in thread [Win32] differing threads behaviour

I'll work on reproducing the difference in a C program and take it up with the appropriate body.

I've arrived at:
#include <stdio.h> #include <stdlib.h> #include <pthread.h> #include <mpfr.h> void *foo( void *ptr ); int main(void) { pthread_t thread1; char *message1 = "precision in thread1:"; int iret1; if(mpfr_buildopt_tls_p()) printf("mpfr was built with TLS support +\n"); else printf("mpfr was NOT built with TLS support\n"); mpfr_set_default_prec(101); iret1 = pthread_create( &thread1, NULL, foo, (void*) message1); pthread_join( thread1, NULL); printf("pthread_create() returned: %d\n",iret1); printf("Back in main: %d\n", mpfr_get_default_prec()); return 0; } void *foo( void * ptr) { char *message; message = (char *) ptr; mpfr_set_default_prec(201); printf("%s %d\n", message, mpfr_get_default_prec()); pthread_exit (NULL); }
It exhibits the same 12.2.0-versus-13.0.l anomaly.
If that C program is compiled using gcc-12.2.0, then the foo() sub reports that default precision is 201, but if it's compiled using gcc-13.0.1 then a default precision of 53 is reported.
According to the mpfr developers, it should report 201.
I'll see if I can get the mingw-w64 developers to shed some light on what's going awry.

Cheers,
Rob

Replies are listed 'Best First'.
Re^3: [Win32] differing threads behaviour
by syphilis (Archbishop) on Apr 12, 2023 at 01:31 UTC
    I'll see if I can get the mingw-w64 developers to shed some light on what's going awry.

    Liu Hao (lh_mouse) has provided the following explanation:
    It's because `__emutls_get_address()` returns two distinct values in c +onsecutive calls with the same descriptor in the same thread, so the second reference to the thread l +ocal `__gmpfr_default_fp_bit_precision` (defined in 'set_dfl_prec.c') gets +a fresh object with its default value.
    The "second reference" is the mpfr_get_default() call made in foo().
    He then followed that up with:
    Looks like emutls could not set the thread-specific value for 'foreign + threads' (those not created by mcfgthread). Although this is by design, I do think the MPFR expect +ation should be reasonably supported. I will fix this in a couple of days.
    Entire thread is at:
    https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/3a656408-a99f-e9c1-e4f0-c4ff8374bb30%40126.com/#msg37802424

    Here endeth this soliloquy ;-)

    Cheers,
    Rob