[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
palmer at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2017-10-25
CC||palmer at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |palmer at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from palmer at gcc dot gnu.org ---
Thanks Alex -- you're correct that this is a documentation/code mismatch. I
just talked to Andrew and we think it's best to change the documentation. How
does this sound:
"""
@item -mabi=@var{ABI-string}
@opindex mabi
Specify integer and floating-point calling convention. The default for this
argument is system dependent, users who want a specific calling convention
should specify one explicitly. The valid calling conventions are: ilp32,
ilp32f, ilp32d, lp64, lp64f, and lp64d.
"""
[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #2 from Alex Bradbury ---
(In reply to palmer from comment #1)
> Thanks Alex -- you're correct that this is a documentation/code mismatch. I
> just talked to Andrew and we think it's best to change the documentation.
> How does this sound:
>
> """
> @item -mabi=@var{ABI-string}
> @opindex mabi
> Specify integer and floating-point calling convention. The default for this
> argument is system dependent, users who want a specific calling convention
> should specify one explicitly. The valid calling conventions are: ilp32,
> ilp32f, ilp32d, lp64, lp64f, and lp64d.
> """
I can see how a doc fix probably makes most sense at this point, as the
behaviour has been shipping in GCC for a while. Although I like the idea of
less typing it could be that inferring a default ABI from the target -march was
a little too magic in the first place.
I'd also suggest adding another sentence or two to explain that ilp32 and lp64
describe soft-float calling conventions, while the f and d suffixes indicate
hard single or double precision floating point calling conventions.
[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #3 from Andrew Waterman ---
On Wed, Oct 25, 2017 at 12:27 PM, asb at lowrisc dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
>
> --- Comment #2 from Alex Bradbury ---
> (In reply to palmer from comment #1)
>> Thanks Alex -- you're correct that this is a documentation/code mismatch. I
>> just talked to Andrew and we think it's best to change the documentation.
>> How does this sound:
>>
>> """
>> @item -mabi=@var{ABI-string}
>> @opindex mabi
>> Specify integer and floating-point calling convention. The default for this
>> argument is system dependent, users who want a specific calling convention
>> should specify one explicitly. The valid calling conventions are: ilp32,
>> ilp32f, ilp32d, lp64, lp64f, and lp64d.
>> """
>
> I can see how a doc fix probably makes most sense at this point, as the
> behaviour has been shipping in GCC for a while. Although I like the idea of
> less typing it could be that inferring a default ABI from the target -march
> was
> a little too magic in the first place.
I think so. The desired mapping from ISA to ABI depends on the
platform (e.g., -march=rv32imaf should probably use the ilp32 ABI on a
Linux system because the standard libraries will be ilp32, but
probably should use the ilp32f ABI on an embedded system). While we
could define platform-specific mappings from -march to -mabi, things
would get confusing quickly. Better, IMO, to specify -mabi
explicitly.
And of course this is mostly only a headache for cross-compilation;
most native compilations will pass neither -mabi nor -march
explicitly.
>
> I'd also suggest adding another sentence or two to explain that ilp32 and lp64
> describe soft-float calling conventions, while the f and d suffixes indicate
> hard single or double precision floating point calling conventions.
[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #4 from palmer at gcc dot gnu.org ---
(In reply to Alex Bradbury from comment #2)
> (In reply to palmer from comment #1)
> > Thanks Alex -- you're correct that this is a documentation/code mismatch. I
> > just talked to Andrew and we think it's best to change the documentation.
> > How does this sound:
> >
> > """
> > @item -mabi=@var{ABI-string}
> > @opindex mabi
> > Specify integer and floating-point calling convention. The default for this
> > argument is system dependent, users who want a specific calling convention
> > should specify one explicitly. The valid calling conventions are: ilp32,
> > ilp32f, ilp32d, lp64, lp64f, and lp64d.
> > """
>
> I can see how a doc fix probably makes most sense at this point, as the
> behaviour has been shipping in GCC for a while. Although I like the idea of
> less typing it could be that inferring a default ABI from the target -march
> was a little too magic in the first place.
We kicked around the idea of making GCC match the docs, but decided that the
whole reason we have two arguments here is because there's no way to guess at
the ABI from the ISA.
For example, what happens if you pass "-march=rv64imafc" on a Linux system?
The "use the natural ABI" convention would say you get "-mabi=lp64f", but we
don't build as part of the multilib set of Linux.
> I'd also suggest adding another sentence or two to explain that ilp32 and
> lp64 describe soft-float calling conventions, while the f and d suffixes
> indicate hard single or double precision floating point calling conventions.
"""
@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 "-march=rv64ifd -mabi=lp64d" means that
"long" and pointers are 64-bit (implicitly defining "int" to be 32-bit), and
that floating-point values up to 64 bits wide are passed in F registers.
Contrast this with "-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
"-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: ilp32, ilp32f, ilp32d, lp64, lp64f, and lp64d. Some calling
conventions are impossible to implement on some ISAs: for example,
"-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.
"""
[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #5 from Alex Bradbury ---
(In reply to palmer from comment #4)
> """
> @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 "-march=rv64ifd -mabi=lp64d" means that
> "long" and pointers are 64-bit (implicitly defining "int" to be 32-bit), and
> that floating-point values up to 64 bits wide are passed in F registers.
> Contrast this with "-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
> "-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: ilp32, ilp32f, ilp32d, lp64, lp64f, and lp64d. Some
> calling conventions are impossible to implement on some ISAs: for example,
> "-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.
> """
Looks great to me!
[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717 --- Comment #6 from palmer at gcc dot gnu.org --- Author: palmer Date: Fri Oct 27 15:22:43 2017 New Revision: 254153 URL: https://gcc.gnu.org/viewcvs?rev=254153&root=gcc&view=rev Log: RISC-V: Correct and improve the "-mabi" documentation 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-27 Palmer Dabbelt PR target/82717 * doc/invoke.texi (RISC-V) <-mabi>: Correct and improve. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717 palmer at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from palmer at gcc dot gnu.org --- Thanks!
[Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
--- Comment #8 from Jim Wilson ---
Author: wilson
Date: Thu Nov 30 18:38:26 2017
New Revision: 255281
URL: https://gcc.gnu.org/viewcvs?rev=255281&root=gcc&view=rev
Log:
Riscv doc fixes and improvements.
gcc/
Backport from mainline
2017-11-30 Jim Wilson
* doc/invoke.texi (RISC-V Options): Delete nonexistent -mmemcpy and
-mno-memcpy options. For -mplt, -mfdiv, -mdiv, -msave-restore, and
-mstrict-align, add info on default value. Delete redundant lines for
-mabi. Add missing -mexplicit-relocs docs.
Backport from mainline
2017-11-01 Palmer Dabbelt
* doc/invoke.texi (RISC-V Options): Use "@minus{}2 GB", not "-2 GB".
* doc/invoke.texi (RISC-V Options): Explicitly name the medlow
and medany code models, and describe what they do.
2017-10-27 Palmer Dabbelt
PR target/82717
* doc/invoke.texi (RISC-V) <-mabi>: Correct and improve.
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/doc/invoke.texi
Re: [Bug target/82717] [RISCV] Default value of the -mabi option doesn't match documentation
On Wed, Oct 25, 2017 at 12:27 PM, asb at lowrisc dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82717
>
> --- Comment #2 from Alex Bradbury ---
> (In reply to palmer from comment #1)
>> Thanks Alex -- you're correct that this is a documentation/code mismatch. I
>> just talked to Andrew and we think it's best to change the documentation.
>> How does this sound:
>>
>> """
>> @item -mabi=@var{ABI-string}
>> @opindex mabi
>> Specify integer and floating-point calling convention. The default for this
>> argument is system dependent, users who want a specific calling convention
>> should specify one explicitly. The valid calling conventions are: ilp32,
>> ilp32f, ilp32d, lp64, lp64f, and lp64d.
>> """
>
> I can see how a doc fix probably makes most sense at this point, as the
> behaviour has been shipping in GCC for a while. Although I like the idea of
> less typing it could be that inferring a default ABI from the target -march
> was
> a little too magic in the first place.
I think so. The desired mapping from ISA to ABI depends on the
platform (e.g., -march=rv32imaf should probably use the ilp32 ABI on a
Linux system because the standard libraries will be ilp32, but
probably should use the ilp32f ABI on an embedded system). While we
could define platform-specific mappings from -march to -mabi, things
would get confusing quickly. Better, IMO, to specify -mabi
explicitly.
And of course this is mostly only a headache for cross-compilation;
most native compilations will pass neither -mabi nor -march
explicitly.
>
> I'd also suggest adding another sentence or two to explain that ilp32 and lp64
> describe soft-float calling conventions, while the f and d suffixes indicate
> hard single or double precision floating point calling conventions.
