On Mon, 24 Mar 2025 22:55:44 +0100
Jakub Jelinek <ja...@redhat.com> wrote:
> > When cbl_field_t::data::value_of returned _Float128, that line
> > compared a _Float128 to its value as a size_t. If the number was
> > negative, had a fractional component, or was too large, the test
> > failed.
> >
> > Now cbl_field_t::data::value_of returns a tree. Steps:
> >
> > 1. produce HOST_WIDE_INT vii from the tree
> > 2. set REAL_VALUE_TYPE vi from vii
> > 3. use real_identical to compare vi to the original
> >
> > The comment for real_identical says it's a bitwise comparison.
> > That's not the same as saying the floating point value can be
> > represented exactly as a size_t.
>
> It isn't 100% the same, but the original doesn't make much sense as
> well, because size_t is the host size type. E.g. if cobol1 is native
> x86_64-linux compiler, size_t will be 64-bit unsigned type, if cobol1
> is i686-linux -> x86_64-linux cross-compiler, size_t will be 32-bit
> unsigned type. We certainly don't want the two to behave differently.
I accept that cross-compilation should be supported as a matter of
policy. You are going to a lot of effort to support
cross-compilation for the COBOL front end. That's work we didn't know
how to do, and are grateful for, even if it makes our lives more
complicated. After all, generality is always more complicated.
> But what exactly the code wants to do is unclear.
(I'm sure that's true. In my defense, the nonterminal is named
"count", and the comment is
// verify not floating point with nonzero fraction
but I admit that's not a lot to go on.)
Let me clarify. :-)
What we're dealing with here is an array subscript. When the constant
compile-time expression is parsed, we don't know how it will be used;
we find out only when it's used as a subscript. As an array subscript,
it can't be negative, fractional, or larger than the target's address
space.
In fact, we shouldn't use floating point for numeric literals. We
grabbed _Float128 because it was available and served our purpose. Per
the ISO specification, though, numeric literals are not floating point.
They are fixed-point.
Given considerations like -0.0 and infinities and NaNs, perhaps we're
better off switching to FIXED_POINT_TYPE, where they don't apply.
If we just check for a positive integral value not too big, that should
suffice for now. Once we switch to fixed point, it will be correct.
How does that sound?
--jkl
