[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:
> > PeteSteinfeld wrote:
> > > klausler wrote:
> > > > 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?
> > > xlf is the only compiler I can find that does not have a fatal error when evaluating `associated(null(), null())`.  It gives the warning:
> > > ```
> > > "test.f90", line 2.7: 1516-303 (W) The pointer and target specified for the ASSOCIATED intrinsic are not type compatible or have mismatching type parameters or rank.  The value of ASSOCIATED will be FALSE.
> > > ```
> > > As the message says, it evaluates the call to `associated()` to false.
> > `nagfor` compiles without warnings and also evaluates to false.
> Ok, so there's good precedent for `.false.`.  Can you fold `associated(null(),null())` to `.false.` with a warning?
I'll look into folding.  There's also the case of folding `associated(null())`.  Note that `nagfor` is the only compiler that compiles this without error.  As expected, it evaluates it to false.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88313