Re: mapping 754R to specific languages

[Guillaume Melquiond <guillaume.melquiond@xxxxxxxxxxx>]

Le lundi 30 juillet 2007 à 09:07 +0100, Nick Maclaren a écrit :

> > I can't speak for Fortran; but for C++ at least, I don't see anything in
> > the 754R+reproducibility draft that goes against the "basic concepts" of
> > the language (scopes, lookup, ODR, object lifetime, types, control flow,
> > and so on).
>
> Try initialization (3.6.2, basic.start.init, 6.7, stmt.decl), for a
> start.  Actually, destructors are worse, but not in C++03 - it is
> the planned introduction of threading and garbage collection in C++0X
> that makes them such a nightmare.
>
> Indeed, a general principle is that you can't allow floating-point
> operations inside a destructor that might be called from a garbage
> collector, if you want both IEEE 754 flags and reproducibility.
> That is one of the many reasons that the IEEE 754 flag model always
> was a Bad Idea - it was 1960s thinking, standardised in the 1980s.

You seem to assume that the 754R draft requires the status flag to be
global to all floating-point operations. As much as I read the section
on "default exception handling", I don't see any such requirement. Quite
the contrary, the draft reads "when flags have scope greater than within
an invoked function, whether and when an asynchronous event, such as a
raising or lowering it in another thread or signal handler, affects the
flag tested within that invoked function". That would solve your issues
both with destructors called at random and concurrent threads, as long
as the language standard decides to do so.

And even if the C++ standard were to decide (or not) that status flags
are global to all the floating-point operations of a thread, I still
don't see any problem. In fact, it's already bad practice to let an
exception fly out of a destructor (because it terminates the program
when unwinding). The C++ standard could well add that it is "undefined
behavior" if a destructor called from a garbage collector does not
restore the floating-point status flags on exit.

As far as I know, the 754R draft does not require a user to be able to
perform floating-point computations in every single point of a program.
If floating-point operations happen to be unsafe when used in a
destructor, is that in any way incompatible with the 754R draft?

So I'm still convinced it can be done.

Best regards,

Guillaume