From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Mitchell To: dave@hiauly1.hia.nrc.ca Cc: law@cygnus.com, gcc-patches@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: C++ Issue on GCC 3.0 branch Date: Thu, 26 Apr 2001 10:25:00 -0000 Message-id: <20010426102456K.mitchell@codesourcery.com> References: <20010425173144F.mitchell@codesourcery.com> <200104261531.LAA16759@hiauly1.hia.nrc.ca> X-SW-Source: 2001-04/msg01262.html >>>>> "John" == John David Anglin writes: John> While I am certain that the patch eliminates the duplicate John> symbols, I am still concerned that assemble_external is John> being called with TREE_PUBLIC and DECL_EXTERNAL set for the John> type declarations. This causes .IMPORT statements to be Yes, that's why I asked about this. There's a basic problem here; both the C and C++ front-ends call assemble_external in a way that is inconsistent with the assemble_external documentation. In particular, ASM_OUTPUT_EXTERNAL is documented as used when something is A C statement (sans semicolon) to output to the stdio stream STREAM any text necessary for declaring the name of an external symbol named NAME which is referenced in this compilation but not defined. The value of DECL is the tree node for the declaration. You can't know this until the end of the translation unit. But, we compile a function-at-a-time, so if we see: extern void f(); void g() { f(); } void f() {} we call this macro for `f'. It's even more extreme in C++ because we don't make up our minds about the linkages of some functions until very late in the game. (See the tricks played with DECL_NOT_REALLY_EXTERN.) That's all really pretty grotesque, but it's not easy to fix, and it's been that way for a long time, so I'm guessing most systems deal with it OK. -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com