This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix one-sized FP arrays returning on MIPS
Eric Botcazou <firstname.lastname@example.org> 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
> 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.