[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation

[daniel.f.starke at freenet dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461

--- Comment #8 from Daniel Starke  ---
This bug was fixes in mingw-w64. The bug fix is included since versions 8.0.1.
See
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/bb03f15f-db70-a511-a10d-396fbd8cf3c1%40126.com/#msg37259429
The bug report here can be closed.

[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation

[daniel.f.starke at freenet dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461

--- Comment #6 from Daniel Starke  ---
Thank you for the suggestion, however, I am not involved in the mingw-w64
project. Furthermore, the fact that this regression remains against all
versions of mingw-w64 known to date does not change.
It is also unclear to me why only these two intrinsics are handled differently
now. What was the purpose of this change? Do we break existing code if the
change is reverted?

[Bug target/100461] [11/12 Regression] mingw build broken due to change of rdtsc implementation

[daniel.f.starke at freenet dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461

--- Comment #4 from Daniel Starke  ---
Created attachment 50772
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50772&action=edit
rdtsc.c

Please find attached the mingw-w64 file.

[Bug target/100461] New: [11/12 Regression] mingw build broken due to change of rdtsc implementation

[daniel.f.starke at freenet dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100461

Bug ID: 100461
   Summary: [11/12 Regression] mingw build broken due to change of
rdtsc implementation
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

GCC 11.1.0 build for mingw-w64 is broken now. Up to 10.3.0 the following was
used in gcc/config/i386/ia32intrin.h:
extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__rdtsc (void)
{
  return __builtin_ia32_rdtsc ();
}

extern __inline unsigned long long
__attribute__((__gnu_inline__, __always_inline__, __artificial__))
__rdtscp (unsigned int *__A)
{
  return __builtin_ia32_rdtscp (__A);
}
but now we have just
#define __rdtsc()   __builtin_ia32_rdtsc ()
#define __rdtscp(a) __builtin_ia32_rdtscp (a)
Changing this back fixes the build.
See also mingw-w64 7.0.0 at mingw-w64-crt/intrincs/rdtsc.c.

[Bug target/100460] New: [11/12 Regression] mingw build broken due to use of unsupported open() flags

[daniel.f.starke at freenet dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100460

Bug ID: 100460
   Summary: [11/12 Regression] mingw build broken due to use of
unsupported open() flags
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

GCC 11.1.0 fails to build with C++ under MinGW due to unsupported open() flags
S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH in function
finish_module_processing() within gcc/cp/module.cc.
I suggest to remove these flags.
MinGW will not fix this due to unforseen side effects:
https://sourceforge.net/p/mingw/mailman/mingw-users/thread/znzrt579@wanadoo.es/

[Bug preprocessor/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

[daniel.f.starke at freenet dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253

--- Comment #6 from Daniel Starke  ---
That is what I did as workaround for me, but I am not sure how this affacts
other targets.

[Bug preprocessor/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253

Daniel Starke  changed:

   What|Removed |Added

  Component|target  |preprocessor

--- Comment #3 from Daniel Starke  ---
Introduced with r270943.

[Bug target/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253

--- Comment #2 from Daniel Starke  ---
Minimal test case on MSys/MinGW:

echo '#include ' | gcc -MD -MF - -fsyntax-only -x c -

Result with gcc 9.3.0:
-:  \
 e:\msys\mingw64_9.3.0\lib\gcc\x86_64-w64-mingw32\9.3.0\include\stddef.h \
[...]

Result with gcc 10.1.0 (':' in path was quoted):
-: E\:/msys/mingw64/mingw/include/stddef.h \
[...]

[Bug target/95253] [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253

--- Comment #1 from Daniel Starke  ---
Edit: I meant colon character, not column operator.

[Bug target/95253] New: [10/11 Regression] Build failure on MSys. Wrong dependency file escaping on Windows.

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95253

Bug ID: 95253
   Summary: [10/11 Regression] Build failure on MSys. Wrong
dependency file escaping on Windows.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Previously in gcc 9.3.0, escaping of the dependency file output still worked
well. Now I get a dependency check error from make when building mingw-w64 crt
due to wrong output escaping in gcc 10.1.0.
9.3.0 output:
 E:/msys/mingw64/include/windows.h
10.1.0 output:
 E\:/msys/mingw64/include/windows.h
Obviously, the column operator should not be escaped here.

Compiled gcc in both cases on MSys/MinGW (not MSys2) with:
Target: x86_64-w64-mingw32
Configured with: ../gcc-src/configure --enable-languages=c,c++
--enable-seh-exceptions --enable-threads=posix --disable-nls
--enable-shared=libstdc++ --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/new-gcc/lib/gmp-6.1.2 --with-mpfr=/new-gcc/lib/mpfr-3.1.6
--with-mpc=/new-gcc/lib/mpc-1.1.0 --with-isl=/new-gcc/lib/isl-0.18
--with-host-libstdcxx='-lstdc++ -lsupc++'
Thread model: posix
Supported LTO compression algorithms: zlib

[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015

Daniel Starke  changed:

   What|Removed |Added

  Known to work||8.3.0

--- Comment #10 from Daniel Starke  ---
Whatever it was, for me the bug is gone using gcc 8.3.0 with binutils 2.32.

[Bug tree-optimization/88896] [8/9 Regression] integer overflow check optimized away

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896

--- Comment #3 from Daniel Starke  ---
Never mind my question.

[Bug tree-optimization/88896] [8/9 Regression] integer overflow check optimized away

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896

--- Comment #2 from Daniel Starke  ---
You are right. So you are saying that the compiler actually checks all cases of
the loop?

[Bug tree-optimization/88896] New: [8/9 Regression] integer overflow check optimized away

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88896

Bug ID: 88896
   Summary: [8/9 Regression] integer overflow check optimized away
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Created attachment 45451
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45451&action=edit
test case and asm output

Using built-in specs.
COLLECT_GCC=E:\msys\mingw64-64\bin\gcc.exe
COLLECT_LTO_WRAPPER=e:/msys/mingw64-64/bin/../libexec/gcc/x86_64-w64-mingw32/8.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../src/gcc-8.2.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--enable-mingw-wildcard=platform --disable-win32-registry
--enable-version-specific-runtime-libs --prefix=/mingw64-64
--with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
--with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9
--with-isl=/usr/new-gcc/lib/isl-0.18 --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check
--enable-cloog-backend=isl
Thread model: posix
gcc version 8.2.0 (GCC) 

Using GCC 8.2.0 instead of 7.3.0 produces with -O2 code with an integer
overflow check optimized away. Compare the attached output for test.c:81 in
7.3.0.S and 8.2.0.S. While 7.3.0.S still contains a comparison and conditional
jump, 8.2.0.S does not.

[Bug debug/87294] New: [8/9 Regression] dwarf-3 generation fails with ICE

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87294

Bug ID: 87294
   Summary: [8/9 Regression] dwarf-3 generation fails with ICE
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Created attachment 44690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44690&action=edit
test case

Using GCC version 8.2.0 in mingw-w64 compiled with the following configuration
fails on the attached test case.
Configured with: ../../src/gcc-8.2.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--enable-mingw-wildcard=platform --disable-win32-registry
--enable-version-specific-runtime-libs --prefix=/mingw64-64
--with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
--with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9
--with-isl=/usr/new-gcc/lib/isl-0.18 --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check
--enable-cloog-backend=isl
Thread model: posix

The command-line
   g++ -Og -gdwarf-3 -fno-omit-frame-pointer -c a.cpp -o a.o
returns
   during RTL pass: final
   a.cpp: In function 'boost::_bi::bind_t::type> boost::bind(R (*)(B1, B2, B3), A1, A2,
A3) [with R = int; B1 = void*; B2 = const unsigned char*; B3 = unsigned int; A1
= boost::arg<1>; A2 = boost::arg<2>; A3 = boost::arg<3>]':
   a.cpp:99:3: internal compiler error: in based_loc_descr, at
dwarf2out.c:14272
  }
  ^
   libbacktrace could not find executable to open

Removing -gdwarf-3 or -fno-omit-frame-pointer does not result in the shown
error.
This issue does not occur with GCC 7.3.0. The bug report took a while as
multidelta needed 25 days to reduce the pre-processed test file (14.6 MiB).

[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015

--- Comment #5 from Daniel Starke  ---
I tried the version 8 branch snapshot from 2018-08-24 but the issue still
remains.

[Bug c++/87015] [8/9 Regression] miscompilation of template heavy Boost Spirit code

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015

--- Comment #4 from Daniel Starke  ---
Sure, but it will take some days as I am currently reducing a testcase for
another bug.

[Bug c++/87015] [8 Regression] miscompilation of template heavy Boost Spirit code

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015

--- Comment #2 from Daniel Starke  ---
I am not quite sure how to do this in this case. GCC terminates without an
error but the resulting application misbehaves since GCC 8.1.0. That means the
assembly output is wrong. Any idea on how to make a reproducable test case that
matches the bug reporting guidelines and works for my issue is welcome.

[Bug c++/87015] New: [8 Regression] miscompilation of template heavy Boost Spirit code

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87015

Bug ID: 87015
   Summary: [8 Regression] miscompilation of template heavy Boost
Spirit code
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Starting with GCC 8.1.0 I encounter wrong code generations when using template
heavy C++ code with Boost Spirit. Using Boost 1.66 with GCC 7.2.0, 7.3.0, 8.1.0
and 8.2.0 to compile https://github.com/daniel-starke/pp results in the
following test case results of pp:
7.2.0
TOTAL:  767
PASSED: 767
FAILED: 0

7.3.0
TOTAL:  767
PASSED: 767
FAILED: 0

8.1.0
TOTAL:  760
PASSED: 140
FAILED: 620

8.2.0
TOTAL:  760
PASSED: 140
FAILED: 620

Tests with GCC8.2.0 did show that some errors occur because the string
terminator _r2 in
https://github.com/daniel-starke/pp/blob/master/src/pp/parser/Script.hpp#L396
does gets propergated to
https://github.com/daniel-starke/pp/blob/master/src/pp/parser/StringLiteral.hpp#L226
but not properly set.

GCC 8.2.0 was configured with:
../../src/gcc-8.2.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--enable-mingw-wildcard=platform --disable-win32-registry
--enable-version-specific-runtime-libs --prefix=/mingw64-64
--with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
--with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9
--with-isl=/usr/new-gcc/lib/isl-0.18 --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check
--enable-cloog-backend=isl
Thread model: posix

It is available here: https://sourceforge.net/projects/gcc-win64/files/8.2.0/

Due to the nature of the bug I am unable to provide a reduced test case without
an better idea of what the cause of the issue is. Compiling with -Og or -O1
instead of -O2 did not change the behavior.

[Bug target/86048] [8/9 Regression] .seh_savexmm offset is negative error when compiling libpng

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048

--- Comment #1 from Daniel Starke  ---
The error does not occur if I pass -fno-reorder-blocks-and-partition.

[Bug target/86048] New: [8/9 Regression] .seh_savexmm offset is negative error when compiling libpng

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86048

Bug ID: 86048
   Summary: [8/9 Regression] .seh_savexmm offset is negative error
when compiling libpng
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Created attachment 44232
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44232&action=edit
pre-processed source file

Using GCC 8.1.0 configured as following:
  Configured with: ../../src/gcc-8.1.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--enable-mingw-wildcard=platform --disable-win32-registry
--enable-version-specific-runtime-libs --prefix=/mingw64-64
--with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
--with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9
--with-isl=/usr/new-gcc/lib/isl-0.18 --with-cloog=/usr/new-gcc/lib/cloog-0.18.4
--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check
--enable-cloog-backend=isl

The pre-build compiler binaries for x64 Windows can be downloaded from:
 
https://sourceforge.net/projects/gcc-win64/files/8.1.0/gcc-8.1.0-no-debug.7z/download

When I try to compile libpng 1.6.34 with -O2 I get the following error from the
assembler:
  Error: .seh_savexmm offset is negative

The error does not occur when compiling the same pre-processed file with GCC
7.3.0 using the same command-line options.

Attached you can find the pre-processed file in question as well as an
automatically reduced version of it.
The file was compiled with:
  gcc -save-temps -O2 -fno-ident -fno-strict-aliasing -fomit-frame-pointer -s
-static -c -o pngvalid.o pngvalid.i

The error was also posted to the libpng library by someone else:
  https://sourceforge.net/p/libpng/bugs/280/
And to the libpng library as part of the MinGW packages:
  https://github.com/Alexpux/MINGW-packages/issues/3893

I believe the error resists in GCC. I only changed the GCC compiler itself and
the MinGW runtime libraries (this was needed to compile GCC 8.1.0 on Windows).

[Bug target/80881] Implement Windows native TLS

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

Daniel Starke  changed:

   What|Removed |Added

  Known to work|5.3.0   |

--- Comment #16 from Daniel Starke  ---
Sorry, the wrong title was just me having mistaken wrong configuration options
in a newer GCC build with a regression. I have removed the "known to work"
version.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #12 from Daniel Starke  ---
I am not an expert on this field but your build does not use platform tls
support as mine is supposed to do. Furthermore, I was building all under
Windows. The only difference during the build process was the target
architecture (x86/x64). Using --enable-targets=all produced a compiler able to
build for both architectures. Not specifying --build= should just default to
the base compilers default target (which is, nevertheless, Windows). The only
issue I could possible see here is that the base compiler used to build GCC did
not support platform tls support but GCC still assumed it was available
resulting in a wrong setup. In this sense I was cross compiling (mingw x86 to
mingw-w64 x64).
Nevertheless, building GCC without --enable-tls like you did produces a working
executable for me too as mentioned on 2017-05-26.

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #9 from Daniel Starke  ---
This was a native build.
I have added the GCC build in question to
https://sourceforge.net/projects/gcc-win64/files/7.1.0/gcc-7.1.0-debug-broken-tls.7z

[Bug target/80881] [7/8 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #7 from Daniel Starke  ---
Error report from Dr.Memory:
Error #1: UNADDRESSABLE ACCESS: reading 0x-0x0008 8
byte(s)
# 0 gomp_resolve_num_threads  
[../../../../src/gcc-7.1.0/libgomp/libgomp.h:677]
# 1 GOMP_parallel 
[../../../../src/gcc-7.1.0/libgomp/parallel.c:166]
# 2 main   [h:\Temp\cpp017/test.c:11]
Note: @0:00:00.450 in thread 3376
Note: instruction: mov%fs:0x00 -> %rax

Backtrace from SIGSEGV in GDB:
#0  gomp_resolve_num_threads (specified=specified@entry=0, count=count@entry=0)
at ../../../../src/gcc-7.1.0/libgomp/parallel.c:47
threads_requested = 
max_num_threads = 
num_threads = 
busy = 
pool = 
#1  0x0040184f in GOMP_parallel (fn=fn@entry=0x401520 ,
data=data@entry=0x22fe60, num_threads=num_threads@entry=0, 
flags=flags@entry=0) at ../../../../src/gcc-7.1.0/libgomp/parallel.c:166
No locals.
#2  0x00401604 in main () at test.c:11
var = {3.72983052e-039, 0, 7.3767739e+033, 0, 7.34706519e+033, 0,
3.20827844e-039, 0, 9.03661843e-038, 0, 3.20798697e-039, 0, 
  3.67341985e-039, 0, 6.86636248e-044, 0, 1.40129846e-045, 0,
7.53898574e-043, 0, 2, 0, 3.67341985e-039, 0, 3.67341985e-039, 0, 
  1.07899982e-043, 0, 2.75506488e-040, 0, 7.67135411e+033, 0, 0, 0,
8.59029811e+009, 0, 0, 0, 3.67390189e-039, 0, 0, 0, 5.60519386e-045, 0, 
  7.53898574e-043, 0, 2.2337, 0, 1.07899982e-043, 0,
4.20389539e-045, 0, 1.77964905e-043, 0, 7.41472914e+033, 0, 3.71850803e-039, 0, 
  8.59029811e+009, 0, 3.67420457e-039, 0, 4.20389539e-043, 0,
3.20836812e-039, 0, 1.8758415e-012, 0, 3.72900095e-039, 0, 1.40129846e-045, 
  0, 3.67420457e-039, 0, 0, 0, 3.67390189e-039, 0, 0, 0,
1.07899982e-043, 0, 4.48415509e-044, 4.20389539e-045, 3.67420457e-039, 0, 0, 0, 
  2.80259693e-045, 0, 3.67420457e-039, 0, 0, 0, 1.40129846e-045, 0, 0,
0, 1.56945428e-043, 0, 0, 0, 0, 0, 3.72904579e-039, 0, 
  5.60519386e-044, 0, 3.20930979e-039, 0, 8.51989466e-043, 0,
3.20865959e-039, 0, 9.82653682e-039, 4.49998415e-039, 5.87344331e+022, 
  2.67781571e+020, 0, 0, 6.74539118e-039, 0, 2.38775653e-039, 0,
-2.81029619e+037, 2.86705666e-042, 0, 0, 1.83673515e-039, 0, 0, 0, 
  1.56945428e-043, 0, 0, 0, 0, 0, 0, 0, 0, 0, 9.93057972e-035, 0, 0, 0,
0, 0, 0, 0, 0, 0, 9.1315e-039, 0, 3.21108104e-039, 0, 
  3.20936585e-039, 0, 7.34316878e+033, 0, 3.20935604e-039, 0,
3.72902337e-039, 0, 0, 0, 3.67341985e-039, 0, 0, 1.34524653e-043, 
  7.18866112e-043, 2.80259693e-045, 3.67341985e-039, 0,
7.63497105e+033, 0, 3.67341985e-039, 0, 3.72900095e-039, 0, 3.21121556e-039, 0, 
  1.34524653e-043, 0, 0, 0, 0, 0, -nan(0x7dd000), 2.86845796e-042,
1.82959882e-018, 0, 3.67341985e-039, 0, 7.48008123e+033, 0, 0, 0, 
  3.72902337e-039, 0...}
PI = 3.14159274

Stack level 0, frame at 0x22edd0:
 rip = 0x401629 in gomp_resolve_num_threads
(../../../../src/gcc-7.1.0/libgomp/parallel.c:47); saved rip 0x40184f
 called by frame at 0x22ee30
 source language c.
 Arglist at 0x22ed88, args: specified=specified@entry=0, count=count@entry=0
 Locals at 0x22ed88, Previous frame's sp is 0x22edd0
 Saved registers:
  rbx at 0x22edb0, rsi at 0x22edb8, rdi at 0x22edc0, rip at 0x22edc8, xmm15 at
0x22edc8

Used mingw-w64-v5.0.2.

[Bug libgomp/80881] [7 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

--- Comment #2 from Daniel Starke  ---
True, I have rebuild GCC without --enable-tls enabled and the null pointer
access is gone. So I guess there is still no TLS support for mingw-w64 (even
though Windows supports it as far as I know).

[Bug libgomp/80881] New: [7.1 Regression] null pointer access in libgomp.h

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80881

Bug ID: 80881
   Summary: [7.1 Regression] null pointer access in libgomp.h
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

GCC 7.1.0 compiled OpenMP applications fail with invalid memory access to
address 0.

Used configuration:
../../src/gcc-7.1.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--enable-tls --disable-nls --disable-shared --enable-static
--enable-fully-dynamic-string --enable-lto --enable-plugins --enable-libgomp
--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw64-64 --with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/usr/new-gcc/lib/gmp-5.0.5 --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
--with-mpc=/usr/new-gcc/lib/mpc-0.9 --with-isl=/usr/new-gcc/lib/isl-0.18
--with-cloog=/usr/new-gcc/lib/cloog-0.18.4 --with-host-libstdcxx='-lstdc++
-lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl
Thread model: posix
gcc version 7.1.0 (GCC)

Sample application:
#include 
#include 

#define N 1024

int main() {
int i;
float var[N];
volatile float PI = 3.1415927;

#   pragma omp parallel for private(i)
for (i = 0; i < N; i++) {
var[i] = (1024.0f / PI) + 0.5f;
}

return EXIT_SUCCESS;
}

Error message from Dr.Memory (32-bit variant):
Error #1: UNADDRESSABLE ACCESS: reading 0x-0x0004 4 byte(s)
# 0 GOMP_parallel  
[../../../../../src/gcc-7.1.0/libgomp/libgomp.h:677]
# 1 main[h:\Temp\cpp017/test.c:11]
Note: @0:00:00.642 in thread 6700
Note: instruction: mov%gs:0x00 -> %esi

Error message from Dr.Memory (64-bit variant):
Error #1: UNADDRESSABLE ACCESS: reading
0x-0x0008 8 byte(s)
# 0 GOMP_parallel  
[../../../../src/gcc-7.1.0/libgomp/libgomp.h:677]
# 1 main[h:\Temp\cpp017/test.c:11]
Note: @0:00:00.170 in thread 1320
Note: instruction: mov%fs:0x00 -> %rdi

[Bug ipa/78535] [6.2] invalid code generation with -O1 -fdevirtualize

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78535

--- Comment #3 from Daniel Starke  ---
Created attachment 40176
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40176&action=edit
-fdump-ipa-devirt-details output

Requested -fdump-ipa-devirt-details output.

[Bug ipa/78535] [6.2] invalid code generation with -O1 -fdevirtualize

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78535

--- Comment #1 from Daniel Starke  ---
Comparing the outputs created with -fdump-tree-all enabled for both tested
command-line combinations hints that -flto -fdevirtualize fails when one of the
following passes is enabled via -O1:
- nothrow
- early_optimizations
- objsz1
- ccp1
- forwprop1
- esra
- ealias
- fre1
- mergephi1
- dse1
- cddce1
- local-pure-const1

[Bug ipa/78535] New: [6.2] invalid code generation with -O1 -fdevirtualize

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78535

Bug ID: 78535
   Summary: [6.2] invalid code generation with -O1 -fdevirtualize
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Using GCC:
Target: x86_64-w64-mingw32
Configured with: ../../src/gcc-6.2.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--enable-tls --disable-nls --enable-shared=libstdc++ --enable-static
--enable-fully-dynamic-string --enable-lto --enable-plugins --enable-libgomp
--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw64-64 --with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/usr/new-gcc/lib/gmp-5.0.5 --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
--with-mpc=/usr/new-gcc/lib/mpc-0.9 --with-isl=/usr/new-gcc/lib/isl-0.14.1
--with-cloog=/usr/new-gcc/lib/cloog-0.18.3 --with-host-libstdcxx='-lstdc++
-lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl
Thread model: posix

I get a segmentation fault when compiling a simple hello world C++ application
(libstdc++ was build with lto enabled).
#include 
int main() {
std::cout << "Hello World!" << std::endl;
return 0;
}
This may be related to PR 71207.

The issue occurs when enabling -flto -O1 -fdevirtualize and not with -flto -O0
-fdevirtualize. I tried to isolate the additional -O1 enabled optimization by
enabling all options that were enabled by -O1 (by comparing the outputs of -Q
-v) manually but the problem did not occur. I noticed that -finline was not
enabled this way, however, passing -fno-inline to the problematic command-line
(with -O1) did produce the same flags in the -Q -v output as when I enabled all
options manually additional to -O0. But it did result in a erroneous
executable. So I assume that there are more options set than shown by -Q -v
when enabling -O1 that finally lead to the issue or these options were passed
differently to the lto stage.

The backtrace looks like this:
#0  0x in ?? ()
No symbol table info available.
#1  0x004ded8a in widen (__c=10 '\n', this=0x4e9180 <(anonymous
namespace)::ctype_c>)
at
E:/msys/new-gcc/bin64-64/gcc-6.2.0/x86_64-w64-mingw32/libstdc++-v3/include/bits/locale_facets.h:877
__c = 10 '\n'
this = 0x4e9180 <(anonymous namespace)::ctype_c>
#2  widen (__c=10 '\n', this=) at
E:/msys/new-gcc/bin64-64/gcc-6.2.0/x86_64-w64-mingw32/libstdc++-v3/include/bits/basic_ios.h:450
No locals.
#3  std::endl > (__os=...) at
E:/msys/new-gcc/bin64-64/gcc-6.2.0/x86_64-w64-mingw32/libstdc++-v3/include/ostream:591
No locals.
#4  0x004e6f0e in operator<< () at
e:/msys/mingw64-64/lib/gcc/x86_64-w64-mingw32/6.2.0/include/c++/ostream:113
No locals.
#5  main () at test.cpp:4

[Bug c/70378] [5.3] inconsistant warnings with -Wconversion for different types

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378

--- Comment #1 from Daniel Starke  ---
No warning was observed when using g++ instead of gcc.

[Bug c/70378] New: [5.3] inconsistant warnings with -Wconversion for different types

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70378

Bug ID: 70378
   Summary: [5.3] inconsistant warnings with -Wconversion for
different types
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Tested with GCC 4.4.3 and 5.3.0 whereas 5.3.0 was configured as
Configured with: ../../src/gcc-5.3.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --enable-threads=posix
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugins --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw64-64 --with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/usr/new-gcc/lib/gmp-5.0.5 --with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2
--with-mpc=/usr/new-gcc/lib/mpc-0.9 --with-isl=/usr/new-gcc/lib/isl-0.12.2
--with-cloog=/usr/new-gcc/lib/cloog-0.18.3 --with-host-libstdcxx='-lstdc++
-lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl

#include 
#include 
#include 

#define PARSE(Type) \
do { \
const char * a = str; \
Type b = 0; \
while (*a != 0) { \
b = (Type)((b * 10) + (Type)(*a) - '0'); \
a++; \
} \
printf(#Type " = %u\n", (unsigned int)b); \
} while (0)

int main() {
const char * str = "123";

PARSE(int8_t);
PARSE(int16_t);
PARSE(int32_t);
PARSE(int64_t);
PARSE(uint8_t);
PARSE(uint16_t);
PARSE(uint32_t);
PARSE(uint64_t);
PARSE(unsigned int);
PARSE(unsigned);

return EXIT_SUCCESS;
}

This code only produces a warning for uint32_t when compiled with -Wconversion:
test.c:10:24: warning: conversion to 'uint32_t {aka unsigned int}' from 'char'
may change the sign of the result [-Wsign-conversion]
b = (Type)((b * 10) + (Type)(*a) - '0'); \
^
test.c:25:2: note: in expansion of macro 'PARSE'
  PARSE(uint32_t);

uint32_t was defined as:
typedef unsigned   uint32_t;

[Bug target/69284] [5.3] SIGSEGV when running 32-bit result on MinGW when linked dynamically

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69284

--- Comment #6 from Daniel Starke  ---
(In reply to katayama.hirofumi...@gmail.com from comment #4)
> Hello, Andrew Pinski.
> Where is ld bug track?

See https://sourceware.org/bugzilla/show_bug.cgi?id=19480

[Bug lto/69394] [5.3] ICE when linking with lto

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394

--- Comment #4 from Daniel Starke  ---
I see, but the output of the same GCC version should be the same regardless the
host if the target is the same, right?
I used the same source tree to build GCC 5.3.0 for x86_64-linux-gnu and for
x86_64-w64-mingw32 host, both targeting x86_64-w64-mingw32.
When I compile for example libsqlite3 on x86_64-w64-mingw32 with LTO enabled
and try to link it on x86_64-linux-gnu, I get the ICE.
If I compile libsqlite on x86_64-linux-gnu with the same options it works
without an issue. So I guess the LTO format does not only depend on the used
GCC version but also on the host. But this would be something I do not expect.
Having the same GCC version (in all 3 places) and the same target should also
give me the same result IMHO.

Nevertheless, should I create a new PR for the problem with the non-executable
result? I fail for example to run
boost_1_54_0/libs/program_options/example/first.cpp on Windows, when I enable
LTO on my Linux host.

[Bug lto/69394] [5.3] ICE when linking with lto

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394

--- Comment #2 from Daniel Starke  ---
I have tested the same with gcc 4.9.3 to make clear whether this is a
regression or not. Sadly I was not able to build the libstdc++ with -flto.
Compiling the same program as before did not result in a ICE but did produce a
binary which was not exatuable on the target platform.
Next I build gcc 5.3.0 again and all used libraries with that compiler. Before
I did use some libraries I generated with gcc 5.3.0 on the target platform, not
on Linux. So I suspect that the output of the same gcc differs on Windows and
Linux even though the same target is built.
The result was the same as with gcc 4.9.3. The produced binary was not
executable.
For information, this was the backtrace:
#0  0x00635ef2 in std::type_info::operator== (this=this@entry=0x6cffe8
, arg=...)
at ../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/tinfo.cc:46
#1  0x005bf0f4 in __cxxabiv1::__si_class_type_info::__do_dyncast
(this=0x6cffe8 , src2dst=0, 
access_path=__cxxabiv1::__class_type_info::__contained_public,
dst_type=0x0, obj_ptr=0x3790a0, 
src_type=0x6e5280 , src_ptr=0x3790a0,
result=...)
at
../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/si_class_type_info.cc:52
#2  0x006a6fdb in __cxxabiv1::__dynamic_cast (src_ptr=0x3790a0,
src_type=src_type@entry=0x6e5280 , 
dst_type=dst_type@entry=0x0, src2dst=src2dst@entry=0) at
../../../../../src/gcc-5.3.0/libstdc++-v3/libsupc++/dyncast.cc:72
#3  0x006a12b0 in std::use_facet >
(__loc=...)
at
/new-gcc/bin64-64/gcc-5.3.0/x86_64-w64-mingw32/libstdc++-v3/include/bits/locale_classes.tcc:139
#4  0x004dfce5 in boost::filesystem::path::codecvt() ()
#5  0x in ?? ()
#6  0x0067b727 in std::__cxx11::basic_string, std::allocator >::basic_string(char const*,
std::allocator const&) [clone .isra.1100] ()
#7  0x0022fde0 in ?? ()
#8  0x004f4ed9 in atexit ()
#9  0x006b52a0 in (anonymous namespace)::__new_handler ()
#10 0x0003 in ?? ()
#11 0x007050f0 in vtable for
boost::detail::sp_counted_impl_p > ()
#12 0x006ab266 in
_GLOBAL__sub_I__ZN3pcf6parser6spirit18getInnerInfoStringB5cxx11ERKN5boost6spirit4infoE
()
#13 0x in ?? ()

Using the compiled libraries from before gives me the following ICE:
lto1: internal compiler error: bytecode stream: expected tag bit_field_ref
instead of error_mark
Replacing for example the libsqlite3 from the build with the compiler in
question gives me the following ICE:
In member function 'do_real_get':
lto1: internal compiler error: bytecode stream: expected tag real_type instead
of error_mark

Is there no version tag within the LTO code which detects if the format is
compatible in an early stage?

[Bug lto/69394] New: [5.3] ICE when linking with lto

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69394

Bug ID: 69394
   Summary: [5.3] ICE when linking with lto
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Created attachment 37410
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37410&action=edit
ICE backtrace

Configured with: ../../src/gcc-5.3.0/configure --enable-languages=c,c++
--enable-seh-exceptions --enable-threads=posix --disable-nls
--enable-shared=libstdc++ --enable-static --enable-fully-dynamic-string
--enable-lto --enable-plugin --enable-libgomp --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw
--with-sysroot=/mingw --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=yes --with-gmp=/new-gcc/lib/gmp-5.0.5
--with-mpfr=/new-gcc/lib/mpfr-2.4.2 --with-mpc=/new-gcc/lib/mpc-0.9
--with-isl=/new-gcc/lib/isl-0.12.2 --with-cloog=/new-gcc/lib/cloog-0.18.3
--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check
--enable-cloog-backend=isl

Linking my C++ application leads to an ICE. The command invoked is:
x86_64-w64-mingw32-g++ -O3 -s -static -municode -D_UNICODE
-Wl,--allow-multiple-definition -flto -flto-partition=none -fuse-linker-plugin
-Wl,--gc-sections -Llib64 -L../libpcfxx/lib64 -o bin/pp.exe bin/pp.o
bin/posix_main.o bin/pp/Script.o bin/pp/Execution.o bin/pp/Variable.o
bin/pp/Shell.o bin/pp/Database.o bin/pp/Type.o bin/pp/parser/Utility.o
lib64/libpcfxx.a -lpcfxx -lboost_program_options -lboost_locale
-lboost_filesystem -lboost_iostreams -lboost_date_time -lboost_thread
-lboost_regex -lboost_system -lpcf -lsqlite3 -lws2_32
Passing -fno-use-linker-plugin instead of -fuse-linker-plugin works just fine
even if all files were compiled with -flto (flat object file).
Attached you can find the backtrace of the ICE.

[Bug target/69284] [5.3] SIGSEGV when running 32-bit result on MinGW when linked dynamically

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69284

--- Comment #1 from Daniel Starke  ---
I have tried a couple of things to find the cause of this bug.
- using -O1 instead of -O3 when building GCC
- using -O2 instead of -O3 when building GCC
- using -fno-lto when building GCC
- using the defaults compile/link flags when building GCC
- removing the -mtune=core2 -march=core2 arguments from the compile/link flags
- configuring GCC with --enable-threads=win32 instead of --enable-threads=posix
Neither worked. And I noticed, that the resulting 32-bit libstdc++-6.dll was
way smaller than its 64-bit variant.
Then I changed from binutils 2.26.51 to 2.25.1 and I got a working
libstdc++-6.dll.
So I suspect that this is a binutils issue rather than a GCC issue.
I will report it to the binutils bug tracker later on.
This bug can be closed in my opinion.

[Bug target/69284] New: [5.3] SIGSEGV when running 32-bit result on MinGW when linked dynamically

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69284

Bug ID: 69284
   Summary: [5.3] SIGSEGV when running 32-bit result on MinGW when
linked dynamically
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Using GCC 5.3 compiled as
../../src/gcc-5.3.0/configure --enable-languages=c,c++ --enable-seh-exceptions
--enable-threads=posix --disable-nls --enable-shared=libstdc++ --enable-static
--enable-fully-dynamic-string --enable-lto --enable-plugin --enable-libgomp
--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw --with-sysroot=/mingw --target=x86_64-w64-mingw32
--enable-targets=all --enable-checking=release
--with-gmp=/new-gcc/lib/gmp-5.0.5 --with-mpfr=/new-gcc/lib/mpfr-2.4.2
--with-mpc=/new-gcc/lib/mpc-0.9 --with-isl=/new-gcc/lib/isl-0.12.2
--with-cloog=/new-gcc/lib/cloog-0.18.3 --with-host-libstdcxx='-lstdc++
-lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl
on Linux (Xubuntu 14.04.3 LTS).
All system libraries where compiled with
-O3 -mtune=core2 -march=core2 -mstackrealign -fomit-frame-pointer
-Wno-maybe-uninitialized -flto -flto-partition=none -fno-builtin-stpcpy
Compiling this simple C++ program for x86 (-m32)
#include 

using namespace std;

int main() {
cout << "Hello World!" << endl;
return 0;
}
results in a SIGSEGV when linking dynamically instead of static.
Sample application compiled with
-m32 -O0 -g3 -ggdb -gdwarf-3 -o test.exe test.cpp
Compiling it in x64 mode (-m64) or static (-static) shows no issue.

See backtrace:
Starting program: H:\test.exe 
[New Thread 1132.0x1144]

Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
#0  0x in ?? ()
No symbol table info available.
#1  0x004015e9 in __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535)
at /mingw/lib/gcc/x86_64-w64-mingw32/5.3.0/include/c++/iostream:74
No locals.
#2  0x00401612 in _GLOBAL__sub_I_main () at test.cpp:8
No locals.
#3  0x00401887 in __main ()
std::moneypunct::id = ::id (Cannot access memory at address 0x0)>
std::__timepunct::id = ::id (Cannot access memory at address 0x0)>
std::num_get > >::id =  > >::id (Cannot access memory at address 0x0)>
std::time_get > >::id =  > >::id (Cannot access memory at address 0x0)>
std::num_put > >::id =  > >::id (Cannot access memory at address 0x0)>
std::money_get > >::id =  > >::id (Cannot access memory at address 0x0)>
std::messages::id = ::id (Cannot access memory at address 0x0)>
std::moneypunct_byname::intl = ::intl (Cannot access memory at address
0x0)>
std::time_put > >::id =  > >::id (Cannot access memory at address 0x0)>
std::collate::id = ::id (Cannot access memory at address 0x0)>
std::numpunct::id = ::id (Cannot access memory at address 0x0)>
std::moneypunct::intl = ::intl (Cannot access memory at address 0x0)>
std::moneypunct::intl = ::intl (Cannot access memory at address 0x0)>
std::money_put > >::id =  > >::id (Cannot access memory at address 0x0)>
std::moneypunct::id = ::id (Cannot access memory at address 0x0)>
std::moneypunct_byname::intl = ::intl (Cannot access memory at address
0x0)>
#4  0x005d in ?? ()
std::moneypunct::id = ::id (Cannot access memory at address 0x0)>
std::__timepunct::id = ::id (Cannot access memory at address 0x0)>
std::num_get > >::id =  > >::id (Cannot access memory at address 0x0)>
std::time_get > >::id =  > >::id (Cannot access memory at address 0x0)>
std::num_put > >::id =  > >::id (Cannot access memory at address 0x0)>
std::money_get > >::id =  > >::id (Cannot access memory at address 0x0)>
std::messages::id = ::id (Cannot access memory at address 0x0)>
std::moneypunct_byname::intl = ::intl (Cannot access memory at address
0x0)>
std::time_put > >::id =  > >::id (Cannot access memory at address 0x0)>
std::collate::id = ::id (Cannot access memory at address 0x0)>
std::numpunct::id = ::id (Cannot access memory at address 0x0)>
std::moneypunct::intl = ::intl (Cannot access memory at address 0x0)>
std::moneypunct::intl = ::intl (Cannot access memory at address 0x0)>
std::money_put > >::id =  > >::id (Cannot access memory at address 0x0)>
std::moneypunct::id = ::id (Cannot access memory at address 0x0)>
std::moneypunc

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995

Daniel Starke  changed:

   What|Removed |Added

  Known to fail||5.2.0

--- Comment #5 from Daniel Starke  ---
The bug is still present in GCC 5.2.0.

[Bug target/65867] [5/6 Regression] bootstrap fails for mingw32 due to missing header in ssp.c

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867

--- Comment #4 from Daniel Starke  ---
I have already sent a patch to the ML.
https://gcc.gnu.org/ml/gcc-patches/2015-04/msg01539.html

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995

--- Comment #4 from Daniel Starke  ---
I was able to build r222810 without bootstrap. However, the result remains the
same. I am still getting the following error when linking all together:
lto1.exe: internal compiler error: in add_symbol_to_partition_1, at
lto/lto-partition.c:211
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper.exe: fatal error: E:\msys\mingw64-64\bin\g++.exe returned 1 exit
status
compilation terminated.
collect2.exe: fatal error: lto-wrapper returned 1 exit status
compilation terminated.

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995

--- Comment #3 from Daniel Starke  ---
I have yet to bootstrap the current trunk (r222810). It currently fails with
/usr/new-gcc/bin32/./prev-gcc/xg++ -B/usr/new-gcc/bin32/./prev-gcc/
-B/mingw/mingw32/bin/ -nostdinc++
-B/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/src/.libs
-B/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/libsupc++/.libs 
-I/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32 
-I/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/include 
-I/usr/new-gcc/src/gcc-trunk/libstdc++-v3/libsupc++
-L/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/src/.libs
-L/usr/new-gcc/bin32/prev-mingw32/libstdc++-v3/libsupc++/.libs -c   -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../src/gcc-trunk/gcc
-I../../src/gcc-trunk/gcc/build -I../../src/gcc-trunk/gcc/../include 
-I../../src/gcc-trunk/gcc/../libcpp/include -DPTW32_STATIC_LIB \
-o build/genmddeps.o ../../src/gcc-trunk/gcc/genmddeps.c
In file included from ../../src/gcc-trunk/gcc/genmddeps.c:19:0:
../../src/gcc-trunk/gcc/system.h:1024:0: error: "CONST_CAST2" redefined
[-Werror]
 #define CONST_CAST2(TOTYPE,FROMTYPE,X) (const_cast (X))
 ^
In file included from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32/bits/gthr.h:148:0,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/ext/atomicity.h:35,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/bits/basic_string.h:39,
 from
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/string:52,
 from ../../src/gcc-trunk/gcc/system.h:201,
 from ../../src/gcc-trunk/gcc/genmddeps.c:19:
E:/msys/new-gcc/bin32/prev-mingw32/libstdc++-v3/include/mingw32/bits/gthr-default.h:33:0:
note: this is the location of the previous definition
 #define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE _q;
TOTYPE _nq;})(X))._nq)
 ^
cc1plus.exe: all warnings being treated as errors

I will try to compile the trunk without bootstrap.

[Bug lto/65995] LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995

--- Comment #2 from Daniel Starke  ---
I already applied the open() patch listed there so this is definitively a
different bug. I will try again with the current trunk hopefully within this
week.

[Bug lto/65995] New: LTO: ICE in add_symbol_to_partition_1 for debug build

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65995

Bug ID: 65995
   Summary: LTO: ICE in add_symbol_to_partition_1 for debug build
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de
  Target Milestone: ---

Using GCC 5.1.0 compiled as:
COLLECT_GCC=E:\msys\mingw64-64\bin\g++.exe
COLLECT_LTO_WRAPPER=e:/msys/mingw64-64/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../src/gcc-5.1.0/configure --host=x86_64-w64-mingw32
--enable-languages=c,c++ --enable-seh-exceptions --disable-nls --disable-shared
--enable-static --enable-fully-dynamic-string --enable-lto --enable-plugins
--enable-libgomp --with-dwarf2 --disable-win32-registry
--enable-version-specific-runtime-libs --prefix=/mingw64-64
--with-sysroot=/mingw64-64 --target=x86_64-w64-mingw32 --enable-targets=all
--enable-checking=release --with-gmp=/usr/new-gcc/lib/gmp-5.0.5
--with-mpfr=/usr/new-gcc/lib/mpfr-2.4.2 --with-mpc=/usr/new-gcc/lib/mpc-0.9
--with-isl=/usr/new-gcc/lib/isl-0.12.2
--with-cloog=/usr/new-gcc/lib/cloog-0.18.1 --with-host-libstdcxx='-lstdc++
-lsupc++' --disable-cloog-version-check --enable-cloog-backend=isl
Thread model: win32
gcc version 5.1.0 (GCC)

produces an ICE at lto/lto-partition.c:211 for me when linking as:
g++ -static -Wl,--allow-multiple-definition -flto -Llib64 -L../libpcfxx/lib64
-o bin/pp.exe lib64/libpcfxx.a bin/pp.o bin/posix_main.o bin/data/pp/Script.o
bin/data/pp/Execution.o bin/data/pp/Variable.o -lpcfxx -lboost_program_options
-lboost_locale -lboost_filesystem -lboost_iostreams -lboost_date_time
-lboost_thread -lboost_regex -lboost_system -lpcf -lws2_32

The command line passed to lto1.exe is:
e:/msys/mingw64-64/lib/gcc/../../libexec/gcc/x86_64-w64-mingw32/5.1.0/lto1.exe
-quiet -dumpdir bin/ -dumpbase pp.exe.wpa -mstackrealign -mtune=core2
-march=core2 -municode -mtune=generic -march=x86-64 -auxbase pp -Og
-fexceptions -fmath-errno -fsigned-zeros -ftrapping-math -fno-trapv
-fno-strict-overflow -fno-openmp -fno-openacc
-fltrans-output-list=C:\Users\a\AppData\Local\Temp\ccx77s2N.ltrans.out -fwpa
@C:\Users\a\AppData\Local\Temp\ccZr8s2N

The backtrace is:
#0  add_symbol_to_partition_1 (part=0x1f6d6fb0, node=0x2ceed930) at
../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:211
added = false
c = 
ref = 
node1 = 0x2cee1000
__FUNCTION__ = "add_symbol_to_partition_1"
#1  0x0043462d in add_symbol_to_partition (part=0x1f6d6fb0,
node=0x2ceed930) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:264
node1 = 
__FUNCTION__ = "add_symbol_to_partition"
#2  0x00434818 in add_references_to_partition (part=0x1f6d6fb0,
node=0x2ce82480) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:115
i = 1
ref = 0x2cfb6030
#3  0x00434510 in add_symbol_to_partition_1 (part=0x1f6d6fb0,
node=0x2ce82480) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:196
c = 
ref = 
node1 = 
__FUNCTION__ = "add_symbol_to_partition_1"
#4  0x0043462d in add_symbol_to_partition (part=0x1f6d6fb0,
node=0x2ce82480) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:264
node1 = 
__FUNCTION__ = "add_symbol_to_partition"
#5  0x00434818 in add_references_to_partition (part=0x1f6d6fb0,
node=0x2ce87620) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:115
i = 0
ref = 0x2cfabf80
#6  0x00434510 in add_symbol_to_partition_1 (part=0x1f6d6fb0,
node=0x2ce87620) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:196
c = 
ref = 
node1 = 
__FUNCTION__ = "add_symbol_to_partition_1"
#7  0x004344a6 in add_symbol_to_partition_1 (part=0x1f6d6fb0,
node=0x2ce877a8) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:181
e = 0x2cf5b750
c = 
ref = 
node1 = 
__FUNCTION__ = "add_symbol_to_partition_1"
#8  0x004344a6 in add_symbol_to_partition_1 (part=0x1f6d6fb0,
node=0x2ce87930) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:181
e = 0x2cf5b7b8
c = 
ref = 
node1 = 
__FUNCTION__ = "add_symbol_to_partition_1"
#9  0x004344a6 in add_symbol_to_partition_1 (part=0x1f6d6fb0,
node=0x2ce87ab8) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:181
e = 0x2cf5b820
c = 
ref = 
node1 = 
__FUNCTION__ = "add_symbol_to_partition_1"
#10 0x004344a6 in add_symbol_to_partition_1 (part=0x1f6d6fb0,
node=0x2cedc620) at ../../../src/gcc-5.1.0/gcc/lto/lto-partition.c:181
e = 0x2cf7ff08
c = 
ref = 
node1 = 
__FUNCTION__ = "add_symbol_to_partition_1"

[Bug lto/65559] [5/6 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559

Daniel Starke  changed:

   What|Removed |Added

 CC||daniel.f.starke at freenet dot 
de

--- Comment #17 from Daniel Starke  ---
I have used a different example to debug this issue. This was easier for me to
reconstruct the problem. The reason for this problem is probably the same.
Using gcc 5.1.0 and binutils 2.25 on mingw32-w64 (Windows host) I observed that
the first object file passed to lto-wrapper.exe fails to be included in the
list of object files. This happens because find_and_merge_options() in
run_gcc() fails when executing simple_object_find_section() for the section
.gnu.lto_.opts which appears to be inside the object file in question (checked
with objdump). Further investigation seems to be needed to track down why it
only fails to read the section only for some object files. Maybe some
incompatibility between the new binutils and gcc?

[Bug target/65867] New: [5 Regression] bootstrap fails for mingw32 due to missing header in ssp.c

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65867

Bug ID: 65867
   Summary: [5 Regression] bootstrap fails for mingw32 due to
missing header in ssp.c
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: trivial
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de

Created attachment 35392
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35392&action=edit
patch

Bootstrapping gcc 5.1 with ming32 (not mingw32-w64) fails due to missing
include of wincrypt.h within ssp.c. See attachment for a possible patch.

[Bug driver/60968] [4.9 Regression] Bootstrap fails on mingw32 with -dumpspecs

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968

--- Comment #6 from Daniel Starke  ---
I can confirm that the problem does not occur in r211103 of the 4.9 branch.

[Bug driver/60968] [4.9 Regression] Bootstrap fails on mingw32 with -dumpspecs

[daniel.f.starke at freenet dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60968

--- Comment #5 from Daniel Starke  ---
Removing --disable-sjlj-exceptions solved the problem.
I did not try the current 4.9.1 branch yet.

[Bug driver/60968] [4.9 Regression] Bootstrap fails on mingw32 with -dumpspecs

[daniel.f.starke at freenet dot de]

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

--- Comment #3 from Daniel Starke  ---
Created attachment 32720
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32720&action=edit
gdb output with backtrace for -falign-functions

I have tried building GCC 4.9.0 with other optimizations enabled and found out
that -falign-functions also causes a SIGILL when executing gcc in state 2.
Please find the GDB output for this attached.
No other optimization enabled by -O1, -O2 or -O3 caused any problem so far.

[Bug driver/60968] [4.9 Regression] Bootstrap fails on mingw32 with -dumpspecs

[daniel.f.starke at freenet dot de]

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

--- Comment #2 from Daniel Starke  ---
I was able to locate the problem. The SIGSEG only occures when bootstrapping
GCC with -fomit-frame-pointer.

[Bug driver/60968] [4.9 Regression] Bootstrap fails on mingw32 with -dumpspecs

[daniel.f.starke at freenet dot de]

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

--- Comment #1 from Daniel Starke  ---
This bug does not occurs when bootstrapping GCC with -O0 -g2.

[Bug driver/60968] New: [4.9 Regression] Bootstrap fails on mingw32 with -dumpspecs

[daniel.f.starke at freenet dot de]

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

Bug ID: 60968
   Summary: [4.9 Regression] Bootstrap fails on mingw32 with
-dumpspecs
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.f.starke at freenet dot de

Created attachment 32684
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32684&action=edit
gdb output with backtrace

Bootstrapping GCC 4.9 on Windows 7 x64 with mingw32 fails in stage 2 when
calling /new-gcc/bin32/gcc/xgcc.exe -B/new-gcc/bin32/gcc/ -dumpspecs.
GCC was configured as:
../src/gcc-4.9.0/configure --enable-languages=c,c++ --disable-sjlj-exceptions
--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string
--enable-libgomp --enable-lto --with-dwarf2 --disable-win32-registry
--enable-version-specific-runtime-libs --enable-bootstrap --build=mingw32
--enable-abi=32 --enable-checking=all --prefix=/mingw --with-mpfr=/mingw
--with-gmp=/mingw --with-mpc=/mingw

See attachment for GDB output.
GCC 4.8.2 did not show this bug.

[Bug libgomp/56357] [4.8 Regression] missing symbol references for libgomp when using -flto -fopenmp on mingw32

[daniel.f.starke at freenet dot de]

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



--- Comment #4 from Daniel Starke  
2013-03-08 20:05:19 UTC ---

I tried the same configuration in a different mingw build environment for gcc.

The resulting gcc build worked fine and did not show the described issue.

[Bug libgomp/56357] [4.8 Regression] missing symbol references for libgomp when using -flto -fopenmp on mingw32

[daniel.f.starke at freenet dot de]

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



--- Comment #3 from Daniel Starke  
2013-02-26 08:02:13 UTC ---

I have currently no means to do so but I will try that as soon as possible.

[Bug target/56412] [4.8 Regression] "libtool: cygpath: command not found" for mingw32 host

[daniel.f.starke at freenet dot de]

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



--- Comment #2 from Daniel Starke  
2013-02-20 20:23:32 UTC ---

Sorry, here is the correct patch proposed.



--- gcc-4.8.0-r196092/lto-plugin/configure2013-02-15 22:11:56 +

+++ gcc-4.8.0-patch/lto-plugin/configure2013-02-20 20:19:57 +

@@ -8734,7 +8734,14 @@

   old_archive_from_new_cmds='true'

   # FIXME: Should let the user specify the lib program.

   old_archive_cmds='lib -OUT:$oldlib$oldobjs$old_deplibs'

-  fix_srcfile_path='`cygpath -w "$srcfile"`'

+  case $host_os in

+cygwin*)

+  fix_srcfile_path='`cygpath -w "$srcfile"`'

+  ;;

+*)

+  fix_srcfile_path=''

+  ;;

+  esac

   enable_shared_with_static_runtimes=yes

   ;;

[Bug target/56412] [4.8 Regression] "libtool: cygpath: command not found" for mingw32 host

[daniel.f.starke at freenet dot de]

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



--- Comment #1 from Daniel Starke  
2013-02-20 20:15:58 UTC ---

A patch of lto-plugin/configure could solve this issue for now if the patch of

libtool.m4 was too extensive for stage4.



--- gcc-4.8.0-r196092/lto-plugin/configure2013-02-15 22:11:56 +

+++ gcc-4.8.0-patched/lto-plugin/configure2013-02-20 20:05:25 +

@@ -8734,7 +8734,7 @@

   old_archive_from_new_cmds='true'

   # FIXME: Should let the user specify the lib program.

   old_archive_cmds='lib -OUT:$oldlib$oldobjs$old_deplibs'

-  fix_srcfile_path='`cygpath -w "$srcfile"`'

+  fix_srcfile_path=''

   enable_shared_with_static_runtimes=yes

   ;;

[Bug target/56412] New: [4.8 Regression] "libtool: cygpath: command not found" for mingw32 host

[daniel.f.starke at freenet dot de]

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



 Bug #: 56412

   Summary: [4.8 Regression] "libtool: cygpath: command not found"

for mingw32 host

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: target

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: daniel.f.sta...@freenet.de





Configuring gcc r196092 for mingw32 on ming32 host without bootstrapping it

failed at lto-plugin for libtool with the following configuration:



../gcc-4.8/configure --enable-languages=c --disable-sjlj-exceptions

--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string

--enable-libgomp --enable-lto --with-dwarf2 --disable-win32-registry

--enable-version-specific-runtime-libs --disable-bootstrap --build=mingw32

--enable-abi=32 --enable-checking=release --with-mpfr=/mingw --with-gmp=/mingw

--with-mpc=/mingw --prefix=/mingw



The error message for "make all-gcc" is:

make[2]: Entering directory `/new-gcc/bin/lto-plugin'

/bin/sh ./libtool --tag=CC --tag=disable-static  --mode=compile gcc

-DHAVE_CONFIG_H -I. -I../../gcc-4.8/lto-plugin 

-I../../gcc-4.8/lto-plugin/../include -DHAVE_CONFIG_H -DPTW32_STATIC_LIB -Wall

-g -O2 -D__USE_MINGW_ACCESS -c -o lto-plugin.lo

../../gcc-4.8/lto-plugin/lto-plugin.c

./libtool: line 2008: cygpath: command not found

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../gcc-4.8/lto-plugin

-I../../gcc-4.8/lto-plugin/../include -DHAVE_CONFIG_H -DPTW32_STATIC_LIB -Wall

-g -O2 -D__USE_MINGW_ACCESS -c ""  -DDLL_EXPORT -DPIC -o .libs/lto-plugin.o

gcc.exe: : No such file or directory

gcc.exe: no input files



with the following values assigned:

srcfile: ../../gcc-4.8/lto-plugin/lto-plugin.c

fix_srcfile_path: `cygpath -w "$srcfile"`



The problem is probably within libtool.m4 where fix_srcfile_path is assigned

with cygpath even for mingw host at line 4790 with:

_LT_TAGVAR(fix_srcfile_path, $1)='`cygpath -w "$srcfile"`'

[Bug libgomp/56357] New: [4.8 Regression] missing symbol references for libgomp when using -flto -fopenmp on mingw32

[daniel.f.starke at freenet dot de]

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



 Bug #: 56357

   Summary: [4.8 Regression] missing symbol references for libgomp

when using -flto -fopenmp on mingw32

Classification: Unclassified

   Product: gcc

   Version: 4.8.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: libgomp

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: daniel.f.sta...@freenet.de

CC: ja...@gcc.gnu.org





The combination of -flto and -fopenmp is broken for mingw32 in r196092.



#define ARRAY_SIZE 10



int main() {

int i;

volatile int a[ARRAY_SIZE];

#pragma omp parallel for private(a)

for (i = 0; i < ARRAY_SIZE; i++) {

a[i] += i;

}



return 0;

}



This code works fine with "gcc -fopenmp gcc-lto-gomp.c" but results in errors

for "gcc -fopenmp -flto gcc-lto-gomp.c". Adding -lgomp does not solves this.



Error output:

C:\Users\Me\AppData\Local\Temp\cccobKR8.ltrans0.ltrans.o:cccobKR8.ltrans0.o:(.text+0x6):

undefined reference to `omp_get_num_threads'

C:\Users\Me\AppData\Local\Temp\cccobKR8.ltrans0.ltrans.o:cccobKR8.ltrans0.o:(.text+0xd):

undefined reference to `omp_get_thread_num'

C:\Users\Me\AppData\Local\Temp\cccobKR8.ltrans0.ltrans.o:cccobKR8.ltrans0.o:(.text.startup+0x26):

undefined reference to `GOMP_parallel_start'

C:\Users\Me\AppData\Local\Temp\cccobKR8.ltrans0.ltrans.o:cccobKR8.ltrans0.o:(.text.startup+0x37):

undefined reference to `GOMP_parallel_end'

could not unlink output filecollect2.exe: error: ld returned 1 exit status



This all works fine in gcc 4.7.2 with the same build configuration.



Using built-in specs.

COLLECT_GCC=D:\Programme\msys\gcc\bin\gcc.exe

COLLECT_LTO_WRAPPER=d:/programme/msys/gcc/bin/../libexec/gcc/mingw32/4.8.0/lto-wrapper.exe

Target: mingw32

Configured with: ../gcc-4.8.0-r196092/configure

--enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions

--disable-nls --disable-shared --enable-static --enable-fully-dynamic-string

--enable-libgomp --enable-lto --with-dwarf2 --disable-win32-registry

--enable-version-specific-runtime-libs --enable-bootstrap --build=mingw32

--enable-abi=32 --enable-checking=release --prefix=/mingw

Thread model: win32

gcc version 4.8.0 20130215 (experimental) (GCC)

[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target

[daniel.f.starke at freenet dot de]

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



--- Comment #13 from Daniel Starke  
2013-02-16 12:41:42 UTC ---

I just tried out to bootstrap r196092 on mingw32. There is still one more cast

patch missing to make it work for that target.



diff -uart gcc-4.8.0-r196092/gcc/ada/seh_init.c gcc-4.8.0/gcc/ada/seh_init.c

--- gcc-4.8.0-r196092/gcc/ada/seh_init.c2013-02-16 08:26:53 +

+++ gcc-4.8.0/gcc/ada/seh_init.c2013-02-06 12:01:20 +

@@ -198,7 +198,7 @@

 #endif



   Raise_From_Signal_Handler (exception, msg);

-  return 0; /* This is never reached, avoid compiler warning  */

+  return (EXCEPTION_DISPOSITION)0; /* This is never reached, avoid compiler

warning  */

 }

 #endif /* !(defined (_WIN64) && defined (__SEH__)) */

[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite

[daniel.f.starke at freenet dot de]

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



--- Comment #6 from Daniel Starke  
2013-02-13 21:08:40 UTC ---

This issue does not occur with checking enabled. See below a working

configuration.



COLLECT_GCC=D:\Programme\msys\mingw64\bin\x86_64-w64-mingw32-gcc.exe

COLLECT_LTO_WRAPPER=d:/programme/msys/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.2/lto-wrapper.exe

Target: x86_64-w64-mingw32

Configured with: ../../src/gcc-4.7.2/configure --enable-languages=c,c++

--disable-nls --disable-shared --enable-static --enable-lto --enable-libgomp

--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs

--prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32

--enable-targets=all --enable-checking=all

--with-gmp=/usr/new-cross-gcc/lib/gmp-5.0.2

--with-mpfr=/usr/new-cross-gcc/lib/mpfr-2.4.2

--with-mpc=/usr/new-cross-gcc/lib/mpc-0.9

--with-ppl=/usr/new-cross-gcc/lib/ppl-0.11.2

--with-cloog=/usr/new-cross-gcc/lib/cloog-parma-0.16.1

--with-host-libstdcxx='-lstdc++ -lsupc++' --enable-cloog-backend=ppl

Thread model: win32

gcc version 4.7.2 (GCC)

[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite

[daniel.f.starke at freenet dot de]

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



--- Comment #5 from Daniel Starke  
2013-02-07 06:43:35 UTC ---

The arithmetic exception is caught by gcc, thus not triggered in gdb. I tried a

couple of things with gdb but could not find the point at which it happens. I

will try to create a gcc variant with checking enabled. Maybe this will give

some hints about the origin of this bug.

[Bug ada/52123] [4.7/4.8 Regression] gcc bootstrap with ada fails on mingw target

[daniel.f.starke at freenet dot de]

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



--- Comment #9 from Daniel Starke  
2013-02-06 17:04:21 UTC ---

This will probably not fix all problems with ada on mingw.

My last tests with 4.7.2 made me also need to patch this:



diff -uart gcc-4.7.2-original/gcc/ada/tracebak.c gcc-4.7.2/gcc/ada/tracebak.c

--- gcc-4.7.2-original/gcc/ada/tracebak.c2011-10-24 10:31:30 +

+++ gcc-4.7.2/gcc/ada/tracebak.c2012-09-23 15:26:50 +

@@ -326,7 +326,7 @@



 #if defined (__WIN32)

 #include 

-#define IS_BAD_PTR(ptr) (IsBadCodePtr((void *)ptr))

+#define IS_BAD_PTR(ptr) (IsBadCodePtr((FARPROC)ptr))

 #elif defined (sun)

 #define IS_BAD_PTR(ptr) ((unsigned long)ptr == -1UL)

 #else

[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite

[daniel.f.starke at freenet dot de]

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



Daniel Starke  changed:



   What|Removed |Added



  Known to work||4.6.3



--- Comment #3 from Daniel Starke  
2013-02-05 19:43:05 UTC ---

Sorry, I forgot to fill out that field. Works fine with:



Using built-in specs.

COLLECT_GCC=D:\Programme\msys\mingw64\bin\x86_64-w64-mingw32-gcc.exe

COLLECT_LTO_WRAPPER=d:/programme/msys/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.6.3/lto-wrapper.exe

Target: x86_64-w64-mingw32

Configured with: ../../src/gcc-4.6.3/configure --enable-languages=c,c++

--disable-nls --disable-shared --enable-static --enable-lto --enable-libgomp

--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs

--prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32

--enable-targets=all --with-gmp=/usr/new-cross-gcc/lib/gmp-5.0.2

--with-mpfr=/usr/new-cross-gcc/lib/mpfr-2.4.2

--with-mpc=/usr/new-cross-gcc/lib/mpc-0.9

--with-ppl=/usr/new-cross-gcc/lib/ppl-0.11.2

--with-cloog=/usr/new-cross-gcc/lib/cloog-parma-0.16.1

--with-host-libstdcxx='-lstdc++ -lsupc++' --enable-cloog-backend=ppl

Thread model: win32

gcc version 4.6.3 (GCC)



This is a cross compiler, thus I can not bootstrap it. The versions of the used

libraries are in the configure string. Or do you need the base of the build

system used to create that cross compiler?

[Bug middle-end/56185] [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite

[daniel.f.starke at freenet dot de]

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



--- Comment #1 from Daniel Starke  
2013-02-03 16:24:56 UTC ---

This issue does not appear with isl backend as in the configuration below.

However, I still need ppl to build gcc.



Using built-in specs.

COLLECT_GCC=D:\Programme\msys\mingw64\bin\x86_64-w64-mingw32-gcc.exe

COLLECT_LTO_WRAPPER=d:/programme/msys/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.2/lto-wrapper.exe

Target: x86_64-w64-mingw32

Configured with: ../../src/gcc-4.7.2/configure --enable-languages=c,c++

--disable-nls --disable-shared --enable-static --enable-lto --enable-libgomp

--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs

--prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32

--enable-targets=all --with-gmp=/usr/new-cross-gcc/lib/gmp-5.0.2

--with-mpfr=/usr/new-cross-gcc/lib/mpfr-2.4.2

--with-mpc=/usr/new-cross-gcc/lib/mpc-0.9

--with-ppl=/usr/new-cross-gcc/lib/ppl-0.11.2

--with-cloog=/usr/new-cross-gcc/lib/cloog-0.18.0

--with-host-libstdcxx='-lstdc++ -lsupc++' --disable-cloog-version-check

--enable-cloog-backend=isl

Thread model: win32

gcc version 4.7.2 (GCC)

[Bug middle-end/56185] New: [4.7 Regression] ICE for Arithmetic exception with -O2 and -fgraphite

[daniel.f.starke at freenet dot de]

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



 Bug #: 56185

   Summary: [4.7 Regression] ICE for Arithmetic exception with -O2

and -fgraphite

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: middle-end

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: daniel.f.sta...@freenet.de





I get an "internal compiler error: Arithmetic exception" for:

//

#define ARRAY_SIZE 6



void bug(int var[ARRAY_SIZE]) {

int i;



for (i = 0; i < ARRAY_SIZE; i++) {

var[i] = i;

}

}

//

if ARRAY_SIZE is >= 6 when compiling it with

x86_64-w64-mingw32-gcc -O2 -fgraphite -c

or

x86_64-w64-mingw32-gcc -O3 -fgraphite -c



Using built-in specs.

COLLECT_GCC=D:\Programme\msys\mingw64\bin\x86_64-w64-mingw32-gcc.exe

COLLECT_LTO_WRAPPER=d:/programme/msys/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/4.7.2/lto-wrapper.exe

Target: x86_64-w64-mingw32

Configured with: ../../src/gcc-4.7.2/configure --enable-languages=c,c++

--disable-nls --disable-shared --enable-static --enable-lto --enable-libgomp

--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs

--prefix=/mingw64 --with-sysroot=/mingw64 --target=x86_64-w64-mingw32

--enable-targets=all --with-gmp=/usr/new-cross-gcc/lib/gmp-5.0.2

--with-mpfr=/usr/new-cross-gcc/lib/mpfr-2.4.2

--with-mpc=/usr/new-cross-gcc/lib/mpc-0.9

--with-ppl=/usr/new-cross-gcc/lib/ppl-0.11.2

--with-cloog=/usr/new-cross-gcc/lib/cloog-parma-0.16.1

--with-host-libstdcxx='-lstdc++ -lsupc++' --enable-cloog-backend=ppl

Thread model: win32

gcc version 4.7.2 (GCC)



Build with:

binutils-2.22

mingw-w64-v2.0.7

[Bug target/48659] Segmentation fault when using openMP and SSE

[daniel.f.starke at freenet dot de]

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



--- Comment #3 from Daniel Starke  
2013-01-28 11:53:14 UTC ---

I can confirm this bug for gcc 4.7.2 mingw64. The -mstackrealign command-line

flag can be used as workaround as described on

http://stackoverflow.com/questions/6716654/segmentation-fault-using-openmp-and-sse

until this bug is properly patched.

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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



--- Comment #10 from Daniel Starke  
2012-09-24 16:57:53 UTC ---

Here is the reference to the autoconf change:

http://git.savannah.gnu.org/gitweb/?p=autoconf.git;a=commitdiff;h=17ea0df46f819a9b64c21151983a5c5b8561fefb

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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



--- Comment #9 from Daniel Starke  
2012-09-24 16:55:33 UTC ---

The problem in autoconf was fixed with version 2.69. I suggest to update

AC_PREREQ within the configure.ac files to this version.

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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



--- Comment #7 from Daniel Starke  
2012-09-22 16:00:03 UTC ---

It seems to be partly a gcc autoconfig macro issue. Seeing the following in

gcc/acinclude.m4



dnl See if symbolic links work and if not, try to substitute either hard links

or simple copy.

AC_DEFUN([gcc_AC_PROG_LN_S],

[AC_MSG_CHECKING(whether ln -s works)

AC_CACHE_VAL(gcc_cv_prog_LN_S,

[rm -f conftestdata_t

echo >conftestdata_f

if ln -s conftestdata_f conftestdata_t 2>/dev/null

then

  gcc_cv_prog_LN_S="ln -s"

else

  if ln conftestdata_f conftestdata_t 2>/dev/null

  then

gcc_cv_prog_LN_S=ln

  else

if cp -p conftestdata_f conftestdata_t 2>/dev/null

then

  gcc_cv_prog_LN_S="cp -p"

else

  gcc_cv_prog_LN_S=cp

fi

  fi

fi

rm -f conftestdata_f conftestdata_t

])dnl

LN_S="$gcc_cv_prog_LN_S"

if test "$gcc_cv_prog_LN_S" = "ln -s"; then

  AC_MSG_RESULT(yes)

else

  if test "$gcc_cv_prog_LN_S" = "ln"; then

AC_MSG_RESULT([no, using ln])

  else

AC_MSG_RESULT([no, and neither does ln, so using $gcc_cv_prog_LN_S])

  fi

fi

AC_SUBST(LN_S)dnl

])



it is obvious that gcc_cv_prog_LN_S="cp -p" needs to be changed to

gcc_cv_prog_LN_S="cp -pr".



On the other hand running autoconfig on this configure.ac:

AC_PREREQ(2.64)

AC_INIT

AC_PROG_LN_S



returns the wrong output as also seen in the patch with:

if (echo >conf$$.file) 2>/dev/null; then

  if ln -s conf$$.file conf$$ 2>/dev/null; then

as_ln_s='ln -s'

# ... but there are two gotchas:

# 1) On MSYS, both `ln -s file dir' and `ln file dir' fail.

# 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable.

# In both cases, we have to default to `cp -p'.

ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe ||

  as_ln_s='cp -p'

  elif ln conf$$.file conf$$ 2>/dev/null; then

as_ln_s=ln

  else

as_ln_s='cp -p'

  fi

else

  as_ln_s='cp -p'

fi



The part mentioned by Tim Vanholder that was not in the attached patch was

certainly just overseen by me as it was not necessary to build gcc.

I have just filed a bug report against autoconf.

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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

--- Comment #5 from Daniel Starke  
2012-04-26 18:07:37 UTC ---
The mailinglist discussion covers only a part of the problem. I have attached a
possible patch for gcc 4.7.0 to highlight to problem.

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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

--- Comment #4 from Daniel Starke  
2012-04-26 18:06:54 UTC ---
Created attachment 27249
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27249
possible patch for gcc 4.7.0

[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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

--- Comment #2 from Daniel Starke  
2012-04-05 16:14:19 UTC ---
(In reply to comment #1)
> Please update this bug with respect to the mailing list discussion that took
> place.

Can you please add a link to the mailing list discussion you are referring to?

[Bug ada/52123] New: [4.7] gcc bootstrap with ada fails on mingw target

[daniel.f.starke at freenet dot de]

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

 Bug #: 52123
   Summary: [4.7] gcc bootstrap with ada fails on mingw target
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de


Bootstrapping gcc 4.7 revision 183875 fails at /gcc/ada/initialize.c when
configuring with:
--enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions
--disable-nls --disable-shared --enable-static --enable-libgomp --enable-lto
--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs
--build=mingw32 --enable-abi=32 --enable-bootstrap --enable-checking=release


Used compiler for bootstrap:
Using built-in specs.
COLLECT_GCC=D:\Programme\msys\gcc\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/gcc/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure
--enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions
--disable-nls --disable-shared --enable-static --enable-libgcj --enable-libgomp
--enable-lto --with-dwarf2 --disable-win32-registry
--enable-version-specific-runtime-libs --build=mingw32 --enable-abi=32
--enable-checking=release --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)


Error message:
/usr/new-gcc/bin/./prev-gcc/g++ -B/usr/new-gcc/bin/./prev-gcc/
-B/mingw/mingw32/bin/ -nostdinc++
-B/usr/new-gcc/bin/prev-mingw32/libstdc++-v3/src/.libs
-B/usr/new-gcc/bin/prev-mingw32/libstdc++-v3/libsupc++/.libs
-I/usr/new-gcc/bin/prev-mingw32/libstdc++-v3/include/mingw32
-I/usr/new-gcc/bin/prev-mingw32/libstdc++-v3/include
-I/usr/new-gcc/gcc-4.7.0-183875/libstdc++-v3/libsupc++
-L/usr/new-gcc/bin/prev-mingw32/libstdc++-v3/src/.libs
-L/usr/new-gcc/bin/prev-mingw32/libstdc++-v3/libsupc++/.libs -c   -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -gtoggle -DIN_GCC  
-fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual 
-Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -Iada
-I../../gcc-4.7.0-183875/gcc -I../../gcc-4.7.0-183875/gcc/ada
-I../../gcc-4.7.0-183875/gcc/../include
-I../../gcc-4.7.0-183875/gcc/../libcpp/include -I/usr/new-gcc/bin/./gmp
-I/usr/new-gcc/gcc-4.7.0-183875/gmp -I/usr/new-gcc/bin/./mpfr
-I/usr/new-gcc/gcc-4.7.0-183875/mpfr -I/usr/new-gcc/gcc-4.7.0-183875/mpc/src 
-I../../gcc-4.7.0-183875/gcc/../libdecnumber
-I../../gcc-4.7.0-183875/gcc/../libdecnumber/bid -I../libdecnumber  
-I/mingw/include ../../gcc-4.7.0-183875/gcc/ada/seh_init.c -o ada/seh_init.o
../../gcc-4.7.0-183875/gcc/ada/initialize.c: In function 'void append_arg(int*,
LPWSTR, LPWSTR, char***, int*, int)':
../../gcc-4.7.0-183875/gcc/ada/initialize.c:91:56: error: invalid conversion
from 'void*' to 'LPWSTR {aka wchar_t*}' [-fpermissive]
../../gcc-4.7.0-183875/gcc/ada/initialize.c:98:65: error: invalid conversion
from 'void*' to 'LPWSTR {aka wchar_t*}' [-fpermissive]
../../gcc-4.7.0-183875/gcc/ada/initialize.c: In function 'void
__gnat_initialize(void*)':
../../gcc-4.7.0-183875/gcc/ada/initialize.c:206:44: error: invalid conversion
from 'void*' to 'LPWSTR {aka wchar_t*}' [-fpermissive]
make[3]: *** [ada/initialize.o] Error 1
make[3]: *** Waiting for unfinished jobs
../../gcc-4.7.0-183875/gcc/ada/seh_init.c: In function 'EXCEPTION_DISPOSITION
__gnat_SEH_error_handler(_EXCEPTION_RECORD*, void*, _CONTEXT*, void*)':
../../gcc-4.7.0-183875/gcc/ada/seh_init.c:93:62: error: invalid conversion from
'void*' to 'FARPROC {aka int (__attribute__((__stdcall__)) *)()}'
[-fpermissive]
In file included from
d:\programme\msys\new-gcc\bin\prev-gcc\../lib/gcc/mingw32/4.7.0/../../../../mingw32/include/windows.h:50:0,
 from ../../gcc-4.7.0-183875/gcc/ada/seh_init.c:68:
d:\programme\msys\new-gcc\bin\prev-gcc\../lib/gcc/mingw32/4.7.0/../../../../mingw32/include/winbase.h:1865:24:
error:   initializing argument 1 of 'BOOL IsBadCodePtr(FARPROC)' [-fpermissive]
../../gcc-4.7.0-183875/gcc/ada/seh_init.c:196:10: error: invalid conversion
from 'int' to 'EXCEPTION_DISPOSITION' [-fpermissive]

[Bug target/52122] New: [4.6.x/4.7] incorrect ln -s replacement for mingw like targets in configure files

[daniel.f.starke at freenet dot de]

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

 Bug #: 52122
   Summary: [4.6.x/4.7] incorrect ln -s replacement for mingw like
targets in configure files
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de


Taking the current gcc 4.7 trunk revision 183875 (and even older versions like
4.6.x) as well as the libraries used the configure files are set to use "cp -p"
as replacement for "ln -s" for mingw targets. This is correct for files but not
for directories especially when contianing sub directories. My proposal is to
replace it with "cp -pr" to handle recursion. As a result of the current
problem ada fails bootstrapping on mingw while trying to copy a folder of
header files.

Extract from gcc/configure:
472as_ln_s='ln -s'
473# ... but there are two gotchas:
474# 1) On MSYS, both `ln -s file dir' and `ln file dir' fail.
475# 2) DJGPP < 2.04 has no symlinks; `ln -s' creates a wrapper executable.
476# In both cases, we have to default to `cp -p'.
477ln -s conf$$.file conf$$.dir 2>/dev/null && test ! -f conf$$.exe ||
478  as_ln_s='cp -p'

I hope this is the right place for this issue as I am not certain how the
configure system is handled.

[Bug target/51900] [4.6/4.7 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

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

--- Comment #10 from Daniel Starke  
2012-01-20 07:41:10 UTC ---
I have tested the problem with the option switches -O0, -O1, -O2, -O3, -O4, -Os
and -Ofast. Only -O0 results in a 5, 6, 7 output. Turning on the options listed
in the documentation activated by -O1 and -O2 in any combination (also all
together) does not results in the problematic output of 0, 0, 0. I have also
used -Wall to detect the issue, however the only warning this returns is
main.c:3:6: warning: return type of 'main' is not 'int' [-Wmain]
Compiling the test case with -O1 -flto results in the same faulty output.

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

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

--- Comment #5 from Daniel Starke  
2012-01-19 14:51:33 UTC ---
Compiling it with
gcc -static -fcommon -o main.o -c main.c
gcc -static -fcommon -o a.o -c a.c
gcc -static -o main.exe main.o a.o
results in
$ ./main
myVar[0] = 5
myVar[1] = 6
myVar[2] = 7

Compiling it with
gcc -static -O2 -fcommon -o main.o -c main.c
gcc -static -O2 -fcommon -o a.o -c a.c
gcc -static -o main.exe main.o a.o
results in
$ ./main
myVar[0] = 0
myVar[1] = 0
myVar[2] = 0

Thus a different option causes this change.

[Bug target/51900] [4.6 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

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

--- Comment #3 from Daniel Starke  
2012-01-19 11:52:27 UTC ---
[...]
COLLECT_GCC_OPTIONS='-static' '-O2' '-v' '-Q' '-o' 'a.o' '-c' '-mtune=i386'
'-march=i386'
[...]
GNU C (GCC) version 4.6.2 (mingw32)
compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version 2.4.2,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
options passed:  -v
 -iprefix d:\programme\msys\mingw462\bin\../lib/gcc/mingw32/4.6.2/ a.c
 -mtune=i386 -march=i386 -auxbase-strip a.o -O2
options enabled:  -falign-labels -fasynchronous-unwind-tables
 -fauto-inc-dec -fbranch-count-reg -fcaller-saves
 -fcombine-stack-adjustments -fcommon -fcompare-elim -fcprop-registers
 -fcrossjumping -fcse-follow-jumps -fdefer-pop -fdelete-null-pointer-checks
 -fdevirtualize -fdwarf2-cfi-asm -fearly-inlining
 -feliminate-unused-debug-types -fexpensive-optimizations
 -fforward-propagate -ffunction-cse -fgcse -fgcse-lm
 -fguess-branch-probability -fident -fif-conversion -fif-conversion2
 -findirect-inlining -finline -finline-functions-called-once
 -finline-small-functions -fipa-cp -fipa-profile -fipa-pure-const
 -fipa-reference -fipa-sra -fira-share-save-slots -fira-share-spill-slots
 -fivopts -fkeep-inline-dllexport -fkeep-static-consts -fleading-underscore
 -fmath-errno -fmerge-constants -fmerge-debug-strings
 -fmove-loop-invariants -fomit-frame-pointer -foptimize-register-move
 -foptimize-sibling-calls -fpartial-inlining -fpeephole -fpeephole2
 -fprefetch-loop-arrays -freg-struct-return -fregmove -freorder-blocks
 -freorder-functions -frerun-cse-after-loop -fsched-critical-path-heuristic
 -fsched-dep-count-heuristic -fsched-group-heuristic -fsched-interblock
 -fsched-last-insn-heuristic -fsched-rank-heuristic -fsched-spec
 -fsched-spec-insn-heuristic -fsched-stalled-insns-dep
 -fset-stack-executable -fshow-column -fsigned-zeros
 -fsplit-ivs-in-unroller -fsplit-wide-types -fstrict-aliasing
 -fstrict-overflow -fstrict-volatile-bitfields -fthread-jumps
 -ftoplevel-reorder -ftrapping-math -ftree-bit-ccp -ftree-builtin-call-dce
 -ftree-ccp -ftree-ch -ftree-copy-prop -ftree-copyrename -ftree-cselim
 -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre
 -ftree-loop-if-convert -ftree-loop-im -ftree-loop-ivcanon
 -ftree-loop-optimize -ftree-parallelize-loops= -ftree-phiprop -ftree-pre
 -ftree-pta -ftree-reassoc -ftree-scev-cprop -ftree-sink
 -ftree-slp-vectorize -ftree-sra -ftree-switch-conversion -ftree-ter
 -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -funwind-tables
 -fvar-tracking -fvar-tracking-assignments -fvect-cost-model
 -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double
 -maccumulate-outgoing-args -malign-double -malign-stringops
 -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mno-red-zone -mno-sse4
 -mpush-args -msahf -mstack-arg-probe
[...]

[Bug c/51900] New: [4.6 Regression] const variable initialization always zero

[daniel.f.starke at freenet dot de]

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

 Bug #: 51900
   Summary: [4.6 Regression] const variable initialization always
zero
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de
  Host: mingw32
Target: mingw32
 Build: mingw32


/* a.c */
#include "a.h"
const int myVar[3] = { 5, 6, 7 };

/* a.h */
#ifndef a_h
#define a_h
const int myVar[3];
#endif

/* main.c */
#include 
#include "a.h"
void main() {
 int i;
 for (i = 0; i < 3; i++) printf("myVar[%i] = %i\n", i, myVar[i]);
 fflush(stdout);
}

Result gcc 4.5.2:
myVar[0] = 5
myVar[1] = 6
myVar[2] = 7

Result gcc 4.6.2:
myVar[0] = 0
myVar[1] = 0
myVar[2] = 0

Configurations:
Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw452\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw452/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --disable-nls --disable-shared --enable-static
--enable-libgcj --enable-libgomp --enable-lto --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw
--program-suffix= --build=mingw32 --enable-abi=32 --enable-checking=release
Thread model: win32
gcc version 4.5.2 (GCC)

Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw462\bin\gcc.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw462/bin/../libexec/gcc/mingw32/4.6.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.6.2/configure
--enable-languages=c,ada,c++,fortran,objc,obj-c++ --disable-sjlj-exceptions
--disable-nls --disable-shared --enable-static --enable-libgcj --enable-libgomp
--enable-lto --with-dwarf2 --disable-win32-registry
--enable-version-specific-runtime-libs --build=mingw32 --enable-abi=32
--enable-checking=release --prefix=/mingw
Thread model: win32
gcc version 4.6.2 (GCC)

Compiled with:
CC = gcc
CFLAGS = -static -O2
LDFLAGS = -static

all: main.exe

.PHONY: clean
clean:
rm -f *.o
rm -f *.exe

main.exe: main.o a.o
$(CC) $(LDFLAGS) -o main.exe main.o a.o

main.o: main.c
$(CC) $(CFLAGS) -o main.o -c main.c

a.o: a.c
$(CC) $(CFLAGS) -o a.o -c a.c

[Bug target/48233] New: [4.6] can't bootstrap with ada, java and go on mingw

[daniel.f.starke at freenet dot de]

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

   Summary: [4.6] can't bootstrap with ada, java and go on mingw
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de
  Host: mingw
Target: mingw
 Build: mingw


Bootstrapping gcc 4.6 r170503 on mingw with ada, java and go enabled and the
following configuration fails with several errors.
configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++,go
--disable-sjlj-exceptions --disable-nls --disable-shared --enable-static
--enable-libgcj --enable-libgomp --enable-lto --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --build=mingw32
--enable-abi=32 --enable-checking=release --prefix=mingw


The first error:
/usr/new-gcc/bin/./prev-gcc/xgcc -B/usr/new-gcc/bin/./prev-gcc/
-B/mingw/mingw32/bin/ -L/usr/new-gcc/bin/mingw32/winsup/mingw
-L/usr/new-gcc/bin/mingw32/winsup/w32api/lib -isystem
/usr/new-gcc/gcc-4.6-20110225/winsup/mingw/include -isystem
/usr/new-gcc/gcc-4.6-20110225/winsup/w32api/include -B/mingw/mingw32/bin/
-B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem
/mingw/mingw32/sys-include-c -g -O2 -D__USE_MINGW_ACCESS
-Wno-pedantic-ms-format -gtoggle  -gnatpg -gnata -nostdinc -I- -I. -Iada
-I../../gcc-4.6-20110225/gcc/ada -I../../gcc-4.6-20110225/gcc/ada/gcc-interface
ada/sdefault.adb -o ada/sdefault.o
gnat1.exe: warning: command line option '-Wno-pedantic-ms-format' is valid for
C/C++/ObjC/ObjC++ but not for Ada [enabled by default]
/usr/new-gcc/bin/./prev-gcc/xgcc -B/usr/new-gcc/bin/./prev-gcc/
-B/mingw/mingw32/bin/ -L/usr/new-gcc/bin/mingw32/winsup/mingw
-L/usr/new-gcc/bin/mingw32/winsup/w32api/lib -isystem
/usr/new-gcc/gcc-4.6-20110225/winsup/mingw/include -isystem
/usr/new-gcc/gcc-4.6-20110225/winsup/w32api/include -B/mingw/mingw32/bin/
-B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem
/mingw/mingw32/sys-include-c   -g -O2 -D__USE_MINGW_ACCESS
-Wno-pedantic-ms-format -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
-Wmissing-format-attribute -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -Wold-style-definition -Wc++-compat  
-DHAVE_CONFIG_H -I. -Iada -I../../gcc-4.6-20110225/gcc
-I../../gcc-4.6-20110225/gcc/ada -I../../gcc-4.6-20110225/gcc/../include
-I../../gcc-4.6-20110225/gcc/../libcpp/include -I/usr/new-gcc/bin/./gmp
-I/usr/new-gcc/gcc-4.6-20110225/gmp -I/usr/new-gcc/bin/./mpfr
-I/usr/new-gcc/gcc-4.6-20110225/mpfr -I/usr/new-gcc/gcc-4.6-20110225/mpc/src 
-I../../gcc-4.6-20110225/gcc/../libdecnumber
-I../../gcc-4.6-20110225/gcc/../libdecnumber/bid -I../libdecnumber   
../../gcc-4.6-20110225/gcc/ada/seh_init.c -o ada/seh_init.o
../../gcc-4.6-20110225/gcc/ada/seh_init.c: In function
'__gnat_SEH_error_handler':
../../gcc-4.6-20110225/gcc/ada/seh_init.c:89:4: error: request for implicit
conversion from 'void *' to 'FARPROC' not permitted in C++ [-Werror=c++-compat]
../../gcc-4.6-20110225/gcc/ada/seh_init.c:192:3: error: enum conversion in
return is invalid in C++ [-Werror=c++-compat]
cc1.exe: all warnings being treated as errors

make[3]: *** [ada/seh_init.o] Error 1
make[3]: Leaving directory `/usr/new-gcc/bin/gcc'
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory `/usr/new-gcc/bin'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/usr/new-gcc/bin'
make: *** [bootstrap] Error 2

can be patched for mingw with:
Index: gcc-4.6-20110225/gcc/ada/seh_init.c
===
--- gcc-4.6-20110225/gcc/ada/seh_init.c(revision 170503)
+++ gcc-4.6-20110225/gcc/ada/seh_init.c(working copy)
@@ -86,7 +86,7 @@
   */
   if ((ExceptionRecord->ExceptionInformation[1] & 3) != 0
   || IsBadCodePtr
-  ((void *)(ExceptionRecord->ExceptionInformation[1] + 4096)))
+  ((FARPROC)(ExceptionRecord->ExceptionInformation[1] + 4096)))
 {
   exception = &program_error;
   msg = "EXCEPTION_ACCESS_VIOLATION";
@@ -189,7 +189,7 @@
 #endif

   Raise_From_Signal_Handler (exception, msg);
-  return 0; /* This is never reached, avoid compiler warning  */
+  return (EXCEPTION_DISPOSITION)0; /* This is never reached, avoid compiler
warning  */
 }

 #if defined (_WIN64)


The seconds error:
/usr/new-gcc/bin/./prev-gcc/xgcc -B/usr/new-gcc/bin/./prev-gcc/
-B/mingw/mingw32/bin/ -L/usr/new-gcc/bin/mingw32/winsup/mingw
-L/usr/new-gcc/bin/mingw32/winsup/w32api/lib -isystem
/usr/new-gcc/gcc-4.6-20110225/winsup/mingw/include -isystem
/usr/new-gcc/gcc-4.6-20110225/winsup/w32api/include -B/mingw/mingw32/bin/
-B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem
/mingw/mingw32/sys-include-c   -g -O2 -D__USE_MINGW_ACCESS
-Wno-pedantic-ms-format -gtoggle -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -

[Bug target/47814] [4.6 Regression] Bootstrap fails on mingw32 by undefined reference to 'lexer_line'

[daniel.f.starke at freenet dot de]

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

--- Comment #2 from Daniel Starke  
2011-02-23 12:31:52 UTC ---
(In reply to comment #1)
> lexer_line as well as the other problematic symbols are defined in
> gengtype-lex.c:
> nm build/gengtype-lex.o  | egrep 'yybegin|yyend|lexer_line'
> 0030 B lexer_line
> 2e38 T yybegin
> 2e9d T yyend
> which is generated from gengtype-lex.l.  Are you sure you don't have buggy or
> not installed flex?

Sorry, it seems that my msys environment was broken for flex which made flex
crash. This did not cause the make process to terminate, hence the failure
occured not until linking. It seems flex wasn't used by gcc 4.5.2 for this
configuration.

[Bug target/47814] New: [4.6 Regression] Bootstrap fails on mingw32 by undefined reference to 'lexer_line'

[daniel.f.starke at freenet dot de]

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

   Summary: [4.6 Regression] Bootstrap fails on mingw32 by
undefined reference to 'lexer_line'
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de


Trying to build gcc 4.6 r170290 configured with
configure --enable-languages="c,c++" --disable-nls --disable-shared
--enable-static --enable-libgcj --enable-libgomp --enable-lto --with-dwarf2
--disable-win32-registry --enable-version-specific-runtime-libs --prefix=/mingw
--program-suffix=-4.6 --build=mingw32 --enable-abi=32 --enable-checking=release

fails on mingw32 with
gcc   -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -DGENERATOR_FILE
-Wl,--stack,12582912 -o build/gengtype.exe \
build/gengtype.o build/errors.o build/gengtype-lex.o
build/gengtype-parse.o build/gengtype-state.o build/version.o
../build-mingw32/libiberty/libiberty.a
build/gengtype.o: In function `create_optional_field_':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:843:
undefined reference to `lexer_line'
build/gengtype.o: In function `adjust_field_rtx_def':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:978:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1032:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1042:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1105:
undefined reference to `lexer_line'
build/gengtype.o:D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype.c:1144:
more undefined references to `lexer_line' follow
build/gengtype-parse.o: In function `token':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:49:
undefined reference to `yylex'
build/gengtype-parse.o: In function `parse_error':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:138:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:138:
undefined reference to `lexer_line'
build/gengtype-parse.o: In function `struct_field_seq':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:688:
undefined reference to `lexer_line'
build/gengtype-parse.o: In function `type':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:722:
undefined reference to `lexer_line'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:754:
undefined reference to `lexer_line'
build/gengtype-parse.o:D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:754:
more undefined references to `lexer_line' follow
build/gengtype-parse.o: In function `parse_file':
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:947:
undefined reference to `yybegin'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:982:
undefined reference to `lexer_toplevel_done'
D:\Programme\msys\new-gcc\bin\gcc/../../gcc-4.6-20110218/gcc/gengtype-parse.c:987:
undefined reference to `yyend'
collect2: ld returned 1 exit status
make[3]: *** [build/gengtype.exe] Error 1
make[3]: Leaving directory `/new-gcc/bin/gcc'
make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory `/new-gcc/bin'
make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory `/new-gcc/bin'
make: *** [bootstrap] Error 2

after running
make bootstrap

Used environment for building:
$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.4.0/configure
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++
--disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp
--with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-runtime-libs --prefix=/mingw
--with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32
Thread model: win32
gcc version 4.4.0 (GCC)

binutils-2.21-2-mingw32
bison-2.4.2-1-msys-1.0.13
flex-2.5.35-2-msys-1.0.13
libiconv-1.13.1-1-mingw32
libintl-0.17-1-mingw32-dll-8
libregex-1.20090805-2-msys-1.0.13
mingwrt-3.18-mingw32
pthreads-w32-2.8.0-mingw32
w32api-3.15-1-mingw32

gcc 4.5.2 builds just fine in this environment.

[Bug c++/47338] [4.5 Regression] cc1plus returns exit code 5

[daniel.f.starke at freenet dot de]

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

--- Comment #7 from Daniel Starke  
2011-01-20 18:51:53 UTC ---
As this patch also works with gcc 4.5.x I'd like to request this change for the
gcc 4.5 branch as well.

[Bug c++/47338] [4.5 Regression] cc1plus returns exit code 5

[daniel.f.starke at freenet dot de]

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

--- Comment #4 from Daniel Starke  
2011-01-18 20:48:34 UTC ---
Here is the debugging output. I can attach the whole back-trace if needed.

GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
...
Reading symbols from
d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe...done.
(gdb) run -fpreprocessed XmlResultReader.ii -quiet -dumpbase XmlResultReader.ii
-mtune=i386 -march=i386 -auxbase-strip XmlResultReader.o -version -o
XmlResultReader.s
Starting program:
d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe
-fpreprocessed XmlResultReader.ii -quiet -dumpbase XmlResultReader.ii
-mtune=i386 -march=i386 -auxbase-strip XmlResultReader.o -version -o
XmlResultReader.s
[New Thread 4016.0x9f4]
GNU C++ (GCC) version 4.5.2 (mingw32)
compiled by GNU C version 4.4.0, GMP version 5.0.1, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.5.2 (mingw32)
compiled by GNU C version 4.4.0, GMP version 5.0.1, MPFR version 3.0.0,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 2ec00196c1446cde6554d87cd326f0cd
XmlResultReader.ii: In function 'std::_Resetiosflags
std::resetiosflags(std::ios_base::fmtflags)':
XmlResultReader.ii:70520:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setiosflags
std::setiosflags(std::ios_base::fmtflags)':
XmlResultReader.ii:70542:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setbase std::setbase(int)':
XmlResultReader.ii:70564:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setfill<_CharT> std::setfill(_CharT)':
XmlResultReader.ii:70594:7: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setprecision std::setprecision(int)':
XmlResultReader.ii:70616:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x
XmlResultReader.ii: In function 'std::_Setw std::setw(int)':
XmlResultReader.ii:70638:5: warning: extended initializer lists only available
with -std=c++0x or -std=gnu++0x

Program received signal SIGSEGV, Segmentation fault.
0x006266d5 in ggc_set_mark (p=0x1d9fae40) at
../../gcc-4.5.2/gcc/ggc-page.c:1330
1330{
(gdb) #0  0x006266d5 in ggc_set_mark (p=0x1d9fae40) at
../../gcc-4.5.2/gcc/ggc-page.c:1330
#1  0x00495798 in gt_ggc_mx_lang_tree_node (x_p=0x1d9fae40) at
./gt-cp-tree.h:146
#2  0x004963d8 in gt_ggc_mx_lang_tree_node (x_p=0x1d9fc800) at
./gt-cp-tree.h:440

[[[roughly 10 mega bytes of back-trace left out]]]

#136740 0x004961d0 in gt_ggc_mx_lang_tree_node (x_p=0x37f2ba0) at
./gt-cp-tree.h:397
#136741 0x00496668 in gt_ggc_mx_lang_tree_node (x_p=0x3872600) at
./gt-cp-tree.h:373
#136742 0x005e9102 in gt_ggc_mx_cgraph_node (x_p=0x1a129170) at
gtype-desc.c:393
#136743 0x005e929f in gt_ggc_m_P11cgraph_node4htab (x_p=0x56032c0) at
gtype-desc.c:2396
#136744 0x00654f05 in ggc_mark_roots () at ../../gcc-4.5.2/gcc/ggc-common.c:167
#136745 0x00626ed6 in ggc_collect () at ../../gcc-4.5.2/gcc/ggc-page.c:1962
#136746 0x005d34ad in execute_todo (flags=3) at
../../gcc-4.5.2/gcc/passes.c:1309
#136747 0x005d3aba in execute_one_pass (pass=0xb68fa0) at
../../gcc-4.5.2/gcc/passes.c:1591
#136748 0x005d3ca1 in execute_pass_list (pass=0xb68fa0) at
../../gcc-4.5.2/gcc/passes.c:1623
#136749 0x007503ba in tree_rest_of_compilation (fndecl=0x1f9c7f00) at
../../gcc-4.5.2/gcc/tree-optimize.c:413
#136750 0x005d5dd0 in cgraph_expand_function (node=) at
../../gcc-4.5.2/gcc/cgraphunit.c:1574
#136751 0x005d8b3b in cgraph_output_in_order () at
../../gcc-4.5.2/gcc/cgraphunit.c:1747
#136752 cgraph_optimize () at ../../gcc-4.5.2/gcc/cgraphunit.c:1904
#136753 0x005d8d07 in cgraph_finalize_compilation_unit () at
../../gcc-4.5.2/gcc/cgraphunit.c:1122
#136754 0x0044f4a5 in cp_write_global_declarations () at
../../gcc-4.5.2/gcc/cp/decl2.c:3833
#136755 0x006050dd in compile_file (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/toplev.c:1065
#136756 do_compile (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/toplev.c:2417
#136757 toplev_main (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/toplev.c:2459
#136758 0x004e612c in main (argc=13, argv=0x38e2b20) at
../../gcc-4.5.2/gcc/main.c:35

[Bug c++/47338] [4.5 Regression] cc1plus returns exist code 5

[daniel.f.starke at freenet dot de]

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

--- Comment #2 from daniel.f.starke at freenet dot de 2011-01-18 17:30:54 UTC 
---
What do you mean by debug? I can't even compile it because cc1plus exists half
the way.

[Bug c++/47338] New: [4.5 Regression][C++] cc1plus returns exist code 5

[daniel.f.starke at freenet dot de]

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

   Summary: [4.5 Regression][C++] cc1plus returns exist code 5
   Product: gcc
   Version: 4.5.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.f.sta...@freenet.de
  Host: mingw32
Target: mingw32
 Build: mingw32


Created attachment 23015
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23015
preprocessed test file .ii

When compiling the attatched code cc1plus returns exit code 5. No warning or
error message is shown. It compiles fine with the same host/target/build and
gcc 4.4.0.

Command:
$ g++ -pass-exit-codes -o XmlResultReader.o -c XmlResultReader.cpp -v
-save-temps || echo "error: $?"
Using built-in specs.
COLLECT_GCC=D:\Programme\msys\mingw\bin\g++.exe
COLLECT_LTO_WRAPPER=d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --disable-bootstrap
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-nls
--disable-shared --enable-static --enable-libgcj --enable-libgomp --enable-lto
--with-dwarf2 --disable-win32-registry --enable-version-specific-runtime-libs
--prefix=/mingw --build=mingw32 --enable-abi=32
Thread model: win32
gcc version 4.5.2 (GCC) 
COLLECT_GCC_OPTIONS='-o' 'XmlResultReader.o' '-c' '-v' '-save-temps'
'-mtune=i386' '-march=i386'
 d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe -E -quiet
-v -iprefix d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/
XmlResultReader.cpp -mtune=i386 -march=i386 -fpch-preprocess -o
XmlResultReader.ii
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include/c++"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include/c++/mingw32"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include/c++/backward"
ignoring nonexistent directory "/mingw/include"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include"
ignoring duplicate directory
"d:/programme/msys/mingw/lib/gcc/../../lib/gcc/mingw32/4.5.2/include-fixed"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/mingw32
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include/c++/backward
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include
 d:\programme\msys\mingw\bin\../lib/gcc/mingw32/4.5.2/include-fixed
 D:/Programme/msys/mingw/include
 d:/programme/msys/mingw/lib/gcc/../../mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-o' 'XmlResultReader.o' '-c' '-v' '-save-temps'
'-mtune=i386' '-march=i386'
 d:/programme/msys/mingw/bin/../libexec/gcc/mingw32/4.5.2/cc1plus.exe
-fpreprocessed XmlResultReader.ii -quiet -dumpbase XmlResultReader.cpp
-mtune=i386 -march=i386 -auxbase-strip XmlResultReader.o -version -o
XmlResultReader.s
error: 5