The Valgrind documentation notes that it doesn't support 80-bit arithmetic internally.  However, it notes that programs that depend on 80-bit arithmetic aren't portable anyway and says, "The impression observed from many FP regression tests is that the accuracy differences aren't significant.".

Well, I'm here to report that this limitation actually caused catastrophic failure on a piece of software that I have that is extremely portable.  My software strictly follows the ANSI C 1990 standard and was compiled with gcc on Linux.

The problem is the disconnect between the Linux/gcc system headers and what valgrind actually implements.

In my program, I used LDBL_MAX and count on it not being infinite.  This is a portable assumption since any conforming implementation of ANSI C must make LDBL_MAX a finite value.  My program works fine on implementations where double and long double are both 64 bits.  All it counts on is that LDBL_MAX being the largest representable finite long double value.

The problem is that when I compile under gcc it uses an 80-bit value for LDBL_MAX, then I run the program under valgrind and that 80-bit value gets converted to a 64-bit value, and since the exponent is too big it turns into the representation for positive infinity.  My program has a loop where it divides the value down to find an exponent, but with infinity instead of a finite value
represented, the loop never makes any progress by dividing down and in fact keeps allocating more memory and blows up.

Hence my very portable program that should work on any implementation of ANSI C 1990 not only goes into an infinite loop under valgrind, but keeps allocating more and more memory until either it or the whole system crashes.

I know the lack of proper long double support is a known issue.  The point of my filing this bug report is to give a data point against the impression given in the documentation that this lack of proper 80-bit floating-point support is not likely a serious drawback for programs that are portable.