[Bug debug/52160] gdb ignores line "bar: if(foo)goto bar;"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52160 Hannes Domani changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #5 from Hannes Domani --- I can reproduce this issue with gcc-4.6.1, but not with gcc-4.9.1 or newer, so I think this has been fixed already.
[Bug demangler/86152] Failure to demange clone names with digits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86152 Hannes Domani changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #1 from Hannes Domani --- Looks like this was fixed by this commit: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=be674bdd11d5fa6b20d469e6d6f43c26da9e744f
[Bug target/100402] [10.3 regression] crash with setjmp/longjmp and SEH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #11 from Hannes Domani --- > Your testcase does not compile with the C compiler: > > Compiling it with the C++ compiler works for me: Sorry about the c/c++ confusion. > Created attachment 50754 [details] > Tentative fix > > Please give it a try if you can rebuild the compiler. Yes, I can confirm that this fixes the crash with my attached test, and also the original non-reduced application (which is gdb).
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #3 from Hannes Domani --- Created attachment 50745 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50745=edit output of -fdump-tree-optimized
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #2 from Hannes Domani --- Created attachment 50744 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50744=edit assembly (-S)
[Bug target/100402] Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402 --- Comment #1 from Hannes Domani --- Created attachment 50743 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50743=edit preprocessed code (-E)
[Bug target/100402] New: Crash in longjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100402
Bug ID: 100402
Summary: Crash in longjmp
Product: gcc
Version: 10.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ssbssa at yahoo dot de
Target Milestone: ---
The following example:
-- >8 --
// gcc -O1 test.c
#include
static jmp_buf buf;
static bool stop = false;
void call_func(void(*func)(void))
{
func();
}
void func()
{
stop = true;
longjmp(buf, 1);
}
int main()
{
setjmp(buf);
while (!stop)
call_func(func);
return 0;
}
-- >8 --
Crashes deep in longjmp():
Starting program: C:\src\tests\a.exe
gdb: unknown target exception 0xc028 at 0x779dd7e8
Program received signal ?, Unknown signal.
0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
(gdb) bt
#0 0x779dd7e8 in ntdll!RtlRaiseStatus () from
C:\Windows\SYSTEM32\ntdll.dll
#1 0x7797f4ec in ntdll!RtlIsDosDeviceName_U () from
C:\Windows\SYSTEM32\ntdll.dll
#2 0x07fefe11e5a3 in msvcrt!longjmp () from C:\Windows\system32\msvcrt.dll
#3 0x00013fe61620 in func ()
#4 0x00013fe61627 in call_func ()
#5 0x00013fe61664 in main ()
#6 0x00013fe61431 in __tmainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:345
#7 0x00013fe615b6 in mainCRTStartup () at
C:/gcc/src/mingw-w64-v8.0.0/mingw-w64-crt/crt/crtexe.c:220
Note: Doesn't crash with -O0, or if I change `while (!stop)` to `if (!stop)`.
And it also works fine with gcc-10.2, or if I revert both fixes [1] [2] of
PR99234.
[1]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=49a714e59194a7c549aa6657676a1b4be4520650
[2]
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=2939b358936bb824330888def98ad848dea41483
[Bug debug/100383] New: cfi sections directive detection fails with binutils 2.36
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100383 Bug ID: 100383 Summary: cfi sections directive detection fails with binutils 2.36 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ssbssa at yahoo dot de Target Milestone: --- Since binutils 2.36 [1], the objdump output [2] of the cfi sections directive detection command (objdump -j .debug_frame -r conftest.o) changed from: conftest.o: file format pe-x86-64 RELOCATION RECORDS FOR [.debug_frame]: OFFSET TYPE VALUE 001c secrel32 .debug_frame 0020 R_X86_64_64 .text to: conftest.o: file format pe-x86-64 RELOCATION RECORDS FOR [.debug_frame]: OFFSET TYPE VALUE 001c IMAGE_REL_AMD64_SECREL .debug_frame 0020 IMAGE_REL_AMD64_ADDR64 .text So because it's now uppercase SECREL, the `grep secrel` fails. I haven't finished my build yet, but it should work like this: --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -3115,7 +3115,7 @@ gcc_GAS_CHECK_FEATURE([cfi sections directive], gcc_cv_as_cfi_sections_directive=no if test "x$gcc_cv_objdump" != x; then if $gcc_cv_objdump -j .debug_frame -r conftest.o 2>/dev/null | \ - grep secrel > /dev/null; then + grep -i secrel > /dev/null; then gcc_cv_as_cfi_sections_directive=yes fi fi [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ec6653d824fef41298fdb384ba74bcbc7be0dc22 [2] https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=84dceb8074ab4615316e09f1f339ed93eca6d6e9;hb=refs/heads/releases/gcc-10#l3117
[Bug bootstrap/98860] [11 Regression] boostrap failure on MinGW-w64 windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860 --- Comment #36 from Hannes Domani --- Note: This is a binutils/ld bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27268 And I've sent a patch there: https://sourceware.org/pipermail/binutils/2021-February/115434.html
[Bug c/89807] Incorrect -Wconversion warning when shifting uint32_t with 24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89807
--- Comment #1 from Hannes Domani ---
(In reply to Nickolay Kolchin-Semyonov from comment #0)
> uint8_t a = (v >> 24) & 0xFF; // ERROR: produces warning
> uint8_t a2 = v >> 24; // ERROR: produces warning
I think the '& 0xFF' part is optimized away, so for the warning, this is
basically the same code.
In unsafe_conversion_p() is an extra check if the result of a bitwise-and
operation fits in the target type, and that's the reason the other lines don't
get a warning.
The following adds a similar check for the result of a right-shift operation:
--- gcc/c-family/c-common.c 2020-07-23 08:35:17.296384000 +0200
+++ gcc/c-family/c-common.c 2021-02-14 00:53:07.130219200 +0100
@@ -1488,6 +1488,26 @@
return SAFE_CONVERSION;
}
}
+ else if (TREE_CODE (expr) == RSHIFT_EXPR)
+ {
+ tree op0 = TREE_OPERAND (expr, 0);
+ tree op1 = TREE_OPERAND (expr, 1);
+
+ /* Don't warn if the result of an unsigned value, right shifted
+by a constant, fits in the target type. */
+ if (TYPE_UNSIGNED (TREE_TYPE (op0))
+ && TREE_CODE (op1) == INTEGER_CST)
+ {
+ int prec_rshift = TYPE_PRECISION (TREE_TYPE (op0))
+ - TREE_INT_CST_LOW (op1);
+ int prec_res = TYPE_PRECISION (type);
+ if (!TYPE_UNSIGNED (type))
+ prec_res--;
+
+ if (prec_rshift <= prec_res)
+ return SAFE_CONVERSION;
+ }
+ }
/* Warn for integer types converted to smaller integer types. */
if (TYPE_PRECISION (type) < TYPE_PRECISION (expr_type))
give_warning = UNSAFE_OTHER;
PS: This is possibly a dup of PR83122.
[Bug c++/90526] Missing DW_AT_const_value for constexpr field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90526
Hannes Domani changed:
What|Removed |Added
CC||ssbssa at yahoo dot de
--- Comment #1 from Hannes Domani ---
The DW_AT_const_value is also emitted if the variable is used, like:
int main()
{
foo p;
return !p.is_always_lock_free;
}
[Bug debug/94459] Missing c++ debug information for 'auto&' return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94459 --- Comment #5 from Hannes Domani --- I also should mention that this is a precursor to fix gdb_bug 24154: https://sourceware.org/bugzilla/show_bug.cgi?id=24154
[Bug debug/94459] Missing c++ debug information for 'auto&' return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94459
--- Comment #3 from Domani Hannes ---
(In reply to Jakub Jelinek from comment #1)
> Looking through DW_TAG_const_type seems insufficient to me, can't there be
> other qualifications (at least DW_TAG_volatile_type, perhaps in various
> orders)?
> So wouldn't be better a loop as long as die and die->die_tag is one of
> dwarf_qual_info[?].t or DW_TAG_{rvalue_}reference, use die = get_AT_ref
> (die, DW_AT_type); ?
As suggested, I'm now using this:
--- gcc/dwarf2out.c 2020-03-12 12:07:21.0 +0100
+++ gcc/dwarf2out.c 2020-04-02 20:10:05.829023900 +0200
@@ -23016,6 +23016,11 @@
if (is_cxx () && debug_info_level > DINFO_LEVEL_TERSE)
{
dw_die_ref die = get_AT_ref (old_die, DW_AT_type);
+ while (die->die_tag == DW_TAG_reference_type
+|| die->die_tag == DW_TAG_rvalue_reference_type
+|| die->die_tag == DW_TAG_const_type
+|| die->die_tag == DW_TAG_volatile_type)
+ die = get_AT_ref (die, DW_AT_type);
if (die == auto_die || die == decltype_auto_die)
add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
TYPE_UNQUALIFIED, false, context_die);
I don't think that restrict/atomic is possible for auto return types, but I may
be wrong about that.
[Bug debug/94459] Missing c++ debug information for 'auto&' return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94459
--- Comment #2 from Domani Hannes ---
(In reply to Jakub Jelinek from comment #1)
> Looking through DW_TAG_const_type seems insufficient to me, can't there be
> other qualifications (at least DW_TAG_volatile_type, perhaps in various
> orders)?
> So wouldn't be better a loop as long as die and die->die_tag is one of
> dwarf_qual_info[?].t or DW_TAG_{rvalue_}reference, use die = get_AT_ref
> (die, DW_AT_type); ?
You're probably right, I wasn't sure if the use of 'auto' allows e.g.
'volatile' as well, so I just stuck with the ones I knew about.
[Bug debug/94459] New: Missing c++ debug information for 'auto&' return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94459
Bug ID: 94459
Summary: Missing c++ debug information for 'auto&' return type
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: ssbssa at yahoo dot de
Target Milestone: ---
For the following example:
template
struct MyClass
{
T value;
auto get()
{
return value;
}
auto _ref()
{
return value;
}
auto &_r_ref()
{
return (T&&)value;
}
const auto c_get()
{
return value;
}
const auto _get_ref()
{
return value;
}
const auto &_get_r_ref()
{
return (T&&)value;
}
};
int main()
{
MyClass mc{1};
return (mc.get() + mc.get_ref() + mc.get_r_ref()
+ mc.c_get() + mc.c_get_ref() + mc.c_get_r_ref());
}
For the simple 'auto' case, the debugger knows the real return type:
(gdb) pt MyClass::get
type = int (MyClass * const)
But not for the others:
(gdb) pt MyClass::get_ref
type = void &(MyClass * const)
(gdb) pt MyClass::get_r_ref
type = void &&(MyClass * const)
(gdb) pt MyClass::c_get
type = void (MyClass * const)
(gdb) pt MyClass::c_get_ref
type = void &(MyClass * const)
(gdb) pt MyClass::c_get_r_ref
type = void &&(MyClass * const)
For 'auto', extra type information is stored on the definition die, this was
implemented here:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=2e5e7103a39315664f9a625bea42981f5251c27e
So I came up with the following patch:
--- gcc/dwarf2out.c 2020-03-12 12:07:21.0 +0100
+++ gcc/dwarf2out.c 2020-04-02 14:54:03.680451100 +0200
@@ -23016,6 +23016,11 @@
if (is_cxx () && debug_info_level > DINFO_LEVEL_TERSE)
{
dw_die_ref die = get_AT_ref (old_die, DW_AT_type);
+ if (die->die_tag == DW_TAG_reference_type
+ || die->die_tag == DW_TAG_rvalue_reference_type)
+ die = get_AT_ref (die, DW_AT_type);
+ if (die->die_tag == DW_TAG_const_type)
+ die = get_AT_ref (die, DW_AT_type);
if (die == auto_die || die == decltype_auto_die)
add_type_attribute (subr_die, TREE_TYPE (TREE_TYPE (decl)),
TYPE_UNQUALIFIED, false, context_die);
This seems to work fine:
(gdb) pt MyClass::get
type = int (MyClass * const)
(gdb) pt MyClass::get_ref
type = int &(MyClass * const)
(gdb) pt MyClass::get_r_ref
type = int &&(MyClass * const)
(gdb) pt MyClass::c_get
type = const int (MyClass * const)
(gdb) pt MyClass::c_get_ref
type = const int &(MyClass * const)
(gdb) pt MyClass::c_get_r_ref
type = const int &&(MyClass * const)
But I can't run the testsuite (I'm on Windows), so I can't be sure that this
would break anything else.
[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292 --- Comment #4 from Domani Hannes --- (In reply to jos...@codesourcery.com from comment #3) > On Tue, 31 Dec 2019, ssbssa at yahoo dot de wrote: > > > But does it make sense to do a format check multiple times for one function? > > Yes. You could have a function with one format string for the message > printed to the terminal and another for the message printed (with the same > arguments) to a logfile, for example. Or multiple format strings from > which the function chooses one to use based on some condition. Interesting, I would never have thought of this possibility. Is there also a scenario where it would make sense to have multiple format attributes for the same format string?
[Bug c/92292] duplicate -Wformat warnings about incorrect printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92292 Domani Hannes changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #2 from Domani Hannes --- (In reply to jos...@codesourcery.com from comment #1) > This would be an interaction between the built-in function having a printf > format attribute and the header having either a gnu_printf or an ms_printf > format attribute (depending on feature test macros); as those attributes > aren't exact duplicates, both are applied (it's perfectly valid for a > function to have multiple format attributes, but I suppose we should > special-case this for format attributes for built-in functions with a more > specific format attribute in the header declaration). But does it make sense to do a format check multiple times for one function? If it's the same format attribute twice, you get duplicate warnings. And if the format attributes are different, then I suspect that one of them has to be wrong.
[Bug debug/86593] [8 Regression] internal compiler error: in based_loc_descr, at dwarf2out.c:14272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86593 Domani Hannes changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #16 from Domani Hannes --- Is there a reason why this wasn't backported to the gcc-8-branch?
[Bug lto/88925] address of static string changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88925 --- Comment #2 from Domani Hannes --- (In reply to Richard Biener from comment #1) > It works for me on x86_64-linux. Note to get the desired behavior GCC > relies on > string-merging performed by the linker. > > Can you elaborate on the host/target you compile for? It's for x86_64-w64-mingw32. I thought string-merging is only for the case when the same string literal is used in multiple locations. But here "Derived1" is only used once for typeDerived1, which Derived1::getType() then returns. So I never would have thought that Derived1::getType() could be different to typeDerived1, which it is. Am I depending on undefined behavior? If yes, why?
[Bug lto/88925] New: address of static string changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88925 Bug ID: 88925 Summary: address of static string changes Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ssbssa at yahoo dot de CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 45468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45468=edit test case With the attached file, I get an unexpected result with these arguments: $ g++ -ovirtual virtual.cpp -flto -flto-partition=max -O3 $ ./virtual This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. This is a heavily reduced test case of another program of mine, but I didn't need -flto-partition=max there to get this problem (I think because it's a lot bigger). So the problem is with the static strings typeDerived1 and typeDerived2. I would expect the pointers of Derived1::getType() and Derived2::getType() to always match either typeDerived1 or typeDerived2.
[Bug lto/82027] [7/8 Regression] wrong code with -O3 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82027
--- Comment #11 from Domani Hannes ---
(In reply to Martin Jambor from comment #10)
> OK, so I did not realize that duplicate_thunk_for_node does not set
> clone_of but former_clone of, which is of course what it must do. I
> have checked and this is the only place where we currently set
> former_clone_of in WPA, and therefore I am testing the following fix:
>
> diff --git a/gcc/lto-cgraph.c b/gcc/lto-cgraph.c
> index a19f8a13dfb..ed3df15b143 100644
> --- a/gcc/lto-cgraph.c
> +++ b/gcc/lto-cgraph.c
> @@ -1958,7 +1958,7 @@ input_offload_tables (bool do_force_output)
> static int
> output_cgraph_opt_summary_p (struct cgraph_node *node)
> {
> - return (node->clone_of
> + return ((node->clone_of || node->former_clone_of)
> && (node->clone.tree_map
> || node->clone.args_to_skip
> || node->clone.combined_args_to_skip));
I can confirm that this fixes the crash in my original (non-reduced)
application.
[Bug ipa/82027] [5/6/7/8 Regression] wrong code with -O3 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82027
--- Comment #4 from Domani Hannes ---
(In reply to Martin Liška from comment #3)
> Note that original function does:
>
> void calcPercent( const char *name,int pos,int size )
> {
> int percent = 100*pos/size;
> if( percent!=m_percent )
> m_percent = percent;
> }
>
> So arguments are shifted by one. Martin can you please take a look?
In div0.exe.ltrans0.000i.cgraph it looks like this:
calcPercent.constprop (struct Combined * const this, int pos, int size)
Could this have anything to do with the argument shift?
[Bug lto/82027] New: wrong code with -O3 -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82027 Bug ID: 82027 Summary: wrong code with -O3 -flto Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ssbssa at yahoo dot de CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 42082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42082=edit test case With the attached file I get a division by 0 when using "-O3 -flto", but not with "-O2 -flto" or just "-O3". Fails with 7.1.0 and 7.2.0, but not with 6.3.0. $ g++ -O3 -flto -g -odiv0 div0.cpp $ gdb -q div0 Reading symbols from div0...done. (gdb) r Starting program: C:\qiewer\div0.exe [New Thread 1768.0x4e0] Program received signal SIGFPE, Arithmetic exception. 0x0040f8f3 in calcPercent (name=0x411000 "", size=0, pos=4263936, this=0x3b1f60) at div0.cpp:49 49int percent = 100*pos/size; (gdb) bt #0 0x0040f8f3 in calcPercent (name=0x411000 "", size=0, pos=4263936, this=0x3b1f60) at div0.cpp:49 #1 Looper::loop() () at div0.cpp:23 #2 main (argc=, argv=) at div0.cpp:64 (gdb) kill Kill the program being debugged? (y or n) [answered Y; input not from terminal] (gdb) quit
[Bug driver/78787] O Color, Where Art Thou? (with -flto)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78787 Domani Hannes changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #2 from Domani Hannes --- Isn't the sub-command output redirected into a file? Thus the terminal detection via isatty() in diagnostic-color.c doesn't work.
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 --- Comment #11 from Domani Hannes --- I can confirm that this patch works for windows as well.
[Bug lto/70955] [6/7 Regression] Wrong code generation for __builtin_ms_va_list with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70955 Domani Hannes changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #9 from Domani Hannes --- I've the same behavior on windows as well, even if I remove the ms_abi attribute (probably because it's always ms_abi anyway?).
[Bug tree-optimization/59124] [4.9/5/6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124
--- Comment #37 from Domani Hannes ---
With the new patch there is still a warning with this example:
=== 8< ===
int f(void);
int test(void)
{
int baz[4];
int q = 0;
int d, i, j, sum;
for (i = 0; i < 2; i++)
{
d = f();
if (d == 3)
{
baz[q] = d;
q++;
if (q == 4) break;
}
}
sum = 0;
for (i = 0; i < q; i++)
{
for (j = i + 1; j < q; j++)
{
sum += baz[j];
}
}
return (sum);
}
=== >8 ===
$ gcc -O3 -Wall -S q.c
q.c: In function 'test':
q.c:27:17: warning: array subscript is above array bounds [-Warray-bounds]
sum += baz[j];
^
[Bug lto/58042] MinGW GCC produces problematic x64 executable with -O2 -static -flto -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58042 Domani Hannes ssbssa at yahoo dot de changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #1 from Domani Hannes ssbssa at yahoo dot de --- I can reproduce this with 4.8.3, but not with 4.9.0 or 4.9.1.
[Bug libquadmath/60349] Any call to expq (or libquadmath function that might possibly call expq) segfaults in mingw-gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60349 Domani Hannes ssbssa at yahoo dot de changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #2 from Domani Hannes ssbssa at yahoo dot de --- This seems to be a bug in mingw-w64. See here: http://sourceforge.net/p/mingw-w64/bugs/368/
