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. > -----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
