[Cfp-interest] implementing tgmath for constant rounding modes

Jim Thomas jaswthomas at sbcglobal.net
Wed Jun 13 14:39:36 PDT 2012


On Jun 7, 2012, at 12:48 PM, Fred J. Tydeman wrote:

> On Sat, 2 Jun 2012 08:22:55 -0700 Jim Thomas wrote:
>> 
>> At our last teleconference, Fred asked about how <tgmath.h> could be written to work correctly
>> with the pragma that switch between constant and dynamic rounding modes. 
>> 
>> <tgmath.h> aside, the math functions that can be affected by constant rounding modes must be 
>> sensitive to whether a constant rounding mode is in effect. 
>> Take the example of cbrt. <math.h> could have
>> 
>> #define cbrt(x) __roundwise_cbrt(x)
>> 
>> Then the translator would have to keep track of whether a constant rounding mode is in effect at 
>> each call site for __roundwise_cbrt and, if so, what the rounding direction is. 
>> 
>> Compilers already keep track of the state of other FP pragmas, which have the same sort of 
>> scoping as the constant rounding mode pragmas.
> 
> As far as I recall, neither gcc nor clang keep track of FENV_ACCESS.  So, I am not
> sure how easy it is to track state of FP pragmas.
> 
> So, in effect, __roundwise_cbrt becomes a special keyword/token/symbol to the compiler.
> And the same for all the other math functions (that is a lot of names to treat special).

Think of it as just one prefix. The compiler can treat any function call with the prefix the same way.

> 
> So, if another compiler did it as
>  #define cbrt(x) __RoundWise_cbrt(x)
> it will be hard for 3rd party library/header implementors
> (such as P.J.Plauger's Dinkumware) to create a header that 
> works with all compilers.

For implementations using HW dynamic rounding modes, the library vendor doesn't have to do anything special because the compiler will (presumably) be generating code to manipulate the dynamic rounding mode to get the required effect.

For implementations with direct HW support for static rounding modes, the library vendor might want to provide a set of functions for each rounding direction. Or, for the functions that are not required to be correctly rounded, it might provide just one version that produces equivalent results for all rounding modes.

The implementation will need to provide headers and/or tables that map the names the compiler uses to the names the library vendor provides.

-Jim

> 
> Would it be better to add just one new attribute, eg,
>  #define cbrt(x) [[ROUNDWISE]] cbrt(x)
> that would be the same for all compilers?


> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> tydeman at tybor.com      Testing, numerics, programming
> +1 (775) 358-9748      Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com
> Savers sleep well, investors eat well, spenders work forever.
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest




More information about the Cfp-interest mailing list