[PATCH] D18596: [MSVC] PR27132: Proper mangling for __unaligned qualifier

Andrey Bokhanko via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 5 01:12:40 PDT 2016

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.



More information about the cfe-commits mailing list