[PATCH] D11324: [PM/AA] Replace the only use of the AliasAnalysis::deleteValue API (in GlobalsModRef) with CallbackVHs that trigger the same behavior.

[Kim Gräsman]

kimgr added inline comments.

================
Comment at: llvm/trunk/lib/Analysis/IPA/GlobalsModRef.cpp:106-114
@@ -105,2 +105,11 @@
 
+  /// Handle to clear this analysis on deletion of values.
+  struct DeletionCallbackHandle;
+
+  /// List of callbacks for globals being tracked by this analysis. Note that
+  /// these objects are quite large, but we only anticipate having one per
+  /// global tracked by this analysis. There are numerous optimizations we
+  /// could perform to the memory utilization here if this becomes a problem.
+  std::list<DeletionCallbackHandle> Handles;
+
 public:
----------------
This doesn't compile on my FreeBSD 10.1 rig;

```
In file included from /home/kimgr/code/llvm-trunk/llvm/lib/Analysis/IPA/GlobalsModRef.cpp:32:
/usr/include/c++/v1/list:227:9: error: field has incomplete type '<anonymous>::GlobalsModRef::DeletionCallbackHandle'
    _Tp __value_;
        ^
/usr/include/c++/v1/type_traits:1994:27: note: in instantiation of template class 'std::__1::__list_node<<anonymous>::GlobalsModRef::DeletionCallbackHandle, void *>' requested here
                 decltype(__is_constructible_test(declval<_Tp>(), declval<_Args>()...))

```

$ clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix

Not sure which libc++ version came with this system. I've confirmed that moving the full `DeletionCallbackHandle` definition up in place of the forward decl resolves the problem.

The Clang version is getting old, but this is FreeBSD's latest production release, so it would be nice if it could be supported.

Thanks!


Repository:
  rL LLVM

http://reviews.llvm.org/D11324