[PATCH] Fix i?86 -mregparm for K&R fn declarations (PR target/36015)

[Mark Mitchell]

Richard Guenther wrote:
> On Wed, Apr 23, 2008 at 3:51 PM, Jakub Jelinek <jakub@redhat.com> wrote:
>> Hi!
>>
>>  As the testcase below shows, we've regressed on i?86 with -mregparm
>>  and K&R fn declarations, !prototype_p functions used to have args passed
>>  in registers according to -mregparm=, attribute regparm or fastcall,
>>  but in 4.3 all arg passing to such functions is forced on the stack.
>>  Unfortunately, in the actual fn definition which has argument types
>>  it expects the arguments to be passed in registers.
>>  As diagnose_arglist_conflict will error on
>>  int foo (); int foo (int x, ...) { return 0; }
>>  it is IMHO safe to assume that functions declared without argument type list
>>  aren't stdarg and so can safely use register passing.

I'm not so sure that's true.  I don't think there's anything invalid 
about declaring foo as unprototyped (e.g., "int foo()") and then 
declaring it as prototyped with variable arguments later.  Joseph, can 
you comment on that issue?

Even if I'm right about the language issue, it might be that we still 
want the behavior you describe for backwards compatibility reasons.  We 
might just want to document that -mregparm disallows this bit of C.

>>  The patch below IMHO restores the 4.2 behavior, which did:
>>   cum->maybe_vaarg = false;

There's a potential ABI issue anytime we're adjusting calling 
conventions.  But, if I understand correctly, the 4.3 behavior was 
internally inconsistent, and thus this kind of code didn't work at all, 
right?  So, it's not so much that 4.3 broke the ABI, but rather than 4.3 
was just broken, and we don't need to worry about the AB issue?

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713