Carsten, Which patch are you referring too? Christoph's patch or my modified version of that?
I looked at all the build logs for the "Maybe-Failed" builds and they all fail the same way, everyone of them is complaining about the "#define __CONCAT(x,y) ...." like what I saw for x86 on Gentoo (see above). That suggests you didn't actually use my version of the patch, or LDBL_MANT_DIG is not 64 like it is for x86 on Gentoo. Either way, it seems the macro expansion is done differently by the compiler/pre-processor on freebsd then the systems we tried to patch.
The compiler/pre-processor on freebsd seems to replace LDBL_MANT_DIG with its actual value before processing the __CONCAT() macro, whereas the systems we tried it on do not. That is, if LDBL_MANT_DIG is 64, __CONCAT(0x1.8p, LDBL_MANT_DIG) will get properly expanded to 0x1.8p64 on freebsd (or so it seems) and on the systems we used it gets expanded to 0x1.8pLDBL_MANT_DIG, which is invalid. From some test code I coubled together the behavior was the same for both gcc/g++ and clang/clang++. I was not able to resolve this macro expansion issue, that's why my version of the patch used the following ugly hack to avoid the problem, but it only works when LDBL_MANT_DIG is 64:
#if (LDBL_MANT_DIG == 64)
return (x + __CONCAT(0x1.8p, 64) / 2 -
__CONCAT(0x1.8p, 64) / 2);
return (x + __CONCAT(0x1.8p, LDBL_MANT_DIG) / 2 -
__CONCAT(0x1.8p, LDBL_MANT_DIG) / 2);