Re: Problem in locate_and_pad_parm

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    You can not just change the endianness of the chip to make it conform
    to a gcc design decision that was made some ten years ago.  And the
    knowledge how to pass the parameters in registers is in the tm.h
    FUNCTION_ARG, FUNCTION_ARG_ADVANCE etc.

You miss the point.  MUST_PASS_IN_STACK is *defined* to be the set of
conditions that GCC cannot support in registers.  This is not something
that can be changed in a port.

    The ports are fine, thank you.  By overriding MUST_PASS_IN_STACK they
    can finally provide a working ABI.

Then it must be the case that GCC now supports things it didn't used to,
so the definition of MUST_PASS_IN_STACK must be wrong.

Which of the those things can now be supported?

The fact that ports "work" doesn't mean the definitions are correct!  GCC
needs to set a much higher standard for its code than simply "working":
it has to be properly documented and consistent.

MUST_PASS_IN_STACK was intended (and I can state that unequivocally since I
wrote it) to mean those cases that GCC did not know how to handle.

If you look at the comments for it in expr.h, it still says that:

    /* Nonzero if we do not know how to pass TYPE solely in registers.

Changing this in a port cannot affect what GCC knows how to do!

Here are the conditions listed.  Which of them can GCC now do?

   - if the type has variable size
   - if the type is marked as addressable (it is required to be constructed
     into the stack)
   - 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.

As you can see from the change that started this thread, these
parameterizations are very tricky and hard to get right.  If we don't
have consistent documentation but instead ports working by accident,
we don't have a maintainable compiler.