RE: [PATCH] Add generic HAVE_RM_CTX implementation

["Wilco" <wdijkstr at arm dot com>]

Hi,

Thanks. Yes my change does correctly keep the exceptions using
feupdateenv, and unconditionally restores execptions using fesetenv 
in the noex variant. The interface is indeed confusing, especially
since there was only one feholdexcept_setround_ctx function which
had to support both cases.

I think it should be possible to significantly reduce the complexity
by removing the _f and _l variants (AFAIK all FPUs have only one set
of FP status flags irrespectively of precision), and conditionally 
compile the generic libc implementations. fenv/math_private.h can then 
implement the generic functions directly (and set a define indicating 
it did so to stop the generic code being compiled). That means targets 
must override all libc functions in one go, but that seems to be the 
only useful case.

By extending the HAVE_RM_CTX functions slightly all the non-CTX libc
functions could be removed altogether. There appear to be 3 use modes:

1. Exceptions must be merged (normal ctx version)
2. Exceptions must be discarded (no-ex ctx version)
3. Exceptions must be cleared within a scope so they can be tested, 
   and then discarded

I'm not sure what the case is for "exceptions may be merged" or allowing
individual exceptions to be merged as well as discarded (this becomes
complex and you likely lose the optimizations that case 1 or 2 allow).

But yes, defining the right set of functionality requires a detailed 
investigation into the remaining fenv uses in the math libs.

Wilco

> Joseph wrote:
> On Tue, 20 May 2014, Wilco wrote:
> 
> > Ping
> >
> > As for an additional reviewer, Joseph could you please have a look?
> 
> OK, although my comments in
> <https://sourceware.org/ml/libc-alpha/2014-03/msg00267.html> apply.  All
> these macros / functions need careful review and refactoring; the present
> set makes it far from obvious that required invariants hold such as "if
> the function used at the start of a fixed-rounding-mode block has the
> feholdexcept effects of disabling traps or clearing existing set
> exceptions, then the function at the end of that block must have the
> reverse effects of restoring previously enabled traps and set exceptions
> (possibly with new exceptions merged in, depending on the semantics of the
> function at the end)".  I suspect things might be clearer if the functions
> / macros had extra arguments for such things as "clearing exceptions
> permitted / required / not permitted" or "new exceptions must be merged
> into the previous set / may be merged in / must be discarded", rather than
> having so many macros with similar names but different semantics.
> 
> --
> Joseph S. Myers
> joseph@codesourcery.com