[Bug c++/43601] Enormous increase in DLL object files size in 4.5

[davek at gcc dot gnu dot org]

------- Comment #23 from davek at gcc dot gnu dot org  2010-09-23 04:08 -------
(In reply to comment #21)
> I see that the main problem is dllexported *inline* functions.

  That is my understanding of it too.

> Can Nathan's change be modified
> to only emit dllexported *non-inline* functions? I see no reason why that
> wouldn't work (and together with auto-import enabled in ld).

  Hmm.  I can think of three approaches, any or all of which might be useful:

- implement "-fno-emit-inline-dllexports" as suggested in comment 14.
- add "nodllexport" and "nodllimport" attributes that can be applied to
individual class members to prevent them inheriting the overall attribute
applied to the class
- modify Nathan's patch to not emit dllexported inline functions when they have
attribute always_inline.

  Of course two of these require annotating the code, so I think that we'd
probably still want #1 as well for convenience.

  I see the thread at http://thread.gmane.org/gmane.comp.gnu.mingw.user/32435
(mentioned in the initial bug report) petered out without any analysis of
exactly where all the file size bloat is coming from.  It would be really
instructive if one of the mingw guys could look at the .o files built by the
two different compiler versions (maybe using "objdump -h" or similar) and try
to find out where all the space is going, particularly making sure it's not
mostly debug or EH tables or something like that.

  Also, it would be good to know if GCC and MSVC really are emitting the same
set of function definitions, as it would be surprising if the figures were that
far apart from each other if they were doing so.  Unless it's some kind of
unexpected contribution from debug/EH data, as suggested earlier, but maybe
there's something malfunctioning in function cloning or something, without a
bit of analysis we can't be sure.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601