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