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

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

[vz-gcc at zeitlins dot org]

Hello,

 This is not necessarily a bug but I don't know about any other place to
discuss this so I'm reporting it here -- please let me know if I should post
somewhere else.

 Anyhow, there seems to be a big problem with building shared C++ libraries
using the typical

        class __attribute(dllexport) SomePublicClass
        {
        public:
                ... a lot of inline functions without dllexport ...

                ... and also a lot of non-inline functions ...
        };

pattern, wxWidgets being one particular example (but AFAIK there is really
nothing special about wxWidgets here). I've described the problem in details
in http://thread.gmane.org/gmane.comp.gnu.mingw.user/32435 but, basically,
the size of object files produced by mingw32 4.5 has been multiplied by 10
compared to mingw32 4.4 making linking them extremely time consuming and
plainly impossible on machines with modest amounts of RAM.

 This seems to be due to the following change in gcc itself (and not
mingw32): http://gcc.gnu.org/viewcvs?view=revision&revision=147799 and I'd
like to know if there is any way to undo its effect. For example, the reply
from Cesar Strauss in the thread above suggested using -fhide-inline-functions
option for this. IMHO ideal would be to revert to the old behaviour at
least until some better approach can be found but any solution would be
nicer than nothing.

 Thanks in advance,
VZ


-- 
           Summary: Enormous increase in DLL object files size in 4.5
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vz-gcc at zeitlins dot org
  GCC host triplet: i686-pc-mingw32


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2010-03-31 21:47 -------
This is by design and the patch even mentions that  Visual Studio 2005 follows
the same rule. 


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


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

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

[vz-gcc at zeitlins dot org]

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

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

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2010-03-31 22:11 -------
Also this change was done to so we would be compliant to the ARM EABI.

http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01481.html

And if the linker is taking a lot of memory, then it is a bug in the linker. 
The linker should not take much more memory for functions which are linked
once.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2010-03-31 22:12 -------
And really it make sense that the functions are exported are marked as
dllexport even if they are vague linkage.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


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

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

[vz-gcc at zeitlins dot org]

------- Comment #5 from vz-gcc at zeitlins dot org  2010-03-31 22:25 -------
(In reply to comment #3)
> And if the linker is taking a lot of memory, then it is a bug in the linker. 
> The linker should not take much more memory for functions which are linked
> once.

Let's admit this. How does it help us in practice? I'm not aware of any plans
to optimize the linker to deal with this situation better so the fact remains
that the users who could build wxWidgets before won't be able to build it any
more. How should we, as its developers, deal with it? Advise them to contribute
to binutils development? Somehow I am not sure if this is going to work really
well.

And I won't even mention that we still have .5GB of object files for each build
(and you may need to have several and this is not negligible even nowadays if
you use a 80GB SSD).

So while the ideal solution might be to avoid the generation of duplicate
copies of the functions in all object files or making the linker smarter the
fact is that in practice we have a big uncalled for and unwanted regression.
With the only justification (for non-ARM platforms) that "it really makes
sense". IMNSHO it doesn't make sense to break working builds of many thousands
of projects. If you think it does, please explain how should we deal with the
inevitable complaints about it when people start switching to gcc 4.5. I
frankly have absolutely no idea.

I won't insist any more but for one last time: Please, please, please try to
view the situation from a gcc user and not gcc developer point of view. Just
imagine that you try a new minor release of the compiler and suddenly the build
takes much longer or maybe doesn't complete at all because linker runs out of
memory. What are you going to do and how are you going to deal with it? And
this is not a whimsical scenario but will likely apply to the *majority* of
non-trivial C++ projects as many of them use some class library with a lot of
inline function inside dllexported classes, be it wxWidgets, Qt or whatever
else.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2010-03-31 22:32 -------
My view this is a bug in how wxWidgets uses (abuses) dllexport and wanting not
to export inline functions also.


-- 


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

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

[vz-gcc at zeitlins dot org]

------- Comment #7 from vz-gcc at zeitlins dot org  2010-03-31 22:36 -------
(In reply to comment #6)
> My view this is a bug in how wxWidgets uses (abuses) dllexport and wanting not
> to export inline functions also.

Andrew, could you please provide a reasonable alternative to what we do?

Also, once again, I'm only aware of this problem because of a bug report of a
wxWidgets user but I really don't think there is anything specific to wx here.
To the best of my knowledge absolutely nobody is masochistic enough to export
every non-inline function in a class separately, all C++ projects supporting
Win32 DLL I ever saw used dllexport declaration with the class itself.

So, once again, if this is our bug, would you be so kind as to propose a
solution? I'm sure many other C++ library developers would be interested in
hearing it as well.

TIA!


-- 


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

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

[bangerth at gmail dot com]

------- Comment #8 from bangerth at gmail dot com  2010-04-02 11:37 -------
I think this is a bug the MingW maintainers should handle.

While I understand Andrew's position, it seems to me that this is nevertheless
a definite regression from the user's perspective.

W.


-- 

bangerth at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at gmail dot com
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WONTFIX                     |


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

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

[vz-gcc at zeitlins dot org]

------- Comment #9 from vz-gcc at zeitlins dot org  2010-04-03 17:15 -------
Just to bring some more hard numbers into this discussion, I've installed both
4.4 and 4.5 (in addition to 3.4.5 which I'll use as a kind of baseline) on my
own machine (4/8 physical/logical CPUs, 8GB of RAM, Windows 7 64 bits). The
results of building the (main) part of wxWidgets with default configure
options excluding some third party libraries (jpeg/tiff/regex):

- With 3.4.5 (mingw-vista special r3):

% time make -sj8 wxcore
make -sj8 wxcore  30.29s user 51.71s system 46% cpu 2:55.61 total
% du -sh lib
24M lib
% du -sSh .
29M .

- With 4.4.0 (GCC):

% time make -sj8 wxcore
make -sj8 wxcore  24.50s user 43.66s system 46% cpu 2:27.97 total
% du -sh lib
29M lib
% du -sSh .
90M .

- With 4.5.0 20100311 (experimental) (GCC):

% time make -sj8 wxcore
make -sj8 wxcore  33.25s user 57.26s system 6% cpu 23:26.19 total
% du -sh lib
80M lib
% du -sSh .
554M .

- Summary of the sizes of the DLL:

% du -h */lib/wxmsw291u_core_gcc_custom.dll
9.2M    wx-mswudll-gcc3.4/lib/wxmsw291u_core_gcc_custom.dll
12M     wx-mswudll-gcc4.4/lib/wxmsw291u_core_gcc_custom.dll
47M     wx-mswudll-gcc4.5/lib/wxmsw291u_core_gcc_custom.dll


The numbers are quite clear and this is without debug information! Notice the
drastic reduction in the CPU usage for 4.5: most of the time is clearly spent
writing the files (and it's an Intel G2 SSD, things would probably be even
worse with a slower disk) and not compiling at all. And while the increase in
the size of the object files (they are mostly what makes for "du -sSh" output)
is less than what was reported before, the size of the DLLs themselves
increased as well (the previous tester couldn't report this as he didn't even
manage to link them, of course).

And while the compilation time change alone (10 times slower!) makes 4.5
unusable IMO, the change in library sizes is pretty horrible too (almost 4
times larger).

I don't know who should handle it but I don't understand how can anybody not
see that it is a real problem.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2010-04-03 17:25 -------
>And while the compilation time change alone

How did you configure 4.5?  Did you use --enable-checking=release ?  If not
then the compile time numbers are not comparable at all.


-- 


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

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

[vz-gcc at zeitlins dot org]

------- Comment #11 from vz-gcc at zeitlins dot org  2010-04-03 17:46 -------
(In reply to comment #10)
> >And while the compilation time change alone
> 
> How did you configure 4.5?  Did you use --enable-checking=release ?  If not
> then the compile time numbers are not comparable at all.

Ok, maybe this is the reason then? Because I have, in the version downloaded
from
http://sourceforge.net/projects/mingw/files/MinGW%20Proposed/gcc-4.5.0_20100311-2/gcc-core-4.5.0_20100311-2-mingw32-bin.tar.lzma/download,
the following:

% /dev/mingw/4.5.0/bin/gcc -v
Using built-in specs.
COLLECT_GCC=c:\dev\mingw\4.5.0\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/dev/mingw/4.5.0/bin/../libexec/gcc/mingw32/4.5.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.0_20100311/configure
--enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions
--with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry
--enable-libstdcxx-debug --enable-version-specific-runtime-libs
--disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.0 20100311 (experimental) (GCC)

i.e. --enable-checking=release is not there. But can this affect the object
file and DLL sizes too?


-- 


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

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

[vz-gcc at zeitlins dot org]

------- Comment #12 from vz-gcc at zeitlins dot org  2010-04-03 18:17 -------
Actually I don't think --enable-checking=release changes anything. I've just
tried Cesar Strauss's suggestion to not use __attribute__((dllexport)) in the
code at all but use --enable-auto-import linker option. And miraculously this
solves all the problems:

% ..configure with LDFLAGS=-Wl,--enable-auto-import ...
% time make -sj8 wxcore
make -sj8 wxcore  18.02s user 34.75s system 34% cpu 2:34.81 total
% du -sh lib
26M     lib
% du -sSh .
24M .
% du -h lib/wxmsw291u_core_gcc_custom.dll
8.7M    lib/wxmsw291u_core_gcc_custom.dll

To summarize: the compilation time is the same as with 4.4 (7s difference is
roughly the same as measurement precision anyhow) and the library size is even
smaller than with 3.4.5.

So it seems that dllexport attribute should simply never be used with 4.5. I
was opposed to using --enable-auto-import initially because it exports too much
(there are plenty of symbols which shouldn't be exported in the DLL export
table now) but its advantages are such that we're clearly going to do it with
4.5.

I still wish somebody could explain me why can auto import work so efficiently
but dllexport had to be made unusable like this.


-- 


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

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

[dannysmith at users dot sourceforge dot net]

------- Comment #13 from dannysmith at users dot sourceforge dot net  2010-04-04 08:20 -------
(In reply to comment #11)
> (In reply to comment #10)
> > >And while the compilation time change alone
> > 
> > How did you configure 4.5?  Did you use --enable-checking=release ?  If not
> > then the compile time numbers are not comparable at all.
>
<snip> 
> gcc version 4.5.0 20100311 (experimental) (GCC)
> 

This will cause defau;t checks for experimental DEV-PHASE to be enabled.
Danny 


-- 


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

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

[tdragon at tdragon dot net]

------- Comment #14 from tdragon at tdragon dot net  2010-04-23 00:05 -------
This affects a *ton* of code in the wild. Can we at least get a command line
flag like "-fno-emit-inline-dllexports"?


-- 

tdragon at tdragon dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tdragon at tdragon dot net


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

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

[loaden at gmail dot com]

------- Comment #15 from loaden at gmail dot com  2010-05-03 11:11 -------
The problem is too serious! I have 4G memory, but not able to compile wxWidgets
2.8.10.


-- 


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

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

[a14331990 at hotmail dot com]

------- Comment #16 from a14331990 at hotmail dot com  2010-05-15 06:01 -------
(In reply to comment #8)
> I think this is a bug the MingW maintainers should handle.
> 
> While I understand Andrew's position, it seems to me that this is nevertheless
> a definite regression from the user's perspective.
> 
> W.
> 

Yes, I think this is mostly a mingw bug, but I think developers of cygwin, a
very similar project had already resolved this issue, they had enabled
auto-import by default in ld, please follow this post
[PATCH] Silence ld auto-import warnings for pe-i386.
http://sourceware.org/ml/binutils/2009-02/msg00341.html
for details.
   With auto-import enabled by default in ld, there is no need to emit exported
inline functions in gcc code.
   See my workaround here:
FYI: GCC 4.5.0 on Mingw.org
http://forums.codeblocks.org/index.php/topic,12183.msg85066.html#msg85066


-- 


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

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

[a14331990 at hotmail dot com]

------- Comment #17 from a14331990 at hotmail dot com  2010-05-15 09:29 -------
Created an attachment (id=20662)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20662&action=view)
enable auto-import in ld

This patch comes from a post by Dave Korn and is slightly modified by me
[PATCH] Silence ld auto-import warnings for pe-i386.
http://sourceware.org/ml/binutils/2009-02/msg00341.html


-- 


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

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

[a14331990 at hotmail dot com]

------- Comment #18 from a14331990 at hotmail dot com  2010-05-15 09:31 -------
Created an attachment (id=20663)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20663&action=view)
don't emit dllexport'd inline functions

This patch is just a removal of nathan's code.
See
r147799 | nathan | 2009-05-22 22:57:15 +0800 (Fri, 22 May 2009) | 16 lines
in gcc svn log


-- 


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

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

[stahta01 at students dot ipfw dot edu]

------- Comment #19 from stahta01 at students dot ipfw dot edu  2010-05-15 11:53 -------
Should not the options -fvisibility-inlines-hidden or -fvisibility=hidden fix
this problem? Option found on http://gcc.gnu.org/wiki/Visibility.
Note: The MinGW GCC 4.5.0-1 does not make smaller DLLs using above options.





-- 


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

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

[a14331990 at hotmail dot com]

------- Comment #20 from a14331990 at hotmail dot com  2010-05-15 13:24 -------
(In reply to comment #19)
> Should not the options -fvisibility-inlines-hidden or -fvisibility=hidden fix
> this problem? Option found on http://gcc.gnu.org/wiki/Visibility.
> Note: The MinGW GCC 4.5.0-1 does not make smaller DLLs using above options.
> 
> 
> 
> 

I don't think these option can undo the change by nathan at 2009-05-22
------------------------------------------------------------------------
r147799 | nathan | 2009-05-22 22:57:15 +0800 (Fri, 22 May 2009) | 16 lines

   gcc/
   * tree.c (handle_dll_attribute): Mark dllexport'd inlines as
   non-external.

   gcc/cp
   * decl2.c (decl_needed_p): Consider dllexport'd functions needed.
   * semantics.c (expand_or_defer_fn): Similarly.

   gcc/testsuite/
   * gcc.dg/dll-6.c: New test.
   * gcc.dg/dll-6a.c: Likewise.
   * gcc.dg/dll-7.c: Likewise.
   * gcc.dg/dll-7a.c: Likewise.
   * g++.dg/ext/dllexport2.C: Likewise.
   * g++.dg/ext/dllexport2a.cc: Likewise.

------------------------------------------------------------------------

   BTW, say SORRY to nathan, your change is indeed useful for building
libstdc++ dll, but I have found an alternative approach. 

Indeed, the explanation page
http://gcc.gnu.org/wiki/Visibility
says "How to use the new C++ visibility support
In your header files, wherever you want an interface or API made public outside
the current DSO, place __attribute__((visibility("default"))) in struct, class
and function declarations you wish to make public (it's easier if you define a
macro as this). You don't need to specify it in the definition. Then, alter
your make system to pass -fvisibility=hidden to each call of GCC compiling a
source file.", 
this means to use these options, you should alter your header files first, but
wxwidgets source code apparently don't contain anything like
"__attribute__((visibility("default")))".
    Correct me if I'm wrong.


-- 


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

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

[vanboxem dot ruben at gmail dot com]

------- Comment #21 from vanboxem dot ruben at gmail dot com  2010-09-22 10:06 -------
What is the status of this problem? Having every project depending on
MinGW(.org/-w64) toolchains modify their code is not an option. I see that the
main problem is dllexported *inline* functions. 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).

IMO this would 
a) fix the large object file size
b) consequently fix ld out of memory issues
c) work fine for old sources which expect old behavior because ld has
auto-import enabled.

This has been a long-standing issue, which needs a fix soon.

PS: this bug should be marked as NEW and the affected host and target should be
*-*-mingw*. Could someone who can change that, do that please?


-- 

vanboxem dot ruben at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vanboxem dot ruben at gmail
                   |                            |dot com


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

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

[davek at gcc dot gnu dot org]

------- Comment #22 from davek at gcc dot gnu dot org  2010-09-23 03:56 -------
(In reply to comment #20)

> Indeed, the explanation page
> http://gcc.gnu.org/wiki/Visibility
 [ ... ]
> this means to use these options, you should alter your header files first, but
> wxwidgets source code apparently don't contain anything like
> "__attribute__((visibility("default")))".

Visibility is only supported on platforms that use the ELF file format;
dllexport/dllimport already is the equivalent feature for windows.


-- 


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

[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

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

[xunxun1982 at gmail dot com]

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

--- Comment #64 from PcX <xunxun1982 at gmail dot com> 2011-06-08 14:26:05 UTC ---
I found that the shared or static gcc edition made a great difference of the wx
unicode release mono dll size.
-----------------------------
At first, I build the gcc 4.6 with "--enable-static --enable-shared", and then
I use the gcc edition to compile wx2.8.12 unicode release mono dll, that is, 

mingw32-make -f makefile.gcc CXXFLAGS="-Os -fno-keep-inline-dllexport"
LDFLAGS="-static -Wl,-s"

this gcc edition can produce the wx dll size about 6-7M, and the dll depends no
any gcc dll.
----------------------------
Another day, I build the gcc4.6 with "--enable-static --disable-shared", and
then do the similar thing, that is,

mingw32-make -f makefile.gcc CXXFLAGS="-Os -fno-keep-inline-dllexport"
LDFLAGS="-Wl,-s"

this gcc edition can produce the wx dll size very large, about 17M, and the dll
depends no any gcc dll, too.
----------------------------

That's why?

Thanks.

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

[vz-gcc at zeitlins dot org]

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

--- Comment #63 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2011-04-21 14:04:37 UTC ---
(In reply to comment #61)
> (In reply to comment #59)
> 
> > I review the patch, and found that we can add "-fno-keep-inline-dllexport" to
> > the compiler option, and then, the compiler and linker stage works well. But
> > the wxWidgets release mono dll's size is so large.(about 17M)
> 
> In newer versions of GCC there is also a lot more debug info and Dwarf-2
> exception table data that didn't used to be there.

FWIW wxWidgets hardly uses exceptions (it has only two try/catch blocks that
basically rethrow an exception thrown by user code but the library doesn't
throw any exceptions itself). It does/can be configured to use the standard
containers which do use exceptions however.

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

[xunxun1982 at gmail dot com]

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

--- Comment #62 from PcX <xunxun1982 at gmail dot com> 2011-04-21 01:28:02 UTC ---
(In reply to comment #61)
> (In reply to comment #59)
> 
> > I review the patch, and found that we can add "-fno-keep-inline-dllexport" to
> > the compiler option, and then, the compiler and linker stage works well. But
> > the wxWidgets release mono dll's size is so large.(about 17M)
> 
> In newer versions of GCC there is also a lot more debug info and Dwarf-2
> exception table data that didn't used to be there.  Stripping the dll and/or
> building a compiler with SJLJ rather than dwarf exceptions might help, although
> SJLJ trades off executable size for slower runtime.  (Badly; dwarf exceptions
> only take CPU time when one is actually thrown, whereas SJLJ exceptions take
> CPU time every time you enter or exit a try block.  Since exceptions are meant
> to be exceptional conditions that only happen occasionally, this tradeoff is
> probably worthwhile on desktop platforms where memory is not in short supply,
> but SJLJ might still be better on embedded platforms where memory is so
> critical that slower runtime performance might be the preferable option.)

I know that, but I have stripped the dll...
With dw2 gcc, mingw gcc4.5.2 can produce the 6M wx release dll (after strip).

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

[davek at gcc dot gnu.org]

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

--- Comment #61 from Dave Korn <davek at gcc dot gnu.org> 2011-04-21 00:40:17 UTC ---
(In reply to comment #59)

> I review the patch, and found that we can add "-fno-keep-inline-dllexport" to
> the compiler option, and then, the compiler and linker stage works well. But
> the wxWidgets release mono dll's size is so large.(about 17M)

In newer versions of GCC there is also a lot more debug info and Dwarf-2
exception table data that didn't used to be there.  Stripping the dll and/or
building a compiler with SJLJ rather than dwarf exceptions might help, although
SJLJ trades off executable size for slower runtime.  (Badly; dwarf exceptions
only take CPU time when one is actually thrown, whereas SJLJ exceptions take
CPU time every time you enter or exit a try block.  Since exceptions are meant
to be exceptional conditions that only happen occasionally, this tradeoff is
probably worthwhile on desktop platforms where memory is not in short supply,
but SJLJ might still be better on embedded platforms where memory is so
critical that slower runtime performance might be the preferable option.)

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

[dongsheng.song at gmail dot com]

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

--- Comment #60 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-04-18 03:48:19 UTC ---
With Kai's great work on binutils, after ld running 172 minutes
(usr + sys), and the memory usage growing to:

VmPeak:  5995156 kB
VmSize:  5995156 kB
VmHWM:   1900732 kB
VmRSS:   1219200 kB
VmData:  5986232 kB

The link finished:
-rwxr-xr-x 1 dongsheng dba 10499584 Apr 18 11:27 wxmsw28u_gcc.dll

I think the memory usage (6GB) and CPU time consume (172 minutes)
have a great room for improvement.

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

[xunxun1982 at gmail dot com]

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

--- Comment #59 from PcX <xunxun1982 at gmail dot com> 2011-04-17 11:06:13 UTC ---
Yea, I review the patch(In reply to comment #57)
> (In reply to comment #56)
> > What works for me on Cygwin, and so may well also work for anyone using MSYS,
> > is setting the heap_chunk_in_mb registry parameter to some value in the range
> > 1024 - 1536.  I use 1024 myself and that gives me sufficient headroom to link
> > libgcj dll, which is huge; if it works for that, it's likely to help with wx
> > dll as well.
> > 
> > http://cygwin.com/cygwin-ug-net/setup-maxmem.html
> 
> I don't think so. Because I observed ld.exe use memory over 1.7GB, so link wx
> monolithic library require use more memory than 32 bit OS limit. For cross
> compile under Linux, link wx can use near 3G memory, it still failed.
> 
> Then link wx require 4G or more memory, maybe someone can try use 64bit linker
> to build single huge monolithic library, tell us the max memory ld used.

I review the patch, and found that we can add "-fno-keep-inline-dllexport" to
the compiler option, and then, the compiler and linker stage works well. But
the wxWidgets release mono dll's size is so large.(about 17M)

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

[dongsheng.song at gmail dot com]

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

--- Comment #58 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-04-10 04:32:23 UTC ---
(In reply to comment #57)
> (In reply to comment #56)
> > What works for me on Cygwin, and so may well also work for anyone using MSYS,
> > is setting the heap_chunk_in_mb registry parameter to some value in the range
> > 1024 - 1536.  I use 1024 myself and that gives me sufficient headroom to link
> > libgcj dll, which is huge; if it works for that, it's likely to help with wx
> > dll as well.
> > 
> > http://cygwin.com/cygwin-ug-net/setup-maxmem.html
> 
> I don't think so. Because I observed ld.exe use memory over 1.7GB, so link wx
> monolithic library require use more memory than 32 bit OS limit. For cross
> compile under Linux, link wx can use near 3G memory, it still failed.
> 
> Then link wx require 4G or more memory, maybe someone can try use 64bit linker
> to build single huge monolithic library, tell us the max memory ld used.

I test on 64bit Linux VM, after ld running 6 CPU hours, use 4728MB memory,
still not finished, so I think there maybe have potential infinite loop and
memory leaks when link many object files.

I don't know this is GCC bug, or ld bug, or both ?

http://sourceware.org/bugzilla/show_bug.cgi?id=12658

ld running 6 hours cpu time, use 4.6GB memory:

VmPeak:  4776608 kB
VmSize:  4734656 kB
VmLck:         0 kB
VmHWM:   3020260 kB
VmRSS:   2982304 kB
VmData:  4728000 kB
VmStk:       100 kB
VmExe:       912 kB
VmLib:      1504 kB
VmPTE:      9232 kB
Threads:        1

Cpu(s):  7.9%us, 11.5%sy,  0.0%ni, 44.4%id, 33.3%wa,  0.2%hi,  2.7%si,  0.0%st
Mem:   3095296k total,  3073516k used,    21780k free,       16k buffers
Swap:  7811064k total,  3905532k used,  3905532k free,     9484k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1110 dongshen  20   0 4623m 2.8g  196 D   49 96.1 358:15.13 ld

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

[dongsheng.song at gmail dot com]

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

--- Comment #57 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-04-07 15:53:38 UTC ---
(In reply to comment #56)
> What works for me on Cygwin, and so may well also work for anyone using MSYS,
> is setting the heap_chunk_in_mb registry parameter to some value in the range
> 1024 - 1536.  I use 1024 myself and that gives me sufficient headroom to link
> libgcj dll, which is huge; if it works for that, it's likely to help with wx
> dll as well.
> 
> http://cygwin.com/cygwin-ug-net/setup-maxmem.html

I don't think so. Because I observed ld.exe use memory over 1.7GB, so link wx
monolithic library require use more memory than 32 bit OS limit. For cross
compile under Linux, link wx can use near 3G memory, it still failed.

Then link wx require 4G or more memory, maybe someone can try use 64bit linker
to build single huge monolithic library, tell us the max memory ld used.

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

[davek at gcc dot gnu.org]

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

--- Comment #56 from Dave Korn <davek at gcc dot gnu.org> 2011-04-07 15:15:14 UTC ---
What works for me on Cygwin, and so may well also work for anyone using MSYS,
is setting the heap_chunk_in_mb registry parameter to some value in the range
1024 - 1536.  I use 1024 myself and that gives me sufficient headroom to link
libgcj dll, which is huge; if it works for that, it's likely to help with wx
dll as well.

http://cygwin.com/cygwin-ug-net/setup-maxmem.html

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

[dongsheng.song at gmail dot com]

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

Dongsheng Song <dongsheng.song at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dongsheng.song at gmail dot
                   |                            |com

--- Comment #55 from Dongsheng Song <dongsheng.song at gmail dot com> 2011-04-06 06:35:11 UTC ---
(In reply to comment #54)
> (In reply to comment #53)
> > If I don't use LTO Optimization, Vadim Zeitlin's patch works well.
> > But if I use LTO Optimization, the compiling speed becomes vey slow, and the
> > linker stage fails. I will get the information: 
> > 
> > lto1.exe: out of memory allocating 1900552 bytes
> > lto-wrapper: g++ returned 1 exit status
> > ld.exe: lto-wrapper failed
> > collect2: ld returned 1 exit status
> > 
> > mingw32-make: *** [wxmsw28u_gcc.dll] Error 1
> 
> BTW, I use gcc 4.6.

me too.

If I use 32bit compiler on windows/Linux, target 32bit windows,
single huge monolithic library build with or without LTO will out of memory, 
multiple libraries build failed with LTO, OK for without LTO.

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

[xunxun1982 at gmail dot com]

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

--- Comment #54 from PcX <xunxun1982 at gmail dot com> 2011-03-16 06:53:47 UTC ---
(In reply to comment #53)
> If I don't use LTO Optimization, Vadim Zeitlin's patch works well.
> But if I use LTO Optimization, the compiling speed becomes vey slow, and the
> linker stage fails. I will get the information: 
> 
> lto1.exe: out of memory allocating 1900552 bytes
> lto-wrapper: g++ returned 1 exit status
> ld.exe: lto-wrapper failed
> collect2: ld returned 1 exit status
> 
> mingw32-make: *** [wxmsw28u_gcc.dll] Error 1

BTW, I use gcc 4.6.

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

[xunxun1982 at gmail dot com]

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

PcX <xunxun1982 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xunxun1982 at gmail dot com

--- Comment #53 from PcX <xunxun1982 at gmail dot com> 2011-03-16 04:42:20 UTC ---
If I don't use LTO Optimization, Vadim Zeitlin's patch works well.
But if I use LTO Optimization, the compiling speed becomes vey slow, and the
linker stage fails. I will get the information: 

lto1.exe: out of memory allocating 1900552 bytes
lto-wrapper: g++ returned 1 exit status
ld.exe: lto-wrapper failed
collect2: ld returned 1 exit status

mingw32-make: *** [wxmsw28u_gcc.dll] Error 1

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

[davek at gcc dot gnu.org]

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

Dave Korn <davek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.6.0

--- Comment #52 from Dave Korn <davek at gcc dot gnu.org> 2011-01-26 01:50:14 UTC ---
Committed rev.169268.

http://gcc.gnu.org/viewcvs?view=revision&revision=169268

(Then added the missing PR refs to the changelogss in the next rev:
http://gcc.gnu.org/viewcvs?view=revision&revision=169269)

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

[davek at gcc dot gnu.org]

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

Dave Korn <davek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                URL|                            |http://gcc.gnu.org/ml/gcc-p
                   |                            |atches/2011-01/msg01432.htm
                   |                            |l
      Known to work|                            |3.4.5
            Version|4.5.0                       |4.6.0
      Known to fail|                            |4.3.4, 4.5.0, 4.6.0

--- Comment #51 from Dave Korn <davek at gcc dot gnu.org> 2011-01-21 04:17:24 UTC ---
Patch submitted.

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

[loaden at gmail dot com]

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

--- Comment #50 from Yuchen Deng <loaden at gmail dot com> 2011-01-09 23:48:09 UTC ---
Good news!

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

[davek at gcc dot gnu.org]

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

--- Comment #49 from Dave Korn <davek at gcc dot gnu.org> 2011-01-09 17:30:31 UTC ---
Created attachment 22935
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22935
trial patch

brings the earlier change that nathan made to always keep dllexported inlines
under control of a command-line flag.  Before:

----------------------------------snip----------------------------------
make[1]: Leaving directory `/tmp/wx/obj-x-ming-clean/utils/wxrc'
Creating library file:
/tmp/wx/obj-x-ming-clean/lib/libwx_mswd_core-2.8.dll.a/op
t/mingw-pr43601-clean/lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/
bin/ld: final link failed: Memory exhausted
collect2: ld returned 1 exit status

make: *** [/tmp/wx/obj-x-ming-clean/lib/wxmsw28d_core_gcc_custom.dll] Error 1

real    79m46.081s
user    50m1.166s
sys     5m45.723s

$ du -cxsh lib/*.dll
59M     lib/wxbase28d_gcc_custom.dll
1.4M    lib/wxbase28d_net_gcc_custom.dll
512K    lib/wxbase28d_xml_gcc_custom.dll
61M     total
----------------------------------snip----------------------------------

... and after ... 

----------------------------------snip----------------------------------
Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_aui-2.8.dll.a
Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_richtext-2.8.dll.a
Creating library file: /tmp/wx/obj-x-ming-new/lib/libwx_mswd_xrc-2.8.dll.a

real    39m32.531s
user    21m52.641s
sys    4m53.111s


$ du -cxsh lib/*.dll
33M     lib/wxbase28d_gcc_custom.dll
1.3M    lib/wxbase28d_net_gcc_custom.dll
512K    lib/wxbase28d_xml_gcc_custom.dll
5.2M    lib/wxmsw28d_adv_gcc_custom.dll
2.2M    lib/wxmsw28d_aui_gcc_custom.dll
117M    lib/wxmsw28d_core_gcc_custom.dll
4.7M    lib/wxmsw28d_html_gcc_custom.dll
576K    lib/wxmsw28d_qa_gcc_custom.dll
4.2M    lib/wxmsw28d_richtext_gcc_custom.dll
8.2M    lib/wxmsw28d_xrc_gcc_custom.dll
176M    total
----------------------------------snip----------------------------------

Needs testcase + doco before I can submit it.

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

[davek at gcc dot gnu.org]

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

Dave Korn <davek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.01.09 17:25:25
         AssignedTo|unassigned at gcc dot       |davek at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

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

[vz-gcc at zeitlins dot org]

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

--- Comment #48 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 17:29:46 UTC ---
(In reply to comment #47)
> One should note that GCC's implementation of PCH is way different from MSVC's. 
> So comparing with PCH is not the correct thing to do really.

I understand this in theory but in practice nobody uses MSVC without PCH (and I
guess by now most people use PCH with gcc as well but this doesn't change
anything here, of course, as after this change gcc is unusable, with or without
PCH). Anyhow, notice that MSVC still manages to produce correctly-sized DLLs
even without using PCH.

And in any case while comparing with MSVC may be interesting, surely the most
urgent goal is to fix gcc to actually work and not to make it more similar to
MSVC at the price of breaking it completely? I just can't wrap my head around
your arguments, everything you say may be correct (except comment 6) but how do
you deduce from it that the current situation is fine and don't even want to
acknowledge this change for a bug and regression that it is is beyond me.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #47 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-14 17:13:01 UTC ---
One should note that GCC's implementation of PCH is way different from MSVC's. 
So comparing with PCH is not the correct thing to do really.  PCH in GCC is
really preprocessed/sematicized headers rather than header that is an object
file  like in MSVC's case.

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

[vz-gcc at zeitlins dot org]

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

--- Comment #46 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 17:09:05 UTC ---
Another data point after having a closer look at .drectve section in all of the
files: as previously noticed, 4.4 generates "-export" directives for 180
symbols while 4.5 generates them for 2724 symbols. MSVC however records
"/EXPORT" directives for 526 symbols when using PCH and 3764 symbols when not
using PCH. In the latter case the size of the object file also inflates to
3.1MB (with all sections growing, not just the ".drectve" one). So while it's
difficult to compare the sets of symbols because of the different name mangling
schemes used, it does seem that MSVC generates these directives for all of the
class members used, as 4.5 does and unlike 4.4. However many classes included
in 4.5 don't appear at all in the MSVC file when using PCH resulting in much
more reasonable object file sizes.

It still remains that the size of the DLL produced by MSVC is very small
compared to gcc. E.g. the wxbase DLL is 1.9MB with MSVC and 6.5MB with gcc 4.4
while the entire wxcore DLL is just 3.9MB with MSVC and 11.6MB with gcc 4.4,
without even mentioning 4.5 numbers. This is without using any "fancy"
optimizations (i.e. "/LG" and/or "/LTCG" MSVC options). And the size of the DLL
does _not_ depend on whether PCH was used or not (although the compilation
speed and disk consumption of the object files definitely do, by a factor of
more than 10 for both of them).

So maybe the new 4.5 behaviour is indeed more MSVC-like. But MSVC seems to
avoid generating ~80% of the stuff gcc creates when using PCH and its linker
still creates reasonably sized files in reasonable time even when the object
files contain a lot of redundant sections. But using MSVC strategy for gcc
currently is simply disastrous and I still don't understand why shouldn't the
change of r147799 be reverted now and be reapplied later when PCH handling is
improved and/or the linker is capable of dealing with it. If this is not a
regression I honestly don't know what counts as one.

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

[vz-gcc at zeitlins dot org]

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

--- Comment #45 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 16:12:00 UTC ---
Here are the files.

Notice that about half of the size of the MSVC object file is taken by debug
information ("/Zi" option was used when compiling it) while all gcc versions
contain no debug information at all. More details about the file contents can
be obtained using dumpbin Microsoft utility which I'd be glad to run for you if
you don't have it. Here is just an overview for now:

Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file build/msw/vc_mswudll/base/appbase.obj

File Type: COFF OBJECT

  Summary

           4 .CRT$XCU
          29 .bss
         3E9 .data
       345D0 .debug$S
          50 .debug$T
        68D2 .drectve
         E67 .rdata
         8BC .rdata$r
         178 .sxdata
        8A34 .text
        13D3 .text$x
          18 .text$yc
          14 .text$yd
        14B4 .xdata$x

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

[vz-gcc at zeitlins dot org]

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

Vadim Zeitlin <vz-gcc at zeitlins dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22041|0                           |1
        is obsolete|                            |

--- Comment #44 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 16:05:02 UTC ---
Created attachment 22042
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22042
appbase.cpp file from wxWidgets compiled with MSVC 9 (a.k.a. 2008)

Oops, sorry for another double post, I accidentally took a non-DLL version of
the file the first time, this one is the right one.

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

[vz-gcc at zeitlins dot org]

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

--- Comment #43 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 16:01:55 UTC ---
Created attachment 22041
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22041
appbase.cpp file from wxWidgets compiled with MSVC 9 (a.k.a. 2008)

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

[vz-gcc at zeitlins dot org]

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

--- Comment #42 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 16:01:20 UTC ---
Created attachment 22040
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22040
appbase.cpp file from wxWidgets compiled with g++ 3.4

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

[davek at gcc dot gnu.org]

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

--- Comment #41 from Dave Korn <davek at gcc dot gnu.org> 2010-10-14 15:50:53 UTC ---
(In reply to comment #40)
> (In reply to comment #36)
> > could Vadim and/or Cesar please add
> > some of the object files we've been discussing as attachments to this bug
> > report, so that we can all take a close look at why gcc's files are so much
> > bigger?
> 
> I attached 4.4 and 4.5 versions and can also add 3.4 one as well as MSVC9 build
> of the same file, please let me know if this could be useful.
> 
> Thanks!


  Yes please, I'm particularly interested in comparing the gcc files with the
MSVC ones.  (I'm going to be AFK for a few hours now and will look through them
this evening.)

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

[vz-gcc at zeitlins dot org]

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

--- Comment #40 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 15:47:36 UTC ---
(In reply to comment #36)
> could Vadim and/or Cesar please add
> some of the object files we've been discussing as attachments to this bug
> report, so that we can all take a close look at why gcc's files are so much
> bigger?

I attached 4.4 and 4.5 versions and can also add 3.4 one as well as MSVC9 build
of the same file, please let me know if this could be useful.

Thanks!

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

[vz-gcc at zeitlins dot org]

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

Vadim Zeitlin <vz-gcc at zeitlins dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #22037|0                           |1
        is obsolete|                            |

--- Comment #39 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 15:45:41 UTC ---
Created attachment 22039
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22039
appbase.cpp file from wxWidgets compiled with g++ 4.4

Replaces previous file which was uncompressed, sorry for the double post.

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

[vz-gcc at zeitlins dot org]

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

--- Comment #38 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 15:44:23 UTC ---
Created attachment 22038
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22038
appbase.cpp file from wxWidgets compiled with g++ 4.5

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

[vz-gcc at zeitlins dot org]

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

--- Comment #37 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 15:42:59 UTC ---
Created attachment 22037
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22037
appbase.cpp file from wxWidgets compiled with g++ 4.4

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

[davek at gcc dot gnu.org]

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

--- Comment #36 from Dave Korn <davek at gcc dot gnu.org> 2010-10-14 15:37:34 UTC ---
Hi everyone, sorry I've been busy working on LTO stuff for a bit but I haven't
forgotten this.

Before this discussion gets too heated, could Vadim and/or Cesar please add
some of the object files we've been discussing as attachments to this bug
report, so that we can all take a close look at why gcc's files are so much
bigger?  Thanks.

I think depending what we uncover this might be an enhancement request rather
than a bug, but we'll see.

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

[vz-gcc at zeitlins dot org]

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

--- Comment #35 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-10-14 15:24:57 UTC ---
(In reply to comment #34)
> (In reply to comment #33)
> > Because of this issue, I have been using GCC4.4.x, but do not want to upgrade
> > to 4.5.x.
> > Why this issue can not been confirmed?
> 
> The way I read it, this is not a bug as Microsoft Visual Studio acts the same
> way (when their precompiled headers are not included).

This reply either demonstrates complete misunderstanding of the issue or is
deliberate misinformation. To set the record straight, Microsoft Visual Studio
absolutely doesn't act the same way and doesn't generate neither object files
nor DLLs of this ridiculous size, whether precompiled headers are used or not.
Besides, the issue does arise when precompiled headers _are_ used with gcc.

Continuing to justify what is clearly and uncontroversially a bad regression in
gcc by "compatibility with MSVC" which never suffered from this problem and
refusing to even acknowledge the issue, let alone revert the breakage, does no
good whatsoever neither to the gcc project nor to its image.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #34 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-10-14 15:09:52 UTC ---
(In reply to comment #33)
> Because of this issue, I have been using GCC4.4.x, but do not want to upgrade
> to 4.5.x.
> Why this issue can not been confirmed?

The way I read it, this is not a bug as Microsoft Visual Studio acts the same
way (when their precompiled headers are not included).

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

[loaden at gmail dot com]

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

--- Comment #33 from Loaden YC <loaden at gmail dot com> 2010-10-14 12:18:58 UTC ---
Because of this issue, I have been using GCC4.4.x, but do not want to upgrade
to 4.5.x.
Why this issue can not been confirmed?

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

[cestrauss at gmail dot com]

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

--- Comment #32 from Cesar Strauss <cestrauss at gmail dot com> 2010-09-28 00:16:48 UTC ---
(In reply to comment #31)
> This is somewhat off topic but unfortunately (MinGW) c++filt doesn't work for
> me, e.g.:
> 
> % echo '.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe
> .text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv

Try echo '__ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe
Anyway, look at the end of each line of objdump -h <object> | c++filt, where it
says 'COMDAT <name of method>'. 

> > Why there is one section for each emitted inline method?
> 
> Excellent question which I'm unfortunately totally unable to answer.

When two or more source files include the same header, the exported inline
functions end up duplicated in both object files. When linking these objects
together in the final DLL, the linker would give an error because of the
multiple definitions. To avoid this, each exported inline function is placed in
a separate section, identified by the COMDAT name. When the linker sees two or
more sections with the same COMDAT name, it can safely keep one of them and
discard the rest.

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

[vz-gcc at zeitlins dot org]

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

--- Comment #31 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-09-27 22:42:55 UTC ---
(In reply to comment #30)
> Sorry, but I do not completely agree with this assessment. If you run
> 
> objdump -h <object> | c++filt
> 
> you will see that 4.4 still generates one section per method, not per class
> (the name of the method is reveled by c++filt).

This is somewhat off topic but unfortunately (MinGW) c++filt doesn't work for
me, e.g.:

% echo '.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv'|/mingw/bin/c++filt.exe
.text$_ZNK17wxMBConvUTF16Base11GetMBNulLenEv

I don't know what could be wrong with it but, anyhow, you're right, of course,
and I was wrong (I managed to look at the classes whose methods were not used
by the object file I was checking...), sorry for misinformation and thanks for
correcting it!

> In my view, the difference is only that 4.5 emits a section for every inline
> method of every dllexported class in sight. 4.4 only emitted those which the
> code actually needed.

Yes, exactly.

> Why there is one section for each emitted inline method?

Excellent question which I'm unfortunately totally unable to answer.

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

[LpSolit at netscape dot net]

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

--- Comment #30 from Cesar Strauss <cestrauss at gmail dot com> 2010-09-27 02:00:39 UTC ---
(In reply to comment #29)

Dear Vadim

> The difference in number of sections seems to correspond to the fact that 4.5
> now generates one section per method of any exported class used by the object
> file instead of just one section per class as in 4.4.

Sorry, but I do not completely agree with this assessment. If you run

objdump -h <object> | c++filt

you will see that 4.4 still generates one section per method, not per class
(the name of the method is reveled by c++filt).

In my view, the difference is only that 4.5 emits a section for every inline
method of every dllexported class in sight. 4.4 only emitted those which the
code actually needed.

Why there is one section for each emitted inline method? As I understand it,
since the same inline method can be exported by multiple object files, there
would be a danger of having multiple definitions at link time. To avoid this,
they reside in separate sections marked as LINK_ONCE_DISCARD, so the linker can
discard these multiple copies and keep just the first one encountered. 

To avoid all these copies in the first place, the idea from Yu Simin in comment
#26 seems to be a good one.

Regards,
Cesar

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

[vz-gcc at zeitlins dot org]

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

--- Comment #29 from Vadim Zeitlin <vz-gcc at zeitlins dot org> 2010-09-26 22:09:16 UTC ---
Thanks Cesar for your analysis, I was doing the same thing but you beat me to
it. Anyhow, I can confirm your results, i.e. that the increase in size is first
and foremost due to the inflation of the total number of sections (which is
multiplied roughly by 10) as well as the changes to the .eh_frame and .drectve
sections sizes.

I compared the object files for 4.4, 4.5 and 4.5 when using auto-export, i.e.
not using "__attribute__((dllexport))" on exported classes declarations. The
typical results (the exact numbers are, of course, different for each object
file but the trend is the same) are:

             4.4      4.5      4.5-autoexp
------------------------------------------
file size    151K     1.2M       87K
# sections    371     3145        85
.text size  16888    17264     24856
.eh_frame    4004    64424        16
.drectve     8620   113232         0

The difference in number of sections seems to correspond to the fact that 4.5
now generates one section per method of any exported class used by the object
file instead of just one section per class as in 4.4.

Please let me know if I can provide any other information.

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

[cestrauss at gmail dot com]

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

--- Comment #28 from Cesar Strauss <cestrauss at gmail dot com> 2010-09-26 01:11:57 UTC ---
(In reply to comment #25)

>   So I would like to see some proper detailed analysis on object files
> establishing exactly what constitutes all this bloat and where it comes from
> before I commit to what might be the wrong path of action.

Here is a comparison of the output of objdump -h for two compiler versions.
The source is src/common/any.cpp from wxWidgets 2.9.1.
The GCC compilers were downloaded from mingw.org.

GCC 4.5.0 (4.4.0)

Total object file size in bytes: 1,080,971 (110,037)

Total number of sections: 3,062 (318)
Number of:
LINK_ONCE_DISCARD .text$xxx sections: 2,887 (145)
LINK_ONCE_SAME_SIZE typeinfo .rdata$xxx sections: 128 (128)
LINK_ONCE_SAME_SIZE vtable .rdata$xxx sections: 36 (35)
.data$xxx sections: 3 (2)

Size of:
.text: 5,692 (5,308)
.data: 0 (0)
.bss: 72 (88)
.rdata: 2,432 (448)
.gcc_except_table: 5,232 (572)
.ctors: 4 (4)
.eh_frame: 41,996 (2,340)
.drectve: 126,440 (5,416)

Total size of:
LINK_ONCE_DISCARD .text$xxx sections: 132,344 (6,004)
LINK_ONCE_SAME_SIZE typeinfo .rdata$xxx sections: 2,552 (2,552)
LINK_ONCE_SAME_SIZE vtable .rdata$xxx sections: 1,184 (1,160)
.data$xxx sections: 76 (12)

Let me know if you need further info.

I hope this is helpful.

Thanks,
Cesar

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

[cestrauss at gmail dot com]

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

--- Comment #27 from Cesar Strauss <cestrauss at gmail dot com> 2010-09-25 03:07:42 UTC ---
(In reply to comment #25)
>   So I would like to see some proper detailed analysis on object files
> establishing exactly what constitutes all this bloat and where it comes from
> before I commit to what might be the wrong path of action.

Understood. I'll proceed by performing such a detailed analysis.

Also, if you come up with something you want to test, I'll be glad to try any
patches you send my way.

Regards,
Cesar

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

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

[silver24k at gmail dot com]

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

Yu Simin <silver24k at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |silver24k at gmail dot com

--- Comment #26 from Yu Simin <silver24k at gmail dot com> 2010-09-24 20:21:08 UTC ---
[English is not my native language ...]
In GCC 4.5 or later, both the compilation time and the sizes of the generated
object files is far longer or far larger than MSVC when PCH is enabled in both
of the compilers.
MSVC requires a DUMMY source file eg:dummy.cpp to be used when generating the
PCH file and will generate an object file eg:dummy.obj. But the dummy object
file is not dummy at all. It contains all the common codes generated from the
sources/headers of the PCH. 
In GCC, PCH is just preprocess + compiling, no common code (is this case
dllexports) generating. so every compilation unit will have to generate the
codes in the PCH file again and again while MSVC will not generate them once
more.

We may add a flag for example -fgenerate-pch-codes/-fno-generate-pch-codes (or
some pragmas) to make GCC work similar to MSVC.
For example, if we make -fno-generate-pch-codes the default
gcc -O2 -o foo.h.gch foo.h
gcc -O2 -fgenerate-pch-codes -o dummy.o dymmy.cpp  # add this to generate the
codes of foo.h to dummy.o
# assuming that other1.cpp/other2.cpp use foo.h.gch
gcc -O2 -o other1.o other1.cpp # no code in foo.h will be generated on other1.o
gcc -O2 -o other2.o other2.cpp # no code in foo.h will be generated on other2.o
...


Here is my patch (picked from my local copy so maybe someting is missing, a bit
different from above and only handle the dllexport case and may have bug for
trunk). with this patch I successfully built wxWidget 2.8.10 & trunk (slightly
modified to make PCH enabled for GCC and added a dummy file with my pragma
below), the monolithic DLL seems ok (~9M in size, at least the wxWidget demos &
examples work well). 


I only care about the compilation time and the size of objects because it make
ld failed to link the wxWidget DLL on my windows box (I do not want to revert
the dllexports change. before this patch is out， I had to link it on 64bit
linux in VirtualBox by a cross toolchain and the generated DLL is ~25MB! This
size explosion seems to be caused by the inline strategy, but I did not look
into it)

I won't have any time to maintain the patch, just hope it will be useful to
help solving the problem finally.

In this patch I've introduced one flag
-fpch-ignore-inline-dllexports (-fno-pch-ignore-inline-dllexports)
and one pragma
#pragma pch_ignore_inline_dllexports on/off


Index: c-family/c-pragma.c
===================================================================
--- c-family/c-pragma.c (版本 164605)
+++ c-family/c-pragma.c (工作副本)
@@ -1314,7 +1314,9 @@
   if (!flag_preprocess_only)
     cpp_register_deferred_pragma (parse_in, "GCC", "pch_preprocess",
                                  PRAGMA_GCC_PCH_PREPROCESS, false, false);
-
+  cpp_register_deferred_pragma (parse_in, "GCC",
"pch_ignore_inline_dllexports",
+                               PRAGMA_GCC_PCH_IGNORE_INLINE_DLLEXPORTS, false,
false);
+
 #ifdef HANDLE_PRAGMA_PACK
 #ifdef HANDLE_PRAGMA_PACK_WITH_EXPANSION
   c_register_pragma_with_expansion (0, "pack", handle_pragma_pack);
Index: c-family/c-pragma.h
===================================================================
--- c-family/c-pragma.h (版本 164605)
+++ c-family/c-pragma.h (工作副本)
@@ -47,6 +47,8 @@

   PRAGMA_GCC_PCH_PREPROCESS,

+  PRAGMA_GCC_PCH_IGNORE_INLINE_DLLEXPORTS,
+
   PRAGMA_FIRST_EXTERNAL
 } pragma_kind;

Index: cgraph.h
===================================================================
--- cgraph.h    (版本 164605)
+++ cgraph.h    (工作副本)
@@ -125,6 +125,10 @@
   /* True if the function is going to be emitted in some other translation
      unit, referenced from vtable.  */
   unsigned vtable_method : 1;
 };

 /* Information about the function that needs to be computed globally
Index: tree.h
===================================================================
--- tree.h      (版本 164605)
+++ tree.h      (工作副本)
@@ -2706,6 +2706,13 @@
 #define DECL_GIMPLE_REG_P(DECL) \
   DECL_COMMON_CHECK (DECL)->decl_common.gimple_reg_flag

+/* To support fkeep-dllexport-inline-functions-in-pch,
+   indicates that the dllexport inline function is defined in PCH */
+#define DECL_DLLEXPORT_INLINE_IN_PCH_P(DECL) \
+  DECL_COMMON_CHECK (DECL)->decl_common.dllexport_inline_in_pch
+
+
 struct GTY(()) tree_decl_common {
   struct tree_decl_minimal common;
   tree size;
@@ -2759,6 +2765,10 @@
   unsigned int off_align : 8;

   /* 24-bits unused.  */
+
+  /* To support fkeep-dllexport-inline-functions-in-pch */
+  unsigned int dllexport_inline_in_pch : 1;

   /* DECL_ALIGN.  It should have the same size as TYPE_ALIGN.  */
   unsigned int align;
Index: common.opt
===================================================================
--- common.opt  (版本 164605)
+++ common.opt  (工作副本)
@@ -1023,6 +1023,10 @@
 Common Report Var(flag_keep_inline_functions)
 Generate code for functions even if they are fully inlined

+fpch-ignore-inline-dllexports
+Common Report Var(flag_pch_ignore_inline_dllexports) Init(0)
+Do not generate code for inline functions defined in the PCH file
+
 fkeep-static-consts
 Common Report Var(flag_keep_static_consts) Init(1)
 Emit static const variables even if they are not used
Index: cp/semantics.c
===================================================================
--- cp/semantics.c      (版本 164605)
+++ cp/semantics.c      (工作副本)
@@ -3436,9 +3436,19 @@
         be emitted; there may be callers in other DLLs.  */
       if ((flag_keep_inline_functions
           && DECL_DECLARED_INLINE_P (fn)
-          && !DECL_REALLY_EXTERN (fn))
-         || lookup_attribute ("dllexport", DECL_ATTRIBUTES (fn)))
+          && !DECL_REALLY_EXTERN (fn)))
        mark_needed (fn);
+      else if(lookup_attribute ("dllexport", DECL_ATTRIBUTES (fn)))
+        {
+         if (pch_file)
+           {
+             DECL_DLLEXPORT_INLINE_IN_PCH_P (fn) = 1;
+           }
+         mark_needed (fn);
+        }
+
     }

   /* There's no reason to do any of the work here if we're only doing
Index: cp/decl2.c
===================================================================
--- cp/decl2.c  (版本 164605)
+++ cp/decl2.c  (工作副本)
@@ -1784,6 +1784,13 @@
      COMDAT until that point.  */
   gcc_assert (at_eof);

+  if (DECL_DLLEXPORT_INLINE_IN_PCH_P (decl)
+      && flag_pch_ignore_inline_dllexports
+      && !pch_file)
+    return false;
+
   /* All entities with external linkage that are not COMDAT should be
      emitted; they may be referred to from other object files.  */
   if (TREE_PUBLIC (decl) && !DECL_COMDAT (decl))
Index: cp/parser.c
===================================================================
--- cp/parser.c (版本 164605)
+++ cp/parser.c (工作副本)
@@ -23828,6 +23828,30 @@
   cp_lexer_get_preprocessor_token (NULL, first_token);
 }

+static void
+cp_parser_pch_ignore_inline_dllexports (cp_parser *parser)
+{
+  cp_token* tok;
+  /* Handle pch_ignore_inline_exports */
+  tok = cp_lexer_peek_token (parser->lexer);
+  if (tok->type == CPP_NAME)
+    {
+      const char *p = IDENTIFIER_POINTER (tok->u.value);
+
+      if (!strcmp ("on", p))
+       flag_pch_ignore_inline_dllexports = 1;
+      else if(!strcmp ("off", p))
+       flag_pch_ignore_inline_dllexports = 0;
+      else
+       error_at (tok->location,
+                 "expected %<on%> or %<off%>");
+      cp_lexer_consume_token (parser->lexer);
+    }
+  else
+    flag_pch_ignore_inline_dllexports = 1;
+
+}
+
 /* Normal parsing of a pragma token.  Here we can (and must) use the
    regular lexer.  */

@@ -23849,6 +23873,10 @@
                "%<#pragma GCC pch_preprocess%> must be first");
       break;

+    case PRAGMA_GCC_PCH_IGNORE_INLINE_DLLEXPORTS:
+      cp_parser_pch_ignore_inline_dllexports (parser);
+      break;
+
     case PRAGMA_OMP_BARRIER:
       switch (context)
        {
Index: c-parser.c
===================================================================
--- c-parser.c  (版本 164605)
+++ c-parser.c  (工作副本)
@@ -7130,6 +7130,29 @@
 }

+static void
+c_parser_pragma_pch_ignore_inline_dllexports (c_parser *parser)
+{
+  c_parser_consume_pragma (parser);
+
+  if (c_parser_next_token_is (parser, CPP_NAME))
+    {
+      const char *p = IDENTIFIER_POINTER (c_parser_peek_token
(parser)->value);
+      if (!strcmp ("on", p))
+       flag_pch_ignore_inline_dllexports = 1;
+      else if(!strcmp ("off", p))
+       flag_pch_ignore_inline_dllexports = 0;
+      else
+       c_parser_error (parser, "expected %<on%> or %<off%>");
+      c_parser_consume_token (parser);
+    }
+  else
+    flag_pch_ignore_inline_dllexports = 1;
+
+  parser->error = true;
+  c_parser_skip_to_pragma_eol (parser);
+}
+
 /* Handle pragmas.  Some OpenMP pragmas are associated with, and therefore
    should be considered, statements.  ALLOW_STMT is true if we're within
    the context of a function and such pragmas are to be allowed.  Returns
@@ -7194,6 +7217,10 @@
       c_parser_skip_until_found (parser, CPP_PRAGMA_EOL, NULL);
       return false;

+    case PRAGMA_GCC_PCH_IGNORE_INLINE_DLLEXPORTS:
+      c_parser_pragma_pch_ignore_inline_dllexports (parser);
+      return false;
+
     default:
       if (id < PRAGMA_FIRST_EXTERNAL)
        {

-- 
Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.