This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: RE: C++ PATCH to attribute handling
- From: Danny Smith <danny_r_smith_2001 at yahoo dot co dot nz>
- To: gcc-patches at gcc dot gnu dot org
- Cc: jason at redhat dot com
- Date: Mon, 11 Feb 2002 12:05:07 +1100 (EST)
- Subject: RE: RE: C++ PATCH to attribute handling
--- Danny Smith <danny_r_smith_2001@yahoo.co.nz> wrote: > Date: Sat, 9 Feb
2002 11:05:13 +1100 (EST)
> From: Danny Smith <danny_r_smith_2001@yahoo.co.nz>
> Subject: RE: C++ PATCH to attribute handling
> To: GCC Patches <gcc-patches@gcc.gnu.org>
> CC: jason@redhat.com
>
>
> This change
> cp/Changelog
> 2002-01-31 Jason Merrill <jason@redhat.com>
>
> Allow attributes in parms and casts.
> * parse.y (named_parm): Don't strip attrs.
> (declmods): Remove 'attributes' production.
> (nonempty_cv_qualifiers): Accept attributes.
> (ATTRIBUTE): Give precedence.
> * decl.c (groktypename): Handle attributes.
> (grokparms): Likewise.
>
>
> causes a regression in handling of attributes in C++ on mingw and cygwin.
>
In particular, this part of the patch is causing me problems:
@@ -1938,11 +1938,6 @@
}
| declmods attributes
{ $$.t = hash_tree_cons ($2, NULL_TREE, $1.t); }
- | attributes %prec EMPTY
- {
- $$.t = hash_tree_cons ($1, NULL_TREE, NULL_TREE);
- $$.new_type_flag = 0; $$.lookups = NULL_TREE;
- }
;
/* Used instead of declspecs where storage classes are not allowed
If I revert that bit only, the windows way
__attribute__((dllexport)) int __attribute__((stdcall)) six (void);
is happy in C++.
Danny
> Prior to this patch all six declarations below were accepted and did
> the right thing in both C and C++. With the patch, the last of the six
> declarations below
>
> __attribute__((dllexport))
> int
> __attribute__((stdcall)) // parse error before '__attribute__' in C++
> six (void);
>
> causes a parse error in C++ (only)
>
> Unfortunately, the sixth form is probably the one most widely used
> in the windows' world and the difference in behaviour between C and C++
> is likely to cause problems amongst cygwin and mingw users.
>
> The post to GCC-patches mentions that this is a "quick hack" until parser
> is overhauled. A "quick local unhack" makes G++ 3.1 friendlier for
> windows
> users. Is the real fix likely to accept the form above?
>
>
> /* foo.C */
>
> int
> __attribute__((dllexport))
> __attribute__((stdcall))
> one(void); // OK
>
> __attribute__((dllexport))
> __attribute__((stdcall))
> int
> two(void); // OK
>
> int
> __attribute__((stdcall))
> three (void)
> __attribute__((dllexport)); // OK
>
> __attribute__((stdcall))
> int
> four (void)
> __attribute__((dllexport)); // OK
>
> int
> five(void)
> __attribute__((dllexport))
> __attribute__((stdcall)); // OK
>
> __attribute__((dllexport))
> int
> __attribute__((stdcall)) // parse error before '__attribute__' in C++
> six (void); // OK in C
>
>
http://greetings.yahoo.com.au - Yahoo! Greetings
- Send your Valentines love online.