public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] RISC-V: Correct and improve the "-mabi" documentation
@ 2017-10-26 16:50 Palmer Dabbelt
  2017-10-27 15:32 ` Palmer Dabbelt
  0 siblings, 1 reply; 2+ messages in thread
From: Palmer Dabbelt @ 2017-10-26 16:50 UTC (permalink / raw)
  To: gcc-patches; +Cc: Alex Bradbury, patches, Palmer Dabbelt

The documentation for the "-mabi" argument on RISC-V was incorrect.  We
chose to treat this as a documentation bug rather than a code bug, and
to make the documentation match what GCC currently does.  In the
process, I also improved the documentation a bit.

Thanks to Alex Bradbury for finding the bug!

PR target/82717: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717

gcc/ChangeLog

2017-10-26  Palmer Dabbelt  <palmer@dabbelt.com>

        PR target/82717
        * doc/invoke.texi (RISC-V) <-mabi>: Correct and improve.
---
 gcc/doc/invoke.texi | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 71b2445f70fd..d184e1d7b7d4 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -21669,9 +21669,26 @@ When generating PIC code, allow the use of PLTs. Ignored for non-PIC.
 
 @item -mabi=@var{ABI-string}
 @opindex mabi
-Specify integer and floating-point calling convention.  This defaults to the
-natural calling convention: e.g.@ LP64 for RV64I, ILP32 for RV32I, LP64D for
-RV64G.
+@item -mabi=@var{ABI-string}
+@opindex mabi
+Specify integer and floating-point calling convention.  @var{ABI-string}
+contains two parts: the size of integer types and the registers used for
+floating-point types.  For example @samp{-march=rv64ifd -mabi=lp64d} means that
+@samp{long} and pointers are 64-bit (implicitly defining @samp{int} to be
+32-bit), and that floating-point values up to 64 bits wide are passed in F
+registers.  Contrast this with @samp{-march=rv64ifd -mabi=lp64f}, which still
+allows the compiler to generate code that uses the F and D extensions but only
+allows floating-point values up to 32 bits long to be passed in registers; or
+@samp{-march=rv64ifd -mabi=lp64}, in which no floating-point arguments will be
+passed in registers.
+
+The default for this argument is system dependent, users who want a specific
+calling convention should specify one explicitly.  The valid calling
+conventions are: @samp{ilp32}, @samp{ilp32f}, @samp{ilp32d}, @samp{lp64},
+@samp{lp64f}, and @samp{lp64d}.  Some calling conventions are impossible to
+implement on some ISAs: for example, @samp{-march=rv32if -mabi=ilp32d} is
+invalid because the ABI requires 64-bit values be passed in F registers, but F
+registers are only 32 bits wide.
 
 @item -mfdiv
 @itemx -mno-fdiv
-- 
2.13.6

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] RISC-V: Correct and improve the "-mabi" documentation
  2017-10-26 16:50 [PATCH] RISC-V: Correct and improve the "-mabi" documentation Palmer Dabbelt
@ 2017-10-27 15:32 ` Palmer Dabbelt
  0 siblings, 0 replies; 2+ messages in thread
From: Palmer Dabbelt @ 2017-10-27 15:32 UTC (permalink / raw)
  To: gcc-patches; +Cc: Alex Bradbury, patches

Committed.

On Thu, 26 Oct 2017 09:45:07 PDT (-0700), Palmer Dabbelt wrote:
> The documentation for the "-mabi" argument on RISC-V was incorrect.  We
> chose to treat this as a documentation bug rather than a code bug, and
> to make the documentation match what GCC currently does.  In the
> process, I also improved the documentation a bit.
>
> Thanks to Alex Bradbury for finding the bug!
>
> PR target/82717: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
>
> gcc/ChangeLog
>
> 2017-10-26  Palmer Dabbelt  <palmer@dabbelt.com>
>
>         PR target/82717
>         * doc/invoke.texi (RISC-V) <-mabi>: Correct and improve.
> ---
>  gcc/doc/invoke.texi | 23 ++++++++++++++++++++---
>  1 file changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 71b2445f70fd..d184e1d7b7d4 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -21669,9 +21669,26 @@ When generating PIC code, allow the use of PLTs. Ignored for non-PIC.
>
>  @item -mabi=@var{ABI-string}
>  @opindex mabi
> -Specify integer and floating-point calling convention.  This defaults to the
> -natural calling convention: e.g.@ LP64 for RV64I, ILP32 for RV32I, LP64D for
> -RV64G.
> +@item -mabi=@var{ABI-string}
> +@opindex mabi
> +Specify integer and floating-point calling convention.  @var{ABI-string}
> +contains two parts: the size of integer types and the registers used for
> +floating-point types.  For example @samp{-march=rv64ifd -mabi=lp64d} means that
> +@samp{long} and pointers are 64-bit (implicitly defining @samp{int} to be
> +32-bit), and that floating-point values up to 64 bits wide are passed in F
> +registers.  Contrast this with @samp{-march=rv64ifd -mabi=lp64f}, which still
> +allows the compiler to generate code that uses the F and D extensions but only
> +allows floating-point values up to 32 bits long to be passed in registers; or
> +@samp{-march=rv64ifd -mabi=lp64}, in which no floating-point arguments will be
> +passed in registers.
> +
> +The default for this argument is system dependent, users who want a specific
> +calling convention should specify one explicitly.  The valid calling
> +conventions are: @samp{ilp32}, @samp{ilp32f}, @samp{ilp32d}, @samp{lp64},
> +@samp{lp64f}, and @samp{lp64d}.  Some calling conventions are impossible to
> +implement on some ISAs: for example, @samp{-march=rv32if -mabi=ilp32d} is
> +invalid because the ABI requires 64-bit values be passed in F registers, but F
> +registers are only 32 bits wide.
>
>  @item -mfdiv
>  @itemx -mno-fdiv

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-10-27 15:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-26 16:50 [PATCH] RISC-V: Correct and improve the "-mabi" documentation Palmer Dabbelt
2017-10-27 15:32 ` Palmer Dabbelt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).