On Mon, 24 Jun 2019, Marc Glisse wrote:

> > OK, fair enough.  I just hoped that global
> > 
> > double x = 1.0/3.0;
> > 
> > do not become runtime initializers with -frounding-math ...
> 
> Ah, I wasn't thinking of globals. Ignoring the new pragma fenv_round, which I
> guess could affect this (the C draft isn't very explicit), the program doesn't

I think FENV_ROUND (for C) definitely affects both interpretation of 
constants (if the constant isn't exactly representable in the format in 
which it is evaluated) and the evaluation of operations in initializers 
with static or thread storage duration.  (F.8.2 in the current C2x draft 
says "During translation, constant rounding direction modes (7.6.2) are in 
effect where specified." and F.8.5 says "All computation for 
initialization of objects that have static or thread storage duration is 
done (as if) at translation time.".)

> One issue is that the C pragmas do not let me convey that I am interested in
> dynamic rounding but not exception flags. It is possible to optimize quite a

TS 18661-5 allows e.g. "#pragma STDC FENV_EXCEPT FE_ALL_EXCEPT NO_FLAG" 
or "#pragma STDC FENV_EXCEPT FE_ALL_EXCEPT OPTIONAL_FLAG".  (But it 
doesn't allow for saying you don't care about exceptions to the extent 
that raising spurious exceptions is OK.)

Some parts of 18661-5 are probably substantially more complicated to 
implement than any of the other floating-point pragmas.  I'm not sure if 
there's any implementation experience at all with 18661-5, in any C 
implementation.

(On the other hand, CX_LIMITED_RANGE is probably the easiest of the 
floating-point pragmas to implement, because it has purely local effects - 
you just need two different forms of IR for complex multiplication and 
division, chosen based on whether the pragma is in effect in the current 
scope, and then lower them in two different ways that GCC already 
supports.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Reply via email to