"Mohamed Shafi" <[EMAIL PROTECTED]> writes: > On 01 Jun 2007 07:22:39 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > "Mohamed Shafi" <[EMAIL PROTECTED]> 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
