------- 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
