This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: New Port for RISC-V
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Palmer Dabbelt <palmer at dabbelt dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, Andrew Waterman <andrew at sifive dot com>, <kito dot cheng at gmail dot com>
- Date: Thu, 12 Jan 2017 17:30:17 +0000
- Subject: Re: New Port for RISC-V
- Authentication-results: sourceware.org; auth=none
- References: <20170112023038.13449-1-palmer@dabbelt.com>
General observation: I see no documentation (no changes to .texi files)
anywhere in this patch series. I also don't see updates to config-list.mk
to add RISC-V targets to the set that builds. (You should make sure the
port builds cleanly when built with current mainline GCC and configured
with --enable-werror-always; config-list.mk uses --enable-werror-always
and it's a rough way of making sure in a cross build that there aren't
warnings that would make a native bootstrap fail. It should build cleanly
for both 32-bit and 64-bit hosts.)
See sourcebuild.texi, "Back End", for a description of various places that
may need updating for a new port, including lots of things that need
documenting if your port has them (not all ports will have all those
target-specific features). That includes website updates.
Regarding binutils support: to be clear, does 2.28 branch have all the
features / fixes known to be required at present and will subsequent fixes
go on there as needed?
Regarding Linux kernel support: how confident are you that the signal
frame ABI, to the extent that this patch embeds it in linux-unwind.h, will
remain unchanged? To what extent has that port been reviewed by Linux
kernel people familiar with the right way to add new Linux kernel ports?
Looking at the architecture specification to resolve some questions about
the port, I see the statement (section 7.4 Subnormal Arithmetic) "In the
parlance of the IEEE standard, tininess is detected after rounding---that
is, the underflow exception is raised only if the rounded result is
subnormal, even if the unrounded result would have been subnormal.".
That "that is" is *not* an accurate description of what after-rounding
tininess detection means. After-rounding tininess detection means the
result is tiny if the result *rounded to normal precision but with
infinite exponent range* has an exponent outside the normal range. This
means that some results that round to the least normal value (given the
actual finite exponent range) count as tiny (the exact range of results
with that property depends on the rounding mode - in round-to-nearest, for
example, if s is the greatest subnormal and s+u is the least normal, it's
the half-open interval [s + u/2, s + 3u/4)). If your processor behaves as
described in "that is", that does not conform to IEEE 754-2008 and you
won't get clean glibc test results, for example.
I also see the architecture has roundTiesToAway support for your hardware
binary floating point. Do you intend to support that rounding mode from C
code? (I expect a fair number of glibc changes would be needed to do so,
although the soft-fp part shouldn't be that big.)
--
Joseph S. Myers
joseph@codesourcery.com