[all-commits] [llvm/llvm-project] e054e0: [flang] Fixed uninitialized std::unique_ptr derefe...

[Slava Zakharin via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e054e0da9fd7055142188036ee713e8c0697324b
      https://github.com/llvm/llvm-project/commit/e054e0da9fd7055142188036ee713e8c0697324b
  Author: Slava Zakharin <szakharin at nvidia.com>
  Date:   2023-01-26 (Thu, 26 Jan 2023)

  Changed paths:
    M flang/lib/Frontend/FrontendActions.cpp

  Log Message:
  -----------
  [flang] Fixed uninitialized std::unique_ptr dereference.

This fixes unittest failures reported in D142279:
  flang-Unit :: Frontend/./FlangFrontendTests/5/7
  flang-Unit :: Frontend/./FlangFrontendTests/6/7


  Commit: 02445263e2f533573a935c1bd502d848bbe6bb27
      https://github.com/llvm/llvm-project/commit/02445263e2f533573a935c1bd502d848bbe6bb27
  Author: Slava Zakharin <szakharin at nvidia.com>
  Date:   2023-01-26 (Thu, 26 Jan 2023)

  Changed paths:
    M flang/lib/Semantics/canonicalize-acc.cpp

  Log Message:
  -----------
  [flang] Fixed restrictions checking for OpenACC loop-associated constructs.

CheckDoConcurrentClauseRestriction and CheckTileClauseRestriction expect
that the construct has associated DoConstruct, while it is not set
when the do-loop has no loop control. The change is to skip the clauses
checks, when the do-loop does not have the loop control.

An alternative fix would be to associate the DoConstruct even when
the do-loop has no loop control and let Check*ClauseRestriction run their
checks, but I am not sure if associating invalid DoConstruct is a good idea.

This fixes failure in Semantics/OpenACC/acc-canonicalization-validity.f90
reported in D142279.

Reviewed By: clementval

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


Compare: https://github.com/llvm/llvm-project/compare/55cf0de35efd...02445263e2f5