[Bug target/68273] [5/6 Regression] Wrong code on mips/mipsel due to (invalid?) peeking at alignments in function_arg.

["jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68273

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #10)
> I understand everything you're saying Richi.  Note however that the MIPS
> backend explicitly wants to align things based on the object's alignment --
> even scalars passed in registers:

And that is the bug, backend should never do that.
Alignment of a scalar object is a property of that object, but if you pass it
by value, you just pass the value, so copy it to some other location.
Except for calls to unprototyped C (and Fortran) functions, one could argue
that some ABI could be using the alignment of the argument type on the function
definition (and require declarations to be matching).  But with calls to
unprototyped functions this becomes major problem.
As for ARM, the questions are what the compiler will do say on:
typedef int alignedint __attribute__((aligned(8)));
int  __attribute__((weak)) foo (int a, alignedint b)
{ return b;}
void bar (alignedint x)
{
  foo (1, x);
}

void
bar2 (alignedint x)
{
  foo (1, (alignedint) 1);
}

void
bar3 (alignedint x)
{
  foo (1, x + (alignedint) 1);
}

alignedint q;

void
bar4 (alignedint x)
{
  foo (1, q);
}

extern int baz (int, int);

void
bar5 (alignedint x)
{
  baz (1, x);
}