This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fix atan / atan2 missing underflows (bug 15319) [committed].

On Wed, 18 Feb 2015, Szabolcs Nagy wrote:

> * Joseph Myers <> [2015-02-18 21:11:57 +0000]:
> > I saw without that are similar to those Carlos reported for other
> > functions, where I haven't seen a response to
> > <>
> > confirming if my diagnosis is correct.  Arguably all libm functions
> > with float and double returns should remove excess range and
> > precision, but that's a separate matter.)
> i think excess precision on return is useful feature for x87
> and sad that c11 silently changed the semantics in a backward
> incompatible way (annex f now requires that return removes
> excess precision, it used to require the opposite, so it
> breaks existing code, in musl i'm following c99 for now)

I don't think there was any incompatible change.  I think the most natural 
interpretation was always that everything that converts as if by 
assignment should remove excess precision the same way as assignment does 
(so that's what I implemented for -fexcess-precision=standard) - anything 
else simply cannot be consistently implemented under ABIs that do not 
always pass arguments and return values in a wider format.  DR#290 made 
the possibility of excess precision on return non-normatively explicit; 
the statement in Annex F simply makes the natural interpretation required 
when Annex F is implemented.  As N1382 says, requiring excess precision on 
return is "not tenable from an ABI/API perspective".

libm returns are a separate matter, where removal of excess precision may 
only be required if libm functions must behave as if they are written in C 
(but seems like a good idea anyway for the sake of callers working with 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]