[PATCH V3] New version of proc whole and dependencies

[chris hermansen]

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?


-- 
Chris Hermansen · clhermansen "at" gmail "dot" com

C'est ma façon de parler.