Doug Gilmore <doug.gilm...@imgtec.com> writes: > 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.
Right, that was the idea. (4, 4) would always mean the current form of -mfp64 and the linker would reject links between (4, 4) and the new -mfp64 form. The flag day was more on the GCC and GAS side. I don't see the point in supporting both forms there at the same time, since it significantly complicates the interface and since AIUI the old form was never really suitable for production use. Thanks, Richard
