[all-commits] [llvm/llvm-project] 7c158e: [flang] add evaluate::IsAllocatableDesignator helper

[jeanPerier via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 7c158e3e554ad7e961480f080571cafab9c5760f
      https://github.com/llvm/llvm-project/commit/7c158e3e554ad7e961480f080571cafab9c5760f
  Author: Jean Perier <jperier at nvidia.com>
  Date:   2022-04-01 (Fri, 01 Apr 2022)

  Changed paths:
    M flang/include/flang/Evaluate/tools.h
    M flang/lib/Evaluate/intrinsics.cpp
    M flang/lib/Evaluate/tools.cpp
    M flang/lib/Semantics/check-call.cpp
    A flang/test/Semantics/allocated.f90
    M flang/test/Semantics/call05.f90

  Log Message:
  -----------
  [flang] add evaluate::IsAllocatableDesignator helper

Previously, some semantic checks that are checking if an entity is an
allocatable were relying on the expression being a designator whose
last symbol has the allocatable attribute.

This is wrong since this was considering substrings and array sections of
allocatables as being allocatable. This is wrong (see NOTE 2 in
Fortran 2018 section 9.5.3.1).

Add evaluate::IsAllocatableDesignator to correctly test this.
Also add some semantic tests for ALLOCATED to test the newly added helper.
Note that ifort and nag are rejecting coindexed-named-object in
ALLOCATED (`allocated(coarray_scalar_alloc[2])`).
I think it is wrong given allocated argument is intent(in) as per
16.2.1 point 3.
So 15.5.2.6 point 4 regarding allocatable dummy is not violated (If the actual
argument is a coindexed object, the dummy argument shall have the INTENT (IN)
attribute.) and I think this is valid. gfortran accepts it.

The need for this helper was exposed in https://reviews.llvm.org/D122779.

Differential Revision: https://reviews.llvm.org/D122899

Co-authored-by: Peixin-Qiao <qiaopeixin at huawei.com>