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

[Peter Klausler via Phabricator via llvm-commits]

klausler 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},
----------------
PeteSteinfeld wrote:
> 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.`.
I could read the standard either way for the case with two NULL()s.  What does XLF do?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88313