[Bug fortran/66311] [5/6 Regression] Problems with some integer(16) values

["rsandifo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #16 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #14)
> (In reply to rsandifo@gcc.gnu.org from comment #12)
> > Created attachment 36128 [details]
> > Alternative patch
> > 
> > Here's an alternative patch. I haven't yet tested it beyond
> > an expanded version of the testcase, but I think it's easier
> > to follow if we separate the "val != valres" and "need an extra
> > zero block" logic.
> 
> Looks cleaner indeed. :-)
> I'm still worried by the case where x is negative and fits in wide_int, but
> its absolute value doesn't.
> It's somehow the same as this case, except that the boundary is at the size
> of wide_int (whatever it is) instead of 64 bits (the size of HOST_WIDE_INT)
> in this case.
> Not sure it matters.

Well, in a sense there's no such wide_int, since wide_ints don't have
an inherent sign.  If a wide_int has precision N, the absolute value
of the minimum signed value is 1<<(N-1).  We'd read that in the same
way as we'd read an unsigned N-bit integer with value 1<<(N-1),
so the value would fit at that stage.  If the mpz is negative we then
negate the wide_int, which for the minimum signed value is a no-op.
We'd end up with an N-bit integer in which only bit N-1 is set.

The problem in the testcase is more to do with the decision that,
if an N-bit wide_int is represented with M<N bits, the other N-M
bits are implicitly sign extensions of bit M-1.  That's a pretty
arbitrary choice.  If we'd decided that the other bits were
implicitly zero then no patch would be needed.  (But of course
we'd then have had to write the other wide_int code differently,
and would have a less efficient representation of "negative"
(or large positive) numbers.)