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
