From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9485 invoked by alias); 24 May 2002 12:46:12 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 9430 invoked by uid 71); 24 May 2002 12:46:08 -0000 Date: Fri, 24 May 2002 05:46:00 -0000 Message-ID: <20020524124608.9425.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Raoul Gough" Subject: Re: c++/6771: no code emitted for locally unused class with dllexport attribute Reply-To: "Raoul Gough" X-SW-Source: 2002-05/txt/msg00768.txt.bz2 List-Id: The following reply was made to PR c++/6771; it has been noted by GNATS. From: "Raoul Gough" To: , , , Cc: Subject: Re: c++/6771: no code emitted for locally unused class with dllexport attribute Date: Fri, 24 May 2002 13:45:30 +0100 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&p r=6771 I have some more information regarding this dllexport problem (and a quick and dirty fix for my system). I hope this is the right way to submit additional information... I've determined that the problematic member function (foofunction) is having comdat_flag set (I believe erroneously) in decl2.c via the import_export_decl function (called from finish_file in the first deferred_fns loop). According the the comments in tree.h, comdat_flag should be set for entities "guaranteed to be generated by any translation unit that needs them, and therefore need not be put out anywhere where they are not needed", which is clearly not the case here (member function of a class with attribute dllexport). So I just hacked the comdat_linkage function as follows, and the problem went away :-) /cygdrive/d/gcc/CVS/gcc/gcc/cp $ diff decl2.c~ decl2.c 2183c2183 < if (DECL_LANG_SPECIFIC (decl)) --- > if (DECL_LANG_SPECIFIC (decl) && !i386_pe_dllexport_p (decl)) (diff with decl2.c CVS:1.520.2.5) This generates an "implicit declaration" warning, and is only suitable for systems that use config/i386/winnt.c. I'm sure this is not the right way to fix it, because comdat_linkage should probably never get called on a dllexport'd member function - maybe a better fix would be to clear DECL_DECLARED_INLINE_P at some stage? I'm willing to spend some more time on this (and possibly any other open bugs within my abilities), but would need a bit of advice on producing a legitimate fix. Regards, Raoul Gough. PS: I've upgraded via CVS to gcc_latest_snapshot (gcc_ss_20020521) and the problem is unchanged. Also, setting the -fno-default-inline flag fixes the problem for the export case, but crashes the compiler for the import case: /cygdrive/f/Users/Raoul/cxx $ /usr/local/bin/g++ -c dllexport.cc -fno-default-inline -save-temps dllexport.cc: In member function `void bar::barfunction()': dllexport.cc:26: Internal compiler error in rest_of_compilation, at toplev.c: 3478 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. This would otherwise be a temporary work-around for the original problem. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com