Re: [patch/rfa] fix call-dummies for hppa

[Andrew Cagney <cagney@gnu.org>]

>>> Which compilers?  I'm suspicious of GCC - it too often gets struct 
>>> parameters and return values internally consistent but wrong :-(
> 
> 
> gcc only; I don't have access to the hp compilers. However, Dave 
> (the hppa gcc maintainer) is quite careful about these things, so I 
> think they are correct ;-)
> 
> 
>>> Be careful of white space change, this shouldn't be included.  If you 
>>> want to fix some indention just do it separatly.
> 
> 
> ok, there were some stray tabs in the file so i was cleaning them up
> along the way, but i'll remove that from this diff.
> 
> 
>>> (I've now got a copy of the 32-bit ABI but it doesn't help much)
> 
> 
> this is the som runtime doc?  it's not particularly clear about small 
> structs.....

yes.  the 64-bit one is much better.

>>> the comment doesn't match the assignment.
>>> 
>>
>>>> >+      /* The first parameter goes into sp-36, each stack slot is 4-bytes. 
>>>> >*/
>>>> >+      CORE_ADDR param_ptr = 32;
> 
> 
> it does, actually, because the param_ptr is incremented by 4 for each
> argument, so the first one goes to 36.

ok, just expand the comment to clarify this.

>>>> >+	  else if (TYPE_CODE (type) == TYPE_CODE_FLT)
>>>> >+            {
>>
>>> 
>>> more comments (the rest is well commented), ``&& TYPE_LENGTH () == 4'' 
>>> test needed?
>>> 
>>
>>>> >+	      param_len = align_up (TYPE_LENGTH (type), 4);
>>>> >+	      memcpy (param_val, VALUE_CONTENTS (arg), param_len);
> 
> 
> yes, this bit is wrong. i found some more bugs in this function. will
> send a new version with the whitespace changes removed and comments
> added.

With a comment tweak, ok to commit.

Andrew