c++/8656: Unable to assign function with __attribute__ and pointer return type to an appropriate variable

[rmathew@hotmail.com]

>Number:         8656
>Category:       c++
>Synopsis:       Unable to assign function with __attribute__ and pointer return type to an appropriate variable
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Wed Nov 20 03:06:03 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     rmathew@hotmail.com
>Release:        GCC 3.2
>Organization:
>Environment:
MinGW, Cygwin and Linux(x86) (and possibly other x86-32
targets)
>Description:
Consider the following source code saved in file "bar.c":
--------------------------- 8< ---------------------------
extern int * (__attribute__((stdcall)) *fooPtr)( void);

int * __attribute__((stdcall)) myFn01( void) { return 0; }

void snafu( void)
{
    fooPtr = myFn01;
}
--------------------------- 8< ---------------------------

Running "g++ -c bar.c" gives:
--------------------------- 8< ---------------------------
bar.c: In function `void snafu()':
bar.c:7: invalid conversion from `int*(*)()' to `int*(*)()'
--------------------------- 8< ---------------------------

However, running "gcc -c bar.c" creates no such problems.

With reference to the source code given above, here're
a few more observations:

1. This problem is not shown by the 2.95.3 g++.

2. If the definition of myFn01 above is changed to
   a declaration or if a declaration for the same is
   added before it, the problem disappears.

3. The problem appears only if the return type is
   of the kind "xyz *" - if there's a "typedef int *intptr;"
   and we use "intptr" instead of "int *" for myFn01, the
   problem disappears.

4. The problem can also be circumvented by putting the
   attribute and the function name together in parentheses
   like "int * (__attribute__((stdcall)) myFn01)( void)".

5. The problem does not come if all the "stdcall" instances
   are replaced by "cdecl", but it reappears if they are
   replaced by "fastcall".

6. Both Borland C/C++ 5.5 and MSVC++ 6.2 compile this code
   perfectly (after using the MS equivalent "__stdcall").

Lastly, this looks very similar to PR 6626, but IMHO is
different - the syntax and semantics are perfectly valid
in this case as far as I can see.
>How-To-Repeat:
Just save the sample code given above as file "bar.c" (or
whatever) and run "g++ -c" on it.
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: