[llvm-bugs] [Bug 41755] omp_sched_monotonic declaration causes error when building the compiler

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=41755

Andrey Churbanov <andrey.churbanov at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kli at ca.ibm.com
         Resolution|---                         |FIXED

--- Comment #4 from Andrey Churbanov <andrey.churbanov at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190513/720c0c62/attachment-0001.html>