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*: Thu, 21 May 2009 19:12:54 -0400 (EDT)*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> <C70047FF4AD24CBEA832935154A13879@glap>

On Wed, 20 May 2009, Kaveh R. Ghazi wrote: > 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. Steve, I reviewed the code again. In all cases, the lines which evaluate complex transcendentals (either using MPFR or MPC) are preceeded by the set_model calls. I see gfc_set_model_kind() in the complex cos, exp and log simplifiers. I see gfc_set_model() calls in the sin and sqrt ones. Either set_model function will set the default precision prior to the evaluation. I don't know why previously it was chosen to use *_kind or not, but as I observed before the MPFR hand-rolled code in there uses the default precisions set by these calls, and so I don't think any new problems are introduced by the MPC variation. There may be existing bugs in the design though. I inserted some code to print the default precision, and the precision of both real/imag of the input and output. I then ran the testcases from the fortran directory that exercise this code path. In all cases the five precisions were the same, they matched either 24 or 53. So it seems consistent throughout and safe to use the default for the intermediate calculations. I realize these testcases aren't particularly comprehensive. E.g. you hinted at a "mixed mode" in fortran, does this mean the real and imaginary parts can have different precisions? If so, it seems that there is an existing precision problem in fortran that needs to be fixed. Perhaps the intermediate precision needs to be MAX(re,im), or maybe even MAX(MAX(input_re,input_im),MAX(output_re,output_im)). If not, then I suggest my original patch is correct. Either way, when you're free of your conference, please let me know how I should proceed. I would very much appreciate your further feedback. Regards, --Kaveh

**Follow-Ups**:**Re: [PATCH]: Integrate gfortran with MPC***From:*Janne Blomqvist

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

**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

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

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

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