diff options
| author | Peter Klausler <pklausler@nvidia.com> | 2022-07-08 14:35:42 -0700 |
|---|---|---|
| committer | Peter Klausler <pklausler@nvidia.com> | 2022-07-13 16:36:25 -0700 |
| commit | 0406c0cda675f3cb7d294a3e65eb4f19c9efe98b (patch) | |
| tree | 6f319abf0fa8d5953c3d3e0747b18f577d8ab3c5 /clang/lib/ExtractAPI/Serialization | |
| parent | e690137dde1c9b037e0c987d393da054d86eeeab (diff) | |
| download | llvm-0406c0cda675f3cb7d294a3e65eb4f19c9efe98b.zip llvm-0406c0cda675f3cb7d294a3e65eb4f19c9efe98b.tar.gz llvm-0406c0cda675f3cb7d294a3e65eb4f19c9efe98b.tar.bz2 | |
[flang] Ensure name resolution visits "=>NULL()" in entity-decl
Most modern Fortran programs declare procedure pointers with a
procedure-declaration-stmt, but it's also possible to declare one
with a type-declaration-stmt with a POINTER attribute. In this
case, e.g. "real, external, pointer :: p => null()" the initializer
is required to be a null-init. The parse tree traversal in name
resolution would visit the null-init if the symbol were an object
pointer only, leading to a crash in the case of a procedure pointer.
That explanation of the bug is longer than the fix. In short,
ensure that a null-init in an entity-decl is visited for both
species of pointers.
Differential Revision: https://reviews.llvm.org/D129676
Diffstat (limited to 'clang/lib/ExtractAPI/Serialization')
0 files changed, 0 insertions, 0 deletions