http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #64 from PcX 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #63 from Vadim Zeitlin 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #62 from PcX 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 a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #61 from Dave Korn 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
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #60 from Dongsheng Song
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: 12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #59 from PcX 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #58 from Dongsheng Song
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 regis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #57 from Dongsheng Song
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 ra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #56 from Dave Korn 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Dongsheng Song changed:
What|Removed |Added
CC||dongsheng.song at gmail dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #54 from PcX 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 fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
PcX changed:
What|Removed |Added
CC||xunxun1982 at gmail dot com
--- Comment #53 from Pc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Dave Korn changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Dave Korn changed:
What|Removed |Added
Keywords||patch
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #50 from Yuchen Deng 2011-01-09 23:48:09
UTC ---
Good news!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #49 from Dave Korn 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Dave Korn changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #48 from Vadim Zeitlin 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 unders
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #47 from Andrew Pinski 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/sematic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #46 from Vadim Zeitlin 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 th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #45 from Vadim Zeitlin 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Vadim Zeitlin changed:
What|Removed |Added
Attachment #22041|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #43 from Vadim Zeitlin 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)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #42 from Vadim Zeitlin 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #41 from Dave Korn 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #40 from Vadim Zeitlin 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 l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Vadim Zeitlin changed:
What|Removed |Added
Attachment #22037|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #38 from Vadim Zeitlin 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #37 from Vadim Zeitlin 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #36 from Dave Korn 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 obj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #35 from Vadim Zeitlin 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 b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #34 from Andrew Pinski 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #33 from Loaden YC 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?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #32 from Cesar Strauss 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #31 from Vadim Zeitlin 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 | c++filt
>
> you will see that 4.4 still generates one section per
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #30 from Cesar Strauss 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 use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #29 from Vadim Zeitlin 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 i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #28 from Cesar Strauss 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
> be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
--- Comment #27 from Cesar Strauss 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
> bef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601
Yu Simin changed:
What|Removed |Added
CC||silver24k at gmail dot com
--- Comment #26 fro
--- 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
--- 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 apparent
--- 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
--- 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
--- 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 ab
--- 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 | 20
--- 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] Silenc
--- 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 perspec
--- 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
--- 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
--
--- 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
--- 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 mira
--- 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, m
--- 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
--- 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 6
--- 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 do
--- 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
--- 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
--- 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
--- 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
--- 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 linke
--- 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
--- 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
--
63 matches
Mail list logo
