wuzish marked 8 inline comments as done. wuzish added inline comments.
================ Comment at: clang/lib/Sema/SemaOverload.cpp:3941 + return ImplicitConversionSequence::Better; + } + ---------------- hubert.reinterpretcast wrote: > This seems to duplicate the bug described here in > https://bugs.llvm.org/show_bug.cgi?id=39361. > ``` > typedef unsigned int GccType __attribute__((__vector_size__(16))); > typedef __vector unsigned int AltiVecType; > > typedef float GccOtherType __attribute__((__vector_size__(16))); > > char *f(GccOtherType, int); > template <typename T> int f(AltiVecType, T); > template <typename T> int g(AltiVecType, T); > char *g(GccOtherType, int); > > bool zip(GccType v) { return f(v, 0) == g(v, 0); } > ``` Thank you for the good case. I will fix it. But the https://bugs.llvm.org/show_bug.cgi?id=39361 is not the same reason but similar. We can propose another patch to do this. I think the essential reason is that code as blow has not considered `ImplicitConversionSequence::Worse` so that outside caller goes into path to choose a non-template candidate first. ``` if (S.getLangOpts().MSVCCompat && SCS1.Second == ICK_Integral_Conversion && SCS2.Second == ICK_Floating_Integral && S.Context.getTypeSize(SCS1.getFromType()) == S.Context.getTypeSize(SCS1.getToType(2))) return ImplicitConversionSequence::Better; ``` ================ Comment at: clang/test/Sema/altivec-generic-overload.c:3 + +typedef signed char __v4sc __attribute__((__vector_size__(16))); +typedef unsigned char __v4uc __attribute__((__vector_size__(16))); ---------------- hubert.reinterpretcast wrote: > wuzish wrote: > > hubert.reinterpretcast wrote: > > > `__v4sc` is suspicious. The most consistent naming I have seen is > > > `v16i8`, `v16u8`, `v8i16`, ... > > > Do we need the double underscores? > > > > > Because it's generic gcc vector type instead of altivec type so I choose > > the naming style. > The naming style from `clang/lib/Headers/avxintrin.h` would still say that > the `__v4sc` here should be `__v16qi`. On, you mean the num. Yes, that should not be '4'. Repository: rC Clang https://reviews.llvm.org/D53417 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits