From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [rfa/i387] Eliminate HOST_*_FORMAT from i387-tdep.c
Date: Fri, 29 Jun 2001 09:53:00 -0000 [thread overview]
Message-ID: <3B3CB299.5000100@cygnus.com> (raw)
Hello,
Very similar to my ARM tweek, this patch replaces a use of
HOST_LONG_DOUBLE_FORMAT with more generic code.
There isn't a loss of precision since extract_floating() on i386 native
should still do a memcopy().
Andrew
(Disclaimers about testing apply, it does compile :-/ ).
From ac131313@cygnus.com Fri Jun 29 10:23:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [rfc/rfa] Almost eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT
Date: Fri, 29 Jun 2001 10:23:00 -0000
Message-id: <3B3CB989.1000706@cygnus.com>
X-SW-Source: 2001-06/msg00531.html
Content-length: 788
Hello,
Attached is a revised patch to defs.h and findvar.c to reduce the
dependency on host floating point formats.
This patch changes GDB so that, if the host configury didn't specify the
floating point format, it will fall back immediatly to floatformat_*().
Previously, GDB would assume that the HOST had IEEE FP and try to use
that.
For hosts that don't specify a HOST_*_FORMAT, this will mean a loss of
FP precision when using GDB :-/
As an accidental side effect, this eliminates the problem where, if the
the host/target both forgot to specify their long-double format/size,
the code would assume that they were identical and do really bizare things.
Andrew
PS: If you haven't figured it out, I'm tring to eliminate xm.h and
(gasp) nm.h for at least one platform.
From ac131313@cygnus.com Fri Jun 29 10:51:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: gdb-patches@sources.redhat.com
Subject: [rfa] NetBSD/PowerPC doesn't need xm.h
Date: Fri, 29 Jun 2001 10:51:00 -0000
Message-id: <3B3CC000.7040700@cygnus.com>
X-SW-Source: 2001-06/msg00532.html
Content-length: 375
Hello,
Assuming that the other patches are accepted, this patch removes xm.h
from the NetBSD/PowerPC host configuration.
This is probably a good host/target to work with since it isn't
mainstream and consequently won't hurt anything like the more important
GNU systems.
Ok?
Andrew
PS: There are several follow-on's to this - HOST_BYTE_ORDER can also be
eliminated.
next reply other threads:[~2001-06-29 9:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-29 9:53 Andrew Cagney [this message]
2001-07-01 5:56 ` Mark Kettenis
2001-07-02 8:55 ` Jim Blandy
2001-07-03 12:26 ` Russ Allbery
2001-07-04 12:18 ` Andrew Cagney
2001-07-04 14:13 ` Mark Kettenis
2001-07-06 5:52 Michael Elizabeth Chastain
2001-07-06 6:16 ` Eli Zaretskii
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=3B3CB299.5000100@cygnus.com \
--to=ac131313@cygnus.com \
--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