diff options
| author | Peter Steinfeld <psteinfeld@nvidia.com> | 2021-03-08 17:17:14 -0800 |
|---|---|---|
| committer | Peter Steinfeld <psteinfeld@nvidia.com> | 2021-03-09 12:35:32 -0800 |
| commit | 63200a058e6d5f275204154a16723e8f169a317a (patch) | |
| tree | e2490ff8d3ce557a994d13abfa3bdf6b3c9edd27 /llvm/lib/ProfileData/Coverage/CoverageMapping.cpp | |
| parent | 5a3bb7dde32a0545cf6f2954ea09cf71af9c0e38 (diff) | |
| download | llvm-63200a058e6d5f275204154a16723e8f169a317a.zip llvm-63200a058e6d5f275204154a16723e8f169a317a.tar.gz llvm-63200a058e6d5f275204154a16723e8f169a317a.tar.bz2 | |
[flang] Sort symbols by creation order
We have a "<" operator defined on the type semantics::Symbol that's based on
the symbols' locations in the cooked character stream. This is potentially
problematic when comparing symbols from .mod files when the cooked character
streams themselves might be allocated to varying memory locations.
This change fixes that by using the order in which symbols are created as the
basis for the "<" operator. Thanks to Tim and Peter for consultation on the
necessity of doing this and the idea for what to use as the basis of the sort.
This change in the "<" operator changed the expected results for three of the
tests. I manually inspected the new results, and they look OK to me. The
differences in data05.f90 and typeinfo01.f90 are entirely the order, offsets,
and sizes of the derived type components. The changes in resolve102.f90 are
due to the new, different "<" operator used for sorting.
Differential Revision: https://reviews.llvm.org/D98225
Diffstat (limited to 'llvm/lib/ProfileData/Coverage/CoverageMapping.cpp')
0 files changed, 0 insertions, 0 deletions