Re: [patch] fr30: Hookize some target macros.

[Jim Wilson <wilson at specifixinc dot com>]

On Wed, 2004-01-28 at 16:09, Zack Weinberg wrote:
> I believe that STRICT_ARGUMENT_NAMING and everything related to it are
> effectively dead code, (intended to be - possibly not) used only for
> <varargs.h> that no lnger exists.  However, the code is so tangled
> that I do not have time to muck with it and find out for sure.

STRICT_ARGUMENT_NAMING was added to solve a problem with both varargs
and stdarg functions on mips-sgi-irix6 n32/n64 ABIs.

There are 3 possible choices here for a stdarg function:
1) all named args except the last are treated as named, the last named
arg and all args that match the ellipsis are treated as unnamed
2) all named args including the last are treated as named, all args that
match the ellipsis are treated as unnamed
3) all args are treated as named

Case 1 is the gcc default, probably an artifact of the varargs support,
when the last named arg was builtin_va_list.  Case 2 is needed for the
MIPS n32/n64 ABIs, you get this if you define STRICT_ARGUMENT_NAMING to
true.  Case 3 is what most gcc targets use, you get this if
pretend_outgoing_args_named is true, or if setup_incoming_varargs is
defined.

If we get rid of strict_argument_naming, then we can no longer have both
case 1 and 2.  A example port that uses case 1 is h8300 (and I had to
look hard to find it, it might be the only one).  If I compile this
testcase for the h8300
int sub1 (int i);
int sub2 (int i, ...);
int sub3(void) { return sub1 (10) + sub2 (20, 30); }
We see that the first arg to sub1 is passed in r0, but the first arg to
sub2 is passed on the stack.  This is probably unintentional, and is
arguably broken, but some might not appreciate us "fixing" this, as that
will introduce ABI incompatibilities.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com