[Bug target/66634] New: Cross building native *-w64-mingw32 failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66634 Bug ID: 66634 Summary: Cross building native *-w64-mingw32 failed Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target 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++ -DIN_GCC -DGENERATOR_FILE -fno-PIE -no-pie -o build/genmddeps \ build/genmddeps.o build/read-md.o build/errors.o ../build-x86_64-unknown-linux-gnu/libiberty/libiberty.a g++: error: unrecognized command line option ‘-no-pie’ Makefile:2631: recipe for target 'build/genmddeps' failed Checking the gcc-6-win64/gcc/gcc/config.log, I found: configure:28726: checking for -fno-PIE option configure:28737: x86_64-w64-mingw32-g++ -c -g -fno-PIE conftest.cpp 5 configure:28737: $? = 0 configure:28745: result: yes configure:28753: checking for -no-pie option configure:28764: x86_64-w64-mingw32-g++ -o conftest.exe -g -static-libstdc++ -static-libgcc -Wl,--stack,12582912 -no-pie conftest.cpp 5 configure:28764: $? = 0 configure:28773: result: yes So the issue is gcc build script mixed up the target flags and the host flags.
[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 dongsheng.song at gmail dot com --- 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 dongsheng.song at gmail dot com --- 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 `mktemp` -c -x c++ -fasynchronous-unwind-tables - /dev/null #pragma GCC target(sse4a) EOF stdin:1:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH $ ./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=./x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-windows-gcc49/libexec/gcc/x86_64-w64-mingw32/4.9.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure --prefix=/home/cauchy/cross/x86_64-windows-gcc49 --with-sysroot=/home/cauchy/cross/x86_64-windows-gcc49 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=core2 --with-tune=generic Thread model: win32 gcc version 4.9.0 20131206 (experimental) (GCC) Build the gcc 4.9 x64 native compiler from the gcc 4.9 cross compiler still failed: x86_64-w64-mingw32-g++ -c -g -O2 -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include \ /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c In file included from /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:27:0, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/winnt.h:1495, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/minwindef.h:146, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windef.h:8, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windows.h:69, from /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c:29: /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:28: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4.2) ^ make[2]: *** [host-mingw32.o] Error 1 make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc/gcc' make[1]: *** [install-strip-gcc] Error 2 make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc' make: *** [install-strip] Error 2 $ 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-4637-0410-b4f5-ada5f102cad1 Revision: 6392 Node Kind: directory Schedule: normal Last Changed Author: ktietz70 Last Changed Rev: 6392 Last Changed Date: 2013-12-05 18:06:07 +0800 (Thu, 05 Dec 2013) Path: gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID
[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 dongsheng.song at gmail dot com --- 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 lines * configure.ac (noexception_flags): Add -fasynchronous-unwind-tables. * configure: Regenerate. 2012-10-04 Uros Bizjak ubiz...@gmail.com * configure.ac (noexception_flags): Add -fasynchronous-unwind-tables. * configure: Regenerate.
[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 dongsheng.song at gmail dot com --- Created attachment 30804 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30804action=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 dongsheng.song at gmail dot com --- 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/mingw-w64/code/trunk Repository Root: svn://svn.code.sf.net/p/mingw-w64/code Repository UUID: 4407c894-4637-0410-b4f5-ada5f102cad1 Revision: 6277 Node Kind: directory Schedule: normal Last Changed Author: snarfle Last Changed Rev: 6277 Last Changed Date: 2013-09-12 03:13:55 +0800 (Thu, 12 Sep 2013) $ svn info gcc/trunk/ Path: gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 202515 Node Kind: directory Schedule: normal Last Changed Author: amodra Last Changed Rev: 202515 Last Changed Date: 2013-09-12 10:47:05 +0800 (Thu, 12 Sep 2013) $ svn diff gcc/trunk/gcc/c/c-decl.c Index: gcc/trunk/gcc/c/c-decl.c === --- gcc/trunk/gcc/c/c-decl.c(revision 202515) +++ gcc/trunk/gcc/c/c-decl.c(working copy) @@ -3604,7 +3604,7 @@ C_DECL_BUILTIN_PROTOTYPE (decl) = prototype_p (type); /* Should never be called on a symbol with a preexisting meaning. */ - gcc_assert (!I_SYMBOL_BINDING (id)); + gcc_assert (TREE_CODE (decl) == CONST_DECL || !I_SYMBOL_BINDING (id)); bind (id, decl, external_scope, /*invisible=*/true, /*nested=*/false, UNKNOWN_LOCATION); @@ -3629,9 +3629,6 @@ const char *name = IDENTIFIER_POINTER (id); C_DECL_BUILTIN_PROTOTYPE (decl) = prototype_p (type); - /* Should never be called on a symbol with a preexisting meaning. */ - gcc_assert (!I_SYMBOL_BINDING (id)); - bind (id, decl, external_scope, /*invisible=*/false, /*nested=*/false, UNKNOWN_LOCATION);
[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 dongsheng.song at gmail dot com --- Created attachment 30805 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30805action=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 dongsheng.song at gmail dot com --- 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/x86intrin.h:27:0, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/winnt.h:1495, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/minwindef.h:146, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windef.h:8, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windows.h:69, from /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c:29: /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:28: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4.2) ^ make[2]: *** [host-mingw32.o] Error 1 make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc' make: *** [all] Error 2 The full error log file in the attachment 30835.
[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 dongsheng.song at gmail dot com --- 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 error occurred: $ i686-w64-mingw32-gcc -c -march=core2 pr57848.c pr57848.c:2:9: internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633 #pragma GCC target(sse4.2) ^ 0x57024b c_builtin_function_ext_scope(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633 0x79f288 add_builtin_function_common /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561 0x79fb43 add_builtin_function_ext_scope(char const*, tree_node*, int, built_in_class, char const*, tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597 0xa63224 ix86_add_new_builtins /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27368 0xa63224 ix86_valid_target_attribute_tree(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4631 0x5f2000 ix86_pragma_target_parse /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:393 0x5e237d handle_pragma_target /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805 0x59696e c_parser_pragma /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8972 0x5a4f5b c_parser_external_declaration /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345 0x5a58c7 c_parser_translation_unit /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251 0x5a58c7 c_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11223 0x5dfec4 c_common_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/home/cauchy/cross/i686-windows-gcc49/libexec/gcc/i686-w64-mingw32/4.9.0/lto-wrapper Target: i686-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure --prefix=/home/cauchy/cross/i686-windows-gcc49 --with-sysroot=/home/cauchy/cross/i686-windows-gcc49 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=i686 --with-tune=generic Thread model: win32 gcc version 4.9.0 20130902 (experimental) (GCC)
[Bug c++/57897] New: pragma
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57897 Bug ID: 57897 Summary: pragma Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc 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 -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include -I. -I. -I/home/cauchy/vcs/svn/gcc/trunk/gcc -I/home/cauchy/vcs/svn/gcc/trunk/gcc/. -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../include -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libcpp/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./gmp -I/home/cauchy/vcs/svn/gcc/trunk/gmp -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpfr/src -I/home/cauchy/vcs/svn/gcc/trunk/mpc/src -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libdecnumber/bid -I../libdecnumber -I/home/cauchy/vcs/svn/gcc/trunk/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/vcs/svn/gcc/trunk/cloog/include -I/home/cauchy/obj/native/gcc-4.9-win64/gcc/./isl/include -I/home/cauchy/vcs/svn/gcc/trunk/isl/include \ /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c In file included from /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:39:0, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/winnt.h:1369, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windef.h:139, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/windows.h:69, from /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/host-mingw32.c:29: /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ammintrin.h:35:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4a) ^ make[2]: *** [host-mingw32.o] Error 1 make[2]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc/gcc' make[1]: *** [install-strip-gcc] Error 2 make[1]: Leaving directory `/home/cauchy/obj/native/gcc-4.9-win64/gcc' make: *** [install-strip] Error 2 From http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html -fasynchronous-unwind-tables Generate unwind table in DWARF 2 format, if supported by target machine. There maybe something wrong, why when I use SEH, the gcc build script use '-fasynchronous-unwind-tables' ? $ cat x.c #pragma GCC target(sse4a) $ x86_64-w64-mingw32-g++ -c -fasynchronous-unwind-tables x.c x.c:1:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4a) ^ $ x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-g++ COLLECT_LTO_WRAPPER=/home/cauchy/cross/x86_64-windows-gcc48/libexec/gcc/x86_64-w64-mingw32/4.8.2/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure --prefix=/home/cauchy/cross/x86_64-windows-gcc48 --with-sysroot=/home/cauchy/cross/x86_64-windows-gcc48 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=core2 --with-tune=generic Thread model: win32 gcc version 4.8.2 20130712 (prerelease) (GCC)
[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 dongsheng.song at gmail dot com --- $ ~/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-windows-gcc49/libexec/gcc/x86_64-w64-mingw32/4.9.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure --prefix=/home/cauchy/cross/x86_64-windows-gcc49 --with-sysroot=/home/cauchy/cross/x86_64-windows-gcc49 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=corei7 --with-tune=generic Thread model: win32 gcc version 4.9.0 20130714 (experimental) (GCC) $ cat x.c #pragma GCC target(sse4a) $ ~/cross/x86_64-windows-gcc49/bin/x86_64-w64-mingw32-g++ -c -fasynchronous-unwind-tables x.c x.c:1:27: sorry, unimplemented: -mno-fentry isn't compatible with SEH #pragma GCC target(sse4a) ^
[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 dongsheng.song at gmail dot com --- 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/57848] New: internal compiler error on build with mingw-w64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 Bug ID: 57848 Summary: internal compiler error on build with mingw-w64 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: 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-4637-0410-b4f5-ada5f102cad1 Revision: 5938 Node Kind: directory Schedule: normal Last Changed Author: sezero Last Changed Rev: 5936 Last Changed Date: 2013-07-07 17:12:42 +0800 (Sun, 07 Jul 2013) Path: gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 200744 Node Kind: directory Schedule: normal Last Changed Author: uros Last Changed Rev: 200744 Last Changed Date: 2013-07-08 03:06:45 +0800 (Mon, 08 Jul 2013) $ make all-am make[1]: Entering directory `/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt' i686-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt -m32 -I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD -I/home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -MT intrincs/lib32_libkernel32_a-__movsb.o -MD -MP -MF intrincs/.deps/lib32_libkernel32_a-__movsb.Tpo -c -o intrincs/lib32_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c' || echo '/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c In file included from /home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/x86intrin.h:27:0, from /home/cauchy/cross/i686-windows-gcc49/i686-w64-mingw32/include/intrin.h:59, from /home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1: /home/cauchy/cross/i686-windows-gcc49/lib/gcc/i686-w64-mingw32/4.9.0/include/ia32intrin.h:54:9: internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633 #pragma GCC target(sse4.2) ^ 0x531e8b c_builtin_function_ext_scope(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633 0x755f28 add_builtin_function_common /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561 0x7567e3 add_builtin_function_ext_scope(char const*, tree_node*, int, built_in_class, char const*, tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597 0xa04fc4 ix86_add_new_builtins /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27199 0xa04fc4 ix86_valid_target_attribute_tree(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4512 0x5b22a0 ix86_pragma_target_parse /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:385 0x5a2abd handle_pragma_target /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805 0x557a1e c_parser_pragma /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8749 0x565ffb c_parser_external_declaration /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345 0x566967 c_parser_translation_unit /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251 0x566967 c_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11000 0x5a0614 c_common_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [intrincs/lib32_libkernel32_a-__movsb.o] Error 1 make[1]: Leaving directory `/home/cauchy/obj/i686-w64-mingw32-gcc49/mingw-w64-crt' make: *** [all] Error 2
[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 dongsheng.song at gmail dot com --- 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/svn/mingw-w64/trunk/mingw-w64-crt -m64 -I/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/include -D_CRTBLD -I/home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -MT intrincs/lib64_libkernel32_a-__movsb.o -MD -MP -MF intrincs/.deps/lib64_libkernel32_a-__movsb.Tpo -c -o intrincs/lib64_libkernel32_a-__movsb.o `test -f 'intrincs/__movsb.c' || echo '/home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/'`intrincs/__movsb.c In file included from /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/x86intrin.h:27:0, from /home/cauchy/cross/x86_64-windows-gcc49/x86_64-w64-mingw32/include/intrin.h:59, from /home/cauchy/vcs/svn/mingw-w64/trunk/mingw-w64-crt/intrincs/__movsb.c:1: /home/cauchy/cross/x86_64-windows-gcc49/lib/gcc/x86_64-w64-mingw32/4.9.0/include/ia32intrin.h:54:9: internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633 #pragma GCC target(sse4.2) ^ 0x5357eb c_builtin_function_ext_scope(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633 0x75e618 add_builtin_function_common /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561 0x75eed3 add_builtin_function_ext_scope(char const*, tree_node*, int, built_in_class, char const*, tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597 0xa12124 ix86_add_new_builtins /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27199 0xa12124 ix86_valid_target_attribute_tree(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4512 0x5b5d90 ix86_pragma_target_parse /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:385 0x5a65ad handle_pragma_target /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805 0x55b37e c_parser_pragma /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8749 0x56995b c_parser_external_declaration /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345 0x56a2c7 c_parser_translation_unit /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251 0x56a2c7 c_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11000 0x5a4104 c_common_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[1]: *** [intrincs/lib64_libkernel32_a-__movsb.o] Error 1 make[1]: Leaving directory `/home/cauchy/obj/x86_64-w64-mingw32-gcc49/mingw-w64-crt' make: *** [all] Error 2
[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 dongsheng.song at gmail dot com 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 dongsheng.song at gmail dot com 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 dongsheng.song at gmail dot com 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 be able to build stuff without isssues for 4.8.x gcc. First advice would be to look into libstdc++'s config.log to see why for you shared library isn't built. Second question is how you are actual configuring it, and what additional patches you might use on built? No additional patches applied. Here is my build cfg: $ /home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure --prefix=/home/cauchy/cross/x86_64-windows --with-sysroot=/home/cauchy/cross/x86_64-windows --target=x86_64-w64-mingw32 --enable-targets=all --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=x86-64 --with-tune=generic --with-fpmath=sse Please see attachments for 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 Dongsheng Song dongsheng.song at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #6 from Dongsheng Song dongsheng.song at gmail dot com 2013-04-30 10:47:39 UTC --- OOPS, not RESOLVED.
[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 dongsheng.song at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #2 from Dongsheng Song dongsheng.song at gmail dot com 2013-04-30 10:52:52 UTC --- (In reply to comment #1) No this change wasn't hastily nor wrong. Actual the change makes things compliant to logic already used for cygwin for years. Additional it fixed a quirk there was about eh-code sometimes not using shared version, if it actual was necessary to. The point is, if you want to avoid dependency to DLL libgcc version, then please use support static option for it. Otherwise you might get dependencies to the shared version, and there is nothing wrong about that. I admit that some functions might be added to shared version, which would be for pe-coff better be placed into the pure static part of libgcc. But well that is an enhancment issue and not a bug. It's a regress to gcc 4.7, it't it ?
[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 dongsheng.song at gmail dot com 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, what mingw-w64 header-set,crt you are using? You will need for = 4.8.x gcc version actual trunk version. Yes, I use mingw-w64 trunk. I looked through the config.log and don't see anything showing that shared-version doesn't work, so I assume the underlying issue you see is PR 54659. OK, I will try without '--disable-nls' option.
[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 dongsheng.song at gmail dot com 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 dongsheng.song at gmail dot com 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 dongsheng.song at gmail dot com 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 dongsheng.song at gmail dot com 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_FindEnclosingFunction [ 3] _Unwind_Find_FDE [ 4] _Unwind_GetCFA [ 5] _Unwind_GetDataRelBase [ 6] _Unwind_GetGR [ 7] _Unwind_GetIP [ 8] _Unwind_GetIPInfo [ 9] _Unwind_GetLanguageSpecificData [ 10] _Unwind_GetRegionStart [ 11] _Unwind_GetTextRelBase [ 12] _Unwind_SetGR [ 13] _Unwind_SetIP [ 14] _Unwind_SjLj_ForcedUnwind [ 15] _Unwind_SjLj_RaiseException [ 16] _Unwind_SjLj_Register [ 17] _Unwind_SjLj_Resume [ 18] _Unwind_SjLj_Resume_or_Rethrow [ 19] _Unwind_SjLj_Unregister [ 20] __absvdi2 [ 21] __absvsi2 [ 22] __addtf3 [ 23] __addvdi3 [ 24] __addvsi3 [ 25] __ashldi3 [ 26] __ashrdi3 [ 27] __bswapdi2 [ 28] __bswapsi2 [ 29] __clear_cache [ 30] __clrsbdi2 [ 31] __clrsbsi2 [ 32] __clzdi2 [ 33] __clzsi2 [ 34] __cmpdi2 [ 35] __ctzdi2 [ 36] __ctzsi2 [ 37] __deregister_frame [ 38] __deregister_frame_info [ 39] __deregister_frame_info_bases [ 40] __divdc3 [ 41] __divdi3 [ 42] __divsc3 [ 43] __divtc3 [ 44] __divtf3 [ 45] __divxc3 [ 46] __emutls_get_address [ 47] __emutls_register_common [ 48] __enable_execute_stack [ 49] __eqtf2 [ 50] __extenddftf2 [ 51] __extendsftf2 [ 52] __extendxftf2 [ 53] __ffsdi2 [ 54] __ffssi2 [ 55] __fixdfdi [ 56] __fixsfdi [ 57] __fixtfdi [ 58] __fixtfsi [ 59] __fixunsdfdi [ 60] __fixunsdfsi [ 61] __fixunssfdi [ 62] __fixunssfsi [ 63] __fixunstfdi [ 64] __fixunstfsi [ 65] __fixunsxfdi [ 66] __fixunsxfsi [ 67] __fixxfdi [ 68] __floatdidf [ 69] __floatdisf [ 70] __floatditf [ 71] __floatdixf [ 72] __floatsitf [ 73] __floatundidf [ 74] __floatundisf [ 75] __floatunditf [ 76] __floatundixf [ 77] __floatunsitf [ 78] __gcc_personality_sj0 [ 79] __getf2 [ 80] __gttf2 [ 81] __letf2 [ 82] __lshrdi3 [ 83] __lttf2 [ 84] __moddi3 [ 85] __muldc3 [ 86] __muldi3 [ 87] __mulsc3 [ 88] __multc3 [ 89] __multf3 [ 90] __mulvdi3 [ 91] __mulvsi3 [ 92] __mulxc3 [ 93] __negdi2 [ 94] __negtf2 [ 95] __negvdi2 [ 96] __negvsi2 [ 97] __netf2 [ 98] __paritydi2 [ 99] __paritysi2 [ 100] __popcountdi2 [ 101] __popcountsi2 [ 102] __powidf2 [ 103] __powisf2 [ 104] __powitf2 [ 105] __powixf2 [ 106] __register_frame [ 107] __register_frame_info [ 108] __register_frame_info_bases [ 109] __register_frame_info_table [ 110] __register_frame_info_table_bases [ 111] __register_frame_table [ 112] __subtf3 [ 113] __subvdi3 [ 114] __subvsi3 [ 115] __trunctfdf2 [ 116] __trunctfsf2 [ 117] __trunctfxf2 [ 118] __ucmpdi2 [ 119] __udivdi3 [ 120] __udivmoddi4 [ 121] __umoddi3 [ 122] __unordtf2 If I use unwind-sjlj.rc (unwind-seh.rc, or unwind-dw2.rc) to make sure libgcc_s_sjlj-1.dll only export _Unwind_* symbols, is it acceptable ?
[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 dongsheng.song at gmail dot com 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++-v3. So DLL should be built, if you don't have a build error. For me 32-bit and 64-bit w64 version builds OOTB without any issue. You are building multilib as I see, so do you have 32-bit and 64-bit setuped too? Could you check if there is for real no dll built by executing within your libstdc++-v3 build-directory the command 'find ./* -name *.dll -print'? Yes, I build x86_64-w64-mingw32 with multilib, i686-w64-mingw32 without multilib (due to binutils trunk regress), both do not generate libstdc++-6.dll: ~/obj/i686-w64-mingw32/gcc$ find ./* -name *.dll -print ./gcc/home/cauchy/cross/i686-windows/i686-w64-mingw32/lib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libgcc/shlib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libssp/.libs/libssp-0.dll ./i686-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./i686-w64-mingw32/libgfortran/.libs/libgfortran-3.dll ~/obj/x86_64-w64-mingw32/gcc$ find ./* -name *.dll -print ./gcc/home/cauchy/cross/x86_64-windows/x86_64-w64-mingw32/lib/libgcc_s_seh-1.dll ./gcc/home/cauchy/cross/x86_64-windows/x86_64-w64-mingw32/lib32/libgcc_s_sjlj-1.dll ./x86_64-w64-mingw32/libgcc/shlib/libgcc_s_seh-1.dll ./x86_64-w64-mingw32/32/libgcc/32/shlib/libgcc_s_sjlj-1.dll ./x86_64-w64-mingw32/32/libssp/.libs/libssp-0.dll ./x86_64-w64-mingw32/32/libquadmath/.libs/libquadmath-0.dll ./x86_64-w64-mingw32/32/libgfortran/.libs/libgfortran-3.dll ./x86_64-w64-mingw32/libssp/.libs/libssp-0.dll ./x86_64-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./x86_64-w64-mingw32/libgfortran/.libs/libgfortran-3.dll
[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 Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dongsheng.s...@gmail.com In gcc 4.7, both static and shared libstdc++ build: i686-w64-mingw32/lib/libstdc++.a x86_64-w64-mingw32/lib/libstdc++.a i686-w64-mingw32/lib/libstdc++-6.dll x86_64-w64-mingw32/lib/libstdc++-6.dll But in gcc 4.8, no shared libstdc++ build anymore, only got static build: lib/libstdc++.a
[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
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dongsheng.s...@gmail.com
Here is example:
$ cat t-w32.c
long long do_div(long long a, long long b)
{
return a/b;
}
i686-w64-mingw32-gcc -shared -o t-w32.dll t-w32.c
i686-w64-mingw32-objdump -x t-w32.dll | grep DLL Name
gcc 4.8:
DLL Name: libgcc_s_sjlj-1.dll
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
gcc 4.7:
DLL Name: KERNEL32.dll
DLL Name: msvcrt.dll
Then I investigate why the gcc 4.8 output dll use libgcc_s_sjlj-1.dll,
I found t-w32.dll use the following symbols in libgcc_s_sjlj-1.dll:
i686-w64-mingw32-objdump -x t-w32.dll | less
DLL Name: libgcc_s_sjlj-1.dll
vma: Hint/Ord Member-Name Bound-To
c200 41 __divdi3
c20c 119 __udivdi3
c218 121 __umoddi3
I think this is a regress, isn't it ?
I found in gcc/config/i386/mingw32.h:
/* Include in the mingw32 libraries with libgcc */
#ifdef ENABLE_SHARED_LIBGCC
#define SHARED_LIBGCC_SPEC \
%{static|static-libgcc:-lgcc -lgcc_eh} \
%{!static: \
%{!static-libgcc: \
%{!shared: \
%{!shared-libgcc:-lgcc -lgcc_eh} \
%{shared-libgcc:-lgcc_s -lgcc} \
} \
%{shared:-lgcc_s -lgcc} \
} \
}
#else
#define SHARED_LIBGCC_SPEC -lgcc
#endif
If I change '-lgcc_s -lgcc' to '-lgcc -lgcc_s', then gcc 4.8 will not use such
symbols like __divdi3 in libgcc_s_sjlj-1.dll, it back to gcc 4.7 behavior.
Because both lib/libgcc_s.a (libgcc_s_sjlj-1.dll）and
lib/gcc/i686-w64-mingw32/4.8.1/libgcc.a
export these symbols:
___divdi3
___moddi3
___moddi3
...
I think this change is hastily, should be rollback, or make
libgcc_s${LIBGCC_EH_EXTN}-1.dll
DO NOT export extra symbols which not owned their self.
[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 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
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 %MEMTIME+ 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
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
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 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 dongsheng.song at gmail dot com 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 http://sourceware.org/ml/binutils/2011-02/msg00337.html fixes this issue, but it is not approved yet. Yes, when I use hjl/lto-mixed branch of binutils: [[[ commit fb6867660be917535a62b35e554dc222a74d92a5 Merge: e3654c4 a0a68e5 Author: H.J. Lu hjl.to...@gmail.com Date: Sat Mar 12 09:29:46 2011 -0800 Merge remote-tracking branch 'hjl/intel/lto-mixed' into hjl/lto-mixed ]]] gcc 4.6 on mingw-w64 (32 bit and 64 bit) target works fine.
[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 dongsheng.song at gmail dot com 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 branch: http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary. sure, it's OK with `-fno-use-linker-plugin'. But I cannot found the document from page: http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html I'm doubt whether this option disable LTO support. Is anyone know why this bug not fixed in the official repository ? Is there any schedule for fix this bug?
[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 dongsheng.song at gmail dot com 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 Lu's linker from lto-mixed branch: http://git.kernel.org/?p=devel/binutils/hjl/x86.git;a=summary. sure, it's OK with `-fno-use-linker-plugin'. But I cannot found the document from page: http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html I'm doubt whether this option disable LTO support. Is anyone know why this bug not fixed in the official repository ? Is there any schedule for fix this bug? Since gcc 4.6 branched, gcc trunk and 4.6 branch both have this issue now.
[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: unassig...@gcc.gnu.org ReportedBy: dongsheng.s...@gmail.com Created attachment 23464 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23464 exe file which have invalid address reference to _puts I have test LTO with hello.cpp and hello.c, testing on hello.cpp passed, testing on hello.c sucks with: Program received signal SIGSEGV, Segmentation fault. Here is gcc and binutils version information: $ i686-w64-mingw32-ld -v GNU ld (GNU Binutils) 2.21.51.20110225 $ i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/home/oracle/gcc-4.6-windows_i686-linux/libexec/gcc/i686-w64-mingw32/4.6.0/lto-wrapper Target: i686-w64-mingw32 Configured with: /home/oracle/vcs/svn/gcc/trunk/configure --prefix=/home/oracle/gcc-4.6-windows_i686-linux --with-sysroot=/home/oracle/gcc-4.6-windows_i686-linux --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-w64-mingw32 --enable-targets=all --with-arch-32=x86-64 --with-tune-32=generic --with-arch-64=x86-64 --with-tune-64=generic --with-fpmath=sse --enable-fully-dynamic-string --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++ --enable-libgomp --enable-libssp --enable-lto --enable-cloog-backend=ppl-legacy Thread model: win32 gcc version 4.6.0 20110224 (experimental) (GCC) With LTO, the generated exe file have invalid address reference to _puts: $ i686-w64-mingw32-gcc -g -flto -o hello.c.lto.exe Hello.c $ i686-w64-mingw32-objdump -d hello.c.lto.exe 00402430 _main: 402430: 55 push %ebp 402431: 89 e5 mov%esp,%ebp 402433: 83 e4 f0and$0xfff0,%esp 402436: 83 ec 10sub$0x10,%esp 402439: e8 02 fb ff ff call 401f40 ___main 40243e: c7 04 24 94 42 40 00movl $0x404294,(%esp) 402445: e8 b6 db bf ff call 0 _puts 40244a: b8 00 00 00 00 mov$0x0,%eax 40244f: c9 leave 402450: c3 ret 402451: 90 nop 402452: 90 nop 402453: 90 nop With LTO, it's OK: $ i686-w64-mingw32-gcc -g -o hello.c.exe Hello.c $ i686-w64-mingw32-objdump -d hello.c.exe 004015f0 _main: 4015f0: 55 push %ebp 4015f1: 89 e5 mov%esp,%ebp 4015f3: 83 e4 f0and$0xfff0,%esp 4015f6: 83 ec 10sub$0x10,%esp 4015f9: e8 72 09 00 00 call 401f70 ___main 4015fe: c7 04 24 68 40 40 00movl $0x404068,(%esp) 401605: e8 fe 0d 00 00 call 402408 _puts 40160a: b8 00 00 00 00 mov$0x0,%eax 40160f: c9 leave 401610: c3 ret 401611: 90 nop 401612: 90 nop 401613: 90 nop I checked GCC 4.5.3 20110224 with same binutils version, it works fine.
[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 dongsheng.song at gmail dot com 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 dongsheng.song at gmail dot com 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 main: 4029c0: 55 push %rbp 4029c1: 48 89 e5mov%rsp,%rbp 4029c4: 48 83 ec 20 sub$0x20,%rsp 4029c8: e8 13 f8 ff ff callq 4021e0 __main 4029cd: 48 8d 0d bc 18 00 00lea0x18bc(%rip),%rcx# 404290 .rdata 4029d4: e8 17 00 00 00 callq 4029f0 puts 4029d9: b8 00 00 00 00 mov$0x0,%eax 4029de: 48 83 c4 20 add$0x20,%rsp 4029e2: 5d pop%rbp 4029e3: c3 retq 4029e4: 90 nop 4029e5: 90 nop 4029e6: 90 nop $ i686-w64-mingw32-gcc -m64 -g -o hello.c.64bit.exe Hello.c $ i686-w64-mingw32-objdump -d hello.c.64bit.exe 004015c0 main: 4015c0: 55 push %rbp 4015c1: 48 89 e5mov%rsp,%rbp 4015c4: 48 83 ec 20 sub$0x20,%rsp 4015c8: e8 43 0c 00 00 callq 402210 __main 4015cd: 48 8d 0d ac 2a 00 00lea0x2aac(%rip),%rcx# 404080 .rdata 4015d4: e8 c7 12 00 00 callq 4028a0 puts 4015d9: b8 00 00 00 00 mov$0x0,%eax 4015de: 48 83 c4 20 add$0x20,%rsp 4015e2: 5d pop%rbp 4015e3: c3 retq 4015e4: 90 nop 4015e5: 90 nop 4015e6: 90 nop
[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 dongsheng.song at gmail dot com 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 are used for doing export definitions. I just sent a patch about it to binutils ML and this issue seems to exists already for some time. I am curious that Dave didn't noticed it earlier. I stumbled about it by doing a binutils regression-test for 32-bit COFF targets. Verified on: gcc version 4.6.0 20110219 gcc version 4.5.3 20110219 This bug not exist now.
[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 dongsheng.song at gmail dot com 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 fixed. Regards, Kai PS:I assume that you won't have the issue by using -static option on gcc command-line. No, maybe the another bug mix up you eyes:-) Even for static link, lto still not works fine for Hello.c: C:\g++ -pipe -O2 -flto -o Hello.c.exe Hello.c C:\Hello.c.exe Pop up a NULL pointer dialog C:\g++ -pipe -O2 -flto -static -o Hello.c.static.exe Hello.c C:\Hello.c.static.exe Pop up a NULL pointer dialog C:\g++ -pipe -O2 -o Hello.exe Hello.c C:\Hello.exe Hello, World!
[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++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: dongsheng.s...@gmail.com Before 2011-02-13, both gcc-4.5 branch and trunk is fine to build mingw-w64/multilib target on i686-pc-linux-gnu host. But now the file size of 32-bit libstdc++.dll.a is very small (2260 byte), 64-bit libstdc++.dll.a is OK: Here is gcc-4.5 branch building result: oracle@vc:~/tmp/gcc-4.5-windows_i686-linux-obj/gcc$ ls -la ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++* -rwxr-xr-x 1 oracle dba 5662948 Feb 15 21:34 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll -rw-r--r-- 1 oracle dba 8874224 Feb 15 21:34 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.a -rw-r--r-- 1 oracle dba2260 Feb 15 21:34 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.dll.a lrwxrwxrwx 1 oracle dba 15 Feb 15 21:34 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.la - ../libstdc++.la -rw-r--r-- 1 oracle dba 986 Feb 15 21:34 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.lai oracle@vc:~/tmp/gcc-4.5-windows_i686-linux-obj/gcc$ ls -la ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++* -rwxr-xr-x 1 oracle dba 7226445 Feb 15 21:35 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++-6.dll -rw-r--r-- 1 oracle dba 10478438 Feb 15 21:35 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.a -rw-r--r-- 1 oracle dba 2591940 Feb 15 21:35 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.dll.a lrwxrwxrwx 1 oracle dba 15 Feb 15 21:35 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.la - ../libstdc++.la -rw-r--r-- 1 oracle dba 986 Feb 15 21:35 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.lai Here is gcc trunk building result: oracle@vc:~/tmp/gcc-4.6-windows_i686-linux-obj/gcc$ ls -la ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++* -rwxr-xr-x 1 oracle dba 5257378 Feb 15 21:16 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll -rw-r--r-- 1 oracle dba 8065534 Feb 15 21:16 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.a -rw-r--r-- 1 oracle dba2260 Feb 15 21:16 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.dll.a lrwxrwxrwx 1 oracle dba 15 Feb 15 21:16 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.la - ../libstdc++.la -rw-r--r-- 1 oracle dba 974 Feb 15 21:16 ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++.lai oracle@vc:~/tmp/gcc-4.6-windows_i686-linux-obj/gcc$ ls -la ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++* -rwxr-xr-x 1 oracle dba 7228283 Feb 15 21:18 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++-6.dll -rw-r--r-- 1 oracle dba 10777424 Feb 15 21:18 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.a -rw-r--r-- 1 oracle dba 2639980 Feb 15 21:18 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.dll.a lrwxrwxrwx 1 oracle dba 15 Feb 15 21:18 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.la - ../libstdc++.la -rw-r--r-- 1 oracle dba 976 Feb 15 21:18 ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++.lai Tested with the latest binutils.
[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 dongsheng.song at gmail dot com 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 binutils git mirror, so I said before 2011-02-13 as DATESTAMP/version. So gcc 4.5.3 prerelease and gcc trunk before 2011-02-13 works for me.
[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 dongsheng.song at gmail dot com 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 existed at least *two months* earlier the date you indicated, or is a much more general build issue not specifically related to libstdc++ details... or the binutils you are using, I don't know. Please provide further details. I don't know which details you want, I think it's good if someone like mingw-w64 folks try building themselves. I suspect that binutils maybe the largest in charge.
[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 dongsheng.song at gmail dot com
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
Thanks, gcc/g++ can link no erros. but during a simple test,
Hello.cpp.exe can run as expected,
Hello.c.exe runing error with NULL pointer.
C:\g++ -pipe -O2 -flto -o Hello.c.exe Hello.c
C:\g++ -pipe -O2 -flto -o Hello.cpp.exe Hello.cpp
C:\Hello.cpp.exe
Hello, Wolrd!
C:\Hello.c.exe
Pop up a NULL pointer dialog
C:\type Hello.cpp
#include iostream
int main()
{
std::cout Hello, Wolrd! std::endl;
return 0;
}
C:\type Hello.c
#include stdio.h
int main()
{
printf(Hello, World!\n);
return 0;
}
[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 dongsheng.song at gmail dot com 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 dongsheng.song at gmail dot com 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 I don't known if this is a binutils issue, I use gcc trunk and binutils trunk: $ svn info vcs/svn/gcc/trunk/ Path: vcs/svn/gcc/trunk URL: svn://gcc.gnu.org/svn/gcc/trunk Repository Root: svn://gcc.gnu.org/svn/gcc Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4 Revision: 170159 Node Kind: directory Schedule: normal Last Changed Author: redi Last Changed Rev: 170159 Last Changed Date: 2011-02-15 07:51:07 +0800 (Tue, 15 Feb 2011) $ git log -1 commit 47fcd70b56abc1d5f158ac488362337a8b26f577 Author: Alan Modra amo...@bigpond.net.au Date: Mon Feb 14 23:00:05 2011 + daily update $ i686-w64-mingw32-g++ Hello.cpp /tmp/ccbwXfkL.o:Hello.cpp:(.text+0x19): undefined reference to `std::cout' /tmp/ccbwXfkL.o:Hello.cpp:(.text+0x1e): undefined reference to `std::basic_ostreamchar, std::char_traitschar std::operator std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char const*)' /tmp/ccbwXfkL.o:Hello.cpp:(.text+0x26): undefined reference to `std::basic_ostreamchar, std::char_traitschar std::endlchar, std::char_traitschar (std::basic_ostreamchar, std::char_traitschar )' /tmp/ccbwXfkL.o:Hello.cpp:(.text+0x2e): undefined reference to `std::basic_ostreamchar, std::char_traitschar ::operator(std::basic_ostreamchar, std::char_traitschar (*)(std::basic_ostreamchar, std::char_traitschar ))' /tmp/ccbwXfkL.o:Hello.cpp:(.text+0x47): undefined reference to `std::ios_base::Init::~Init()' /tmp/ccbwXfkL.o:Hello.cpp:(.text+0x6a): undefined reference to `std::ios_base::Init::Init()' collect2: ld returned 1 exit status But when I use static link, no errors: $ i686-w64-mingw32-g++ -static Hello.cpp
[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 dongsheng.song at gmail dot com 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: current ar archive $ ls -l gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a -rwxr-xr-x 1 oracle dba 2260 Feb 15 10:34 gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a $ i686-w64-mingw32-g++ Hello.cpp gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/libstdc++.dll.a /tmp/cc39V2U9.o:Hello.cpp:(.text+0x19): undefined reference to `std::cout' /tmp/cc39V2U9.o:Hello.cpp:(.text+0x1e): undefined reference to `std::basic_ostreamchar, std::char_traitschar std::operator std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char const*)' /tmp/cc39V2U9.o:Hello.cpp:(.text+0x26): undefined reference to `std::basic_ostreamchar, std::char_traitschar std::endlchar, std::char_traitschar (std::basic_ostreamchar, std::char_traitschar )' /tmp/cc39V2U9.o:Hello.cpp:(.text+0x2e): undefined reference to `std::basic_ostreamchar, std::char_traitschar ::operator(std::basic_ostreamchar, std::char_traitschar (*)(std::basic_ostreamchar, std::char_traitschar ))' /tmp/cc39V2U9.o:Hello.cpp:(.text+0x47): undefined reference to `std::ios_base::Init::~Init()' /tmp/cc39V2U9.o:Hello.cpp:(.text+0x6a): undefined reference to `std::ios_base::Init::Init()' collect2: ld returned 1 exit status
[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...@airs.com
ReportedBy: dongsheng.s...@gmail.com
When I building language go with the following configuration:
export BUILD_TRIPLET=i686-pc-linux-gnu
export TARGET_TRIPLET=i686-w64-mingw32
${GCC_SOURCE_DIR}/configure --prefix=${CROSS_PREFIX}
--with-sysroot=${CROSS_PREFIX} \
--build=${BUILD_TRIPLET} --host=${BUILD_TRIPLET} --target=${TARGET_TRIPLET}
--enable-targets=all \
--with-arch-32=x86-64 --with-tune-32=generic \
--with-arch-64=x86-64 --with-tune-64=generic --with-fpmath=sse \
--enable-fully-dynamic-string --disable-nls \
--enable-languages=c,c++,fortran,objc,obj-c++,go \
--enable-libgomp --enable-libssp --enable-lto
--enable-cloog-backend=ppl-legacy
Then make failed. I think this maybe due to libgo invade the traditional
C name-space in the header file 'libgo/runtime/malloc.h', could we change
the header name to 'libgo/runtime/go-malloc.h' ?
make failed with the following errors:
make[4]: Entering directory
`/home/oracle/tmp/gcc-4.6-windows_i686-linux-obj/gcc/i686-w64-mingw32/libgo'
/home/oracle/tmp/gcc-4.6-windows_i686-linux-obj/gcc/./gcc/xgcc
-B/home/oracle/tmp/gcc-4.6-windows_i686-linux-obj/gcc/./gcc/
-L/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib
-L/home/oracle/gcc-4.6-windows_i686-linux/mingw/lib -isystem
/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/include -isystem
/home/oracle/gcc-4.6-windows_i686-linux/mingw/include
-B/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/bin/
-B/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/lib/ -isystem
/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/include -isystem
/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/sys-include
-DHAVE_CONFIG_H -I. -I/home/oracle/vcs/svn/gcc/trunk/libgo -I
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime
-I/home/oracle/vcs/svn/gcc/trunk/libgo/../libffi/include -I../libffi/include
-fexceptions -fplan9-extensions -Wall -Wextra -Wwrite-strings -Wcast-qual
-Werror -minline-all-stringops -I /home/oracle/vcs/svn/gcc/trunk/libgo/../gcc
-I ../../gcc/include -g -O2 -MT go-main.o -MD -MP -MF .deps/go-main.Tpo -c -o
go-main.o `test -f 'runtime/go-main.c' || echo
'/home/oracle/vcs/svn/gcc/trunk/libgo/'`runtime/go-main.c
In file included from
/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/include/stdlib.h:635:0,
from /home/oracle/vcs/svn/gcc/trunk/libgo/runtime/go-main.c:9:
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:98:1: error: unknown type
name 'uintptr'
In file included from
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:116:0,
from
/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/include/stdlib.h:635,
from /home/oracle/vcs/svn/gcc/trunk/libgo/runtime/go-main.c:9:
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/mheapmap32.h:36:1: error: unknown
type name 'bool'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/mheapmap32.h:36:58: error: unknown
type name 'uintptr'
In file included from
/home/oracle/gcc-4.6-windows_i686-linux/i686-w64-mingw32/include/stdlib.h:635:0,
from /home/oracle/vcs/svn/gcc/trunk/libgo/runtime/go-main.c:9:
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:138:24: error: unknown
type name 'uintptr'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:139:31: error: unknown
type name 'uintptr'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:140:33: error: unknown
type name 'uintptr'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:153:2: error: unknown
type name 'uintptr'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:155:27: error: unknown
type name 'byte'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:158:2: error: unknown
type name 'byte'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:159:2: error: unknown
type name 'uint32'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:160:2: error: unknown
type name 'uintptr'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:161:2: error: unknown
type name 'uintptr'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:164:41: error: unknown
type name 'uintptr'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:164:101: error: unknown
type name 'byte'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:164:109: error: expected
';', ',' or ')' before 'void'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:174:2: error: unknown
type name 'uint64'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:175:2: error: unknown
type name 'uint64'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:176:2: error: unknown
type name 'uint64'
/home/oracle/vcs/svn/gcc/trunk/libgo/runtime/malloc.h:177:2: error: unknown
type name 'uint64'
[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 dongsheng.song at gmail dot com changed: What|Removed |Added CC||dongsheng.song at gmail dot ||com --- Comment #11 from Dongsheng Song dongsheng.song at gmail dot com 2011-02-11 02:36:22 UTC --- (In reply to comment #10) Author: ktietz Date: Thu Feb 10 08:57:24 2011 New Revision: 16 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=16 Log: 2011-02-10 Kai Tietz kai.ti...@onevision.com PR lto/47241 * lto.c (lto_read_section_data): Free fd_name in failure case. For mingw targets don't hash file-descriptor. (read_cgraph_and_symbols): Close current_lto_file in failure case. Modified: trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c No, this commit still not resolve the issue. The filename is something like 'cc8dHzVI.ltrans0.ltrans.o', tt still exists in TEMP dir like 'C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp' . The file is created by: COLLECT_GCC_OPTIONS='-c' '-O2' '-pipe' '-s' '-v' '-v' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-fltrans' '-o' 'C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o' '-shared-libgcc' c:/gcc-4.6-windows/lib/gcc/../../libexec/gcc/i686-w64-mingw32/4.6.0/lto1.exe -quiet -dumpbase cc8dHzVI.ltrans0.o -mtune=generic -march=x86-64 -auxbase-strip C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o -O2 -version -fltrans @C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\ccseSWUb -o - | c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/as.exe -o C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o COLLECT_GCC_OPTIONS='-c' '-O2' '-pipe' '-s' '-v' '-v' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-fltrans' '-o' 'C:\DOCUME~1\SONGDO~1\LOCALS~1\Temp\cc8dHzVI.ltrans0.ltrans.o' '-shared-libgcc' c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe: could not unlink output file collect2: ld returned 1 exit status
[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 dongsheng.song at gmail dot com 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 c4773de8739c6155aa847c5ee80f1fa1437a656a Author: Alan Modra amo...@bigpond.net.au Date: Mon Feb 7 23:00:05 2011 + daily update
[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 dongsheng.song at gmail dot com 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..bd5040e 100644 --- a/ld/configure.in +++ b/ld/configure.in @@ -173,7 +173,7 @@ AC_SEARCH_LIBS([dlopen],[dl],[],[enable_plugins=no],[]) AC_CHECK_FUNCS([dlopen dlsym dlclose],[],[enable_plugins=no]) # We also support plugins on Windows (MinGW). if test x$enable_plugins = xno ; then - AC_CHECK_HEADERS([Windows.h],[enable_plugins=yes],[],[AC_INCLUDES_DEFAULT]) + AC_CHECK_HEADERS([windows.h],[enable_plugins=yes],[],[AC_INCLUDES_DEFAULT]) fi AM_CONDITIONAL([ENABLE_PLUGINS], [test x$enable_plugins = xyes]) diff --git a/ld/plugin.c b/ld/plugin.c index b285787..8631d25 100644 --- a/ld/plugin.c +++ b/ld/plugin.c @@ -33,7 +33,7 @@ #include plugin-api.h #include elf-bfd.h #if !defined (HAVE_DLFCN_H) defined (HAVE_WINDOWS_H) -#include Windows.h +#include windows.h #endif /* The suffix to append to the name of the real (claimed) object file
[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 dongsheng.song at gmail dot com 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/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe: could not unlink output file collect2: ld returned 1 exit status
[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 dongsheng.song at gmail dot com 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.c is correct, but indeed it seems that the plugin
doesn't get installed by doing 'make install-gcc'.
Today, I can building with LTO enabled like gcc 4.5 now.
For the compiler:
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-w64-mingw32
--enable-targets=all
I can compile simple C source with LTO, then I use above compiler to generate
native compiler:
--build=i686-pc-linux-gnu --host=i686-w64-mingw32 --target=i686-w64-mingw32
--enable-targets=all
The native compiler can not compile simple C source with LTO:
C:\g++ -O2 -pipe -m32 -flto Hello.cpp
c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe:
unrecognized option '-plugin'
c:/gcc-4.6-windows/bin/../lib/gcc/i686-w64-mingw32/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe:
use the --help optionfor usage information
collect2: ld returned 1 exit status
It seems that the binutils not building correctly, but I building native
binutils with LTO enabled same as GCC:
${BINUTILS_SOURCE_DIR}/configure --prefix=${NATIVE_PREFIX}
--with-sysroot=${CROSS_PREFIX} \
--build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET}
--target=${TARGET_TRIPLET} \
--enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --disable-nls \
--enable-lto --enable-cloog-backend=ppl-legacy \
--disable-ppl-version-check --with-ppl=${NATIVE_OBJ_ROOT}/misc \
--disable-cloog-version-check --with-cloog=${NATIVE_OBJ_ROOT}/misc
${GCC_SOURCE_DIR}/configure --prefix=${NATIVE_PREFIX}
--with-sysroot=${NATIVE_PREFIX} \
--build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET}
--target=${TARGET_TRIPLET} --enable-targets=all \
--with-arch-32=x86-64 --with-tune-32=generic \
--with-arch-64=x86-64 --with-tune-64=generic --with-fpmath=sse \
--with-gmp=${NATIVE_OBJ_ROOT}/misc --with-mpfr=${NATIVE_OBJ_ROOT}/misc
--with-mpc=${NATIVE_OBJ_ROOT}/misc \
--enable-fully-dynamic-string --disable-nls \
--enable-languages=c,c++,fortran,objc,obj-c++ \
--enable-libgomp --enable-libssp \
--enable-lto --enable-cloog-backend=ppl-legacy \
--disable-ppl-version-check --with-ppl=${NATIVE_OBJ_ROOT}/misc \
--disable-cloog-version-check --with-cloog=${NATIVE_OBJ_ROOT}/misc
Any suggestions?
[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 dongsheng.song at gmail dot com 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: config.gcc
===
--- config.gcc (revision 169824)
+++ config.gcc (working copy)
@@ -1489,7 +1489,19 @@
fi
# Shared libgcc DLL install dir depends on cross/native build.
if test x${host} = x${target} ; then
- tmake_dlldir_file=i386/t-dlldir
+ # Are we building multilib version?
+ if test x$enable_targets = xall; then
+ case ${target} in
+ *-w64-*)
+ tmake_dlldir_file=i386/t-dlldir-x
+ ;;
+ *)
+ tmake_dlldir_file=i386/t-dlldir
+ ;;
+ esac
+ else
+ tmake_dlldir_file=i386/t-dlldir
+ fi
else
tmake_dlldir_file=i386/t-dlldir-x
fi
Since the cross compiler building is OK, so I only tried the native compiler
building. I got the same wrong results.
My next complete building will be started at 23:50 PM(UTC), if I got different
answer, I will inform you.
[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 dongsheng.song at gmail dot com 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 other files installation is wrong. oracle@vc:~/gcc-4.6-windows$ find . -name *.dll | grep -v pthread | sort ./bin/libgfortran-3.dll ./bin/libgomp-1.dll ./bin/libobjc-3.dll ./bin/libquadmath-0.dll ./bin/libssp-0.dll ./bin/libstdc++-6.dll ./lib64/libgcc_s_sjlj-1.dll ./lib/libgcc_s_sjlj-1.dll PS: For windows users, I think 32bit DLLs should go to bin/, and 64bit DLLs should go to bin/64/ .
[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 dongsheng.song at gmail dot com 2011-02-04 16:05:13 UTC --- On Fri, Feb 4, 2011 at 23:54, ktietz at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47142 --- Comment #7 from Kai Tietz ktietz at gcc dot gnu.org 2011-02-04 15:54:10 UTC --- OOPS, libgcc_s_sjlj-1.dll installed OK. But the other files installation is wrong. oracle@vc:~/gcc-4.6-windows$ find . -name *.dll | grep -v pthread | sort ./bin/libgfortran-3.dll ./bin/libgomp-1.dll ./bin/libobjc-3.dll ./bin/libquadmath-0.dll ./bin/libssp-0.dll ./bin/libstdc++-6.dll ./lib64/libgcc_s_sjlj-1.dll ./lib/libgcc_s_sjlj-1.dll Hmm, did you rebuild target libraries, or did you reused existing build-tree? I rebuild gcc-4.6-windows, remove gcc build-tree, then configure and building. PS: I preform the rebuilding ahead of time, remove the cross compiler, third-party software, and native compiler, a really fresh building, no good news.
[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 dongsheng.song at gmail dot com 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 retest? Thanks, Kai Yes, are you mean the cross building configured with: --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-w64-mingw32 --enable-targets=all --enable-languages=c,c++,fortran,objc,obj-c++ But when I build native compiler with the generated compiler: --build=i686-pc-linux-gnu --host=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-targets=all --enable-languages=c,c++,fortran,objc,obj-c++ Some DLLs still not installed correctly. PS: Could you build gcc 4.6 with LTO enabled? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47528
[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 dongsheng.song at gmail dot com 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, too. Could you please retest? Thanks, Kai Yes, are you mean the cross building configured with: --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-w64-mingw32 --enable-targets=all --enable-languages=c,c++,fortran,objc,obj-c++ But when I build native compiler with the generated compiler: --build=i686-pc-linux-gnu --host=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-targets=all --enable-languages=c,c++,fortran,objc,obj-c++ Some DLLs still not installed correctly. Here is the result: oracle@vc:~/gcc-4.6-windows$ find . -name *.dll | sort ./bin/64/pthreadGC2.dll ./bin/libgcc_s_sjlj-1.dll ./bin/libgfortran-3.dll ./bin/libgomp-1.dll ./bin/libobjc-3.dll ./bin/libquadmath-0.dll ./bin/libssp-0.dll ./bin/libstdc++-6.dll ./bin/pthreadGC2.dll oracle@vc:~/gcc-4.6-windows$ file bin/*.dll bin/libgcc_s_sjlj-1.dll: PE32+ executable for MS Windows (DLL) (console) Mono/.Net assembly bin/libgfortran-3.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit bin/libgomp-1.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit bin/libobjc-3.dll: PE32+ executable for MS Windows (DLL) (console) Mono/.Net assembly bin/libquadmath-0.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit bin/libssp-0.dll:PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit bin/libstdc++-6.dll: PE32+ executable for MS Windows (DLL) (console) Mono/.Net assembly bin/pthreadGC2.dll: PE32 executable for MS Windows (DLL) (console) Intel 80386 32-bit
[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 dongsheng.song at gmail dot com 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, the fatal-error is on purpose and it will not be changed. Which version is OK ? I can confirm my working copy is not older than 2011-01-27. In any case, I'll try again at tomorrow.
[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 dongsheng.song at gmail dot com 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-0d04-0410-961f-82ee72b054a4
Revision: 169456
Node Kind: directory
Schedule: normal
Last Changed Author: ian
Last Changed Rev: 169456
Last Changed Date: 2011-02-01 07:43:49 +0800 (Tue, 01 Feb 2011)
${GCC_SOURCE_DIR}/configure --prefix=${CROSS_PREFIX}
--with-sysroot=${CROSS_PREFIX} \
--build=${BUILD_TRIPLET} --host=${BUILD_TRIPLET} --target=i686-w64-mingw32
--enable-targets=all \
--with-arch-32=x86-64 --with-tune-32=generic \
--with-arch-64=x86-64 --with-tune-64=generic --with-fpmath=sse \
--enable-fully-dynamic-string --disable-nls \
--enable-languages=c,c++,fortran,objc,obj-c++ \
--enable-libgomp --enable-libssp --enable-lto
make -j8 all-gcc
make install-gcc
$ i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/home/oracle/gcc-4.6-windows_i686-linux/libexec/gcc/i686-w64-mingw32/4.6.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: /home/oracle/vcs/svn/gcc/trunk/configure
--prefix=/home/oracle/gcc-4.6-windows_i686-linux
--with-sysroot=/home/oracle/gcc-4.6-windows_i686-linux
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-w64-mingw32
--enable-targets=all --with-arch-32=x86-64 --with-tune-32=generic
--with-arch-64=x86-64 --with-tune-64=generic --with-fpmath=sse
--enable-fully-dynamic-string --disable-nls
--enable-languages=c,c++,fortran,objc,obj-c++ --enable-libgomp --enable-libssp
--enable-lto
Thread model: win32
gcc version 4.6.0 20110131 (experimental) (GCC)
oracle@vc:~$ i686-w64-mingw32-gcc -c ~/Hello.c
i686-w64-mingw32-gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so
not found
compilation terminated.
[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 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: dongsheng.s...@gmail.com When build gcc without CRT available like mingw-w64: 1. Build Binutils 2. Install mingw-w64-headers 3. Make all-gcc and install-gcc 4. Build mingw-w64 CRT and install 5. Make all-target-libgcc and install-target-libgcc 6. Build pthread and install 7. Make gcc finally and install In step 4, gcc should create simple C program which need not use CRT functions. But if gcc configured with enable-lto, there will have an fatal error: i686-w64-mingw32-gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found In my opinion, if liblto_plugin.so not found, gcc should issued an error message and going on gengerate code without lto support.
[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 dongsheng.song at gmail dot com changed: What|Removed |Added CC||dongsheng.song at gmail dot ||com --- Comment #17 from Dongsheng Song dongsheng.song at gmail dot com 2011-01-05 05:08:48 UTC --- Hi Kai, please fix for Debian too: Index: trunk/libstdc++-v3/configure.ac === --- trunk/libstdc++-v3/configure.ac (revision 168503) +++ trunk/libstdc++-v3/configure.ac (working copy) @@ -349,6 +349,10 @@ glibcxx_stylesheets=yes fi +if test -f /usr/share/xml/docbook/stylesheet/docbook-xsl-ns/VERSION; then + glibcxx_stylesheets=yes +fi + # Check for xml/html dependencies. AM_CONDITIONAL(BUILD_XML, test $ac_cv_prog_DOXYGEN = yes
[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 dongsheng.song at gmail dot com 2011-01-05 05:31:08 UTC --- This xml catalog testing passed on Debian and RHEL: echo 'article/' | xsltproc --noout --nonet \ http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl -
[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.gnu.org ReportedBy: dongsheng.s...@gmail.com When I cross build i686-w64-mingw32 target with multilib support on i686-pc-linux (Debian 6.0), libgcc_s_sjlj-1.dll not install correctly: gcc-4.6-w32_i686-linux$ find . -name *.dll ./bin/64/pthreadGC2.dll ./bin/pthreadGC2.dll ./bin/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/lib/libgfortran-3.dll ./i686-w64-mingw32/lib/libquadmath-0.dll ./i686-w64-mingw32/lib/libobjc-3.dll ./i686-w64-mingw32/lib/libgomp-1.dll ./i686-w64-mingw32/lib/libssp-0.dll ./i686-w64-mingw32/lib/libstdc++-6.dll ./i686-w64-mingw32/lib64/libgfortran-3.dll ./i686-w64-mingw32/lib64/libquadmath-0.dll ./i686-w64-mingw32/lib64/libobjc-3.dll ./i686-w64-mingw32/lib64/libgomp-1.dll ./i686-w64-mingw32/lib64/libssp-0.dll ./i686-w64-mingw32/lib64/libstdc++-6.dll $ file bin/libgcc_s_sjlj-1.dll bin/libgcc_s_sjlj-1.dll: PE32+ executable for MS Windows (DLL) (console) Mono/.Net assembly So no 32-bit version installed, not 64 bit version installed incorrectly. But the building result is correct: $ find . -name *.dll ./i686-w64-mingw32/64/libgomp/.libs/libgomp-1.dll ./i686-w64-mingw32/64/libgfortran/.libs/libgfortran-3.dll ./i686-w64-mingw32/64/libobjc/.libs/libobjc-3.dll ./i686-w64-mingw32/64/libstdc++-v3/src/.libs/libstdc++-6.dll ./i686-w64-mingw32/64/libquadmath/.libs/libquadmath-0.dll ./i686-w64-mingw32/64/libgcc/64/shlib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/64/libssp/.libs/libssp-0.dll ./i686-w64-mingw32/libgomp/.libs/libgomp-1.dll ./i686-w64-mingw32/libgfortran/.libs/libgfortran-3.dll ./i686-w64-mingw32/libobjc/.libs/libobjc-3.dll ./i686-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll ./i686-w64-mingw32/libquadmath/.libs/libquadmath-0.dll ./i686-w64-mingw32/libgcc/shlib/libgcc_s_sjlj-1.dll ./i686-w64-mingw32/libssp/.libs/libssp-0.dll
