[Bug c/102148] New: ppc64le: homogeneous float arguments are not passed correctly

[Bug c/102148] New: ppc64le: homogeneous float arguments are not passed correctly

[zlwang at ca dot ibm.com]

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

            Bug ID: 102148
           Summary: ppc64le: homogeneous float arguments are not passed
                    correctly
           Product: gcc
           Version: 8.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zlwang at ca dot ibm.com
  Target Milestone: ---

example program:

typedef struct {
        float a[2];
} sub;
typedef struct {float b; sub c; float d;} R;
extern R func(long,R,float,int);
R v = {0, {1,2}, 3};

double ma() {
        R rv = func(77,v,88,99);
        return rv.d;
}


Since R is a homogeneous float aggregate with less than 8 elements, func
argument passing should look like the following function:

func(long, float, float, float, float, float, int)

But they are not. At least for gcc8.4.1, the latter's long/int are passed in r3
and r9 respectively; while the former's long/int are passed in r3 and r7
respectively.

[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly

[dje at gcc dot gnu.org]

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

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-09-01
             Target|powerpc64le                 |powerpc64le-*-linux
     Ever confirmed|0                           |1

--- Comment #1 from David Edelsohn <dje at gcc dot gnu.org> ---
Confirmed.

[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly

[zlwang at ca dot ibm.com]

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

--- Comment #2 from julian <zlwang at ca dot ibm.com> ---
ABI text will be clarified re this case.  The two cases are different after all
(register foot-print are the same, but the parameter saving-area will be
different). such that GPR skipping is different.

I am closing this.

[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly

[zlwang at ca dot ibm.com]

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

julian <zlwang at ca dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #3 from julian <zlwang at ca dot ibm.com> ---
closing ...

[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
Thanks, Julian.  I'll record this for the next ABI update.

[Bug target/102148] ppc64le: homogeneous float arguments are not passed correctly

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
For anyone running into this problem and wondering about the resolution:

It is a matter of some confusion how homogeneous aggregates are mapped to the
parameter save area. This came up recently with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102148. It would be helpful to add
some clarifying text for the following points.

(1) The parameter save area layout is completely independent from the rules for
passing homogeneous aggregates in registers.
(2) The size of a homogeneous aggregate parameter in the parameter save area is
the size of that aggregate by normal rules of alignment and padding. This means
that the parameter save area for a homogeneous aggregate of 32-bit floats takes
up less room than the amount of register space consumed.
(3) The number of GPRs skipped is based upon the size of the aggregate in the
parameter save area.

An example of this exists (Figure 2.26 in revision 1.5), but it is easy to have
difficulty spotting the information there.