On 19 October 2013 23:55, Alp Toker <[email protected]> wrote: > Hi Rafael, > > The old gcc syntax, ugly as it is, allows aliasing of overloaded functions: > > void alias2() __attribute__((alias("_Z6alias1v"))); > void alias1() {} > void alias1(int) {} > > Your patch precludes that because it's using simple identifier lookup. > > I've attached a patch against yours that uses overload resolution to > find an exact match, otherwise the appropriate overload as long it can > be found unambiguously, so this continues to work as: > > void alias2() __attribute__((alias("alias1"))); > void alias1() {} > void alias1(int) {} > > My second thought is that, instead of overloading the gcc alias > attribute in an incompatible way, I'd prefer to preserve the current > behaviour, at least in the quoted form. It doesn't feel right to change > the attribute semantics given that it's already specified to work with > symbol names, complete with working tests. > > Some options might be to have a new clang syntax accepting an unquoted > IdentifierArgument / NNS, or even to make this a new attribute as a > clang extension. What do you think?
We chatted a bit on IRC and I agree. I was undecided as to what is the best way of handling pr17535, but given the above argument I now think that this is one of the exceptional cases where producing an error from codegen is reasonable. I also agree that solution is reasonable only because this is a really terrible attribute. Designing a more user friendly one that uses identifiers and works with c++ features would be really nice. I will try to implement the codegen fix for pr17535 and start a new thread with it. Anyone interested in implementing a c++ and user friendly alias attribute should probably start from Alp's patch. Thanks, Rafael _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
