yaxunl added a comment.
In D79526#2025761 <https://reviews.llvm.org/D79526#2025761>, @tra wrote:
> I've tested the patch on our sources and it still breaks tensorflow
> compilation, though in a different way:
>
> In file included from
> third_party/tensorflow/core/kernels/slice_op_gpu.cu.cc:22:
> In file included from
> ./third_party/tensorflow/core/framework/register_types.h:20:
> In file included from
> ./third_party/tensorflow/core/framework/numeric_types.h:28:
> In file included from ./third_party/tensorflow/core/platform/types.h:22:
> In file included from ./third_party/tensorflow/core/platform/tstring.h:24:
> In file included from ./third_party/tensorflow/core/platform/cord.h:23:
> In file included from
> ./third_party/tensorflow/core/platform/google/cord.h:19:
> In file included from ./third_party/absl/strings/cord.h:89:
> ./third_party/absl/strings/internal/cord_internal.h:34:16: error: no
> matching constructor for initialization of 'std::atomic<int32_t>' (aka
> 'atomic<int>')
> Refcount() : count_{1} {}
> ^ ~~~
>
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1778:8:
> note: candidate constructor (the implicit copy constructor) not viable: no
> known conversion from 'int' to 'const std::__u::atomic<int>' for 1st argument
> struct atomic
> ^
>
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1784:5:
> note: candidate constructor not viable: requires 0 arguments, but 1 was
> provided
> atomic() _NOEXCEPT _LIBCPP_DEFAULT
> ^
>
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1807:52:
> error: call to deleted constructor of
> '__atomic_base<base::scheduling::Schedulable *>'
> _LIBCPP_CONSTEXPR atomic(_Tp* __d) _NOEXCEPT : __base(__d) {}
> ^ ~~~
> ./third_party/absl/base/internal/thread_identity.h:162:66: note: in
> instantiation of member function
> 'std::__u::atomic<base::scheduling::Schedulable *>::atomic' requested here
> std::atomic<base::scheduling::Schedulable*> bound_schedulable{nullptr};
> ^
>
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1675:5:
> note: '__atomic_base' has been explicitly marked deleted here
> __atomic_base(const __atomic_base&) = delete;
> ^
>
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1786:51:
> error: call to implicitly-deleted copy constructor of '__atomic_base<long>'
> _LIBCPP_CONSTEXPR atomic(_Tp __d) _NOEXCEPT : __base(__d) {}
> ^ ~~~
> ./third_party/absl/synchronization/mutex.h:927:25: note: in instantiation
> of member function 'std::__u::atomic<long>::atomic' requested here
> inline Mutex::Mutex() : mu_(0) {
> ^
>
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1698:7:
> note: copy constructor of '__atomic_base<long, true>' is implicitly deleted
> because base class '__atomic_base<long, false>' has a deleted copy constructor
> : public __atomic_base<_Tp, false>
> ^
>
> third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/atomic:1675:5:
> note: '__atomic_base' has been explicitly marked deleted here
> __atomic_base(const __atomic_base&) = delete;
> ^
>
>
Looks like we went overboard to treat implicit host device candidate as
inferior. They should be treated
as inferior in device compilation, not in host compilation. Here because they
are treated as inferior
to same-sided candidate in host compilation, they changed overload resolution
in host compilation
therefore caused the failure in host compilation.
I have updated the patch to treat implicit host device candidate as inferior in
device compilation.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D79526/new/
https://reviews.llvm.org/D79526
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
