[Bug libstdc++/57119] New: libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Bug #: 57119 Summary: libstdc++-6.dll missed in default gcc 4.8 build Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: major

[Bug c/57120] New: Plain C link with libgcc_s_sjlj-1.dll which not needed

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 Bug #: 57120 Summary: Plain C link with libgcc_s_sjlj-1.dll which not needed Classification: Unclassified Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: major

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #3 from Dongsheng Song 2013-04-30 10:42:21 UTC --- Created attachment 29979 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29979 x86_64-w64-mingw32/libstdc++-v3/config.log

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #4 from Dongsheng Song 2013-04-30 10:44:03 UTC --- Created attachment 29980 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29980 gcc/config.log

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #5 from Dongsheng Song 2013-04-30 10:46:54 UTC --- (In reply to comment #2) > Hmm, I can't reproduce that. I just built things myself again for 4.8.1 gcc. > I am a bit curious to read that due distributions like Fedora seem to

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 Dongsheng Song changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|

[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 Dongsheng Song changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #8 from Dongsheng Song 2013-04-30 11:29:10 UTC --- (In reply to comment #7) > Hmm, only issue I see is the use of '--disable-nls' option, which is known to > cause issue. See here PR 54659. > > Another question I have is, wh

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #9 from Dongsheng Song 2013-04-30 11:41:29 UTC --- Created attachment 29981 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29981 gcc/config-v2.log

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #10 from Dongsheng Song 2013-04-30 11:42:27 UTC --- Created attachment 29982 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29982 i686-w64-mingw32/libstdc++-v3/config-v2.log

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #11 from Dongsheng Song 2013-04-30 11:43:42 UTC --- Please see gcc/config-v2.log and i686-w64-mingw32/libstdc++-v3/config-v2.log, still not build libstdc++-6.dll

[Bug target/57120] Plain C link with libgcc_s_sjlj-1.dll which not needed

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57120 --- Comment #4 from Dongsheng Song 2013-04-30 11:53:35 UTC --- libgcc_s_sjlj-1.dll export the following symbos: [Ordinal/Name Pointer] Table [ 0] _Unwind_Backtrace [ 1] _Unwind_DeleteException [ 2] _Unwind

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #13 from Dongsheng Song 2013-04-30 14:46:43 UTC --- (In reply to comment #12) > Hmm, I don't see in config.log any difference to the variant I have built on > my > box. Shared is actual enabled in you config.log for libstdc++

[Bug c/47142] New: incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 Summary: incorrect libgcc_s_sjlj-1.dll install Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.g

[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with "cannot check for file existence when cross compiling"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 Dongsheng Song changed: What|Removed |Added CC||dongsheng.song at gmail dot

[Bug libstdc++/47145] [4.6 Regression] cross-compilation fails with "cannot check for file existence when cross compiling"

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47145 --- Comment #18 from Dongsheng Song 2011-01-05 05:31:08 UTC --- This xml catalog testing passed on Debian and RHEL: echo '' | xsltproc --noout --nonet \ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl -

[Bug lto/47528] New: liblto_plugin.so not found should not to be an fatal error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 Summary: liblto_plugin.so not found should not to be an fatal error Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #2 from Dongsheng Song 2011-01-31 14:34:07 UTC --- (In reply to comment #1) > I think you use an old GCC snapshot (if you didn't pass -fuse-linker-plugin > manually). That said, your target should not use the flag unconditionally, >

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #3 from Dongsheng Song 2011-02-01 07:28:37 UTC --- Confirmed, $ svn info ${GCC_SOURCE_DIR} Path: /home/oracle/vcs/svn/gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #2 from Dongsheng Song 2011-02-04 00:09:50 UTC --- (In reply to comment #1) > Hmm, this issue seems to be fixed already. At least for my installation > libgcc_s DLL is put into corresponding lib-folder, too. > > Could you please rete

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #3 from Dongsheng Song 2011-02-04 01:33:55 UTC --- (In reply to comment #2) > (In reply to comment #1) > > Hmm, this issue seems to be fixed already. At least for my installation > > libgcc_s DLL is put into corresponding lib-folder,

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #5 from Dongsheng Song 2011-02-04 13:29:09 UTC --- (In reply to comment #4) > Could you please check if this patch solves the issue for multilib? (It treats > multilib scenario like cross for installation of dll files). > > Index: co

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #6 from Dongsheng Song 2011-02-04 14:26:44 UTC --- (In reply to comment #5) > My next complete building will be started at 23:50 PM(UTC), if I got different > answer, I will inform you. OOPS, libgcc_s_sjlj-1.dll installed OK. But the

[Bug target/47142] incorrect libgcc_s_sjlj-1.dll install

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #8 from Dongsheng Song 2011-02-04 16:05:13 UTC --- On Fri, Feb 4, 2011 at 23:54, ktietz at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 > > --- Comment #7 from Kai Tietz 2011-02-04 15:54:10 > UTC --- >

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #5 from Dongsheng Song 2011-02-08 06:41:50 UTC --- (In reply to comment #4) > Does it help on cross-compile to do after 'make all-gcc && make install-gcc' > to > do additionally 'make install-lto-plugin'? > > The fatal error in gcc.

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #7 from Dongsheng Song 2011-02-08 08:56:26 UTC --- The source of binutils for native compiler same as the cross building compiler, so I think this maybe an autotools bug of binutils: oracle@vc:~/vcs/git/binutils$ git log -1 commit c4

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #9 from Dongsheng Song 2011-02-08 10:04:25 UTC --- Thanks, with the following patch (Windows.h => windows.h), the building OK now: $ git diff ld/configure.in ld/plugin.c diff --git a/ld/configure.in b/ld/configure.in index 2836545..b

[Bug lto/47528] liblto_plugin.so not found should not to be an fatal error

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528 --- Comment #11 from Dongsheng Song 2011-02-08 11:04:32 UTC --- I don't known where I report the following issue: C:\>gcc -O2 -pipe Hello.c C:\>a Hello, World! C:\>gcc -O2 -pipe -flto Hello.c c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 Dongsheng Song changed: What|Removed |Added CC||dongsheng.song at gmail dot

[Bug go/47726] New: language go can not build for mingw target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47726 Summary: language go can not build for mingw target Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: go AssignedTo: i...@air

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #14 from Dongsheng Song 2011-02-15 01:24:02 UTC --- (In reply to comment #13) > So, necessary patch is now committed to binutils. Could you please retest this > issue with a recent binutils/HEAD version? > > Thanks in advance, > Kai

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #15 from Dongsheng Song 2011-02-15 01:25:18 UTC --- Created attachment 23345 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23345 Hello.c.exe running with NULL pointer error

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #16 from Dongsheng Song 2011-02-15 02:42:31 UTC --- (In reply to comment #13) > So, necessary patch is now committed to binutils. Could you please retest this > issue with a recent binutils/HEAD version? > > Thanks in advance, > Kai

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #17 from Dongsheng Song 2011-02-15 02:46:14 UTC --- It seems that libstdc++.dll.a is too small: $ file gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a: c

[Bug lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47241 --- Comment #19 from Dongsheng Song 2011-02-15 08:23:35 UTC --- (In reply to comment #18) > Well, I see the issue you are describing here, but it isn't any longer related > to this PR. So please open an new PR for it. > > So I close this bug as

[Bug libstdc++/47753] New: Invalid 32bit libstdc++.dll.a on mingw-w64 target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47753 Summary: Invalid 32bit libstdc++.dll.a on mingw-w64 target Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assigned

[Bug libstdc++/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47753 --- Comment #2 from Dongsheng Song 2011-02-15 14:57:13 UTC --- (In reply to comment #1) > You say before 2011-02-13: can you figure out which specific commit did it? Do > stock 4.5.2 or 4.5.1 work for you? I checkout source from gcc svn and binu

[Bug libstdc++/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47753 --- Comment #5 from Dongsheng Song 2011-02-15 15:14:27 UTC --- (In reply to comment #3) > Note that since 2010-12-16, when 4.5.2 has been released, only *very small* > changes went into the 4_5-branch libstdc++ code: either the problem already >

[Bug target/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47753 --- Comment #8 from Dongsheng Song 2011-02-20 04:18:08 UTC --- (In reply to comment #7) > Yes, I assume it is a binutils issue. And my bets are going to version-script > issue. I am not 100% sure, but it looks pretty likely, as version-scripts ar

[Bug lto/47891] New: GCC 4.6 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 Summary: GCC 4.6 LTO not worked reliable on Windows target Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: un

[Bug lto/47891] GCC 4.6 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 --- Comment #1 from Dongsheng Song 2011-02-25 03:01:38 UTC --- Sorry, there is a typo: With LTO, it's OK: should be: Without LTO, it's OK:

[Bug lto/47891] GCC 4.6 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 --- Comment #2 from Dongsheng Song 2011-02-25 03:06:01 UTC --- This issues only in 32bit, 64bit is fine: $ i686-w64-mingw32-gcc -m64 -g -flto -o hello.c.64bit.lto.exe Hello.c $ i686-w64-mingw32-objdump -d hello.c.64bit.lto.exe 004029c0

[Bug c/57848] New: internal compiler error on build with mingw-w64

: c Assignee: unassigned at gcc dot gnu.org Reporter: dongsheng.song at gmail dot com $ svn info mingw-w64/trunk/ gcc/trunk/ Path: mingw-w64/trunk URL: svn://svn.code.sf.net/p/mingw-w64/code/trunk Repository Root: svn://svn.code.sf.net/p/mingw-w64/code Repository UUID: 4407c894

[Bug target/57848] internal compiler error on build with mingw-w64

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #1 from Dongsheng Song --- x86_64-w64-mingw32 failed with same errors: $ make all-am make[1]: Entering directory `/home/cauchy/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt' x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/home/cauchy/vcs/

[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #6 from Dongsheng Song --- Linux gcc 4.4.5 (Debian GNU/Linux 6.0), gcc 4.4.7 (Red Hat Enterprise Linux Server release 6.4) failed too.

[Bug c++/57897] New: pragma

dot gnu.org Reporter: dongsheng.song at gmail dot com Due to Bug 57848, I must build gcc 4.9 with '--with-arch=corei7', then the cross compiler building success. But when I use the cross compiler to build native compiler, it failed with: x86_64-w64-mingw32-g++ -c -g -O

[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #1 from Dongsheng Song --- $ ~/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=/home/cauchy/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-

[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #10 from Dongsheng Song --- If your compiler default target support sse4.2, then you can't reproduce it: i686-w64-mingw32-gcc -march=corei7 pr57848.c But when you use target which do not support sse4.2, then the internal compiler err

[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #14 from Dongsheng Song --- Created attachment 30804 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30804&action=edit 32 bit gcc 4.9 build errors

[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #15 from Dongsheng Song --- Yes,it helps, 64 bit gcc 4.9 build fine. but 32 bit failed with lots of 'conflicting types' errors, this maybe another story. $ svn info mingw-w64/trunk/ Path: mingw-w64/trunk URL: svn://svn.code.sf.net/p/m

[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #16 from Dongsheng Song --- Created attachment 30805 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30805&action=edit 64 bit gcc 4.9 - cross to native build errors

[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #19 from Dongsheng Song --- When I use this 64 bit gcc 4.9 cross compiler to generate the native compiler, I got the error: In file included from /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intr

[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #6 from Dongsheng Song --- After revert r192062, I can build gcc smoothly. $ svn log -r 192062 r192062 | uros | 2012-10-04 13:53:22 +0800 (Thu, 04 Oct 2012) | 4

[Bug target/57119] libstdc++-6.dll missed in default gcc 4.8 build

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57119 --- Comment #15 from Dongsheng Song --- gcc 4.7.x never have such issue. for gcc 4.8.x or trunk, I did not build multilib long ago. because I can not build multilib which x64 use SEH, and x86 use SJLJ. I must build with SJLJ for x64 and x86.

[Bug c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 --- Comment #8 from Dongsheng Song --- It's hard to understand SEH reqiure unwind table in DWARF 2 format. can you give me a brief description ? Your patch does not help: $ cat << EOF | ./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -O2 -o `

[Bug target/66634] New: Cross building native *-w64-mingw32 failed

Assignee: unassigned at gcc dot gnu.org Reporter: dongsheng.song at gmail dot com Target Milestone: --- The cross compiler building fine, but when use it to build the native compiler, I got: make[2]: Entering directory '/home/cauchy/obj/native/gcc-6-win64/gcc/gcc' g+

[Bug lto/47891] GCC 4.6 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 --- Comment #4 from Dongsheng Song 2011-03-15 03:30:09 UTC --- (In reply to comment #3) > GCC 4.6.0 also generates a correct executable with `-fno-use-linker-plugin' > option. It's a linker bug. You can try Hongjiu Lu's linker from lto-mixed > br

[Bug lto/47891] GCC 4.6/4.7 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 --- Comment #5 from Dongsheng Song 2011-03-15 03:30:59 UTC --- (In reply to comment #4) > (In reply to comment #3) > > GCC 4.6.0 also generates a correct executable with `-fno-use-linker-plugin' > > option. It's a linker bug. You can try Hongjiu

[Bug lto/47891] GCC 4.6/4.7 LTO not worked reliable on Windows target

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47891 --- Comment #7 from Dongsheng Song 2011-03-15 08:01:34 UTC --- (In reply to comment #6) > > Since gcc 4.6 branched, gcc trunk and 4.6 branch both have this issue now. > > It is not a GCC bug, it's a Binutils bug. The patch >

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43601 Dongsheng Song changed: What|Removed |Added CC||dongsheng.song at gmail dot

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

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

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

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

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

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