------- Comment #6 from sylvain dot pion at sophia dot inria dot fr 2008-08-18 16:12 ------- Maybe my comment is going to be out of scope, but the question is also to know what the "primary question" is here, that is, what usage is supposed to be supported by -frounding-math.
g++ currently accepts code like the following (in non-pedantic mode) : template <int i> struct A {}; A<(int) (1.5-2.0)> a; I am not sure it would be wise to have -frounding-math break this (I understand that this would be a consequence of one of Jakub's proposals). There are users who would like to see constant propagation of floats, obviously, even with -frounding-math. (see also C++0x's constexpr which requires this ability, I think). And there are users who would like to have constant propagation aware of the rounding mode (either deferring the computation at runtime, and/or have a way to tell the compiler which rounding mode to use at compile-time). It's also related to the FENV_ACCESS pragma. The current behavior of -frounding-math which keeps on propagating floats constants is not nice for interval arithmetic code (the main user of -frounding-math I guess?): you need to protect against the compiler in ways which affects performance (and code clarity like introducing volatiles or other workarounds in odd places...). The fact that -frounding-math affects the whole translation unit is also problematic. Usually, it's only in very particular places that you need to tell the compiler that a block of code needs such an attention. Ideally, for me, one should have the option to tell the compiler that a block of code (e.g. using the new option attributes, or a pragma a la FENV_ACCESS), or maybe even a single operation, depends on a non-default rounding-mode, hence stopping inexact constant propagation and other transformations. As a bonus, it would be great to also have a way to tell the compiler that the rounding-mode to be used is known at compile-time. One could add another option e.g. -frounding-math-at-runtime to distinguish the two behaviors mentioned by Jakub, but IMO this would not be helpful for the users who want to mix the 2 features in the same translation unit. My 2 cents. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36912