gcc bug relating to __declspec(dllimport)?

gcc bug relating to __declspec(dllimport)?

[geoff schmidt]

Hi!

With gcc 2.95.2 targeting mingw32 from linux, this code:

/*--- xyz.cpp ---------------------------------------------------------------*/
#include "xyz.h"

#pragma implementation "foo"
#pragma interface "foo"

class two: public one {};

/*--- xyz.h -----------------------------------------------------------------*/
#pragma interface "bar"

class __declspec(dllimport) one {
 public:
  // virtual ~one(void); // see note
  virtual void func(void);
} ;

/*---------------------------------------------------------------------------*/

gets me:

$ gcc xyz.cpp
xyz.cpp:6: Internal compiler error, output_operand_lossage `invalid
expression as operand'

If I use -fno-rtti, I have to uncomment the virtual destructor to get
the same behavior.

I know that this error message has come up on the list before, but I'm
pretty sure that this instance is an actual bug and not a result of
trying to do things that are impossible with imported DLL data -- 
because the above code is a snippet from the wxWindows cross-platform
GUI library, which compiles happily under several different windows
compilers.  Or am I missing something obvious?

Am I doing something wrong?  Is there a way to work around this?  If
it's a bug, I'd be willing to take a stab at a patch if someone can
point me in the right direction.

thanks very much,

geoff schmidt
gschmidt@mit.edu

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gcc bug relating to __declspec(dllimport)?

[Chris Faylor]

On Wed, Nov 17, 1999 at 05:27:34AM -0500, geoff schmidt wrote:
>xyz.cpp:6: Internal compiler error, output_operand_lossage `invalid
>expression as operand'
>
>I know that this error message has come up on the list before, but I'm
>pretty sure that this instance is an actual bug and not a result of
>trying to do things that are impossible with imported DLL data -- 
>because the above code is a snippet from the wxWindows cross-platform
>GUI library, which compiles happily under several different windows
>compilers.  Or am I missing something obvious?

Well, if it says "internal compiler error" it is an actual gcc bug.
There is no doubt about that.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gcc bug relating to __declspec(dllimport)?

[Mumit Khan]

geoff schmidt <gschmidt@mit.edu> writes:
> Hi!
> 
> With gcc 2.95.2 targeting mingw32 from linux, this code:
> 
> /*--- xyz.cpp ---------------------------------------------------------------
> */
> #include "xyz.h"
> 
> #pragma implementation "foo"
> #pragma interface "foo"
> 
> class two: public one {};
> 
> /*--- xyz.h -----------------------------------------------------------------
> */
> #pragma interface "bar"
> 
> class __declspec(dllimport) one {
>  public:
>   // virtual ~one(void); // see note
>   virtual void func(void);
> } ;
> 
> /*---------------------------------------------------------------------------
> */
> 
> gets me:
> 
> $ gcc xyz.cpp
> xyz.cpp:6: Internal compiler error, output_operand_lossage `invalid
> expression as operand'
> 
> If I use -fno-rtti, I have to uncomment the virtual destructor to get
> the same behavior.
> 
> I know that this error message has come up on the list before, but I'm
> pretty sure that this instance is an actual bug and not a result of
> trying to do things that are impossible with imported DLL data -- 
> because the above code is a snippet from the wxWindows cross-platform
> GUI library, which compiles happily under several different windows
> compilers.  Or am I missing something obvious?
> 
> Am I doing something wrong?  Is there a way to work around this?  If
> it's a bug, I'd be willing to take a stab at a patch if someone can
> point me in the right direction.
> 

There are a few nasty bugs when you have virtual functions and also
inline functions in DLL imported classes. It's going to take quite
a few tweaks in the C++ front end to fix these, and unfortunately
I don't have the time right now. Hopefully someone else will jump
in fix these ... the vtable issue is particular harder to fix since
the GNU C++ vtables use offsets, which don't work for dllimported
functions.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[gschmidt]

Mumit Khan <khan@nanotech.wisc.edu> writes: 
> There are a few nasty bugs when you have virtual functions and also
> inline functions in DLL imported classes. It's going to take quite
> a few tweaks in the C++ front end to fix these, and unfortunately
> I don't have the time right now. Hopefully someone else will jump
> in fix these ... the vtable issue is particular harder to fix since
> the GNU C++ vtables use offsets, which don't work for dllimported
> functions.

I finally gritted my teeth and dove into the source last night.

My understanding of the problem is that dllimported functions
currently can't appear in vtables, so when you derive a child class
from a parent class exported from a DLL and don't override all of the
virtual members, you get the aforementioned error.  Normally when you
take the address of a dllimported function in global scope, ie

void func(void) __declspec(dllimport);
void (*some_pointer)(void) = func;

GCC works around the problem of func not having an address knowable at
compiletime by generating an initialization function that's called
automatically at startup that sets func to the correct value.  But
vtables are handled separately and GCC aborts instead of knowing to
add the vtable to the runtime-init list.  As far as I can tell the
offset data, whether in the vtable or a thunk function, isn't part of
the problem -- it can be computed at compile-time from the header
files, right?

A workaround exists.  Keep in mind that if a function isn't declared
dllimport but is in fact imported from a DLL, the springboard function
in the import library gets used (at a slight performance penalty.)
Since you *can* take the address of the springboard function at
compile time, it can go in the vtable, so if you simply *don't declare
virtual functions as dllimport* but just make sure they're exported
correctly when the import library is made, everything will be fine
(except for the small performance hit.)

However, you still must declare any static class data as dllimport.
So instead of tagging the whole class __declspec(dllimport), you have
to individually tag just the static data members, and optionally
non-virtual functions for performace.  I've tested this in a toy case
and it seems to work as reasoned.

Since I don't want to go through the whole library retagging all of
the classes, and since I want to keep MSVC compatibility, and since
this case should really be handled correctly, I've been thinking about
the best way to patch this.  I know very little about GCC so any
suggestions are appreciated.  Should I:

-- add code to finish_file or thereabouts to catch the case where a
vtable would contain addresses not known at compiletime and tack stuff
on to the static storage duration function (the ___static_initialization_
and_destruction thingy) to init the vtable at runtime?  this is the
"right way" in the sense that the springboard function isn't used, so
it's most efficient at the expense of a few extra bytes of init
function..

-- hack the dllimport attribute so that when it's applied to a class,
it filters down only to members that are static data or non-virtual
functions, and is automatically turned off for virtual functions (even
if you try to do it manually, I guess)?  this has the advantage of not
touching the front end, just config/i386/winnt.c (or that's my initial
impression)..

-- something else?

thanks,

Geoff Schmidt
gschmidt@mit.edu

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

Geoff,

Thanks for your comments on the dllimport/dllexport business, especially
with respect to the C++ front end. I haven't looked at your proposal in
detail yet (I tried, but my attention span just isn't there thanks to
my schedule), but I'll hopefully comment this weekend. Hopefully the
C++ maintainer(s) will jump in as well. I don't know how the new ABI
will affect this issue.

Would you be willing to take on fixing some of these problems?

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Jason Merrill]

What does VC++ do?

Jason

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

Jason Merrill <jason@cygnus.com> writes:
> What does VC++ do?
> 

Give me a day or two to dig out and run my tests with VC++. The MSDN 
docs have some info, but extremely scattered, so that's usually not 
much help in this matter, especially when it comes implementation 
details. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[gschmidt]

Mumit Khan <khan@nanotech.wisc.edu> writes: 
> There are a few nasty bugs when you have virtual functions and also
> inline functions in DLL imported classes. It's going to take quite
> a few tweaks in the C++ front end to fix these, and unfortunately
> I don't have the time right now. Hopefully someone else will jump
> in fix these ... the vtable issue is particular harder to fix since
> the GNU C++ vtables use offsets, which don't work for dllimported
> functions.

I finally gritted my teeth and dove into the source last night.

My understanding of the problem is that dllimported functions
currently can't appear in vtables, so when you derive a child class
from a parent class exported from a DLL and don't override all of the
virtual members, you get the aforementioned error.  Normally when you
take the address of a dllimported function in global scope, ie

void func(void) __declspec(dllimport);
void (*some_pointer)(void) = func;

GCC works around the problem of func not having an address knowable at
compiletime by generating an initialization function that's called
automatically at startup that sets func to the correct value.  But
vtables are handled separately and GCC aborts instead of knowing to
add the vtable to the runtime-init list.  As far as I can tell the
offset data, whether in the vtable or a thunk function, isn't part of
the problem -- it can be computed at compile-time from the header
files, right?

A workaround exists.  Keep in mind that if a function isn't declared
dllimport but is in fact imported from a DLL, the springboard function
in the import library gets used (at a slight performance penalty.)
Since you *can* take the address of the springboard function at
compile time, it can go in the vtable, so if you simply *don't declare
virtual functions as dllimport* but just make sure they're exported
correctly when the import library is made, everything will be fine
(except for the small performance hit.)

However, you still must declare any static class data as dllimport.
So instead of tagging the whole class __declspec(dllimport), you have
to individually tag just the static data members, and optionally
non-virtual functions for performace.  I've tested this in a toy case
and it seems to work as reasoned.

Since I don't want to go through the whole library retagging all of
the classes, and since I want to keep MSVC compatibility, and since
this case should really be handled correctly, I've been thinking about
the best way to patch this.  I know very little about GCC so any
suggestions are appreciated.  Should I:

-- add code to finish_file or thereabouts to catch the case where a
vtable would contain addresses not known at compiletime and tack stuff
on to the static storage duration function (the ___static_initialization_
and_destruction thingy) to init the vtable at runtime?  this is the
"right way" in the sense that the springboard function isn't used, so
it's most efficient at the expense of a few extra bytes of init
function..

-- hack the dllimport attribute so that when it's applied to a class,
it filters down only to members that are static data or non-virtual
functions, and is automatically turned off for virtual functions (even
if you try to do it manually, I guess)?  this has the advantage of not
touching the front end, just config/i386/winnt.c (or that's my initial
impression)..

-- something else?

thanks,

Geoff Schmidt
gschmidt@mit.edu

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gcc bug relating to __declspec(dllimport)?

[Mumit Khan]

geoff schmidt <gschmidt@mit.edu> writes:
> Hi!
> 
> With gcc 2.95.2 targeting mingw32 from linux, this code:
> 
> /*--- xyz.cpp ---------------------------------------------------------------
> */
> #include "xyz.h"
> 
> #pragma implementation "foo"
> #pragma interface "foo"
> 
> class two: public one {};
> 
> /*--- xyz.h -----------------------------------------------------------------
> */
> #pragma interface "bar"
> 
> class __declspec(dllimport) one {
>  public:
>   // virtual ~one(void); // see note
>   virtual void func(void);
> } ;
> 
> /*---------------------------------------------------------------------------
> */
> 
> gets me:
> 
> $ gcc xyz.cpp
> xyz.cpp:6: Internal compiler error, output_operand_lossage `invalid
> expression as operand'
> 
> If I use -fno-rtti, I have to uncomment the virtual destructor to get
> the same behavior.
> 
> I know that this error message has come up on the list before, but I'm
> pretty sure that this instance is an actual bug and not a result of
> trying to do things that are impossible with imported DLL data -- 
> because the above code is a snippet from the wxWindows cross-platform
> GUI library, which compiles happily under several different windows
> compilers.  Or am I missing something obvious?
> 
> Am I doing something wrong?  Is there a way to work around this?  If
> it's a bug, I'd be willing to take a stab at a patch if someone can
> point me in the right direction.
> 

There are a few nasty bugs when you have virtual functions and also
inline functions in DLL imported classes. It's going to take quite
a few tweaks in the C++ front end to fix these, and unfortunately
I don't have the time right now. Hopefully someone else will jump
in fix these ... the vtable issue is particular harder to fix since
the GNU C++ vtables use offsets, which don't work for dllimported
functions.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

Jason Merrill <jason@cygnus.com> writes:
> What does VC++ do?
> 

Give me a day or two to dig out and run my tests with VC++. The MSDN 
docs have some info, but extremely scattered, so that's usually not 
much help in this matter, especially when it comes implementation 
details. 

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: gcc bug relating to __declspec(dllimport)?

[Chris Faylor]

On Wed, Nov 17, 1999 at 05:27:34AM -0500, geoff schmidt wrote:
>xyz.cpp:6: Internal compiler error, output_operand_lossage `invalid
>expression as operand'
>
>I know that this error message has come up on the list before, but I'm
>pretty sure that this instance is an actual bug and not a result of
>trying to do things that are impossible with imported DLL data -- 
>because the above code is a snippet from the wxWindows cross-platform
>GUI library, which compiles happily under several different windows
>compilers.  Or am I missing something obvious?

Well, if it says "internal compiler error" it is an actual gcc bug.
There is no doubt about that.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

Geoff,

Thanks for your comments on the dllimport/dllexport business, especially
with respect to the C++ front end. I haven't looked at your proposal in
detail yet (I tried, but my attention span just isn't there thanks to
my schedule), but I'll hopefully comment this weekend. Hopefully the
C++ maintainer(s) will jump in as well. I don't know how the new ABI
will affect this issue.

Would you be willing to take on fixing some of these problems?

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Jason Merrill]

What does VC++ do?

Jason

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

gcc bug relating to __declspec(dllimport)?

[geoff schmidt]

Hi!

With gcc 2.95.2 targeting mingw32 from linux, this code:

/*--- xyz.cpp ---------------------------------------------------------------*/
#include "xyz.h"

#pragma implementation "foo"
#pragma interface "foo"

class two: public one {};

/*--- xyz.h -----------------------------------------------------------------*/
#pragma interface "bar"

class __declspec(dllimport) one {
 public:
  // virtual ~one(void); // see note
  virtual void func(void);
} ;

/*---------------------------------------------------------------------------*/

gets me:

$ gcc xyz.cpp
xyz.cpp:6: Internal compiler error, output_operand_lossage `invalid
expression as operand'

If I use -fno-rtti, I have to uncomment the virtual destructor to get
the same behavior.

I know that this error message has come up on the list before, but I'm
pretty sure that this instance is an actual bug and not a result of
trying to do things that are impossible with imported DLL data -- 
because the above code is a snippet from the wxWindows cross-platform
GUI library, which compiles happily under several different windows
compilers.  Or am I missing something obvious?

Am I doing something wrong?  Is there a way to work around this?  If
it's a bug, I'd be willing to take a stab at a patch if someone can
point me in the right direction.

thanks very much,

geoff schmidt
gschmidt@mit.edu

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

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;
> 
> to the beginning of i386_pe_dllimport_p in winnt.c.  With this patch
> I've successfully compiled and used a large OOP GUI framework with
> lots of inline and virtual functions as a DLL.  Only tested with
> -fvtable-thunks.

I dug through MSVC's output a bit, and it does something similar[1]
I'm going to try out your change and see if it's indeed the solution. 
I actually had this change way back (winnt.c still has code commented 
out from that experiment), but was never quite sure if it was the right 
thing to do or not.  

Thanks again for working on this problem. 

[1] MSVC's language front-ends understand the dllimport/dllexport 
directives, and do quite a bit more. One example is the following
code:

  /* top level. */
  __declspec(dllimport) extern int foo();
  int (*bar) () = foo;

this will emit different code in C and C++, but that's awkward to do in
language-independent GCC backend in the current implemention in winnt.c.
C will use the thunk (foo), and C++ will use __imp__foo to initialize
bar.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

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

[Mumit Khan]

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;
> 
> to the beginning of i386_pe_dllimport_p in winnt.c.  With this patch
> I've successfully compiled and used a large OOP GUI framework with
> lots of inline and virtual functions as a DLL.  Only tested with
> -fvtable-thunks.

I dug through MSVC's output a bit, and it does something similar[1]
I'm going to try out your change and see if it's indeed the solution. 
I actually had this change way back (winnt.c still has code commented 
out from that experiment), but was never quite sure if it was the right 
thing to do or not.  

Thanks again for working on this problem. 

[1] MSVC's language front-ends understand the dllimport/dllexport 
directives, and do quite a bit more. One example is the following
code:

  /* top level. */
  __declspec(dllimport) extern int foo();
  int (*bar) () = foo;

this will emit different code in C and C++, but that's awkward to do in
language-independent GCC backend in the current implemention in winnt.c.
C will use the thunk (foo), and C++ will use __imp__foo to initialize
bar.

Regards,
Mumit


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com