[patch][pr17535] Reject alias attributes that point to undefined names.

Rafael EspĂ­ndola rafael.espindola at gmail.com
Mon Oct 21 07:25:38 PDT 2013


On 19 October 2013 23:55, Alp Toker <alp at nuanti.com> 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



More information about the cfe-commits mailing list