This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Workaround for virtual function/dllimport bug, also patch guidance request
- To: geoff schmidt <gschmidt at MIT dot EDU>
- Subject: Re: Workaround for virtual function/dllimport bug, also patch guidance request
- From: Mumit Khan <khan at nanotech dot wisc dot edu>
- Date: Fri, 26 Nov 1999 13:29:58 -0600
- cc: gcc at gcc dot gnu dot org
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