r196415 - This attribute somehow remained nameless in the attribute tablegen, until now.

[Alexander Potapenko]

On Fri, Dec 6, 2013 at 5:36 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> On Fri, Dec 6, 2013 at 4:05 AM, Alexander Potapenko <glider at google.com> wrote:
>> Maybe MSVC doesn't define __GNUC__? I guess it's better to remove the
>> #ifdef clutter so that the attribute is applied unconditionally.
>
> Even when I did that, I was unable to reproduce. A very basic test of:
>
> __attribute__((__force_align_arg_pointer__))
> void f(void);
>
> Would not demonstrate the issue. When I stepped through the code, it
> would get to getKind, strip off the leading and trailing underscores,
> and determine the proper attribute id.
The above test also reproduces the problem for me with -m64. This
isn't the case with -m32, (obviously because the attribute is an
x86-only)

>
> I don't have access to a Linux box right now. Give me a bit to set one
> up; any particular distro you are seeing this with? Also, x86 or x64
> host environment?
This is Ubuntu Precise, but since no headers are involved I doubt the
distribution version should affect the output.
The host environment is x86_64.

> In the meantime, does the following code work for you:
>
> __attribute__((force_align_arg_pointer))
> void f(void);
It doesn't, with the same symptoms (only when targeting x86_64)

If the code in QCMS is correct,
__has_attribute(__force_align_arg_pointer__) should return 1 on x86
and 0 on x86_64.
Looks like this is not the case for the ToT Clang on Linux:

$ cat p.cc
#include <stdio.h>
int main() {
  printf("%d\n", __has_attribute(__force_align_arg_pointer__));
  printf("%d\n", __has_attribute(force_align_arg_pointer));
  return 0;
}

$ bin/clang++ p.cc -o p -m32 && ./p
1
1
$ bin/clang++ p.cc -o p -m64 && ./p
1
1