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
next prev 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: linkBe 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).