------- 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
