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.23456789abcdef0123456789abcdp-914L
is that we have:
1st iteration x = 8.215640181713713163755129115618857e-276  
2nd iteration x = -9.9763047253779979586613445625595544e-293  
3rd iteration x = -4.1720134847010025932941863449982576e-309  
div10 = 5.5626846462680034577255817933310102e-309
As 3rd iteration x is smaller in absolute value than div10, we divide it by
0x1p-1024 (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.215640181713713163755129115618857e-276 it will be
roughly 8.215640181713713163755129115618857e-276 * 0x1p-1024 plus roughly 0.75 * 0x1p-1024.  Shifting t up by the difference would be IMHO unsafe, as it could make the whole number overflow.

Of course even better would be to write a native IEEE quad long double -> mpfr conversion similarly how set_d.c handles IEEE double -> mpfr conversion, by understanding the floating point format in question and just fil in mantissa, exponent and sign.

Created attachment 453794 [details]
mpfr-set_ld.patch

This is just untested patch, which actually cures this testcase, but I think it might be unsafe with the IBM double double long double format - shifting t up temporarily (so that it can be shifted down again) might overflow it.  For sane floating point formats that shouldn't happen I'd say.

Anyway, it would be preferrable if set_ld and get_ld had native code for IEEE quad (and perhaps also double double, e.g. set_ld with double double should be trivial, just set_d the first double, then set_d the second double, add them together).  Ivana, can you please talk to upstream about this?

FYI, the mpfr fma tester I talked about is at
http://sources.redhat.com/ml/libc-hacker/2010-10/txt00000.txt
(attachment of http://sources.redhat.com/ml/libc-hacker/2010-10/msg00005.html ).

Or alternatively get IBM to write the native support for IEEE quad and double double.  glibc has sysdeps/ieee754/ldbl-128/ldbl2mpn.c and sysdeps/ieee754/ldbl-128/mpn2ldbl.c, maybe that can be used as a help.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

This was fixed upstream by https://gforge.inria.fr/scm/viewvc.php/trunk/src/set_ld.c?root=mpfr&r1=7136&r2=7222

Upstream bug tracker: https://gforge.inria.fr/tracker/?group_id=136&atid=619&func=detail&aid=11300

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/