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. 
