This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: __builtin_apply_args - GCC 4.1.1


"Mohamed Shafi" <shafitvm@gmail.com> writes:

> On 01 Jun 2007 07:22:39 -0700, Ian Lance Taylor <iant@google.com> wrote:
> > "Mohamed Shafi" <shafitvm@gmail.com> writes:
> >
> > > I am working with a private target(GCC v4.1.1).
> > > For my target the function arguments are passed through registers.
> > > For this purpose 4 registers are used. If the no. of arguments are
> > > more than 4, the remaining arguments are passed through stack.
> > >
> > > But for varargs the arguments are pushed into the stack by the caller function.
> >
> > These days the usual style is to handle arguments for normal and
> > varargs functions in exactly the same way.  This avoids errors when
> > calling a function without a proper prototype in scope.  But certainly
> > what you describe is a valid way to implement a backend.
> 
> Initially implementation was same for both. But DWARF2 was going wrong
> for varargs function. So we had to change the implementation for that.
> What we did was removing the target hook TARGET_SETUP_INCOMING_VARARGS.

That doesn't seem like the right approach to me, but, whatever.


> > For your platform, __builtin_apply will only work when the callee has
> > the same signature as the caller.  __builtin_apply has no support for
> > changing the way that arguments are passed.  It simply passes the
> > arguments to the callee in the same way that they were passed to the
> > caller.
> 
> This test case passed before removing the target hook
> TARGET_SETUP_INCOMING_VARARGS. All that changed is that now varable
> arguments are pushed into the stack by the caller function. So i guess
> the term "same signature" also include the way the arguments are
> passed by the functions.

The signature is the type of the function, including the return type
and the parameter types and whether an ellipsis is used, so, yes.


> > Before you really dig into this, do you care?  __builtin_apply only
> > exists to implement the Objective C runtime.  And in fact it is
> > generally considered desirable to change that code to use libffi
> > instead, in which case __builtin_apply will probably be deprecated and
> > removed.  If you don't need to compile Objective C, I wouldn't worry
> > about __builtin_apply.
> 
> I am concerned about only C. If __builtin_apply is important only in
> Objective C why is it that this test case is included in C test suites
> ?
> If the outcome of the test cases involving __builtin_apply and
> __builtin_apply_args doesnt matter for a C compiler is it proper to
> include them in the C testsuites ?

They need to work in C in order to implement the Objective C runtime.
Besides, they are documented, so they should be tested.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]