This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: C++ PATCH for c++/41611 (emitting guard without guarded var leading to undefined symbols)
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Rafael Espindola <espindola at google dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>, hubicka at gcc dot gnu dot org, Diego Novillo <dnovillo at google dot com>
- Date: Fri, 04 Dec 2009 18:31:57 +0000
- Subject: Re: C++ PATCH for c++/41611 (emitting guard without guarded var leading to undefined symbols)
- References: <4B1597B9.1070400@redhat.com> <38a0d8450912040926mc74b0cdp3723e97ffb80ec5a@mail.gmail.com>
Rafael Espindola wrote:
>> Also, it seems strange to have a decl with DECL_COMDAT_GROUP set, but not
>> DECL_COMDAT. Does that ever make sense?
>
> I am not sure.
It could be happening here, in ix86_file_end() in gcc/config/i386.c:
> if (USE_HIDDEN_LINKONCE)
> {
> tree decl;
>
> decl = build_decl (BUILTINS_LOCATION,
> FUNCTION_DECL, get_identifier (name),
> error_mark_node);
> TREE_PUBLIC (decl) = 1;
> TREE_STATIC (decl) = 1;
> DECL_COMDAT_GROUP (decl) = DECL_ASSEMBLER_NAME (decl);
I just dug this up. Not sure if it's relevant in this particular case, but
I think caution is indicated.
> Would a patch changing DECL_COMDAT be OK at this stage if it
> bootstraps and passes all tests?
Please Cc me if you do spin one, and I'll test it on cygwin for you. The
COMDAT flags have some tricky interactions with windows dll import/export
attributes.
cheers,
DaveK