https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |powerpc* Status|UNCONFIRMED |NEW Last reconfirmed| |2016-03-14 Ever confirmed|0 |1 --- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> --- So another way to "fix" this would be to stop the simplification of isinf to isgreater(fabs(x),DBL_MAX) by providing patterns for isinf and friends (isfinite, isnormal), see fold_builtin_interclass_mathfn. Though neither isfinite nor isnormal have associated optabs - breaking testcases for them could be easily constructed. For the long double case more optimal implementation should be possible in the backend. Given we can't easily expose long double implementation details on GENERIC/GIMPLE it needs to be done there (well, in theory we could use sth. like VIEW_CONVERT <struct doubledouble> (ldbl_1).d[0] or so ... or REALPART (V_C_E <_Complex double> (ldbl_1)) whatever would work better. But then struct realformat needs to expose this fact (real.c checks fmt->pnan < fmt->p for this!?). Confirmed anyway. The question remains whether the long double value from gnulib is "valid" (it's a valid bit pattern that is _not_ inf after all). I still somewhat think that GCC is at fault here and not gnulib - even if it is technically not LDBL_MAX that is wrong but the folding to isgreater(fabs(x),DBL_MAX).