On Thu, 20 Mar 2025, Robert Dubner wrote:

> Okay, I managed to figure out a way of getting the debug information back
> into the libgcobol.
> 
> The addition is done by the routine __gg__add_fixed_phase1()
> 
> The run-tiome inputs to that routine should be 1 and 55555555555.
> 
> What's coming through in the patched code are 1 and 55555555554
> 
> I haven't looked at the compile-time code yet.  But I have a nickel that
> says somebody is converting "555.55555555" to floating-point, and getting
> an internal value of 555.555555549999999...., and that's getting truncated
> to the internal value of 55555555554
>
> I haven't checked for sure, but I suppose I've been counting on the
> strfromf128 routines to round sensibly.  I guess if mpfr can handle that
> kind of thing, then we should switch to mpfr.  I am not that familiar with
> mpfr.

Note I have not consistently used real_value_truncate to the target
float128 format - I was debating on whether ->value should be
aribitrary precision or not.  Some real_* functions can take VOIDmode
(no format, whatever that does exactly), but to build a 'tree' we
have to use a type (and I've not consistently performed rounding
or truncation to the format there).

Now a question on COBOL:

77 var8 PIC 999V9(8) COMP-5

what precision/digits does this specify?  When then doing

         add 0.00000001 TO var555 giving var8 rounded

what's the precision/digit specification for the literal floating
point values and how does that or that of var555 or var8
"promote" or "demote" to a common specification for the arithmetic
operation?

Does the COBOL standard expect a literal floating point value to
be represented exactly?  Maybe rounding then only applies at the
"giving var8 rounded" point, forcing the exact value to the
specification of var8?

Richard.

> > -----Original Message-----
> > From: Robert Dubner <rdub...@symas.com>
> > Sent: Thursday, March 20, 2025 17:50
> > To: Jakub Jelinek <ja...@redhat.com>
> > Cc: Richard Biener <rguent...@suse.de>; gcc-patches@gcc.gnu.org
> > Subject: RE: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value
> > from _Float128 to tree
> > 
> > It's time to slow down a bit and give me a chance to catch up.
> > 
> > First, all those tests are not arbitrary.  I was getting the correct
> > answers before, and it was not an insignificant effort to get them
> correct
> > in the first place.
> > 
> > If we don't get the same answers, then something isn't the same as it
> was
> > before.
> > 
> > I need to know what.
> > 
> > First-prime:
> > 
> > Also, keep in mind that this is COBOL, where words don't mean what you
> > think they mean.  Under Rounding, we have
> > 
> > The following forms of rounding are provided (examples presume an
> integer
> > destination):
> > 
> > -AWAY-FROM-ZERO: Rounding is to the nearest value farther from zero.
> > 
> > -NEAREST-AWAY-FROM-ZERO: Rounding is to the nearest value. If two values
> > are equally near, the value farther from zero is selected. This mode has
> > historically been associated with the ROUNDED clause in earlier versions
> > of standard COBOL.
> > 
> > -NEAREST-EVEN: Rounding is to the nearest value. If two values are
> equally
> > near, the value whose rightmost digit is even is selected. This mode is
> > sometimes called "Banker's rounding".
> > 
> > -NEAREST-TOWARD-ZERO: Rounding is to the nearest value. If two values
> are
> > equally near, the value nearer to zero is selected.
> > 
> > -PROHIBITED: No rounding is performed. If the value cannot be
> represented
> > exactly in the desired format, the EC-SIZE-TRUNCATION condition is set
> to
> > exist and the results of the operation are undefined.
> > 
> > -TOWARD-GREATER: Rounding is toward the nearest value whose algebraic
> > value is larger.
> > 
> > -TOWARD-LESSER: Rounding is toward the nearest value whose algebraic
> value
> > is smaller.
> > 
> > -TRUNCATION: Rounding is to the nearest value that is nearer to zero
> than
> > the algebraic value. This mode has historically been associated with the
> > absence of the ROUNDED clause as well as for the formation of
> intermediate
> > results in the prior COBOL standard.
> > 
> > Any of those can be set as the default.
> > 
> > Second, I just tried to debug the way I have been debugging for years --
> > and I can't.
> > 
> > I wanted to check that the attempt to add 0.00000001 to 555.55555555 was
> > actually adding those two numbers.  This wasn't a rounding problem.
> Both
> > of those numbers have eight decimal places.  So, internally, 1 is
> supposed
> > to be added to a 64-bit integer value 55555555555 to get 55555555556
> > 
> > I am suspicious that the 0.00000001 is becoming zero, which would result
> > in the 555.55555555 being unchanged.
> > 
> > To do an initial check of this, I tried to trap at
> __gg__add_fixed_phase1
> > 
> > But libgcobol.so has no debug info.  So, somehow, the way I used to
> cause
> > it to be "-ggdb -O0" has gotten lost.  I need it back.
> > 
> > What I have been doing, lo these many months, is compiling after doing
> > this ../configure
> > 
> > CFLAGS="-ggdb -O0" \
> > CXXFLAGS="-ggdb -O0" \
> > CFLAGS_FOR_BUILD="-ggdb" \
> > CXXFLAGS_FOR_BUILD="-ggdb" \
> > LIBCFLAGS_FOR_BUILD="-ggdb" \
> > LIBCXXFLAGS_FOR_BUILD="-ggdb" \
> > CFLAGS_FOR_TARGET="-ggdb -O0" \
> > CXXFLAGS_FOR_TARGET="-ggdb -O0" \
> > LIBCFLAGS_FOR_TARGET="-ggdb -O0" \
> > LIBCXXFLAGS_FOR_TARGET="-ggdb -O0" \
> > ../configure \
> > --with-pkgversion="$PKGVERSION" \
> > --enable-languages=c,c++,cobol \
> > --prefix=/usr/local/gcobol \
> > --with-gcc-major-version-only \
> > --program-suffix=-$MAJOR_VERSION \
> > --enable-shared \
> > --enable-linker-build-id \
> > --without-included-gettext \
> > --enable-threads=posix \
> > --disable-bootstrap \
> > --enable-clocale=gnu \
> > --enable-libstdcxx-debug \
> > --enable-libstdcxx-time=yes \
> > --with-default-libstdcxx-abi=new \
> > --enable-gnu-unique-object \
> > --disable-vtable-verify \
> > --enable-plugin \
> > --enable-default-pie \
> > --with-system-zlib \
> > --with-target-system-zlib=auto \
> > --disable-werror \
> > --disable-cet \
> >   $arch_options     \
> > --disable-multilib \
> > --without-cuda-driver \
> > --enable-checking \
> > --build=$arch-linux-gnu \
> > --host=$arch-linux-gnu \
> > --target=$arch-linux-gnu \
> > --with-build-config=bootstrap-lto-lean \
> > --enable-link-mutex --without-isl
> > 
> > And, no, I don't know what much of that means.  I cloned it from the
> > Ubuntu "gcc -v" description of their configuration.
> > 
> > But I do know that one of those flag settings used to control the build
> of
> > the library.  But now the library isn't being built with debug_info, and
> I
> > need it to be.
> > 
> > I'll start looking, but any help would be appreciated.
> > 
> > > -----Original Message-----
> > > From: Jakub Jelinek <ja...@redhat.com>
> > > Sent: Thursday, March 20, 2025 17:07
> > > To: Robert Dubner <rdub...@symas.com>
> > > Cc: Richard Biener <rguent...@suse.de>; gcc-patches@gcc.gnu.org
> > > Subject: Re: [PATCH][RFC] [cobol] change
> cbl_field_data_t::etc_t::value
> > > from _Float128 to tree
> > >
> > > On Thu, Mar 20, 2025 at 03:30:30PM -0500, Robert Dubner wrote:
> > > > Let me find one inky-dink example.  Talk amongst yourselves...here
> we
> > > go.
> > > >
> > > >         identification          division.
> > > >         program-id.             prog.
> > > >         data                    division.
> > > >         working-storage         section.
> > > >         77 var8 PIC 999V9(8) COMP-5 .
> > > >         77 var555 PIC 999V99999999 COMP-5 VALUE 555.55555555.
> > > >         procedure               division.
> > > >         move 555.55555555 to var8
> > > >         add 0.00000001 TO var555 giving var8 rounded
> > > >         if var8 not equal to 555.55555556 display var8 " should be
> > > > 555.55555556".
> > > >         end program             prog.
> > > >
> > > > With your patches, the output is
> > > >
> > > >         555.55555555 should be 555.55555556
> > >
> > > Thanks.
> > > Now, the code certainly could try to do the rounding of the last
> digits
> > > based on the remaining digits in the string that are being discarded,
> > > if followed by 0-4, don't change anything, if followed by 6-9,
> increase
> > > last digit, if followed by 5 and any non-zero digit, increase too, if
> > > followed
> > > by 5 and all zeros, round to even.
> > > But I'm afraid it can have double rounding, when round_to_decimal
> rounds
> > > for the precision 33 printing something e.g. with 49999999999999999999
> > at
> > > the end to 500000000000 and this second rounding again.
> > > So I really think we should go to mpfr, I can implement it tomorrow
> > unless
> > > Richi wants to do that.
> > >
> > >   Jakub
> 
> 

-- 
Richard Biener <rguent...@suse.de>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)

Reply via email to