Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id: <199911171806.MAA07458@pluto.xraylith.wisc.edu>
To: gschmidt AT mit DOT edu
cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: gcc bug relating to __declspec(dllimport)? 
In-Reply-To: Your message of "Wed, 17 Nov 1999 05:27:34 EST."
             <199911171027 DOT FAA19044 AT pinball-wizard DOT mit DOT edu> 
Date: Wed, 17 Nov 1999 12:06:38 -0600
From: Mumit Khan <khan AT nanotech DOT wisc DOT edu>

geoff schmidt <gschmidt AT mit DOT 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 AT sourceware DOT cygnus DOT com