[Bug c/113455] New: ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[Bug c/113455] New: ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[newbie-02 at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

            Bug ID: 113455
           Summary: ROUNDING: IEEE Standard: Missing decimal rounding mode
                    'nearest, ties away from zero' for decimalxxx
                    datatypes.
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: newbie-02 at gmx dot de
  Target Milestone: ---

hi @all,  

most likely 'me bad', but searched too long and need professional help.  

Short - just need a tip:   
A.) me blind, 'ties away' is available,  
in that case how to activate? or  
B.) no hope, 'ties away' is NOT available,  
in that case evtl. 'why?', and if planned for the future?  
Or doe's someone know a workaround?  

what I'd like to have:  
'= 8.000000000000001DD + 0.5E-15DD' -> 8.000000000000002E+00  
'= 8.000000000000002DD + 0.5E-15DD' -> 8.000000000000003E+00  
not by 'round up', but by 'round nearest, ties away from zero'.  

what I get instead:  
'= 8.000000000000001DD + 0.5E-15DD' -> 8.000000000000002E+00  
'= 8.000000000000002DD + 0.5E-15DD' -> 8.00000000000000**2**E+00  
the second calculation suffers from 'ties to even' rounding mode.  

'The standard' IEEE 754 requires a decimal rounding mode  
'nearest, ties away from zero' since 2008, see  
http://www.dsc.ufcg.edu.br/~cnum/modulos/Modulo2/IEEE754_2008.pdf  
there '4.3.3 Rounding attribute requirements'.  

I **am** aware that gcc / glibc don't claim full standard  
compatibility for 'decimals', but consider the rounding mode  
one of the most important advantages.  

I **am** aware that 'ties away' is in effect for 'round'  
operations. But couldn't find how to activate for the implicit  
rounding in calculations.  

I **am** aware that there are near religious fanatic discussions  
about which rounding is 'better', I don't want to start similar,  
just get qualified info. Posted here despite I know it's not a  
user support forum, think the info is relevant for others too.  

In case of relevant: Intel, Linux, gcc.

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

--- Comment #1 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
The decimal rounding mode is set with fe_dec_setround.  libdfp provides that
function and an fenv.h wrapper with constant definitions including
FE_DEC_TONEARESTFROMZERO.  Providing that library is outside the scope of GCC;
see https://sourceware.org/pipermail/libc-alpha/2019-September/106579.html for
a discussion of considerations for any integration of such support directly in
glibc (which would certainly be a lot of work).

libdfp is at https://github.com/libdfp/libdfp but doesn't have that much
activity.

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[newbie-02 at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

--- Comment #2 from newbie-02 <newbie-02 at gmx dot de> ---
(In reply to Joseph S. Myers from comment #1)  

hello and thank you very much!!,  
> The decimal rounding mode is set with fe_dec_setround.  

found in my directories that I already had experimented with that,  
a distinct include of libdfp/dfp/fenv.h made progress,  
but also with `fe_dec_setround(FE_DEC_TONEARESTFROMZERO)`,  
successful as `if ((r = fe_dec_getround()) == -1)` produces '4',  
the implicit rounding for the addition stays with 'to even'.  

:-(    will continue research tomorrow.  

the strategic discussion is above my experience, from POV  
wanting an alternative for people fed up with bin-FP imprecision  
it would be:  
- good if it works,  
- is easy to find,  
- wouldn't require much 'info gathering' and configuration effort,

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

--- Comment #3 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
If you're linking with the version of the DFP arithmetic functions
(__bid_adddd3 etc.) in libdfp rather than the libgcc version - check the link
order carefully to make sure the right version is linked in - and they're not
respecting the rounding mode, that would be a libdfp issue, not a GCC one. If
you're doing arithmetic with constant operands, it might be folded at compile
time; make sure you're using -frounding-math to avoid that.

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[newbie-02 at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

--- Comment #4 from newbie-02 <newbie-02 at gmx dot de> ---
(In reply to Joseph S. Myers from comment #3)  

:-)  - thank you, you are my hero,  

> If you're doing arithmetic with constant operands, it might be
> folded at compile time; make sure you're using -frounding-math to avoid that.

Think that was it, using volatile variables makes a difference.  
( I hate! cheating compilers and I hate me again and again seeking for that
same trap ... sorry )   

reg. 'availability': think that 'modul' / each 'modul' which provides the
datatype should also provide the rounding mode ... good logic? Effort to
implement is once, users seeking would be over and over again ... endless ...
not good.

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[newbie-02 at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

--- Comment #5 from newbie-02 <newbie-02 at gmx dot de> ---
> If you're doing arithmetic with constant operands, it might be folded at compile time; make sure you're using -frounding-math to avoid that.  

hmmmmm... that issue is left. From your comment I was in hope the following
program would work:  
````  
// compile with 'gcc -std=gnu99 -I/usr/local/include/dfp -frounding-math -o
round_constants_ties_away round_constants_ties_away.c -ldfp', 

#define __STDC_WANT_DEC_FP__                                                   
        // req. for decimal rounding mode, 
#include <fenv.h>                                                              
        // req. for decimal rounding mode, 
#include <stdio.h>                                                             
        // reg. e.g. printf and perror, 

int main( int argc, char *argv[ ] ) { 
        fe_dec_setround( 4 ); 
        printf( "fe_dec_rounding_mode : %d \n", fe_dec_getround() ); 
        volatile _Decimal64 x1DD = 8.0000000000000015DD; 
        volatile _Decimal64 x2DD = 8.0000000000000025DD; 

        printf( "Read in of 8.0000000000000015 produced : %.17DE \n", x1DD ); 
        printf( "Read in of 8.0000000000000025 produced : %.17DE \n", x2DD ); 
        printf( "In operation it works                  : %.17DE \n", x2DD +
5E-16DD ); 

        return( 0 ); 
} 
````  

It works, but doesn't round the constants as wanted:  

````  
└─$ ./round_constants_ties_away                                                 
fe_dec_rounding_mode : 4 
Read in of 8.0000000000000015 produced : 8.00000000000000200E+00 
Read in of 8.0000000000000025 produced : 8.00000000000000200E+00 
In operation it works                  : 8.00000000000000300E+00 
````

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[jsm28 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

--- Comment #6 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
-frounding-math is only relevant for arithmetic that occurs as-if at runtime in
the abstract machine. Conversion of constants to their type (or a type with
excess range and precision as indicated by DEC_EVAL_METHOD, but (a) that
doesn't apply here and (b) none of the excess precision support in GCC is
hooked up for decimal floating point, I think) occurs at translation time, not
at runtime, so is never affected by -frounding-math or fe_dec_setround (and GCC
doesn't implement the FENV_DEC_ROUND pragma to set a constant rounding mode in
a particular scope).

[Bug c/113455] ROUNDING: IEEE Standard: Missing decimal rounding mode 'nearest, ties away from zero' for decimalxxx datatypes.

[newbie-02 at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113455

--- Comment #7 from newbie-02 <newbie-02 at gmx dot de> ---

> (and GCC doesn't implement the FENV_DEC_ROUND pragma to set a constant rounding mode in a particular scope)  

here we are leaving my level of knowledge about internals.  

Let me formulate from a user / programmers perspective:  
Wanted is 'decimal compatible math'. Which is to some degree  
announced and partly fulfilled with _Decimalxxx datatypes.  

Shortcomings are: 
- requires libdfp ( hard to find and tricky to use ), or  
other library.  
- even with that there are situations where the rounding  
mode isn't respected, 
thus no system of reliable human compatible math.  

Could and should - IMHO - be improved by implementing  
something in gcc which accounts users wish 'ties away'  
in all situations. Can't say if that is a 'pragma' or  
what else.  

The essential point is to offer a well-rounded system /  
environment that relieves programmers and users from  
being constantly surprised by deviations. And thus set's  
them free from always and anytime having to check for it.  

Too big a wish?  

( code - compiler - libraries - math shouldn't play  
Larry Laffer )