Problem in locate_and_pad_parm

[Jim Wilson]

In article < 10010191043.AA28275@vlsi1.ultra.nyu.edu > you write:
>Here are the conditions listed.  Which of them can GCC now do?
>   - if the padding and mode of the type is such that a copy into a register
>     would put it into the wrong part of the register.

This one.  Sort of.

The real situation is actually a lot more complicated.  Arguments can have
padding on the stack, and they can have padding in registers.  This padding is
not necessarily the same.  We have a macro to describe padding:
FUNCTION_ARG_PADDING, however this gets used inconsistently.  It is used for
arguments in the stack pretty much everywhere, but some places loading args
into register use it and some don't.  We have different ways of loading
arguments into registers.  I don't think any of them handle padding in a
reasonable way, but some of them default to different padding than others.
If you choose the argument loading mechanism carefully, then you can get
the right padding.  In particular, I think the emit_group_{load,store} routines
default to padding that is the opposite of that used by the generic code
for loading BLKmode values into registers.  It would be better if both allowed
the back end to specify padding, but meanwhile you can usually get the right
padding by choosing between the two alternatives.

I ran into this problem when doing the Irix6 port.  There is an infamous
irix6 structure parameter passing bug that still isn't fixed yet.  I tried
to fix it by changing MUST_PASS_IN_STACK/FUNCTION_ARG_PADDING/etc, and every
time I changed something I broke something else.  I eventually gave up.
Nowadays, I think it should be pretty easy to fix this bug by using the
emit_group_{load,store} routines.  Instead of trying to define a set of
macros that interact in confusing ways, we just have the back-end define
a table of info saying where to put the arguments.  Long term, I think we
need to extend this approach so it can handle all arguments, and throw away
all of the confusing macros we currently use.

I still believe that it is a bad idea to try to change the default definition
of MUST_PASS_IN_STACK.  This is going to change the ABIs implemented by an
unknown number of ports in unknown ways.  That isn't a wise change, even if
it does conflict with the theory behind the macro.

Jim