<div dir="ltr">We did discuss this proposal a couple of weeks ago in WG21/SG6.<div><br></div><div>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. </div><div><br></div><div>(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.)<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Hans<br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 30, 2023 at 2:28 AM Vincent Lefevre <<a href="mailto:vincent@vinc17.net" target="_blank">vincent@vinc17.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2023-01-27 09:07:21 -0800, Hans Boehm wrote:<br>
> AFAICT, a significant problem with the current and proposed facilities is<br>
> that they are so rarely used that implementations commonly don't pay enough<br>
> attention to them. I think many implementations don't properly handle<br>
> FENV_ACCESS correctly, so I have relatively little confidence in<br>
> FENV_ROUND, especially since I think we agree it still doesn't handle<br>
> constants.<br>
<br>
The problem is known in GCC:<br>
  <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678" rel="noreferrer" target="_blank">https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678</a><br>
and<br>
  <a href="https://gcc.gnu.org/legacy-ml/gcc-help/2004-05/msg00176.html" rel="noreferrer" target="_blank">https://gcc.gnu.org/legacy-ml/gcc-help/2004-05/msg00176.html</a><br>
(where a hack to avoid CSE is described).<br>
<br>
I think that the main issue is that with the current facility, it is<br>
generally not possible to know with which rounding mode an operation<br>
is done, so that the current GCC model used for CSE does not work,<br>
and there does not seem to be a way to disable FP CSE alone (and even<br>
CSE alone). I think that even -O0 is not enough, e.g. for constant<br>
expressions. Anyway, even if FENV_ACCESS could be taken into account,<br>
the current facility is bad for optimizations.<br>
<br>
-- <br>
Vincent Lefčvre <<a href="mailto:vincent@vinc17.net" target="_blank">vincent@vinc17.net</a>> - Web: <<a href="https://www.vinc17.net/" rel="noreferrer" target="_blank">https://www.vinc17.net/</a>><br>
100% accessible validated (X)HTML - Blog: <<a href="https://www.vinc17.net/blog/" rel="noreferrer" target="_blank">https://www.vinc17.net/blog/</a>><br>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)<br>
</blockquote></div>