From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27901 invoked by alias); 31 Mar 2010 22:05:12 -0000 Received: (qmail 27051 invoked by uid 48); 31 Mar 2010 22:04:51 -0000 Date: Wed, 31 Mar 2010 22:05:00 -0000 Message-ID: <20100331220451.27050.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/43601] Enormous increase in DLL object files size in 4.5 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "vz-gcc at zeitlins dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-03/txt/msg03211.txt.bz2 ------- Comment #2 from vz-gcc at zeitlins dot org 2010-03-31 22:04 ------- I'm sorry but is this really all you have to say about this? Granted, VS does follow the same rule but the size of object files produced by it was twice less than that of object files produced by gcc _before_ this change and it would seem to me that keeping the size of object files reasonable should have higher precedence than implementing the same behaviour that the Microsoft compiler implements. I don't know how does VS manage to avoid this exponential growth of object files but it demonstrably does while gcc does not. Once again, it's a serious problem for many developers that the size of object files is now 500MB instead of 50MB. Linking a module from 500MB of object files requires a lot of RAM and takes a long time. And, to top it all, the change resulting in this regression (because from the point of view of any gcc user this is how it will look) doesn't bring any tangible benefits -- compatibility with VS notwithstanding. While generating inline methods in DLL might be desirable (although the patch also only speaks about ARM ABI so it doesn't seem like this is really _required_ under x86/x64), it seems strange to completely disregard practical consequences of this lofty idea. Please reconsider your decision, IMO at least an option restoring the old behaviour (with a prominent mention in release notes/changelog) is badly needed. P.S. Personally, I'd also love to understand why exactly was this change considered so desirable at all. But this is just out of my personal curiosity. What really matters is that plenty of people will be simply unable to compile projects which they had no trouble compiling with gcc 4.4. This will result in massive amounts of pain all around. -- vz-gcc at zeitlins dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |UNCONFIRMED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601