https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 14 Mar 2016, joseph at codesourcery dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70117 > > --- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery > dot com> --- > On Mon, 14 Mar 2016, rguenth at gcc dot gnu.org wrote: > > > but it will end up with libcalls for isinf, isfinite and isnormal for > > IBM extended double. I'm told glibc does the right thing for the gnulib > > And corresponding libcalls don't exist (or at least GCC doesn't know of > them; glibc has some functions such as __isinfl internally). Hmm, so the target(s) would need to import softfp variants into their libgcc then. Not a very good solution IMHO. This leaves the option to implement optabs and target patterns for all three functions (only the isinf optab is present at the moment). Such change could be safely backported to release branches (the softfp hackery likely not). > For the question of correctness of LDBL_MAX - and the related question of > whether LDBL_EPSILON, although correct by the current standard definition, > should change - see DR#467 (open). (But the reference there to DBL_MAX*2 > as a finite number does not apply to the IBM long double format > implemented by GCC, because of the rule about the round-to-nearest sum of > the two parts equalling the top part.) > (libgcc/config/rs6000/ibm-ldouble-format defines values with more than 106 > mantissa bits not to be normal - denormal but not subnormal.) So denormals are isinf()? I still believe the folding we apply is at least fishy for these kinds of float formats. Richard.
