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: ARM: testsuite gcc.c-torture/execute/20020307-2.c failure


> Richard Earnshaw wrote:
> >>Looking at testcase
> >>	gcc.c-torture/execute/20020307-2.c
> >>
> [...]
> > 
> > 
> > When a struct is of potentially variable size (from the viewpoint of the 
> > callee), then the argument has to be passed by reference (we can't put it 
> > into the registers since it would mess up dereferencing everything else).  
> 
> Why is this such a problem ?
> 
> Looking at the current code (gcc-3.2) produced for the callee (with va_arg), the callee just
> starts dumping r0-r3 to the stack, so that from that point,
> he (it?) can access the arguments as if passed on the stack...
> I guess something similar can be done (without variable arguments) when
> a variable-sized array is passed...

Consider it from the callers point of view; for example

void foo(int size, ...);

bar ()
{
   int i;

   for (i = 1, i < 5; i++)
     {
        struct {
	  int x[i];
        } d;
	int j;

	for (j = 0; j < i; j++)
	  d[j] = j;

        foo (i, d, 99);
     }
}

Where is 99 put?  Answer: it depends on the value of i.  If i < 3, then 99 
is placed in a register, otherwise it is on the stack.  For the register 
case even that can vary.

That makes compiling the call to foo very difficult, if not impossible.

It's even worse for passing d itself, part of it (sometimes all of it) is 
in registers, and the remainder of it (if there is any) is on the stack.  
How much stack space do we have to allocate...

It's far cleaner to handle this case by making a copy and passing an 
address of the copy, even if this isn't the way most other types of 
argument are handled.

Variadic functions are rare in real life, and are inherently slow; so I 
don't think we need to spend a lot of time on this, especially since it's 
a rather peculiar GCCism.

Now if the above were legal ISO C, then I'd worry about it more; but it 
isn't, so I'm not.

R.



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