This is the mail archive of the
`fortran@gcc.gnu.org`
mailing list for the GNU Fortran project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: FX Coudert <fxcoudert at gmail dot com>*To*: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>*Cc*: "fortran at gcc dot gnu dot org Fortran" <fortran at gcc dot gnu dot org>*Date*: Sun, 30 Sep 2007 11:59:32 +0100*Subject*: Re: Difference between real(kind=16) and long double*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; bh=hOg2kwFbpJy9RJn62gig1hugcyuMJrPeiKwgCpZI/YY=; b=DTvxshGy5i29PoFiLhyNYioSpgjx6VWtArCnYiYBlu4J0jv1WueBBMpb6AJUw7By3xWezSbRJH+3268LikGWpgJr9fksmU2OMAZ7Kb44rphisJMBeoHBvYbybn/e3DY9BVucX3CthmgN5l6uapzYByBEM87JAOdJHIcoTgTzAd4=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=Tx1rDrdCCwAn0Xyn/2H5DstcJyyD1GiXujYI5LO0y4Oj7H+EuNMWd0gUowkPuQQfL9plgJ5UbkdCZRZN+Jnfg1/Mj4uTfL/PaJeNRf4OGAn7r6fYvpAegpglFrdSLo+nBnwPT/5A+svGqWdrdrap4GsZSGOaGxOm0soCMMZjCU0=*References*: <A40D9D7A-5E94-4F34-BB2E-F3B18234FE01@gmail.com> <20070930001457.GA52988@troutmask.apl.washington.edu>

Please, don't break gfortran to paper over problems with darwin (and HPUX). If these arch have broken long double or missing/broken C99 math functions, then so be it. It seems that you are spending too much time applying wallpaper for targets with little vendor support.

As far as I can say, this problem is present on all targets that have long doubles made of 2 IEEE doubles, including powerpc and mips processors. It's not a question of target library support, but simply a question of mismatch between the definition of that long double floating-point mode and the definition of the Fortran number model. See below.

The model numbers and results for the numeric inquiry functions are generated in arith.c. The numeric inquiry functions, which includes HUGE(), are well-defined in the standard. If FLT_MAX, DBL_MAX, and LDBL_MAX on a platform do not agree with fortran's HUGE(), then open a bug report with the vendor. Their float.h is broken.

trans-types.c has the following comment:

/* This is an IBM extended double format (or the MIPS variant)

made up of two IEEE doubles. The value of the long double is

the sum of the values of the two parts. The most significant

part is required to be the value of the long double rounded

to the nearest double. If we use emax of 1024 then we can't

represent huge(x) = (1 - b**(-p)) * b**(emax-1) * b, because

rounding will make the most significant part overflow. */

gfc_real_kinds[r_index].max_exponent = fmt->emax - 1;

Under no circumstance should one change (!isfinte(x)) into (!isfinite(x) || x > HUGE || x < HUGE).

That's true. I think the only way to go is to recognize that the Fortran standard doesn't forbid that there can be floating-point numbers larger than HUGE() which aren't Infinities, and as such are not printed out as +Inf. So, it probably means that our implementation is right but we need only fix the testcase.

Opinions welcome, everyone, FX

**Follow-Ups**:**Re: Difference between real(kind=16) and long double***From:*FX Coudert

**Re: Difference between real(kind=16) and long double***From:*Steve Kargl

**References**:**Difference between real(kind=16) and long double***From:*FX Coudert

**Re: Difference between real(kind=16) and long double***From:*Steve Kargl

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |