Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
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
X-Authentication-Warning: hp2.xraylith.wisc.edu: khan owned process doing -bs
Date: Fri, 17 Dec 1999 23:51:18 -0600 (CST)
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
Reply-To: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
To: gschmidt AT mit DOT edu
cc: Joost Kraaijeveld <JKraaijeveld AT Askesis DOT nl>, cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Internal compiler error in `rest_of_compilation', at toplev.c :441 5 
In-Reply-To: <199912171755.MAA13530@pinball-wizard.mit.edu>
Message-ID: <Pine.HPP.3.96.991217234215.28160D-100000@hp2.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 17 Dec 1999 gschmidt AT BUNSEN-AND-BEAKER DOT MIT DOT EDU wrote:

> dllimport'd virtual function members aren't correctly handled
> currently -- the compiler chokes when it tries to generate the vtable.
> That's not a disaster, because unlike data, functions don't have to be
> declared dllimport for them to be correctly imported.
> 
> I posted a workaround patch for this to the list earlier, and some
> others with more gcc internals clue than myself are working on a
> cleaner and more efficient solution.

I'll have an "update" for gcc-2.95.2 that will fix quite a few of the
known bugs in importing and exporting C++ methods (and C functions).
The method actually is somewhat similar, at least in spirit, to the 
change Geoff had suggested in gcc mailing list.

The gotcha in my update will be the following:
 
 - C++ methods will still use the thunks. Not a big deal.
 - Still won't be able to erroneous code like the one this bug report
   was about (trying to *define* a dll imported method). Even MSVC
   warns about this, and this behaviour IMO can lead to buggy code
   that is hard to track down.
 - lots of extra vtables generated, which makes the executable larger 
   than say what MSVC will produce.

What we're trying to do for gcc-2.96 is more ambitious -- trying to 
match what MSVC does. However, as I keep on finding out, this requires
quite a few tricky changes to the C++ front-end to make certain bits
of information available earlier so that dllimport/export code use it. 
This is turning out to be not so easy. Fingers crossed. Thanks to Jason 
Merrill (C++ co-maintainer) for taking a look at this issue. C++ front-
end is hairy, privy to only a handful of folks out there and I certainly 
am not one of those. Not even by a long shot!

I do hope that users will hold on for a while and we will fix these over
time (contingent upon how much of our free time we're willing to devote
to it of course).

Regards,
Mumit




--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com