public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "kargl at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
Date: Fri, 06 Oct 2006 17:03:00 -0000	[thread overview]
Message-ID: <20061006170316.16188.qmail@sourceware.org> (raw)
In-Reply-To: <bug-29335-578@http.gcc.gnu.org/bugzilla/>



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


  parent reply	other threads:[~2006-10-06 17:03 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-03 16:48 [Bug middle-end/29335] New: " ghazi at gcc dot gnu dot org
2006-10-05  5:11 ` [Bug middle-end/29335] " pinskia at gcc dot gnu dot org
2006-10-05 17:54 ` kargl at gcc dot gnu dot org
2006-10-06 13:25 ` ghazi at gcc dot gnu dot org
2006-10-06 14:40 ` kargl at gcc dot gnu dot org
2006-10-06 15:36 ` ghazi at gcc dot gnu dot org
2006-10-06 17:03 ` kargl at gcc dot gnu dot org [this message]
2006-10-07  2:05 ` ghazi at gcc dot gnu dot org
2006-10-07 14:08 ` ghazi at gcc dot gnu dot org
2006-10-09 17:16 ` ghazi at gcc dot gnu dot org
2006-10-14 16:12 ` ghazi at gcc dot gnu dot org
2006-10-14 16:14 ` ghazi at gcc dot gnu dot org
2006-10-20 15:54 ` ghazi at gcc dot gnu dot org
2006-10-23 20:25 ` ghazi at gcc dot gnu dot org
2006-10-24 17:45 ` ghazi at gcc dot gnu dot org
2006-10-25 20:44 ` ghazi at gcc dot gnu dot org
2006-10-28  3:20 ` ghazi at gcc dot gnu dot org
2006-10-28  3:48 ` sgk at troutmask dot apl dot washington dot edu
2006-10-28  9:07 ` vincent at vinc17 dot org
2006-10-28 13:29 ` ghazi at gcc dot gnu dot org
2006-10-28 14:06 ` vincent at vinc17 dot org
2006-10-28 16:04 ` ghazi at gcc dot gnu dot org
2006-10-28 16:58 ` vincent at vinc17 dot org
2006-10-29  2:02 ` ghazi at gcc dot gnu dot org
2006-10-30 20:22 ` ghazi at gcc dot gnu dot org
2006-10-31  3:14 ` ghazi at gcc dot gnu dot org
2006-10-31  9:55 ` vincent at vinc17 dot org
2006-10-31 20:09 ` ghazi at gcc dot gnu dot org
2006-10-31 22:15 ` vincent at vinc17 dot org
2006-11-02  3:21 ` ghazi at gcc dot gnu dot org
2006-11-02 14:41 ` ghazi at gcc dot gnu dot org
2006-11-02 15:57 ` vincent at vinc17 dot org
2006-11-02 22:44 ` ghazi at gcc dot gnu dot org
2006-11-05 23:27 ` vincent at vinc17 dot org
2006-11-07  2:46 ` ghazi at gcc dot gnu dot org
2006-11-30 19:45 ` chaoyingfu at gcc dot gnu dot org
2006-12-18 14:54 ` ghazi at gcc dot gnu dot org
2006-12-26 19:03 ` ghazi at gcc dot gnu dot org
2006-12-26 19:13 ` ghazi at gcc dot gnu dot org
2007-01-20  0:33 ` ghazi at gcc dot gnu dot org
2007-01-31 15:06 ` ghazi at gcc dot gnu dot org
     [not found] <bug-29335-4@http.gcc.gnu.org/bugzilla/>
2014-02-16 10:00 ` jackie.rosen at hushmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061006170316.16188.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).