[PATCH V3] New version of proc whole and dependencies

[Jose E. Marchesi]

Hi Chris.

> Ok, here is a summary of what I have done for a test (at end)
>
> On Wed, Jul 15, 2026 at 11:50 AM chris hermansen <clhermansen@gmail.com> wrote:
>>
>> My eagerness has laid me low... see at end.
>>
>> On Wed, Jul 15, 2026 at 1:22 AM Jose E. Marchesi <jemarch@gnu.org> wrote:
>> >
>> >
>> > > Excellent!  I have moved my git-fu from "total loser" to "loser", that's a
>> > > big milestone for me :-)
>> > >
>> > > On Tue, Jul 14, 2026 at 2:32 PM Jose E. Marchesi <jemarch@gnu.org> wrote:
>> > >>
>> > >>
>> > >> Hi Chris.
>> > >>
>> > >> This is looking good! :)
>> > >>
>> > >> We will need some tests added to gcc/gcc/testsuite/algol68/execute, in
>> > >> files like whole-1.a68, whole-2.a68, ...
>> > >>
>> > >> For example:
>> > >>
>> > >>
>> > >> whole-1.a68
>> > >>
>> > >>
>> > >>  if bits_width = 32
>> > >>  then assert(whole(max_int,0) = "4294967296");
>> > >>       ...
>> > >>  elif bits_width = 64
>> > >>  then assert(whole(max_int,0) = "18446744073709551616");
>> > >>       ...
>> > >>  fi
>> > >
>> > > Your numbers above are unsigned 32 and 64 bit.
>> > >
>> > > Ok.  I will also test bits_width = 16 and bits_width = 8.
>> > >
>> > > As well,  in each bits_width interval, I propose to test:
>> > >
>> > > -max_int
>> > > -max_int - 1
>> > > 0 (zero)
>> > > and 1000 random numbers in the range -max_int - 1 .. max_int
>> > > which I will pre-compute in "another programming language".
>> > >
>> > > Of course the long long, long, short and short short versions as well
>> > > (for short short I will test 100 random numbers)
>> > >
>> > > How does this sound?
>> >
>> > Sounds great, thank you.
>> >
>> > I would also make sure to include the particular values for which the RR
>> > implementation produces different strings than printf, due to the
>> > different semantics of MOD.
>>
>> I have come to realize that I cannot generate a list of random
>> constants for testing in a bit size different than is supported.
>>
>> That is, I cannot write tests like
>>
>> if long_bits_width = 128
>> then
>>      assert(whole(long 70633560080410094655970279334248157444,0) =
>> "70633560080410094655970279334248157444")
>>      assert(whole(long -43321681882868515784549936298597932495,0) =
>> "-43321681882868515784549936298597932495")
>>      { etc }
>> fi
>>
>> because the compiler is not going to compile a 128 bit long.
>>
>> So for now, I can check short_short_max_int, short_max_int, max_int,
>> long_max_int and long_long_max_int
>> against the corresponding {xlx_}bit_length, but the random numbers
>> will have to stay within the mins and maxes
>> that are currently supported.
>>
>> As far as I can think, anyway.
>
> I have a series of tests based on {xlx_}bits_width that look like this:
>
>       if short_short_bits_width = 8
>       then
>            assert(whole(-short_short_max_int - short short 1,0) = "-128");
>            assert(whole(short short 0,0) = "0");
>            assert(whole(short short 0,5) = "   +0");
>            assert(whole(short short 0,-5) = "    0");
>            assert(whole(short short 100,5) = " +100");
>            assert(whole(-short short 100,5) = " -100");
>            assert(whole(short short 100,-5) = "  100");
>            assert(whole(-short short 100,-5) = " -100");
>            assert(whole(short short 100,4) = "+100");
>            assert(whole(-short short 100,4) = "-100");
>            assert(whole(short short 100,3) = "***");
>            assert(whole(-short short 100,3) = "***");
>            assert(whole(short_short_max_int,0) = "127")
>       elif short_short_bits_width = 16
>
> You can see in the above that we test {xlx_}max_int and
> -{xlx_}max_int - 1.  Recall that it was the latter that cause the RR
> whole to fail (not match C printf).
>
> We also test with positive width (which requires always printing a sign, even
> for zero, which gets a plus sign) and negative width (which only requires a
> sign for negative numbers).  We check in a width one greater than necessary,
> one equal to the necessary, and one less, which should be filled with the
> error char.
>
> We test {xlx_}bits_width 8, 16, 32, 64 and 128 using the above pattern. Of
> course given the current state of the compiler, things like 128 bit wide
> short short int values are not tested, but the code compiles this way.
>
> Then for testing random values, i have a series of tests that look like this:
>
>       {testing random short short int values between -128 and 127}
>
>       assert(whole(short short 30,0) = "30");
>       assert(whole(-short short 116,0) = "-116");
>       assert(whole(short short 117,0) = "117");
>       assert(whole(short short 44,0) = "44");
>       assert(whole(short short 21,0) = "21");
>
> There are 100 randomly chosen numbers over the smallest..largest
> interval for short short int, short int, int, long int and long long int.
>
> I've run this stand-alone and it reports no assert issues.
>
> So my plan is to put this in the gcc/gcc/testsuite/algol68/execute,
> do a commit and rebase / squash and patch and send the "final"
> patch.
>
> Sound OK?

Sounds great, thanks!