From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-405590-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 130463 invoked by alias); 19 Aug 2015 17:53:38 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 130449 invoked by uid 89); 19 Aug 2015 17:53:37 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-oi0-f42.google.com
Received: from mail-oi0-f42.google.com (HELO mail-oi0-f42.google.com) (209.85.218.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 19 Aug 2015 17:53:27 +0000
Received: by oio137 with SMTP id 137so7892057oio.0        for <gcc-patches@gcc.gnu.org>; Wed, 19 Aug 2015 10:53:25 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.202.214.72 with SMTP id n69mr11300837oig.67.1440006805707; Wed, 19 Aug 2015 10:53:25 -0700 (PDT)
Received: by 10.76.170.36 with HTTP; Wed, 19 Aug 2015 10:53:25 -0700 (PDT)
In-Reply-To: <20150819174805.GC32473@gate.crashing.org>
References: <20150804192913.GO11083@gate.crashing.org>	<CAMe9rOrrtDZxS2E3pD5DsUYox7ze1un0m8+LJ0Eo79BBLOsZgQ@mail.gmail.com>	<20150804204506.GP11083@gate.crashing.org>	<CAMe9rOoMzgkguZ+zY24Jytpr9HnoXvu5BUP3c7K-34Gmm2SDLg@mail.gmail.com>	<CAMe9rOrHUnJJx68qKUe0gsVVwYXNALmCR6-4UVV_V3df4KO3_A@mail.gmail.com>	<20150819125145.GC8652@gate.crashing.org>	<CAMe9rOrymZ3N_2HTd87C-LfoHYeZ_P7myMCL9ZvikE+uU19eRg@mail.gmail.com>	<CAMe9rOqLxX3h_Pn2Rn1Ph-FH41e1DfEG1qPheDLBNdycPa=sNw@mail.gmail.com>	<20150819165854.GB32473@gate.crashing.org>	<CAMe9rOqDjBKWXcA7mYXeCoktUj4Q5FRWiDq+rxKRTyZiyXRBTQ@mail.gmail.com>	<20150819174805.GC32473@gate.crashing.org>
Date: Wed, 19 Aug 2015 19:13:00 -0000
Message-ID: <CAMe9rOoOiWQGrTey+J54=JRVd0wK9p65HEj0s8F1nkx0+1qg=A@mail.gmail.com>
Subject: Re: [PATCH] Add __builtin_stack_top
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Mike Stump <mikestump@comcast.net>, GCC Patches <gcc-patches@gcc.gnu.org>, 	Uros Bizjak <ubizjak@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2015-08/txt/msg01127.txt.bz2

On Wed, Aug 19, 2015 at 10:48 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
> On Wed, Aug 19, 2015 at 10:08:01AM -0700, H.J. Lu wrote:
>> > Maybe something like (heavily cut'n'pasted):
>> >
>> >
>> > @deftypefn {Built-in Function} {void *} __builtin_argument_address (void)
>> > This function is similar to @code{__builtin_frame_address} with an
>> > argument of 0, but it returns the address of the incoming arguments to
>> > the current function rather than the address of its frame.
>>
>> This doesn't make senses when there is no argument or arguments
>> are passed in registers.
>
> Sure, but see the weasel-words below ("The exact...")
>
>> To me, argument pointer is a virtual concept
>> and an implementation detail internal to GCC.  I am not sure if another
>> compiler can implement it based on this description.
>
> The same is true for frame_address, on many machines.

Stack frame is well understood unlike argument pointer which is
pretty vague.

>> > The exact definition of this address depends upon the processor and the
>> > calling convention.  Usually some arguments are passed in registers and
>> > the rest on the stack, and this builtin returns the address of the first
>> > argument that is on the stack.
>
>
> Segher



-- 
H.J.