diff mbox

[rs6000] Document location of ELF V2 ABI specification

Message ID 77c9a580-4ce4-5b21-7916-076696f5199a@linux.vnet.ibm.com
State New
Headers show

Commit Message

Bill Schmidt March 29, 2017, 9:27 p.m. UTC
Hi,

There is finally a permanent link to the OpenPOWER ELF V2 ABI Specification
document.  This patch adds a paragraph to the PowerPC Built-Ins section of
the GCC documentation to describe its value and provide a link to it.

I've generated and verified the PDF, and it looks ok.  I am very open to
changes in wording.  Is this ok for trunk?

Thanks,
Bill


2017-03-29  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>

	* doc/extend.texi (6.60.22 PowerPC AltiVec Built-in Functions):
	Add reference to the OpenPOWER 64-Bit ELF V2 ABI Specification.

Comments

Segher Boessenkool March 29, 2017, 10:36 p.m. UTC | #1
On Wed, Mar 29, 2017 at 04:27:28PM -0500, Bill Schmidt wrote:
> There is finally a permanent link to the OpenPOWER ELF V2 ABI Specification
> document.  This patch adds a paragraph to the PowerPC Built-Ins section of
> the GCC documentation to describe its value and provide a link to it.

Woohoo!

> I've generated and verified the PDF, and it looks ok.  I am very open to
> changes in wording.  Is this ok for trunk?

It's fine with me, but maybe Gerald (cc:ed) has some remarks?


> 2017-03-29  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>
> 
> 	* doc/extend.texi (6.60.22 PowerPC AltiVec Built-in Functions):

Section numbers are useless: they are not in thre source document, and
they also change all the time.


Segher
Bill Schmidt March 31, 2017, 3:06 p.m. UTC | #2
On Mar 29, 2017, at 5:36 PM, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> 
> On Wed, Mar 29, 2017 at 04:27:28PM -0500, Bill Schmidt wrote:
>> There is finally a permanent link to the OpenPOWER ELF V2 ABI Specification
>> document.  This patch adds a paragraph to the PowerPC Built-Ins section of
>> the GCC documentation to describe its value and provide a link to it.
> 
> Woohoo!
> 
>> I've generated and verified the PDF, and it looks ok.  I am very open to
>> changes in wording.  Is this ok for trunk?
> 
> It's fine with me, but maybe Gerald (cc:ed) has some remarks?

OK, I've committed this as r246617.  Gerald, please let me know if you'd like
any changes to the text.
> 
> 
>> 2017-03-29  Bill Schmidt  <wschmidt@linux.vnet.ibm.com>
>> 
>> 	* doc/extend.texi (6.60.22 PowerPC AltiVec Built-in Functions):
> 
> Section numbers are useless: they are not in thre source document, and
> they also change all the time.

Removed...

Thanks,
Bill
Gerald Pfeifer April 1, 2017, 5:15 p.m. UTC | #3
On Fri, 31 Mar 2017, Bill Schmidt wrote:
> OK, I've committed this as r246617.  Gerald, please let me know 
> if you'd like any changes to the text.

This looks fine to me.

Just "These are described briefly below." I'd written as "These 
are briefly described below." to avoid "briefly" seen as referring 
to "below".

Gerald
Bill Schmidt April 4, 2017, 3:16 p.m. UTC | #4
> On Apr 1, 2017, at 12:15 PM, Gerald Pfeifer <gerald@pfeifer.com> wrote:
> 
> On Fri, 31 Mar 2017, Bill Schmidt wrote:
>> OK, I've committed this as r246617.  Gerald, please let me know 
>> if you'd like any changes to the text.
> 
> This looks fine to me.
> 
> Just "These are described briefly below." I'd written as "These 
> are briefly described below." to avoid "briefly" seen as referring 
> to "below".

Thanks, I'll fix this later today.  Appreciate the review!

Bill

> 
> Gerald
>
diff mbox

Patch

Index: gcc/doc/extend.texi
===================================================================
--- gcc/doc/extend.texi	(revision 246566)
+++ gcc/doc/extend.texi	(working copy)
@@ -15539,6 +15539,15 @@  Internally, GCC uses built-in functions to achieve
 the aforementioned header file, but they are not supported and are
 subject to change without notice.
 
+GCC complies with the OpenPOWER 64-Bit ELF V2 ABI Specification,
+which may be found at
+@uref{http://openpowerfoundation.org/wp-content/uploads/resources/leabi-prd/content/index.html}.
+Appendix A of this document lists the vector API interfaces that must be
+provided by compliant compilers.  Programmers should preferentially use
+the interfaces described therein.  However, historically GCC has provided
+additional interfaces for access to vector instructions.  These are
+described briefly below.
+
 The following interfaces are supported for the generic and specific
 AltiVec operations and the AltiVec predicates.  In cases where there
 is a direct mapping between generic and specific operations, only the