On 02/24/2014 10:42 AM, Richard Sandiford wrote: >... >> AIUI the old form never really worked reliably due to things like >> newlib's setjmp not preserving the odd-numbered registers, so it doesn't >>> seem worth keeping around. Also, the old form is identified by the GNU >>> attribute (4, 4) so it'd be easy for the linker to reject links between >>> the old and the new form. >> >> That is true. You will have noticed a number of changes over recent >> months to start fixing fp64 as currently defined but having found this >> new solution then such fixes are no longer important. The lack of >> support for gp32 fp64 in linux is further reason to permit redefining >> it. Would you be happy to retain the same builtin defines for FP64 if >> changing its behaviour (i.e. __mips_fpr=64)? > >I think that should be OK. I suppose a natural follow-on question >is what __mips_fpr should be for -mfpxx. Maybe just 0? I think we should think carefully about just making -mfp64 just disappear. The support has existed for bare iron for quite a while, and we do internal testing of MSA using -mfp64. I'd rather avoid a flag day. It would be good to continue recognizing that object files with attribute (4, 4) (-mfp64) are not compatible with other objects. Note that adding EF_MIPS_FP64 is a recent change, which was made to enable Linux kernel support, and there probably is little code out there that is dependent on it. I am more comfortable in changing the interpretation of EF_MIPS_FP64 to simply mean that the process is to be set with FR=1 mode as apposed to FR=0. This will allow us to ease our way off of -mfp64 to -mfr1 mode for those environments where FR=1 is really needed.
Doug >...
