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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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 target/57119] libstdc++-6.dll missed in default gcc 4.8 build

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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



Dongsheng Song  changed:



   What|Removed |Added



 Status|RESOLVED|UNCONFIRMED

 Resolution|WORKSFORME  |



--- Comment #6 from Dongsheng Song  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

[dongsheng.song at gmail dot com]

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



Dongsheng Song  changed:



   What|Removed |Added



 Status|RESOLVED|UNCONFIRMED

 Resolution|INVALID |



--- Comment #2 from Dongsheng Song  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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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++-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 c/47142] New: incorrect libgcc_s_sjlj-1.dll install

[dongsheng.song at gmail dot com]

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

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

[dongsheng.song at gmail dot com]

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

Dongsheng Song  changed:

   What|Removed |Added

 CC||dongsheng.song at gmail dot
   ||com

--- Comment #17 from Dongsheng Song  
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"

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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 lto/47528] liblto_plugin.so not found should not to be an fatal error

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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-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 target/47142] incorrect libgcc_s_sjlj-1.dll install

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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, 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 target/47142] incorrect libgcc_s_sjlj-1.dll install

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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 ---
>> 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 lto/47528] liblto_plugin.so not found should not to be an fatal error

[dongsheng.song at gmail dot com]

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.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 lto/47528] liblto_plugin.so not found should not to be an fatal error

[dongsheng.song at gmail dot com]

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 c4773de8739c6155aa847c5ee80f1fa1437a656a
Author: Alan Modra 
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

[dongsheng.song at gmail dot com]

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..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 
+#include 
 #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

[dongsheng.song at gmail dot com]

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/4.6.0/../../../../i686-w64-mingw32/bin/ld.exe:
could not unlink output file
collect2: ld returned 1 exit status

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

[dongsheng.song at gmail dot com]

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

Dongsheng Song  changed:

   What|Removed |Added

 CC||dongsheng.song at gmail dot
   ||com

--- Comment #11 from Dongsheng Song  
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=gcc&view=rev&rev=16
> Log:
> 2011-02-10  Kai Tietz  
> 
> 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 go/47726] New: language go can not build for mingw target

[dongsheng.song at gmail dot com]

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'
/home/oracle/vcs/s

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

[dongsheng.song at gmail dot com]

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

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


C:\>type Hello.cpp
#include 
int main()
{
std::cout << "Hello, Wolrd!" << std::endl;
return 0;
}

C:\>type Hello.c
#include 
int main()
{
printf("Hello, World!\n");
return 0;
}

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

[dongsheng.song at gmail dot com]

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'

[dongsheng.song at gmail dot com]

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

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 
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_ostream >& std::operator<<
 >(std::basic_ostream >&,
char const*)'
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x26): undefined reference to
`std::basic_ostream >& std::endl >(std::basic_ostream >&)'
/tmp/ccbwXfkL.o:Hello.cpp:(.text+0x2e): undefined reference to
`std::basic_ostream
>::operator<<(std::basic_ostream >&
(*)(std::basic_ostream >&))'
/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'

[dongsheng.song at gmail dot com]

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: 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_ostream >& std::operator<<
 >(std::basic_ostream >&,
char const*)'
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x26): undefined reference to
`std::basic_ostream >& std::endl >(std::basic_ostream >&)'
/tmp/cc39V2U9.o:Hello.cpp:(.text+0x2e): undefined reference to
`std::basic_ostream
>::operator<<(std::basic_ostream >&
(*)(std::basic_ostream >&))'
/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 lto/47241] lto not work on mingw32, reporting 'ld.exe: could not unlink output file'

[dongsheng.song at gmail dot com]

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


C:\>g++ -pipe -O2 -flto -static -o Hello.c.static.exe Hello.c
C:\>Hello.c.static.exe


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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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
> 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 target/47753] Invalid 32bit libstdc++.dll.a on mingw-w64 target

[dongsheng.song at gmail dot com]

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 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/47891] New: GCC 4.6 LTO not worked reliable on Windows target

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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 :
  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 
  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 :
  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 
  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 c/57848] New: internal compiler error on build with mingw-w64

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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/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  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/57848] internal compiler error on builtin and '#pragma GCC target()' option

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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'

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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
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  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 target/57848] internal compiler error on builtin and '#pragma GCC target()' option

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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/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 c++/57897] Target x86_64-w64-mingw32 failed with '-mno-fentry isn't compatible with SEH'

[dongsheng.song at gmail dot com]

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 lines

* configure.ac (noexception_flags): Add -fasynchronous-unwind-tables.
* configure: Regenerate.


2012-10-04  Uros Bizjak  

* configure.ac (noexception_flags): Add -fasynchronous-unwind-tables.
* configure: Regenerate.

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

[dongsheng.song at gmail dot com]

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'

[dongsheng.song at gmail dot com]

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
`mktemp` -c -x c++ -fasynchronous-unwind-tables - >/dev/null
> #pragma GCC target("sse4a")
> EOF
: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: 138bc75d-0d04-0410-961f-82ee

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

[dongsheng.song at gmail dot com]

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 lto/47891] GCC 4.6 LTO not worked reliable on Windows target

[dongsheng.song at gmail dot com]

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
> branch: .

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

[dongsheng.song at gmail dot com]

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 Lu's linker from lto-mixed
> > branch: .
> 
> 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] GCC 4.6/4.7 LTO not worked reliable on Windows target

[dongsheng.song at gmail dot com]

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
>  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 
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 c++/43601] Enormous increase in DLL object files size in 4.5

[dongsheng.song at gmail dot com]

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

Dongsheng Song  changed:

   What|Removed |Added

 CC||dongsheng.song at gmail dot
   ||com

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

me too.

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

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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

[dongsheng.song at gmail dot com]

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