This is the mail archive of the
mailing list for the GCC project.
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
- From: "kargl at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 6 Oct 2006 17:03:16 -0000
- Subject: [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
- References: <email@example.com/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #6 from kargl at gcc dot gnu dot org 2006-10-06 17:03 -------
> > There is mpfr_get_ld(), which converts to a long double. If the data type
> > never exceeds the properties of long double, then one may be able to
> > use mpfr_get_ld() and then fold_convert() the result to the proper type.
> I think using long double defeats the whole purpose of using mpfr.
It appears you misread what I wrote (or meant to write). "If the data
type never exceeds the properties of long double" applies to a cross
compiler as well where "data type" is on the target and "long double"
is on the host.
> supposed to avoid relying on the properties of the host's floating point for
> cross-compilers where the target format is different.
The host's long double is simply an intermediate representation of the
value. It is the responsibility of the fold_convert to get the right
target representation. This is no different than using strings as the
> I was hoping there was an easy was to extract the exponent and mantissa from
> one of (REAL_VALUE_TYPE/mpft_t) and put them back into the other in a way that
> preserves everything clean in both directions.
See trans-intrinsics.c (prepare_arg_info), although I'm get ready to submit
a patch that removes that function.
> > > Also where is the function that does the reverse,
> > > i.e. tree or REAL_VALUE_TYPE to mpfr_t?
> > gfortran doesn't have a need of going in the opposite direction.
> > gmp/mpfr are used in the frontend for the internal representation
> > of data types. By the time gfortran reaches the functions in
> > trans-*.c, it has done all the constant folding and manipulation
> > of the data types that it can. The trans-*.c functions simply
> > convert gfortran's black and red trees into the tree-ssa form.
> Okay I hacked up something in the other direction using strings again. If
> someone comes up with something better, then great. But it's not strictly
> necessary. I can put the two conversion functions into real.[ch].
I would be interested in seeing the functions because gfortran currently
can't constant fold a TRANSFER() of the form
real, parameter :: x = transfer(1234,x)
This is a bitwise copy of the integer 1234 into x. In gfortran 1235 is
a gmp mpz_t type and x is an mpfr mpfr_t type. Emulating the bitwise
copy will require strings manipulations.
kargl at gcc dot gnu dot org changed:
What |Removed |Added
CC| |kargl at gcc dot gnu dot org