On Wed, Feb 4, 2015 at 9:36 PM, Richard Smith <[email protected]> wrote:
> On Wed, Feb 4, 2015 at 6:38 PM, John McCall <[email protected]> wrote: > >> > On Jun 5, 2014, at 4:17 PM, Richard Smith <[email protected]> >> wrote: >> > On Thu, Jun 5, 2014 at 3:11 PM, Alp Toker <[email protected]> wrote: >> > Author: alp >> > Date: Thu Jun 5 17:11:20 2014 >> > New Revision: 210295 >> > >> > URL: http://llvm.org/viewvc/llvm-project?rev=210295&view=rev >> > Log: >> > Remove old proposal notices >> > >> > Let's just go ahead and assume the answer was 'I do' >> > >> > :) >> > >> > You can check what proposals have made it into the ABI here: >> > >> > http://mentorembedded.github.io/cxx-abi/abi.html >> > >> > For the ones that aren't in the ABI, having a comment explaining why >> we're using them and where they come from is useful. None of these three >> are in the ABI document yet; please back this out for now. >> > >> > John: any chance we could get the ABI document updated with these? ( >> http://sourcerytools.com/pipermail/cxx-abi-dev/2012-January/000024.html) >> >> After much delay, added. We don’t seem to get this right, though, at >> least not when the destination type isn’t dependent: >> >> template <class T, class U> T fst(T, U); >> struct A { >> int x[3]; >> }; >> template <class T> decltype(fst(A{1,2},T())) foo(T t) {} >> >> int main() { >> foo(1); >> } >> >> We produce: >> _Z3fooIiEDTcl3fstcv1AililLi1ELi2EEEcvT__EEES1_ >> It should be: >> _Z3fooIiEDTcl3fsttl1ALi1ELi2EcvT__EEES1_ >> > > There are quite a few bugs conspiring to give that result :( Our AST is > also poorly-suited to this mangling, because the braces are not considered > to be part of the functional cast itself; they're part of its subexpression. > > If you parenthesize the argument to A: >> template <class T> decltype(fst(A({1,2}),T())) foo(T t) {} >> We produce: >> _Z3fooIiEDTcl3fstcv1AcvS0_ililLi1ELi2EEEcvT__EEES1_ >> It should be: >> _Z3fooIiEDTcl3fstcv1AliLi1ELi2EcvT__EEES1_ >> > > Somewhat related, we also get this wrong: > > struct X { X(int); }; > int f(X); > template<typename T> void f(decltype(f(0), T())) { f(0); } > void g() { f<int>(0); } > > ... because we explicitly mangle the implicit conversion from int to X. I > see > > _Z1fIiEvDTcmcl1fLi0EEcvT__EE from EDG > _Z1fIiEvDTcmclL_Z1f1XELi0EEcvT__EE from GCC > _Z1fIiEvDTcmclL_Z1f1XEcvS0_cvS0_Li0EEcvT__EE from Clang > > I think GCC and Clang are right to use the resolved name L_Z1f1XE rather > than the unresolved name 1f here, and GCC's mangling is right overall. Do > you agree? > All of the above fixed in r228274. I'm not really very happy with our AST representation here; we've overloaded CXXConstructExpr to mean too many different syntactic things that it's hard to reconstruct the right mangling. As an aside: if we have a fully-resolved call in an instantiation-dependent expression, should we really be putting any used default arguments into the mangling?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
