i386 fegetround bug

i386 fegetround bug

[Szabolcs Nagy]

fegetround had a bug: eax was not cleared properly

while fixing it i also changed fesetround see my commit message

http://nsz.repo.hu/git/?p=musl;a=commit;h=88cfaf8a142a8c57beccb89398a6421c4bbf121a

the feclearexcept probably shouldn't get changed like fesetround

i havent checked the x86_64 code

Re: i386 fegetround bug

[Szabolcs Nagy]

* Szabolcs Nagy <nsz@port70.net> [2012-03-17 15:42:44 +0100]:
> fegetround had a bug: eax was not cleared properly
> 
> while fixing it i also changed fesetround see my commit message
> 
> http://nsz.repo.hu/git/?p=musl;a=commit;h=88cfaf8a142a8c57beccb89398a6421c4bbf121a
> 

i realized my analysis was not entirely correct after rereading
Intel 64 and IA-32 .. Manual, vol.1. 8.6 last paragraph and 8.7.1

it suggests that pending unmasked exceptions can occur
with normal operation (assuming there are unmasked exceptions)
(i just couldn't produce such case from c as an arithmetic op
is usually followed by an fld which traped before i could test
my theory with an fnstenv)

so if we want to be unmasked-exception-friendly then
fnstenv/fldenv pair should be used

(maybe with some extra check for unmasked exceptions first:
fnstcw x
and $0x3f,x
sub $0x3f,x
jnz unmasked_exceptions
...
and the unmasked_exceptions case uses fnstenv/fldenv, otherwise
plain fldcw is used)

(fnstenv/fldenv can probably hurt those who change rounding
mode frequently, i haven't seen such code but in theory
it makes sense for interval arithmetics)

Re: i386 fegetround bug

[Rich Felker]

On Sat, Mar 17, 2012 at 07:48:01PM +0100, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [2012-03-17 15:42:44 +0100]:
> > fegetround had a bug: eax was not cleared properly
> > 
> > while fixing it i also changed fesetround see my commit message
> > 
> > http://nsz.repo.hu/git/?p=musl;a=commit;h=88cfaf8a142a8c57beccb89398a6421c4bbf121a
> > 
> 
> i realized my analysis was not entirely correct after rereading
> Intel 64 and IA-32 .. Manual, vol.1. 8.6 last paragraph and 8.7.1
> 
> it suggests that pending unmasked exceptions can occur
> with normal operation (assuming there are unmasked exceptions)
> (i just couldn't produce such case from c as an arithmetic op
> is usually followed by an fld which traped before i could test
> my theory with an fnstenv)
> 
> so if we want to be unmasked-exception-friendly then
> fnstenv/fldenv pair should be used

I'm not in favor of hurting performance or other useful
characteristics for the sake of a nonstandard feature of dubious
usefulness. Unless there's a demand to change it, I'm fine with your
new (fastest) version of the code.

> (maybe with some extra check for unmasked exceptions first:
> fnstcw x
> and $0x3f,x
> sub $0x3f,x
> jnz unmasked_exceptions
> ....
> and the unmasked_exceptions case uses fnstenv/fldenv, otherwise
> plain fldcw is used)

I'm not opposed to this solution, but also don't really find it
necessary. By the way, I think shifting right the low 6 bits and
checking carry flag would be more efficient. :)

Rich