[Bug fortran/96859] Wrong answer with intrinsic merge_bits

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859

--- Comment #10 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Sep 01, 2020 at 03:20:20PM +0000, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96859
> 
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I've read that.  But I think in this case it is an obvious bug (just, what I've
> missed in the patch, there is another copy of the same bug in another routine).
> The
>       /* Clear first bit.  */
>       if (kind == 1 || kind == 4 || kind == 16)
>         {
>           if (buf[0] == '4')
>             buf[0] = '0';
>           else if (buf[0] == '5')
>             buf[0] = '1';
>           else if (buf[0] == '6')
>             buf[0] = '2';
>           else if (buf[0] == '7')
>             buf[0] = '3';
>         }
> part looks correct, for kind 1, 4 and 16 the calculated len times 3 is 1 larger
> than the number of bits it needs, so the above ensures that the first digit is
> 0-3 even if it is 4-7 by subtracting 4.
> But the:
>       /* Clear first two bits.  */
>       else
>         {
>           if (buf[0] == '4' || buf[0] == '6')
>             buf[0] = '0';
>           else if (buf[0] == '5' || buf[0] == '7')
>             buf[0] = '1';
>         }
> which is needed for kind 2 and 8, when he calculated len times 3 is 2 larger
> than the number of bits it needs, is only correct for digits 0-1 an 4-7, for
> which it ensures the digit is 0 if it is even and 1 if it is odd.  But 2 and 3
> are kept as is, while they don't fit into 1 bit.
> 

It is certainly possible I have/had an off-by-one in handwritten
conversions I was doing; in particular, I don't often work with
octal numbers.