As Fortran 2018 16.9.169, the argument of selected_int_kind is integer
scalar, and result is default integer scalar. The constant expression in
this intrinsic has been supported by folding the constant expression.
This supports lowering and runtime for variables in this intrinsic.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Trying to fix windows bot fail by adding #ifdef __SIZEOF_INT128__ in flang/lib/Optimizer/Builder/Runtime/Numeric.cpp.
flang/lib/Optimizer/Builder/Runtime/Numeric.cpp | ||
---|---|---|
385 | To workaround the fact that the host may not support in128 but the target might, the int128 runtime interface are usually manually defined here, see ForcedRRSpacing16 for example (with floating point instead of integers). | |
flang/runtime/numeric.cpp | ||
146 | The result type could also be CppTypeFor<TypeCategory::Integer, 4> here regardless of T. | |
147 | Why are you handling negative arguments as if they were positive ? I am not seeing a special case for negative R in 16.9.169. |
flang/lib/Optimizer/Builder/Runtime/Numeric.cpp | ||
---|---|---|
385 | Thanks for the direction. Fixed. | |
flang/runtime/numeric.cpp | ||
146 | Right. This as one typo. | |
147 | This is to compute the abs of x. I tried std::abs, but it does work for 128 bit. I followed the classic-flang: |
flang/runtime/numeric.cpp | ||
---|---|---|
147 | If I am following the classic-flang correctly, the abs call is quite different, it is made on the descriptor kind code for some reason specific to classic-flang format, not the "x" value itself. |
flang/unittests/Runtime/Numeric.cpp | ||
---|---|---|
124 | print *, selected_int_kind(-10) end gfortran, nvfortran, ifort all return 1 here, I think the abs is wrong. |
Thanks @jeanPerier for the correction.
flang/unittests/Runtime/Numeric.cpp | ||
---|---|---|
124 | You are right. According to the standard, the value is in the range −pow(10, R) < n < pow(10, R) (I don't know how to type it here. In Fortran 2018 16.9.169), where R is the input argument. When R is negative, pow(10, R) is always less than 1. So, the result is 1. |
Update the approach to follow the style of SELECTED_REAL_KIND as @jeanPerier suggested.
flang/lib/Lower/IntrinsicCall.cpp | ||
---|---|---|
926 | I have a couple of small questions around here. Does the string of the argument have to be the dummy argument name as specified in the spec? If so, in my draft of Fortran 2018 this is called r instead of scalar. Also, why passing the argument asAddr, could it be passed asValue instead? I imagine that would require converting the value into some specific integer type before passing it to the runtime function. Do we really expect a user to pass an integer so large that forces us to cast the address to the proper integer type. |
flang/lib/Lower/IntrinsicCall.cpp | ||
---|---|---|
926 |
I don't think the string must be totally same as that in the standard. Usually it's better to keep the same since the argument name in the standard means something. scalar has better meaning than r, so I use it.
This intrinsic is not performance-sensitive. It is recommended to use the current approach in https://reviews.llvm.org/D130183#3667603. |
flang/lib/Lower/IntrinsicCall.cpp | ||
---|---|---|
926 | Thanks for the clarifications! |
I have a couple of small questions around here.
Does the string of the argument have to be the dummy argument name as specified in the spec? If so, in my draft of Fortran 2018 this is called r instead of scalar.
Also, why passing the argument asAddr, could it be passed asValue instead? I imagine that would require converting the value into some specific integer type before passing it to the runtime function. Do we really expect a user to pass an integer so large that forces us to cast the address to the proper integer type.