Martin Husemann <martin%duskware.de@localhost> writes: > On Tue, Apr 30, 2013 at 08:11:57AM -0400, Greg Troxel wrote: >> Probably not. But can you point to something in standards or existing >> practice that makes per-thread rounding mode make any sense at all? >> This discussion is the first I've heard of the concept. > > It is what happens on hardware FPUs - the rounding mode is typically > part of the saved FPU state that gets switched between threads. Sure, but that applies equally to process scheduling, not just threads. The real question is whether the standards-specified interfaces to set the rounding mode have scope that is thread-local or process-wide. I've always read the man pages to imply process-wide scope. And as a programmer you want a chunk of code to behave a certain way, not a thread (which is only sort of the same if you have a plan for separation of code paths into threads along these lines). I got a copy of IEEE754-2008, and it (pages 15-17) talks about "attributes", which are about source-code blocks, implying that rounding should be settable dynamically. So it's not really thread local so much as value to be in effect for a particular procedure's execution (which I agree turns out to be thread-local). C99's fenv.h is not entirely obviously aligned with IEEE754, but surely that must be the intent. > For softfloat we use a global variable in libc currently, so it is shared > in this case. So I guess the questions on the table are: 1) Figure out which interpretation of fesetround rounding mode (thread local vs process) is correct according to C99. 2) Then, determine how our implementation behaves for hardfloat and maybe fix it. 3) If it's supposed to be thread local, use tls for softfloat. The hard part seems to be 1 and 2. Having tried to read the specs, I lean towards the interpretation that fesetround should affect a thread.
Attachment:
pgps4lg3vUVI7.pgp
Description: PGP signature