Re: New Port for RISC-V v3

[Palmer Dabbelt]

On Wed, 08 Feb 2017 00:43:09 PST (-0800), ebotca...@adacore.com wrote:
>> I believe we're in.  Thanks for the help!
>
> Congratulations.  There are a few post-integration items to be done:
>
> "If the back end is added to the official GCC source repository, the
> following are also necessary:
>
>* An entry for the target architecture in `readings.html' on the GCC
>  web site, with any relevant links.
>
>* Details of the properties of the back end and target architecture
>  in `backends.html' on the GCC web site.

These two patches were in flight, they were just approved and I committed them
a few minutes ago.

>* A news item about the contribution of support for that target
>  architecture, in `index.html' on the GCC web site.

There's a "RISC-V support" section in index.html.

>* Normally, one or more maintainers of that target listed in
>  `MAINTAINERS'.  Some existing architectures may be unmaintained,
>  but it would be unusual to add support for a target that does not
>  have a maintainer when support is added.

Sorry, we forgot about that.  I just sent a patch.

>* Target triplets covering all `config.gcc' stanzas for the target,
>  in the list in `contrib/config-list.mk'."

I added the Linux targets, but forgot the ELF ones.  I sent a patch for this as
well.

Thanks for checking up!

Re: New Port for RISC-V v3

[Eric Botcazou]

> I believe we're in.  Thanks for the help!

Congratulations.  There are a few post-integration items to be done:

"If the back end is added to the official GCC source repository, the
following are also necessary:

   * An entry for the target architecture in `readings.html' on the GCC
 web site, with any relevant links.

   * Details of the properties of the back end and target architecture
 in `backends.html' on the GCC web site.

   * A news item about the contribution of support for that target
 architecture, in `index.html' on the GCC web site.

   * Normally, one or more maintainers of that target listed in
 `MAINTAINERS'.  Some existing architectures may be unmaintained,
 but it would be unusual to add support for a target that does not
 have a maintainer when support is added.

   * Target triplets covering all `config.gcc' stanzas for the target,
 in the list in `contrib/config-list.mk'."

if they haven't already been done of course.

-- 
Eric Botcazou

Re: New Port for RISC-V v3

[Palmer Dabbelt]

On Mon, 06 Feb 2017 11:19:56 PST (-0800), ja...@redhat.com wrote:
> On Mon, Feb 06, 2017 at 11:18:12AM -0800, Palmer Dabbelt wrote:
>> OK, great!  I think we're all set:
>>
>>  * Here's the responses to the documentation comments
>>,
>>.
>>
>>  * I believe the patch was silently dropped because it was over the size
>>limits, so I gzip'd the patch and sent it to the mailing list here
>>.
>>
>>  * We don't touch anything in any of the other ports.
>>
>> If you give the OK, then I can commit this as soon as I figure out git-svn
>> (which I'm looking at now).
>
> Ok (or just check out svn, apply the patch and commit from svn).

I believe we're in.  Thanks for the help!

Re: New Port for RISC-V v3

[Jakub Jelinek]

On Mon, Feb 06, 2017 at 11:18:12AM -0800, Palmer Dabbelt wrote:
> OK, great!  I think we're all set:
> 
>  * Here's the responses to the documentation comments
>,
>.
> 
>  * I believe the patch was silently dropped because it was over the size
>limits, so I gzip'd the patch and sent it to the mailing list here
>.
> 
>  * We don't touch anything in any of the other ports.
> 
> If you give the OK, then I can commit this as soon as I figure out git-svn
> (which I'm looking at now).

Ok (or just check out svn, apply the patch and commit from svn).

Jakub

Re: New Port for RISC-V v3

[Palmer Dabbelt]

On Mon, 06 Feb 2017 00:21:36 PST (-0800), ja...@redhat.com wrote:
> On Sun, Feb 05, 2017 at 10:38:18AM -0800, Palmer Dabbelt wrote:
>> There have been a handful of changes since we submitted our v2 port:
>>
>>  * Some documentation formatting fixes.
>>
>>  * A documentation typo fix.
>>
>>  * Some changes to wwwdocs, which have been mailed to the list.
>>
>>  * The port now builds via contrib/config-list.mk.  I worked around the
>>warnings in other parts of the codebase with some "#pragma GCC diagnostic
>>ignored" when I couldn't fix them properly, so the patches aren't useful,
>>but I fixed the warnings in our port reasonably.  I can try to fix all 
>> these
>>reasonably, but it might take a while.
>>
>> As far as I know there are currently no outstanding problems with this port, 
>> so
>> I think it's at the point where we should talk about actually getting the 
>> code
>> in.  We have been accepted as maintainers of the port, and I have write 
>> access
>> to the repositories, so I think we're all good to go on that end.  Of course 
>> if
>> there's any remaining comments I'd love to fix them, but it seems the 
>> comments
>> on our v2 were somewhat minimal.
>>
>> What's the procedure for moving forward with the port?
>>
>> Thanks to everyone who helped with reviewing the port!
>>
>> [PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c
>> [PATCH 2/6] RISC-V Port: gcc
>> [PATCH 3/6] RISC-V Port: libgcc
>> [PATCH 4/6] RISC-V Port: libatomic
>> [PATCH 5/6] RISC-V Port: gcc/testsuite
>> [PATCH 6/6] RISC-V Port: contrib
>
> Richard in another mail said he is ok with the patchset, Sandra said some
> notes on the documentation patch and have seen just 5 of these 6 patches
> posted in v3 (the 2/6 patch is missing).
> From RM POV as long as it doesn't affect other targets it is ok for trunk,
> but please don't delay it too much (i.e. resolve Sandra's comments, post the
> missing patch, then check it in).

OK, great!  I think we're all set:

 * Here's the responses to the documentation comments
   ,
   .

 * I believe the patch was silently dropped because it was over the size
   limits, so I gzip'd the patch and sent it to the mailing list here
   .

 * We don't touch anything in any of the other ports.

If you give the OK, then I can commit this as soon as I figure out git-svn
(which I'm looking at now).

Thanks!

Re: New Port for RISC-V v3

[Jakub Jelinek]

On Sun, Feb 05, 2017 at 10:38:18AM -0800, Palmer Dabbelt wrote:
> There have been a handful of changes since we submitted our v2 port:
> 
>  * Some documentation formatting fixes.
> 
>  * A documentation typo fix.
> 
>  * Some changes to wwwdocs, which have been mailed to the list.
> 
>  * The port now builds via contrib/config-list.mk.  I worked around the
>warnings in other parts of the codebase with some "#pragma GCC diagnostic
>ignored" when I couldn't fix them properly, so the patches aren't useful,
>but I fixed the warnings in our port reasonably.  I can try to fix all 
> these
>reasonably, but it might take a while.
> 
> As far as I know there are currently no outstanding problems with this port, 
> so
> I think it's at the point where we should talk about actually getting the code
> in.  We have been accepted as maintainers of the port, and I have write access
> to the repositories, so I think we're all good to go on that end.  Of course 
> if
> there's any remaining comments I'd love to fix them, but it seems the comments
> on our v2 were somewhat minimal.
> 
> What's the procedure for moving forward with the port?
> 
> Thanks to everyone who helped with reviewing the port!
> 
> [PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c
> [PATCH 2/6] RISC-V Port: gcc
> [PATCH 3/6] RISC-V Port: libgcc
> [PATCH 4/6] RISC-V Port: libatomic
> [PATCH 5/6] RISC-V Port: gcc/testsuite
> [PATCH 6/6] RISC-V Port: contrib

Richard in another mail said he is ok with the patchset, Sandra said some
notes on the documentation patch and have seen just 5 of these 6 patches
posted in v3 (the 2/6 patch is missing).
>From RM POV as long as it doesn't affect other targets it is ok for trunk,
but please don't delay it too much (i.e. resolve Sandra's comments, post the
missing patch, then check it in).

Jakub

Re: New Port for RISC-V v2

[Richard Henderson]

On 02/02/2017 01:05 AM, Palmer Dabbelt wrote:

Thanks to everyone who reviewed our original patch set.  I've tried to CC
everyone who provided a review, sorry if I missed anyone!

Andrew, Kito and I believe that we've addressed almost all of the feedback from
the reviews of our v1 patch set.  Since it's been a while we wanted to get a v2
patch set out, just to make sure we're all on the same page going forward.
As far as I know, there's just one thing that still needs to be taken care of:


I've had another look over the code and I'm happy with this version.

The timing for this is unfortunate -- it'll be up to the release managers 
whether or not it can be included during stage4.  The one good thing in its 
favor is that there are zero changes outside the port itself.



r~

New Port for RISC-V v3

[Palmer Dabbelt]

There have been a handful of changes since we submitted our v2 port:

 * Some documentation formatting fixes.

 * A documentation typo fix.

 * Some changes to wwwdocs, which have been mailed to the list.

 * The port now builds via contrib/config-list.mk.  I worked around the
   warnings in other parts of the codebase with some "#pragma GCC diagnostic
   ignored" when I couldn't fix them properly, so the patches aren't useful,
   but I fixed the warnings in our port reasonably.  I can try to fix all these
   reasonably, but it might take a while.

As far as I know there are currently no outstanding problems with this port, so
I think it's at the point where we should talk about actually getting the code
in.  We have been accepted as maintainers of the port, and I have write access
to the repositories, so I think we're all good to go on that end.  Of course if
there's any remaining comments I'd love to fix them, but it seems the comments
on our v2 were somewhat minimal.

What's the procedure for moving forward with the port?

Thanks to everyone who helped with reviewing the port!

[PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c
[PATCH 2/6] RISC-V Port: gcc
[PATCH 3/6] RISC-V Port: libgcc
[PATCH 4/6] RISC-V Port: libatomic
[PATCH 5/6] RISC-V Port: gcc/testsuite
[PATCH 6/6] RISC-V Port: contrib

Re: New Port for RISC-V v2

[Gerald Pfeifer]

On Fri, 3 Feb 2017, Palmer Dabbelt wrote:
> How do these look?

Fine for readings.html.  backends.html, not my cup of tea. ;-)

Gerald

Re: New Port for RISC-V v2

[Palmer Dabbelt]

On Thu, 02 Feb 2017 17:08:06 PST (-0800), Palmer Dabbelt wrote:
> On Thu, 02 Feb 2017 09:58:32 PST (-0800), jos...@codesourcery.com wrote:
>> On Thu, 2 Feb 2017, Palmer Dabbelt wrote:
>>
>>> Additionally, here's a diff against wwwdocs.  This is really just to check 
>>> this
>>> is all I'm supposed to do, I can submit a proper patch via the mailing list 
>>> (I
>>> just don't know how to use CVS, sorry).
>>
>> Other parts of the wwwdocs changes (backends.html, readings.html) are
>> probably of more interest.
>
> Thanks, that didn't feel like enough stuff.  I'll submit some wwwdocs changes
> that address all the feedback from this code review.

How do these look?

Index: htdocs/backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision 1.73
diff -u -r1.73 backends.html
--- htdocs/backends.html3 Jan 2017 22:03:25 -   1.73
+++ htdocs/backends.html3 Feb 2017 20:44:56 -
@@ -99,6 +99,7 @@
 nvptx  |   S Q   Cq mg   e
 pa |   ? Q   CBD  qr  b   i  e
 pdp11  |L   ICqrc b  e
+riscv  | Q   Cqr gia
 rl78   |L  F l   gs
 rs6000 | Q   Cqr pb   ia
 rx |  s
Index: htdocs/readings.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/readings.html,v
retrieving revision 1.256
diff -u -r1.256 readings.html
--- htdocs/readings.html3 Feb 2017 07:43:57 -   1.256
+++ htdocs/readings.html3 Feb 2017 20:44:56 -
@@ -250,6 +250,12 @@
   Manufacturer: DEC
   http://simh.trailing-edge.com/";>Simulators
  
+
+ riscv
+  Manufacturer: Many (open ISA standard)
+  http://riscv.org";>RISC-V Foundation
+  http://riscv.org/specifications/";>ISA Specifications
+ 

  rs6000 (powerpc, powerpcle)
   Manufacturer: IBM, Motorola

Re: New Port for RISC-V v2

[Gerald Pfeifer]

On Thu, 2 Feb 2017, Palmer Dabbelt wrote:
> OK, thanks.  As far as I know, I don't have write access to anything 
> yet. Should I request it from overse...@sourceware.org?  I already have 
> binutils git access.

Yes, and you can name me as your sponsor.

Gerald

Re: New Port for RISC-V v2

[Palmer Dabbelt]

On Thu, 02 Feb 2017 13:07:25 PST (-0800), ger...@pfeifer.com wrote:
> Hi Palmer,
>
> On Thu, 2 Feb 2017, Palmer Dabbelt wrote:
>> Additionally, here's a diff against wwwdocs.  This is really just to
>> check this is all I'm supposed to do, I can submit a proper patch via
>> the mailing list (I just don't know how to use CVS, sorry).
>>
>>   Index: htdocs/gcc-7/changes.html
>>   ===
>>   +RISC-V
>>   +
>>   +  Support for the RISC-V instruction set has been added
>>   +
>
> This looks fine and is approved.  (Well, modulo adding a full stop. ;-)
>
> And of course we should add this achievement to the News section of our
> home page.  Something like
>
>RISC-V support
>Support for the RISC-V processor family was added, contributed
>by Palmer Dabbelt and Andrew Waterman.
>
> That is pre-approved as well.

OK, thanks.  As far as I know, I don't have write access to anything yet.
Should I request it from overse...@sourceware.org?  I already have binutils git
access.

Re: New Port for RISC-V v2

[Palmer Dabbelt]

On Thu, 02 Feb 2017 09:58:32 PST (-0800), jos...@codesourcery.com wrote:
> On Thu, 2 Feb 2017, Palmer Dabbelt wrote:
>
>> Additionally, here's a diff against wwwdocs.  This is really just to check 
>> this
>> is all I'm supposed to do, I can submit a proper patch via the mailing list 
>> (I
>> just don't know how to use CVS, sorry).
>
> Other parts of the wwwdocs changes (backends.html, readings.html) are
> probably of more interest.

Thanks, that didn't feel like enough stuff.  I'll submit some wwwdocs changes
that address all the feedback from this code review.

Re: New Port for RISC-V v2

[Gerald Pfeifer]

Hi Palmer,

On Thu, 2 Feb 2017, Palmer Dabbelt wrote:
> Additionally, here's a diff against wwwdocs.  This is really just to 
> check this is all I'm supposed to do, I can submit a proper patch via 
> the mailing list (I just don't know how to use CVS, sorry).
> 
>   Index: htdocs/gcc-7/changes.html
>   ===
>   +RISC-V
>   +
>   +  Support for the RISC-V instruction set has been added
>   +

This looks fine and is approved.  (Well, modulo adding a full stop. ;-)

And of course we should add this achievement to the News section of our 
home page.  Something like

   RISC-V support
   Support for the RISC-V processor family was added, contributed
   by Palmer Dabbelt and Andrew Waterman.

That is pre-approved as well.

Gerald

Re: New Port for RISC-V v2

[Joseph Myers]

On Thu, 2 Feb 2017, Palmer Dabbelt wrote:

> Additionally, here's a diff against wwwdocs.  This is really just to check 
> this
> is all I'm supposed to do, I can submit a proper patch via the mailing list (I
> just don't know how to use CVS, sorry).

Other parts of the wwwdocs changes (backends.html, readings.html) are 
probably of more interest.

-- 
Joseph S. Myers
jos...@codesourcery.com

New Port for RISC-V v2

[Palmer Dabbelt]

Thanks to everyone who reviewed our original patch set.  I've tried to CC
everyone who provided a review, sorry if I missed anyone!

Andrew, Kito and I believe that we've addressed almost all of the feedback from
the reviews of our v1 patch set.  Since it's been a while we wanted to get a v2
patch set out, just to make sure we're all on the same page going forward.
As far as I know, there's just one thing that still needs to be taken care of:

 * I haven't managed to get contrib/config-list.mk to build anywhere, and the
   errors I'm seeing look like valid warnings to me.  One example is the
   following snippit from gcc/genhooks.c:

 while (fscanf (f, "%*[^@]"), buf[0] = '\0',
fscanf (f, "@%5[^ \n]", buf) != EOF)

   which throws a warning about not checking the return value of the first
   fscanf.  I've tried various GCC releases and the trunk, but this looks like
   a valid warning to me.

   If I'm meant to go through and fix all the warnings I can do that, but it
   might take a while.  Is this what's expected?  I feel like I'm doing
   something wrong here...

Additionally, here's a diff against wwwdocs.  This is really just to check this
is all I'm supposed to do, I can submit a proper patch via the mailing list (I
just don't know how to use CVS, sorry).

  Index: htdocs/gcc-7/changes.html
  ===
  RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
  retrieving revision 1.54
  diff -u -r1.54 changes.html
  --- htdocs/gcc-7/changes.html   1 Feb 2017 19:23:00 -   1.54
  +++ htdocs/gcc-7/changes.html   2 Feb 2017 08:23:20 -
  @@ -826,6 +826,11 @@
  
   
  
  +RISC-V
  +
  +  Support for the RISC-V instruction set has been added
  +
  +
   IA-32/x86-64
   
 Support for the AVX-512 Fused Multiply Accumulation Packed Single 
precision

Thanks for all the reviews!

[PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c
[PATCH 2/6] RISC-V Port: gcc
[PATCH 3/6] RISC-V Port: libgcc
[PATCH 4/6] RISC-V Port: libatomic
[PATCH 5/6] RISC-V Port: gcc/testsuite
[PATCH 6/6] RISC-V Port: contrib

Re: New Port for RISC-V

[Andrew Waterman]

Thank you for taking the time to give us feedback.

On Thu, Jan 12, 2017 at 9:30 AM, Joseph Myers  wrote:
> 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.

Thanks for the pointer.  We'll write documentation, adjust the build
list, and look at sourcebuild.texi for further guidance before
submitting an updated version of the patch set.

>
> 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?

Yes, and we will continue to apply fixes to both the trunk and the 2.28 branch.

>
> 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?

I will consult with the kernel folks on this matter.

>
> 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.

That is an error in the specification; the intent is that RISC-V
implementations conform to IEEE 754-2008.  The next revision of the
spec will simply remove the "that is" clause.  Thank you for pointing
this out.

>
> 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.)

Our expectation was that roundTiesToAway would be primarily used in
hand-written library routines, and that application code wouldn't be
interested in using it because most architectures do not provide it
for binary FP.  Perhaps that is not forward-thinking.  We will consult
with the glibc maintainers about the possibility of a RISC-V-specific
extension to the fenv API.

>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Re: New Port for RISC-V

[Joseph Myers]

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

New Port for RISC-V

[Palmer Dabbelt]

We'd like to submit for inclusion in GCC a port for the RISC-V architecture.
The port suffices to build a substantial body of software (including Linux and
some 2,000 Fedora packages) and passes most of the gcc and g++ test suites; so,
while it is doubtlessly not complete, we think it is far enough along to start
the upstreaming process.  It is our understanding that it is OK to submit this
port during stage 3 because it does not touch any shared code.  Our binutils
port has already been accepted for the 2.28 release, and we plan on submitting
glibc and Linux patch sets soon.

This port targets Version 2.0 of the RV32I and RV64I base user ISAs, and the
five standard extensions M, A, F, D, and C, all of which are frozen and will
not change over time.  The RISC-V community and the 50-some member companies of
the RISC-V Foundation are quite eager to have a single, standard GCC port.  We
thank you in advance for your help in this process and for your feedback on the
software contribution itself.

These patches build on top of cac3398e5f378549d84bc2ebb6af97cfd0189b25, the
latest commit in the GCC git mirror as of last night.

Andrew and I will volunteer to maintain this port if it's OK with everyone.
Our understanding is that the GCC steering committee decides this, and this is
the correct place to contact them.

We'd like to thank the various members of the RISC-V software community who
have helped us with the port.  Specifically we'd like to thank Kito Cheng for
his work getting the GCC test suite running (and running correctly).

Thanks!

[PATCH 1/6] RISC-V Port: gcc/config/riscv/riscv.c
[PATCH 2/6] RISC-V Port: gcc
[PATCH 3/6] RISC-V Port: libgcc
[PATCH 4/6] RISC-V Port: libsanitizer
[PATCH 5/6] RISC-V Port: libatomic
[PATCH 6/6] RISC-V Port: gcc/testsuite