[Bug target/15941] [3.4/3.5 regression] new fails gcc.dg/compat/struct-by-value-11 and gcc.dg/compat/struct-by-value-1

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

------- Additional Comments From danglin at gcc dot gnu dot org  2004-06-18 04:05 -------
The file yyy.c demonstrates the problem introduced by Richard's change.
The first hunk now always sets the memory alignment for stack_parm to
that specified by FUNCTION_ARG_BOUNDARY.  For a 5-byte struct, this is
64 bits.  Previously, the maximum memory alignment for stack_parm was
PARM_BOUNDARY.  PARM_BOUNDARY is 32 bits on this target.

This is the code that 3.4.1 generates to load the 5-byte struct passed
on the stack for the call to check5:

        ldw -117(%r30),%r21
        ldb -113(%r30),%r19
        zdep %r21,23,24,%r20
        extru %r21,0+8-1,8,%r25
        .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR
        bl check5,%r2
        or %r19,%r20,%r26

Except for the fact that the ldw insn is not aligned correctly, the code
is correct.  On hpux, the unaligned load causes a segmentation fault.

This is the code that 3.3 generates:

        ldb -117(%r30),%r25
        ldb -116(%r30),%r21
        ldb -115(%r30),%r20
        zdep %r21,7,8,%r21
        zdep %r20,15,16,%r20
        ldb -114(%r30),%r19
        ldb -113(%r30),%r22
        or %r20,%r21,%r20
        zdep %r19,23,24,%r19
        or %r19,%r20,%r19
        .CALL ARGW0=GR,ARGW1=GR,ARGW2=GR
        bl check5,%r2
        or %r22,%r19,%r26

It's significantly less efficient but has no unaligned accesses.  For
comparison, this is what the HP compiler generates to load the arguments:

        LDB     -117(%r30),%r25 ;offset 0x18
        LDW     -116(%r30),%r26 ;offset 0x1c

I believe what has happened is that Richard's change has enabled the
the access optimization in emit_group_load, and we are not correctly
setting the alignment of the source data when it is in a stack slot.
This is a result of using downward padding in stack slots on this target.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15941