This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC 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*: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>*To*: "Steve Kargl" <sgk at troutmask dot apl dot washington dot edu>*Cc*: "Tobias Burnus" <burnus at net-b dot de>, <fortran at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>*Date*: Wed, 20 May 2009 17:54:12 -0700*Subject*: Re: [PATCH]: Integrate gfortran with MPC*References*: <Pine.GSO.4.58.0905191143200.8319@caipclassic.rutgers.edu> <4A133724.8090301@net-b.de> <20090519231835.GA42327@troutmask.apl.washington.edu> <Pine.GSO.4.58.0905200000490.9846@caipclassic.rutgers.edu> <20090520074023.GA44750@troutmask.apl.washington.edu>

I'm at a conference and can't get to this until at least the weekend. I think that you may have misread the code. The 128 in arith.c is only used for determining the inquiry values of the INTEGER type. In gfc_arith_init_1, there are 2 loops the first loop deals with INTEGER, the second deals with REAL. In the second loop, you'll find a call to gfc_set_model_kind(real_info->kind). This sets the default precision to the precision of the current REAL type. The inquiry values are then determined for the current REAL type (ie., HUGE(), DIGITS(), etc.). If you spend time reading both arith.c and simplify.c, you'll see that gfortran correctly sets the precision to the required precision with either gfc_set_model_kind() or gfc_set_model().

Yes, I think I did misread it, I'll go back and recheck. However I may have done it "right" anyway. I was careful to preserve the existing calls to gfc_set_model_kind() before using either MPC or MPFR. So if those calls set the right default precision, then my code will use it too.

Elsewhere you've stated that gfortran's constant folding of some complex-valued intrinsic functions is less accurate than mpc. I think you may be mistaken, unless mpfr is broken, because the 128 has deceived you. Steve

I think regardless of using 128 or some other value, if you're using intermediate MPFR values of *any* precision there are pathological cases where you'll get rounding errors. MPC has code to speicifically detect when these errors occur and automatically increases the precision until there is enough for that particular input value. I've been told it's called "Ziv's strategy". Anyway, until I find a testcase that produces an error, let's call it "theoretical". The benefit of using MPC for fortran can be found merely in removing the code duplication and for the missing functionality for ctan and complex hyperbolics for now.

I'll do some more thorough testing and see, but as I said I may have written the patch correctly even if I misread how default precision is set for fortran. :-)

Thanks, --Kaveh

**Follow-Ups**:**Re: [PATCH]: Integrate gfortran with MPC***From:*Kaveh R. GHAZI

**References**:**[PATCH]: Integrate gfortran with MPC***From:*Kaveh R. GHAZI

**Re: [PATCH]: Integrate gfortran with MPC***From:*Tobias Burnus

**Re: [PATCH]: Integrate gfortran with MPC***From:*Steve Kargl

**Re: [PATCH]: Integrate gfortran with MPC***From:*Kaveh R. GHAZI

**Re: [PATCH]: Integrate gfortran with MPC***From:*Steve Kargl

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

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