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

[Richard Sandiford <rsandifo at redhat dot com>]

Eric Botcazou <ebotcazou@act-europe.fr> writes:
>> (a) The code in calls.c is supposed to handle this case.  It really
>>     is a bug that it doesn't.  Regardless of what MIPS does, other ABIs
>>     could have this requirement, and the code should deal with it
>> properly.
>
> I think patching this code might be dangerous on a release branch.
> You could inadvertently introduce ABI changes there.  So the safe
> approach could be to patch only the mainline.

Disagree.  See my RFA post for an explanation.  If you still think
there's a risk of an ABI change after my explanation there, can you
respond to the message saying why?

>> (b) You wanted a patch that could be applied to 3.4.  That means not
>>     changing the ABI.  I believe that the callee side does _not_ ICE
>>     on single-element float arrays, so this is definitely an ABI change.
>
> Confirmed, it doesn't ICE on the callee side.  However, I don't see how you 
> could qualify this as an ABI change, since there is currently no Interface 
> for that case.

Interface is an Ada thing, I presume?  But the bug can trigger for C too.
Again, see the test case in the RFA post.  So regardless of the Ada
situation, your patch is definitely an ABI change for C.

>> (d) As you said yourself, the patch to change the ABI would be a kludge.
>>     I don't see why we should prefer that over a patch that addresses
>>     the ICE directly.
>
> To sum up: less risky,

Less risky?  I strongly disagree that a change to the MIPS ABI code
is less risky than the patch I'm proposing, which simply changes the
mode of an rtx from SFmode to SImode _after_ the ABI-specific stuff
has been dealt with.

Richard