[all-commits] [llvm/llvm-project] 5a9497: [flang] Allow large and erroneous ac-implied-do's

[Pete Steinfeld via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 5a9497d6890145da74325dfcb032ad2963b5da3f
      https://github.com/llvm/llvm-project/commit/5a9497d6890145da74325dfcb032ad2963b5da3f
  Author: Peter Steinfeld <psteinfeld at nvidia.com>
  Date:   2021-05-11 (Tue, 11 May 2021)

  Changed paths:
    M flang/include/flang/Evaluate/shape.h
    M flang/include/flang/Parser/message.h
    M flang/lib/Parser/message.cpp
    M flang/test/Semantics/allocate02.f90
    A flang/test/Semantics/array-constr-big.f90
    M flang/test/Semantics/io06.f90
    M flang/test/Semantics/omp-atomic.f90
    M flang/test/Semantics/omp-clause-validity01.f90
    M flang/test/Semantics/omp-flush01.f90
    M flang/test/Semantics/resolve70.f90

  Log Message:
  -----------
  [flang] Allow large and erroneous ac-implied-do's

We sometimes unroll an ac-implied-do of an array constructor into a flat list
of values.  We then re-analyze the array constructor that contains the
resulting list of expressions.  Such a list may or may not contain errors.

But when processing an array constructor with an unrolled ac-implied-do, the
compiler was building an expression to represent the extent of the resulting
array constructor containing the list of values.  The number of operands
in this extent expression was based on the number of elements in the
unrolled list of values.  For very large lists, this created an
expression so large that it could not be evaluated by the compiler
without overflowing the stack.

I fixed this by continuously folding the extent expression as each operand is
added to it.  I added the test .../flang/test/Semantics/array-constr-big.f90
that will cause the compiler to seg fault without this change.

Also, when the unrolled ac-implied-do expression contains errors, we were
repeating the same error message referencing the same source line for every
instance of the erroneous expression in the unrolled list.  This potentially
resulted in a very long list of messages for a single error in the source code.

I fixed this by comparing the message being emitted to the previously emitted
message.  If they are the same, I do not emit the message.  This change is also
tested by the new test array-constr-big.f90.

Several of the existing tests had duplicate error messages for the same source
line, and this change caused differences in their output.  So I adjusted the
tests to match the new message emitting behavior.

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