This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Integrate gfortran with MPC
From: "Steve Kargl" <firstname.lastname@example.org>
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.
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