andreybokhanko added a comment. In http://reviews.llvm.org/D18596#388295, @aaron.ballman wrote:
> Regression is a bit of a question mark, to me depending on the diagnostic. I > think warning the user "this has absolutely no effect" is a reasonable > diagnostic for that situation -- the user wrote something, possibly expecting > it to have an effect, and it turns out that it does absolutely nothing > (including in the compiler that implements the language extension). If MSVC > were to ever add semantic effect in those cases (diverging from what Clang > implements), the diagnostic becomes even more important for Clang users. So I > think it's fine to accept __unaligned for non-pointer types, but issue an > "attribute ignored" warning diagnostic. As David wrote, __unaligned is a qualifier in MSVC, so MS accepts the following: __unaligned int *p; as a correct usage (and does mangling for __unaligned). We model it as an attribute, so we create a new AttributedType for int, not for the pointer. This is OK, since our mangling code takes PointeeType and checks presence of the attribute. Unfortunately, this means that we can't issue warnings, as it's impossible (to the best of my knowledge) to distinguish between __unaligned int *p; __unaligned int p; in processTypeAttrs function. As I said before, the purpose of this patch is to implement correct mangling (and thus, improve object level compatibility with MSVC), not to provide a fully correct implementation of __unaligned. Another alternative is to model __unaligned as a qualifier, but this would require addition of an extra field to TypeBitfields. Do we want to do this for an ignored qualifier? I don't see any practical purpose. Andrey http://reviews.llvm.org/D18596 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
