https://bugs.llvm.org/show_bug.cgi?id=41755
Andrey Churbanov <andrey.churba...@intel.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |k...@ca.ibm.com
Resolution|--- |FIXED
--- Comment #4 from Andrey Churbanov <andrey.churba...@intel.com> ---
I added Kelvin to CC list just in case, as a Fortran expert.
I am sorry, I could be too rigorous in my initial comment without
enough details, as I referred to the Fortran 2008 standard
(ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf).
Indeed, for the F03, things are not so clear, because it only states
that the boz-literal-constant should behave in our case (given that
we've fixed non-standard assignment) as
INT(INT(0x80000000, kind=16), kind=4),
and I failed to find what should happen during conversion of
128-bit value into 32-bit value in the F03 standard.
> 2. 0x80000000 = 2,147,483,648. This cannot be represented by a signed 4-byte
> integer; it requires an unsigned 4-byte integer.
That sounds a bit ambiguous to me. I'd say that definitely
0x80000000 = 2147483648_16
given gfortran supports 128-byte integers. And then
2147483648_16 = -2147483648_4.
Which is perfectly valid 32-bit integer. And that is what gfortran does with
-fno-range-check flag. I agree that possibly gfortran has the right to treat
the integer conversion the way it does (C-style, as opposed to Fortran bit
model), and complain on integer overflow. But the F03 does not require it to
behave this way, as there are no details on what the integer conversion should
do. According to bit model (section 13.3. of F03) our code looks fine.
And I don't think we should treat F08 to be in contradiction with F03 here. I'd
rather treat F08 as a clarification of F03, in which case again gfortan behaves
wrong by default.
> c). Finally, even if the code is changed to be standard-conforming, its
> extensive use of digit-strings as kind type parameters makes it
> non-portable...
We try to not use digit strings as kinds, so the code still looks pretty
portable (we use c_int and propagate it to all integer kinds of default size).
If some implementation only supports 16-bit integers, than that can be a
problem. But as Johnny noted, here we follow OpenMP specification which
hardcoded the value in the text.
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
