https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66311
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org,
| |jakub at redhat dot com
--- Comment #6 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Definitely a middle-end issue. We get it right on the front-end, the variable
initialization gets screwed when translated later. Reduced testcase:
$ cat a.f90
program test
integer(kind=16) :: z = 18446744073709551614_16
print *, z
end
$ ./usr/local/bin/gfortran -fdump-parse-tree -fdump-tree-original a.f90 &&
./a.out
-2
The "parse tree" clearly shows that z has value of 18446744073709551614_16. But
in the a.f90.003t.original, we get the wrong initialization:
static integer(kind=16) z = -2;
I tracked the issue to the two calls to wi::from_mpz() and wide_int_to_tree()
in gcc/fortran/trans-const.c:gfc_conv_mpz_to_tree(). There the mpz value (which
is correct) in translated into:
wide_int_storage = {
val = ([0] = -2, [1] = 0, [2] = 56)
len = 1
precision = 128
}
which appears to be where the -2 comes from. Probably not seen outside Fortran
because people don't use this conversion routine in C (because there is not way
to input literal __int128 values in C).
Can someone familiar with wide-int look into it?
