https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92438
--- Comment #2 from sagebar at web dot de --- The c++ standard may not cover it, however in the interest of compatibility with other compilers, g++ for cygwin actually defines the following predefined macros (among others): g++ -dM -E -x c++ - < /dev/null | grep cdecl ``` #define _cdecl __attribute__((__cdecl__)) #define __cdecl __attribute__((__cdecl__)) ``` Obviously, these are there for compatibility with msvc, and as it turns out: msvc _only_ allows calling convention attributes if they are written between a function's return type, and its name (or in the case of there being parenthesis: only inside of them). ``` // - The only way that msvc accepts it // - One of the ways that g++ for cygwin accepts it int __cdecl foo(); int (__cdecl bar)(); ``` So it does make perfect sense, and in a way is very much intended behavior in my mind that __attribute__((...)) is accepted in that same place, and even more so: If you look at the windows headers used by cygwin, you'll see that this is behavior that is very much depended upon. And even disregarding the (thus far fully maintained) compatibility with msvc as far as the annotation of calling conventions go, this is most definitely still a bug since using the typedef'd name `MYINT` as return type breaks g++, however using the struct's name (including the `struct` prefix) as `struct myint_struct` gets parsed correctly (so whatever would be the ~correct~ way of doing, g++ is inconsistent about it).
