--- a/clang/test/SemaCXX/destructor.cpp	Mon May 25 11:50:15 2020 +0900
+++ b/clang/test/SemaCXX/destructor.cpp	Mon May 25 11:55:54 2020 +0900
@@ -510,4 +510,44 @@
   N::C::~C() {}
 #pragma clang diagnostic pop
 }
+
+// Ignore ambiguity errors in destructor name lookup. This matches the observed
+// behavior of ICC, and is compatible with the observed behavior of GCC (which
+// appears to ignore lookups that result in ambiguity) and MSVC (which appears
+// to perform the lookups in the opposite order from Clang).
+namespace PR44978 {
+  // All compilers accept this despite it being clearly ill-formed per the
+  // current wording.
+  namespace n {
+    class Foo {}; // expected-note {{found}}
+  }
+  class Foo {}; // expected-note {{found}}
+  using namespace n;
+  static void func(n::Foo *p) { p->~Foo(); } // expected-warning {{ambiguous}}
+
+  // GCC rejects this case, ICC accepts, despite the class member lookup being
+  // ambiguous.
+  struct Z;
+  struct X { using T = Z; }; // expected-note {{found}}
+  struct Y { using T = int; }; // expected-note {{found}}
+  struct Z : X, Y {};
+  void f(Z *p) { p->~T(); } // expected-warning {{ambiguous}}
+
+  // GCC accepts this and ignores the ambiguous class member lookup.
+  //
+  // FIXME: We should warn on the ambiguity here too, but that requires us to
+  // keep doing lookups after we've already found the type we want.
+  using T = Z;
+  void g(Z *p) { p->~T(); }
+
+  // ICC accepts this and ignores the ambiguous unqualified lookup.
+  struct Q {};
+  namespace { using U = Q; } // expected-note {{candidate}} expected-note {{found}}
+  using U = int; // expected-note {{candidate}} expected-note {{found}}
+  void f(Q *p) { p->~U(); } // expected-warning {{ambiguous}}
+
+  // We still diagnose if the unqualified lookup is dependent, though.
+  template<typename T> void f(T *p) { p->~U(); } // expected-error {{ambiguous}}
+}
+
 #endif // BE_THE_HEADER