[flang-commits] [flang] [flang] Fix for atand(Y, X), and implment atan2d(Y, X) (PR #79002)

via flang-commits flang-commits at lists.llvm.org
Tue Jan 23 09:40:55 PST 2024


================
@@ -333,11 +333,15 @@ static const IntrinsicInterface genericIntrinsicFunction[]{
                 common::Intent::In, {ArgFlag::canBeNull}}},
         DefaultLogical, Rank::elemental, IntrinsicClass::inquiryFunction},
     {"atan", {{"x", SameFloating}}, SameFloating},
-    {"atand", {{"x", SameFloating}}, SameFloating},
     {"atan", {{"y", OperandReal}, {"x", OperandReal}}, OperandReal},
-    {"atand", {{"y", OperandReal}, {"x", OperandReal}}, OperandReal},
+    {"atand",
+        {{"y", SameReal, Rank::scalar, Optionality::required,
+             common::Intent::In},
+            {"x", SameReal, Rank::scalar, Optionality::optional,
+                common::Intent::In}},
+        SameReal, Rank::scalar, IntrinsicClass::inquiryFunction},
----------------
jeanPerier wrote:

For what where these semantics changes required?
This does not looks correct to me. There is a subtle by important difference between the standard writing `ATAND([Y], X)` and `ATAND(Y, X) or ATAND(X)`.

In the former, we would have to treat Y has having the OPTIONAL attribute, and need special handling when the actual argument is a pointer, allocatable or OPTIONAL dummy. See the little `(optional)` that the standard adds for such argument (e.g. STAT in ATOMIC_ADD).

In the later, there is no such semantics, and if Y is syntactically here, it cannot be a disassociated pointer or absent optional.

Thus, I think the new change is not correct.

I would also not update things from  `OperandReal` to `SameReal`, flang is relaxed with regard to the same kind rule and should upcast to the highest precision (because that is what some other compilers do with numerical intrinsics and may be expected). Was there a reason to differ from atan2 behavior here too?

https://github.com/llvm/llvm-project/pull/79002


More information about the flang-commits mailing list