This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix one-sized FP arrays returning on MIPS

Hi Eric,

Sorry for the late answer.  I was away last week, and I've been desperately
trying to catch up on mail since.

I saw your discussion on gcc@ with Jim, in which you said:

>> > - one-sized arrays of integers are returned in the upper half of $2,
>> > while they were returned in the lower half previously.  If I read
>> > correctly again, this ABI change is not listed in
>> >
>> This is item E.
> Strictly speaking, I don't think so.  Take a look at the second line in the 
> document, I see no mention of arrays.
> Now if you're saying that mips-abi.html should be fixed to use the same 
> wording as the header of mips_return_in_msb, it's fine with me.  I only 
> wanted someone to decide which one should be corrected.

And yes, IMO, we should treat these sorts of arrays as aggregates as well,
in which case the definition of "aggregate" in mips-abi.html should be
extended.  As Jim says, this case didn't occur to me, since it isn't a
problem with C, C++ or (I believe) Fortran.

> @@ -7331,6 +7332,12 @@ mips_fpr_return_fields (tree valtype, tr
>    if (!TARGET_NEWABI)
>      return 0;
> +  /* Accept one-sized arrays of FP type.  */
> +  if (TREE_CODE (valtype) == ARRAY_TYPE
> +      && TREE_CODE (TREE_TYPE (valtype)) == REAL_TYPE
> +      && TYPE_MODE (valtype) != BLKmode)
> +    return 1;
> +
>    if (TREE_CODE (valtype) != RECORD_TYPE)
>      return 0;

As far as I can tell, your patch treats arrays with one floating-point
element in the same way as structures with one floating-point field,
but it doesn't treat arrays with two elements in the same way as
structures with two floating-point fields.  This seems a little

I'm also suspicious of any ABI-related check that depends on TYPE_MODE
rather than TYPE_CODE.  (Yes, there are other bits of ABI code that
depend on TYPE_MODE, but I think they're a mistake as well.)

As I understand it, the special case for structures of one or two
floating-point fields was motivated by Fortran complex values (the ABI
having been defined before C had complex values too).  I don't see any
particular reason to treat single-element floating-point arrays as a
further special case: it seems better to treat all arrays alike.

In other words, I think the return_in_msb hook is right to return
true for the test case you quote.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]