[PATCH] D88313: [flang] Failed call to CHECK() for call to ASSOCIATED(NULL())

[Pete Steinfeld via Phabricator via llvm-commits]

PeteSteinfeld added inline comments.


================
Comment at: flang/lib/Evaluate/intrinsics.cpp:286
+        {{"pointer", AnyPointer, Rank::known},
             {"target", Addressable, Rank::known, Optionality::optional}},
         DefaultLogical, Rank::elemental, IntrinsicClass::inquiryFunction},
----------------
klausler wrote:
> PeteSteinfeld wrote:
> > klausler wrote:
> > > Can the optional `TARGET=` argument be `NULL(MOLD=)` or even just `NULL()`?
> > Good question.
> > 
> > My reading of the standard is that `NULL()` should be allowed as the `TARGET`
> > argument of `ASSOCIATED()`.  The note at the bottom of section 16.9.16
> > explicitly mentions `disassociated pointers`.  Also, if we're going to allow
> > `NULL()` as the first argument, it seems like we're implicitly stating that
> > null pointers match all pointer types, and thus we should allow `NULL()` as the
> > second argument to `ASSOCIATED()`.
> > 
> > I wrote some tests and tried them on several compilers.  The only one that
> > seems to agree with my analysis above is IBM.  GNU, pgf90, nagfor, and ifort
> > all give various compile-time errors when using any form of `null()` as the
> > second argument to `ASSOCIATED()`.
> Will you allow `NULL()` as the second (TARGET=) argument here?
Yes.  I added a test for this to resolve89.f90.  I would think that, if the second argument is `NULL()` and the first argument evaluates to `NULL()`, that `ASSOCIATED()` would evaluate to `.TRUE.`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D88313/new/

https://reviews.llvm.org/D88313