On Mon, 6 May 2019, Jim Wilson wrote: > > Hmm, I've been thinking a little bit about this hybrid mode and I have > > one question: how do we pass the IEEE rounding mode setting between `fcsr' > > and softfp where we have `-march=rv32imafc -mabi=ilp32' and > > `-march=rv32imac -mabi=ilp32' object modules interlinked? > > If you look at libgcc/config/riscv/sfp-machine.h you will see > definitions of FP_INIT_ROUNDMODE and FP_HANDLE_EXCEPTIONS for reading > rounding mode from the fcsr before soft-float FP operations, and > storing the exception flags back into fcsr after soft-float FP > operations, if FP regs exist.. Whether this actually works, I don't > know, I haven't tested it.
I've looked at the code and it looks like it should do what's intended here. > I think in practice people using > soft-float libraries are probably not relying on rounding modes and > exception flags much if at all, so this is unlikely to be a problem. However I gather the intent for the hybrid mode has been to permit people to seamlessly interlink hard-float and soft-float code, perhaps libraries that have only been supplied in a binary form (whether we like it or not) and cannot therefore be rebuilt for the other FP model. As such I think we should ensure that consistent operation has been architected for the reasonable scenarios, such that if any problem problem arises, then it's at most a bug and not a design fault. It does appear to me we don't have a design fault here, so no need to worry. > If someone does find a problem, I will worry about how to fix it then. Sure. I just wanted to double-check we don't have an ABI issue here. Maciej
