llvm dev - Jan 2019 - Assertion `LICM.getLoopToAliasSetMap().empty() && "Didn't free loop alias sets"' failed.

Hi everyone,
Recently, I made some tests for LLVM/Clang/opt, and I found many test cases that
can cause a crash bug for opt with "...-loop-unroll -licm...".
For the truck version of LLVM, the output is
"llvm/lib/Transforms/Scalar/LICM.cpp:222: virtual bool
{anonymous}::LegacyLICMPass::doFinalization(): Assertion
`LICM.getLoopToAliasSetMap().empty() && "Didn't free loop alias
sets"' failed."
For example, when compiling the following source code with the pass sequence
"-loop-rotate -gvn -prune-eh -loop-unroll -licm", the bug can be
triggered.
---------------------------------------------------
#include "csmith.h"
g, h;
int16_t a();
b() {
  a();
  for (;;) {
    uint64_t c;
    int d, e, f;
    for (d = 0; d < 4; d++)
      for (; e < f;)
        c;
  }
}
int16_t a() {
  for (; 0;)
    for (; 0;)
      for (; 0;)
        ;
  g = 0;
  for (; g < 5; g++)
    for (; h;)
      ;
}
$clang -O3 -c -emit-llvm  -mllvm -disable-llvm-optzns small1.c -o small1.bc
$opt -loop-rotate -gvn -prune-eh -loop-unroll -licm small1.bc -o small1-opt.bc
----------------------------------------------------
My question is that why the information in LoopToAliasSetMap must be freed
before the doFinalization() function.
When the program runs into the doFinalization() function, the information in
LoopToAliasSetMap is no longer useful,
so can we free these elements in LoopToAliasSetMap manually? Like this:
bool doFinalization() override {
    //assert(LICM.getLoopToAliasSetMap().empty() &&
           //"Didn't free loop alias sets");
    for (auto &LTAS : LICM.getLoopToAliasSetMap())
        delete LTAS.second;
    LICM.getLoopToAliasSetMap().clear();
    return false;
  }
I test it on my system and it works, but I do not know whether there are some
side-effects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190126/e3029d5f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: small1.bc
Type: application/octet-stream
Size: 2764 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190126/e3029d5f/attachment.obj>