From: Ian Lance Taylor <ian@wasabisystems.com>
To: Carlo Wood <carlo@alinoe.com>
Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com
Subject: Re: RFA: Support infinity, NaN, and denormalized numbers in floatformat.c
Date: Wed, 03 Dec 2003 18:44:00 -0000 [thread overview]
Message-ID: <m3iskxbv1v.fsf@gossamer.airs.com> (raw)
In-Reply-To: <20031203183511.GA30132@alinoe.com>
Carlo Wood <carlo@alinoe.com> writes:
> On Wed, Dec 03, 2003 at 01:12:45PM -0500, Ian Lance Taylor wrote:
> > Here is a patch to improve the support for infinity, NaN, and
> > denormalized numbers in floatformat.c. It's not clear how to handle
> > these for non-IEEE formats. But the old code did entirely the wrong
> > thing even when using IEEE formats, which are used by pretty much all
> > modern processors. So I think we might as well do the right thing
> > here.
>
> Sorry if this is not related - but what are you going to do
> with the demangling of floating point values? I sensed a strong
> opposition against the IEEE decoding - so I removed my IEEE print
> routine again :/.
>
> But if your demangler will demangle everything as IEEE regardless
> then I suppose I might as well do the same.
What I'm working toward right now is permitting the caller of the
demangling routines to pass in an optional array mapping floating
point types to floatformat structures. Then if I see a floating point
literal, I can use the floatformat structures to pull it apart. I
then plan to output the literal as a C99 hex floating point constant.
(A couple of people suggested this approach, and I can't think of a
good reason to not do it.)
If the demangler is called with no floatformat structures, then I plan
to just dump out the string without any attempt to display it as a
floating point number, just as I do today.
This approach probably doesn't help you, since you probably don't want
to deal with the floatformat routines.
Anyhow, I was setting up the floatformat array when I realized that
the floatformat routines were moderately bogus in that they completely
failed to handle denormalized numbers. So I fixed them.
I do think this is all kind of ridiculous, since I'm sure that nobody
uses floating point constants in template expressions in real life.
And I think that changing the mangling of floating point constants
would be a much better solution for all concerned. But I don't know
how to make that happen.
Ian
next prev parent reply other threads:[~2003-12-03 18:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-03 18:12 Ian Lance Taylor
2003-12-03 18:17 ` Daniel Jacobowitz
2003-12-03 19:09 ` Andrew Cagney
2003-12-03 18:35 ` DJ Delorie
2003-12-03 18:35 ` Carlo Wood
2003-12-03 18:44 ` Ian Lance Taylor [this message]
2003-12-03 18:57 ` Carlo Wood
2003-12-03 18:47 ` Paul Koning
2012-08-16 16:20 ` Andreas Schwab
2012-08-17 21:16 ` Ian Lance Taylor
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=m3iskxbv1v.fsf@gossamer.airs.com \
--to=ian@wasabisystems.com \
--cc=carlo@alinoe.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=gdb-patches@sources.redhat.com \
/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