Detailed description 
https://bugzilla.redhat.com/show_bug.cgi?id=643505
On s390/s390x (and probably any other arch with IEEE quad long double):
#include <mpfr.h> #include <stdio.h>
int main (void) { mpfr_set_default_prec (__LDBL_MANT_DIG__); mpfr_set_emin (__LDBL_MAX_EXP____LDBL_MANT_DIG__+4); mpfr_set_emax (__LDBL_MAX_EXP__); mpfr_t xx, yy; long double l = 0x1.23456789abcdef0123456789abcdp913L; mpfr_init_set_ld (xx, l, GMP_RNDN); mpfr_printf ("%Ra\n%La\n%La\n", xx, l, mpfr_get_ld (xx, GMP_RNDN)); mpfr_clear (xx); l = 0x1.23456789abcdef0123456789abcdp914L; mpfr_init_set_ld (yy, l, GMP_RNDN); mpfr_printf ("%Ra\n%La\n%La\n", yy, l, mpfr_get_ld (yy, GMP_RNDN)); mpfr_clear (yy); return 0; }
prints correct number in the first case, but when it is divided by two, it prints (and similarly retrieves with mpfr_get_ld) complete garbage:
0x9.1a2b3c4d5e6f78091a2b3c4d5e68p916 0x1.23456789abcdef0123456789abcdp913 0x1.23456789abcdef0123456789abcdp913 0xb.fffffffffffffffffffffffffff8p1028 0x1.23456789abcdef0123456789abcdp914 0x1.7fffffffffffffffffffffffffffp1025
I think the bug can be quite obviously seen in set_ld.c, the shift_exp = NNNN and x /= div1N stuff is only safe if inexact = mpfr_set_d (u, (double) x, GMP_RNDZ); hasn't been done in that function, because otherwise all of what has been accumulated into t will be wrongly multiplied by 2^1024 etc. What happens when trying to mpfr_set_ld on 0x1.23456789abcdef0123456789abcdp914L is that we have: 1st iteration x = 8.215640181713713163755129115618857e276 2nd iteration x = 9.9763047253779979586613445625595544e293 3rd iteration x = 4.1720134847010025932941863449982576e309 div10 = 5.5626846462680034577255817933310102e309 As 3rd iteration x is smaller in absolute value than div10, we divide it by 0x1p1024 (i.e. multiply by 0x1p1024 to get something like 0.75 in x) and set shift_exp to 1024. But we don't adjust t in any way, so instead of the whole value being roughly 8.215640181713713163755129115618857e276 it will be roughly 8.215640181713713163755129115618857e276 * 0x1p1024 plus roughly 0.75 * 0x1p1024.
Shifting up (untested patch attached to above bugzilla bugreport) might work for IEEE quad, but might cause issues with IBM double double long double format where the low double may be many thousands bits away from the upper double. 
