> -----Original Message-----
> From: Richard Biener <rguent...@suse.de>
> Sent: Friday, March 21, 2025 03:48
> To: Robert Dubner <rdub...@symas.com>
> Cc: Jakub Jelinek <ja...@redhat.com>; gcc-patches@gcc.gnu.org
> Subject: RE: [PATCH][RFC] [cobol] change cbl_field_data_t::etc_t::value
> from _Float128 to tree
>
> 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?
>
I neglected to address this in Part 1 of my response.
Yes, the ROUNDED phrase of the ADD statement specifies that the result of
the operation gets ROUNDED to whatever VAR555 precision VAR555 has. The
meaning of ROUNDED is as described below from my earlier message.
That's handled by assignment logic, found elsewhere, and has nothing to do
with the issues of the front end creating literals and establishing
initial values of variables, which is what all these messages are dealing
with.
> 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)
