Richard Sandiford <rdsandif...@googlemail.com> writes: > Matthew Fortune <matthew.fort...@imgtec.com> writes: > > Are you're OK with automatically selecting fpxx if no -mfp option, no > > .module and no .gnu_attribute exists? Such code would currently end up > > as FP ABI Any even if FP code was present, I don't suppose anything > > would get worse if this existing behaviour simply continued though. > > The -mfp setting is usually implied by the -mabi setting. I don't think > we should change that. Since this is a new mode, and since the fpxx > markup will be available from the start, everyone using fpxx should say > so explicitly. > > E.g. maybe the rules should be: > > (1) Any explicit .gnu_attribute 4 is always used, although we might > give a diagnostic if it's incompatible with the module-level > setting. > > (2) Otherwise, if the code does not use FP then the attribute is left > at the default of 0. > > (3) Otherwise, a nonzero .gnu_attribute 4 is implied from the module- > level > setting. > > (4) For compatibility, -mabi=32 continues to imply -mfp32. fpxx mode > must > be selected explicitly. > > Which was supposed to be simple, but maybe isn't so much.
This sounds OK. I'd rather (4) permitted transition to fpxx for 'safe' FP code but let's see if we can do without it. Setjmp/longjmp are the only obvious candidates for using FP code in assembly files and these need to transition to fpxx. The glibc implementation of setjmp/longjmp is in C so the new defaults from the compiler will lead to this being fpxx as -mips32r2 will imply -mfpxx so that is OK, these modules will be tagged as fpxx. Currently newlib's implementation is assembly code with no .gnu_attributes. Under the rules above this would start to be implicitly tagged as gnu_attribute 4,1 (fp32). Any thoughts on how we transition this to fpxx and still have the modules buildable with old tools as well? I'm not sure if it will be acceptable to say that it has to be rewritten in C. There will also be uclibc and bionic to deal with too for setjmp/longjmp but I don't have their source to hand. Regards, Matthew
