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 jos...@codesourcery.com
