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 <[email protected]>
> > Sent: Thursday, March 20, 2025 17:50
> > To: Jakub Jelinek <[email protected]>
> > Cc: Richard Biener <[email protected]>; [email protected]
> > 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 <[email protected]>
> > > Sent: Thursday, March 20, 2025 17:07
> > > To: Robert Dubner <[email protected]>
> > > Cc: Richard Biener <[email protected]>; [email protected]
> > > 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 <[email protected]>
SUSE Software Solutions Germany GmbH,
Frankenstrasse 146, 90461 Nuernberg, Germany;
GF: Ivo Totev, Andrew McDonald, Werner Knoblich; (HRB 36809, AG Nuernberg)
