public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Steve Ellcey <sellcey@cavium.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>,
	"richard.earnshaw"	 <richard.earnshaw@arm.com>
Subject: [Patch] Document __builtin_extend_pointer
Date: Tue, 20 Feb 2018 17:33:00 -0000	[thread overview]
Message-ID: <1519147981.6296.18.camel@cavium.com> (raw)

While working on PR 83335 I proposed a change to a test case that
used __builtin_extend_pointer and Richared Earnshaw pointed out
that this builtin is not documented.  Since I could not find any
other (reasonable) way to generate an extended address in inline
assembly other than this builtin I would like to document it for
use.

Here is a proposed patch, the one problem I found was the return
type of the builtin.  I don't know how to describe it other than
Pmode, but that is not a user visible type.

See https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01051.html
for my PR 83335 patch and follow up comments.

Should I go ahead and add this documentation?


2018-02-20  Steve Ellcey  <sellcey@cavium.com>

	* doc/extend.texi (__builtin_extend_pointer): Document builtin.


diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index d38840e..94e47aa 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -11042,6 +11042,7 @@ the built-in function returns -1.
 @findex __builtin_alloca_with_align
 @findex __builtin_alloca_with_align_and_max
 @findex __builtin_call_with_static_chain
+@findex __builtin_extend_pointer
 @findex __builtin_fpclassify
 @findex __builtin_isfinite
 @findex __builtin_isnormal
@@ -12419,6 +12420,15 @@ Similar to @code{__builtin_bswap32}, except the argument and return types
 are 64 bit.
 @end deftypefn
 
+@deftypefn {Built-in Function} Pmode __builtin_extend_pointer (void * x)
+On targets where the user visible pointer size is different than the size
+of an actual hardware address this function returns the extended user
+pointer.  Targets where this is true included ILP32 mode on x86_64 or
+Aarch64.  This function is mainly useful when writing inline assembly
+code.
+@var{addr}
+@end deftypefn
+
 @node Target Builtins
 @section Built-in Functions Specific to Particular Target Machines
 

             reply	other threads:[~2018-02-20 17:33 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-20 17:33 Steve Ellcey [this message]
2018-02-22  5:04 ` Jeff Law
2018-03-20 12:13 ` Tom de Vries
2018-03-20 21:00   ` Jeff Law

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1519147981.6296.18.camel@cavium.com \
    --to=sellcey@cavium.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.earnshaw@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).