[Cfp-interest 2697] Re: Floating point rounding modes

[Hans Boehm]

We did discuss this proposal a couple of weeks ago in WG21/SG6.

The study group appeared unanimous in disliking fesetround(). There was an
advocate for the C23 statically-scoped rounding mode approach, and we may
get a proposal to adapt that for C++.  Information on implementation
progress in C23 would be helpful. As would any additional information in
use cases.

(I would not expect a pragma-based solution to fly in the C++ standard, so
the syntax would have to change. Thus it's hard to discuss details without
an actual proposal.)

Concern was expressed about how rounding-mode-aware math functions would be
implemented, and in how that would be reflected in ABIs. Does this group
have a story about recommended practice here? What does a call to sin()
with a statically specified FE_UPWARD rounding mode get compiled to? Is
there a single sin() function that looks at the dynamic rounding mode? Or
is there a sin_FE_UPWARD() function, or a function with an explicit
rounding mode argument, behind the covers? It seems like we need agreement
among compilers on the same platform.

Pretty much the rest of the committee preferred the simplest possible
library solution, i.e. free functions that operate directly on float and
double, with an explicit rounding mode argument. I plan to write that up. I
would expect such a solution to be C compatible, if there is interest.

Hans


On Mon, Jan 30, 2023 at 2:28 AM Vincent Lefevre <vincent at vinc17.net> wrote:

> On 2023-01-27 09:07:21 -0800, Hans Boehm wrote:
> > AFAICT, a significant problem with the current and proposed facilities is
> > that they are so rarely used that implementations commonly don't pay
> enough
> > attention to them. I think many implementations don't properly handle
> > FENV_ACCESS correctly, so I have relatively little confidence in
> > FENV_ROUND, especially since I think we agree it still doesn't handle
> > constants.
>
> The problem is known in GCC:
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678
> and
>   https://gcc.gnu.org/legacy-ml/gcc-help/2004-05/msg00176.html
> (where a hack to avoid CSE is described).
>
> I think that the main issue is that with the current facility, it is
> generally not possible to know with which rounding mode an operation
> is done, so that the current GCC model used for CSE does not work,
> and there does not seem to be a way to disable FP CSE alone (and even
> CSE alone). I think that even -O0 is not enough, e.g. for constant
> expressions. Anyway, even if FENV_ACCESS could be taken into account,
> the current facility is bad for optimizations.
>
> --
> Vincent Lefčvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230221/825a6a4b/attachment.htm>