This is the mail archive of the gcc-bugs@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]

[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time



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

>  We're
> 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
intermediate.

> 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


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]