This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Workaround for virtual function/dllimport bug, also patch guidance request


geoff schmidt <gschmidt@MIT.EDU> writes:
> 
> Since this has come up on the list before, if you're like me and have
> something you really want to compile, a crude but functional
> workaround is to add
> 
>   /* Don't let any functions get dllimport'd */
>   if (TREE_CODE (decl) == FUNCTION_DECL)
>     return 0;
> 
>   /* Don't let vtables get dllimport'd; it confuses the assembler */
>   if (TREE_CODE (decl) == VAR_DECL
>       && DECL_VIRTUAL_P (decl))
>     return 0;

Geoff,

Please see if the following fixes the problem:

Fri Nov 26 13:26:36 1999  Mumit Khan  <khan@xraylith.wisc.edu>

	* i386/winnt.c (i386_pe_dllimport_p): Don't import virtual 
	functions.

Index: gcc/config/i386/winnt.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/gcc-2.95.2/gcc/config/i386/winnt.c,v
retrieving revision 1.4
diff -u -3 -p -r1.4 winnt.c
--- winnt.c	1999/11/05 08:21:44	1.4
+++ winnt.c	1999/11/26 18:53:39
@@ -208,7 +208,7 @@ i386_pe_dllimport_p (decl)
   tree context;
 
   if (TREE_CODE (decl) == FUNCTION_DECL
-      && TARGET_NOP_FUN_DLLIMPORT)
+      && (TARGET_NOP_FUN_DLLIMPORT || DECL_VIRTUAL_P(decl)))
     return 0;
 
   if (TREE_CODE (decl) != VAR_DECL

> 
> The first if un-dllimports all functions so none can show up in
> vtables.  I couldn't find a way to determine if a function is virtual
> without telling winnt.c about C++ front end internals (DECL_VIRTUAL_P
> doesn't take into account functions declared virtual in some parent
> class but not this class).  At very least this should be changed to
> only un-dllimport _member_ functions (all of 5 minutes).

DECL_VIRTUAL_P is defined in the backend, so it's ok.

> The second if un-dllimports vtables.  It's unclear to me what exactly
> is supposed to happen, but if I take this part out and try to import a
> whole class, a vtable can be generated named "_=" which makes assembly
> fail with a syntax error.  Probably dllimport'd vtables (and inlines
> for that matter) should be marked as not to be generated, even though
> if you get #pragma interface/implementation working right it shouldn't
> be a problem.

Can you send me a testcase of this `_=' problem please? I already know
of a few cases where pragma interface/implementation causes trouble, so
I'm not too surprised.

You may also want to try out the following:

Sat Jun 26 11:51:20 1999  Mumit Khan  <khan@xraylith.wisc.edu>

	* decl.c (start_function): Disable Jason Merrill's change on
	1999-03-18 to suppress normal linkage heuristics for #pragma 
	interface under MULTIPLE_SYMBOL_SPACES.

Index: gcc-2.95.2/gcc/cp/decl.c
===================================================================
RCS file: /homes/khan/src/CVSROOT/gcc-2.95.2/gcc/cp/decl.c,v
retrieving revision 1.3
diff -u -3 -p -r1.3 decl.c
--- gcc-2.95.2/gcc/cp/decl.c	1999/11/05 06:26:36	1.3
+++ gcc-2.95.2/gcc/cp/decl.c	1999/11/05 06:34:42
@@ -13555,6 +13555,9 @@ start_function (declspecs, declarator, a
       DECL_NOT_REALLY_EXTERN (decl1) = 0;
       DECL_INTERFACE_KNOWN (decl1) = 1;
     }
+#if 0
+  /* FIXME: Don't use this heuristic. Breaks GNU Octave and a few other
+     packages that use #pragma interface/implementation extensively.  */
   else if (interface_unknown && interface_only
 	   && (! DECL_TEMPLATE_INSTANTIATION (decl1)
 	       || flag_alt_external_templates))
@@ -13569,6 +13572,7 @@ start_function (declspecs, declarator, a
       DECL_INTERFACE_KNOWN (decl1) = 1;
       DECL_DEFER_OUTPUT (decl1) = 1;
     }
+#endif /* 0 */
   else
     {
       /* This is a definition, not a reference.

Regards,
Mumit


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]