mingw-notify Mailing List for MinGW - Minimalist GNU for Windows (Page 2)

Bugs item #918223, was opened at 2004-03-17 11:04
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=918223&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: binutils
>Group: Aged issue
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Mike Nordell (tamlin)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Odd COFF relocation record

Initial Comment:
MinGW GCC 3.3.1 on Win32.

First let me say I'm no expert in this area, why there 
might be an obvious reason I just failed to see - but I 
sincerely don't think so.

I think this is a problem with binutils as.

Compiling a C file containing lots of inline assembler, I 
had to use -ffunction-sections to be able to know how 
large the generated code for a specific function was 
(parsing the generated object file), and it turned up a 
lot of "interesting stuff". As I used MSVC6 as a "baseline" 
for Win32 COFF/PE object files, many things surprised 
me.

The possibly most surprising was however a relocation 
record pointing not to the symbol referenced by the 
function, but to the (I'd guess) pseudo-symbol ".data", 
with just the offset of the "real" symbol within 
the ".data" section.

To actually get to the symbol I had to iterate all 
symbols, to find a symbol in that section matching the 
offset into it [the section] given by the relocation.

Wouldn't it be more logical to have the tool always emit 
a relocation record pointing to the actual symbol, 
instead of just _most_ of the time do this, but 
sometimes (for whatever reason I do not know)  do 
what I outlined?


----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-11 09:24

Message:
If this is still an issue please take it up on the GCC and binutils bugs
frameworks.

----------------------------------------------------------------------

Comment By: Mike Nordell (tamlin)
Date: 2004-03-19 08:45

Message:
Logged In: YES 
user_id=7243

Small sample to display behaviour:
struct S { int m1; };
struct S s[] = { {1}, {0} };
void bar() { s[1].m1 = 0; }

This, even when compiled with plain "gcc -c", emits a single 
OFF reloc record, but instead of referring to the symbol "s" 
and an offset from this symbol, it refers to the pseudo-
symbol ".data", and the offset of "s[1].m1" in the data section.

As a had a specific need to look up what symbol a relocation 
referred to, this behaviour created a bit of a headache.

For reference, I have also tested it with what I define 
a "baseline" Win32 compiler, and that compiler emitted what 
expected: a reloc that referred to the symbol "_s" (incl. name 
mangling) and the offset from this symbol.


----------------------------------------------------------------------

Comment By: Danny Smith (dannysmith)
Date: 2004-03-17 12:35

Message:
Logged In: YES 
user_id=11494

Sorry, I don't know what you mean without an example.

Danny

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=918223&group_id=2435

Bugs item #3591569, was opened at 2012-11-30 19:43
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3591569&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Unreproducible
>Status: Closed
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: SquallATF (squallatf)
Assigned to: Cesar Strauss (cstrauss)
Summary: msys can't malloc memory biger than 268169196

Initial Comment:
here is the test code

#include <stdio.h>
#include <stdlib.h>

int main()
{
  void *okmem = malloc(1024*1024*256 - 1024*260 -20); //ok size 268169196
  if(okmem) {
      printf("malloc ok\n");
  }
  void *failedmem = malloc(1024*1024*256 - 1024*260 -19); //failed size 268169197
  if(!okmem) {
      printf("malloc failed\n");
  }
  return 0;
}


----------------------------------------------------------------------

Comment By: Cesar Strauss (cstrauss)
Date: 2013-01-08 17:39

Message:
I can't reproduce it.

$ gcc -o bug.exe bug3591569.c

$ ./bug.exe
malloc ok

OS: Windows 7 Home Premium N (64-bit)
MSYS runtime: 1.0.18
gcc version 3.4.4 (msys special)



----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:02

Message:
Ping, Cesar, any comment on this issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-12-02 11:08

Message:
Okay, then I'll leave it to Cesar to figure out a fix.

----------------------------------------------------------------------

Comment By: SquallATF (squallatf)
Date: 2012-12-01 19:20

Message:
I'm sorry because too much time and I remember correctly.
The right is i use msys gcc complie subversion. I get this error

cc1.exe: out of memory allocation 172600 bytes after a total of 268120064
bytes

So I debug the msysCore then found in source\winsup\cygwin\heap.cc at line
120

  commitbytes = pround (newtop - (char *) cygheap->heaptop);
  if (VirtualAlloc(cygheap->heaptop, commitbytes, MEM_COMMIT,
PAGE_READWRITE) != NULL)
    goto good;

the VirtualAlloc failed.
If too large source code to compile will appear this error


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-12-01 08:33

Message:
@squallatf: This has nothing to do with linking large programs.  Please use
the min...@li... list to discuss your issue and not
this ticket.

----------------------------------------------------------------------

Comment By: SquallATF (squallatf)
Date: 2012-11-30 19:46

Message:
so that when mingw link large program may failed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3591569&group_id=2435

Bugs item #3591569, was opened at 2012-11-30 19:43
Message generated for change (Comment added) made by cstrauss
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3591569&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: SquallATF (squallatf)
Assigned to: Cesar Strauss (cstrauss)
Summary: msys can't malloc memory biger than 268169196

Initial Comment:
here is the test code

#include <stdio.h>
#include <stdlib.h>

int main()
{
  void *okmem = malloc(1024*1024*256 - 1024*260 -20); //ok size 268169196
  if(okmem) {
      printf("malloc ok\n");
  }
  void *failedmem = malloc(1024*1024*256 - 1024*260 -19); //failed size 268169197
  if(!okmem) {
      printf("malloc failed\n");
  }
  return 0;
}


----------------------------------------------------------------------

>Comment By: Cesar Strauss (cstrauss)
Date: 2013-01-08 17:39

Message:
I can't reproduce it.

$ gcc -o bug.exe bug3591569.c

$ ./bug.exe
malloc ok

OS: Windows 7 Home Premium N (64-bit)
MSYS runtime: 1.0.18
gcc version 3.4.4 (msys special)



----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:02

Message:
Ping, Cesar, any comment on this issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-12-02 11:08

Message:
Okay, then I'll leave it to Cesar to figure out a fix.

----------------------------------------------------------------------

Comment By: SquallATF (squallatf)
Date: 2012-12-01 19:20

Message:
I'm sorry because too much time and I remember correctly.
The right is i use msys gcc complie subversion. I get this error

cc1.exe: out of memory allocation 172600 bytes after a total of 268120064
bytes

So I debug the msysCore then found in source\winsup\cygwin\heap.cc at line
120

  commitbytes = pround (newtop - (char *) cygheap->heaptop);
  if (VirtualAlloc(cygheap->heaptop, commitbytes, MEM_COMMIT,
PAGE_READWRITE) != NULL)
    goto good;

the VirtualAlloc failed.
If too large source code to compile will appear this error


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-12-01 08:33

Message:
@squallatf: This has nothing to do with linking large programs.  Please use
the min...@li... list to discuss your issue and not
this ticket.

----------------------------------------------------------------------

Comment By: SquallATF (squallatf)
Date: 2012-11-30 19:46

Message:
so that when mingw link large program may failed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3591569&group_id=2435

Bugs item #3594484, was opened at 2012-12-10 06:17
Message generated for change (Comment added) made by oleh_derevenko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: Remind
Priority: 5
Private: No
Submitted By: Oleh Derevenko (oleh_derevenko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect argument clearance in one of method instances

Initial Comment:

After upgrading to GCC 4.7.2 I'having an issue that release build of my DLL crashes. Debugging shows that this is due to bad code generated by GCC, Alas I can't provide small test case but here is the faulting function fragment itself.
 -----------------------
 int CProfileGenerator::CalcAccProfile(
 pos_type p0,
 vel_type v0,
 acc_type a0,
 jerk_type j,
 vel_type vel,
 acc_type acc,
 CProfile& ret_profile
 ) const {
 time_type t0 = 0.0;
 ret_profile.clear(); ret_profile.reserve(10);
 
vel_type dv = vel-v0;
 
if (ABS(dv) < m_epsilon_v && ABS(a0) < m_epsilon_a) {
 if (dv == 0.0) {
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 } else {
 acc_type a0 = (dv<0.0)?-1.0:1.0;
 time_type dt = ABS(dv);
 pos_type p1 = p0 + v0*dt + 0.5*dv*dv;
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 ret_profile.push_back(CProfileStep(dt, p1, vel, 0.0, 0.0)); VALIDATEPROFILE(ret_profile);
 }
 G_BLOG_4("acc profile calc skiped ");
 return ret_profile.size();
 }
 if (v0 < vel) {
 acc = ABS(acc);
 } else if (v0 == vel) {
 acc = -SIGN(a0)*ABS(acc);
 } else {
 acc = -ABS(acc);
 }
 
if (j == 0.0) {
 return InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile);
 // <------------------------------ FAULTS DUE TO RETURNING TO ADDRESS 0x00000000 HERE
 }
 ...
 -----------------------
 Here all the *_type typedefs are doubles and CProfile is std::vector of CProfileStep structure.
 
I've built library with -fno-inline to be able to see function calls more clearly and here is the problem is assembler code.
 -----------------------
 Dump of assembler code for function CProfileGenerator::CalcAccProfile(double, double, double, double, double, double, CP
 rofileGenerator::CProfile&) const:
 0x100622e0 <+0>: push %ebp
 0x100622e1 <+1>: mov %ecx,%ebp
 0x100622e3 <+3>: push %edi
 0x100622e4 <+4>: push %esi
 0x100622e5 <+5>: push %ebx
 0x100622e6 <+6>: sub $0x14c,%esp
 ; <------------------------ Initial stack preparation ends here
 0x100622ec <+12>: mov 0x160(%esp),%eax
 0x100622f3 <+19>: mov 0x190(%esp),%ebx
 0x100622fa <+26>: fldl 0x188(%esp)
 0x10062301 <+33>: fstpl 0x98(%esp)
 ...
 ...
 ...
 0x1006254a <+618>: jbe 0x10062920 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+1600>
 0x10062550 <+624>: fldl 0x98(%esp)
 0x10062557 <+631>: fstpl (%esp)
 0x1006255a <+634>: call 0x1005f2e0 <ABS<double>(double const&)>
 0x1006255f <+639>: fldl 0xb0(%esp)
 0x10062566 <+646>: fldz
 0x10062568 <+648>: fld %st(0)
 0x1006256a <+650>: fxch %st(2)
 0x1006256c <+652>: fucomi %st(2),%st
 0x1006256e <+654>: fstp %st(2)
 0x10062570 <+656>: jnp 0x10062b00 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+2080>
 ...
 ...
 ...
 0x10062b00 <+2080>: jne 0x10062580 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+672>
 0x10062b06 <+2086>: fstp %st(1)
 0x10062b08 <+2088>: fxch %st(1)
 0x10062b0a <+2090>: fstpl 0x30(%esp)
 0x10062b0e <+2094>: mov %ebx,%ecx
 0x10062b10 <+2096>: fldl 0x90(%esp)
 0x10062b17 <+2103>: mov $0x1,%edx
 0x10062b1c <+2108>: mov $0x1,%eax
 0x10062b21 <+2113>: fstpl 0x28(%esp)
 0x10062b25 <+2117>: fstl 0x20(%esp)
 0x10062b29 <+2121>: fstl 0x18(%esp)
 0x10062b2d <+2125>: fldl 0x88(%esp)
 0x10062b34 <+2132>: fstpl 0x10(%esp)
 0x10062b38 <+2136>: fldl 0xc8(%esp)
 0x10062b3f <+2143>: fstpl 0x8(%esp)
 0x10062b43 <+2147>: fstpl (%esp)
 0x10062b46 <+2150>: call 0x10061890 <CProfileGenerator::InternalAccCalc(double, double, double, double, double, bo
 ol, bool, double, double, bool, CProfileGenerator::CProfile&) const>
 
0x10062b4b <+2155>: sub $0x38,%esp <----------------------------------------- THIS COMMAND CORRUPTS STACK POINTER WHICH OTHERWISE WOULD BE VALID
 
0x10062b4e <+2158>: add $0x14c,%esp
 0x10062b54 <+2164>: pop %ebx
 0x10062b55 <+2165>: pop %esi
 0x10062b56 <+2166>: pop %edi
 0x10062b57 <+2167>: pop %ebp
 0x10062b58 <+2168>: ret $0x34
 -----------------------

It looks like you reuse the same stack area for all the calls and just re-adjust stack pointer back to compensate ret <N> instruction in functions being called. With this, the cause of the problem is the following. It's all about the method CProfileGenerator::InternalAccCalc which is being invoked. In function faulting the method is called 4 times from different execution paths (the first one shown above and the other 3 further in the function). Actually, GCC has generated two instances of CProfileGenerator::InternalAccCalc: at 0x1005aa40 and 0x1005a660, - each of those two instances being called twice. For first instance the stack is adjusted by 0x38 in caller, while for second instance the stack is adjusted by 0x48. However if second instance contains correct "ret 0x48" exit instructions, the first one containg just plain "ret" which causes the stack corruption.
Attached is the method's source and disassembled text of two instances generated.
The instances are invoked as InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc1, false, ret_profile); // #2
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc2, false, ret_profile); // #2



 
The GCC was auto-installed by setup application from SourceForge
 H:\Projects\FTSI\other\GUI>"c:\Util\MinGW\bin\g++.exe" -v
 Using built-in specs.
 COLLECT_GCC=c:\Util\MinGW\bin\g++.exe
 COLLECT_LTO_WRAPPER=c:/util/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.e
 xe
 Target: mingw32
 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
 c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
 mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
 with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
 Thread model: win32
 gcc version 4.7.2 (GCC)
 
The file was compiled with following options
 g++ -D"USED_LIBS=" -D_NDEBUG -DNDEBUG -DNODEBUG -DNO_EXCEPTIONS -D__STL_THREADS
 -D_MT -DUSE_DELPHI_STRINGS -mwindows -mconsole -mthreads -malign-double -Wall -
 W -Wno-unused-function -Wno-unused-parameter -O3 -march=i686 -g -DLOGING -D_C
 ONSOLE -fno-exceptions -fno-rtti -Woverloaded-virtual -fno-inline ../../shared/pr
 ofiles/MoveProfileGenerator.cpp -c -o bin/release/MoveProfileGenerator.obj
 

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 10:36

Message:
And also, sorry - there is n 4.7.3 available for download yet. It's only in
their bugtracker that this new version is available for some reason (a
beta, perhaps?)

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 10:35

Message:
OK, reported it for GCC. Let's see if I'll be able to win the fight with
them. ;)

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 10:15

Message:
It has to be either GCC or binutils or your source.  Since you're stating
the stack frame, then we need to eliminate either GCC or binutils.

If you don't open the bug reports you'll never convince them of a bug.  It
could be that the bug is yet undiscovered and not in 4.7.3 release or
discovered and not in 4.7.3 release.  I understand the testing on the
current release but it isn't provided to you yet as you already state. 
That doesn't mean the bug report isn't valuable.

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:30

Message:
Also, GCC has already release 4.7.3 available. The first thing they'll do
is going to be asking me to upgrade to 4.7.3. And I will not be able to do
that since MinGW is only 4.7.2 yet.

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:09

Message:
I've decided to report it against MinGW because the same source compiled
with the same version of compiler and similar options on QNX does not
produce this invalid code. How can I prove to GCC developers it's their
issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:14

Message:
Please file a bug report with GCC see gcc.gnu.org/bugs.html for
instructions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Bugs item #3594484, was opened at 2012-12-10 06:17
Message generated for change (Comment added) made by oleh_derevenko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: Remind
Priority: 5
Private: No
Submitted By: Oleh Derevenko (oleh_derevenko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect argument clearance in one of method instances

Initial Comment:

After upgrading to GCC 4.7.2 I'having an issue that release build of my DLL crashes. Debugging shows that this is due to bad code generated by GCC, Alas I can't provide small test case but here is the faulting function fragment itself.
 -----------------------
 int CProfileGenerator::CalcAccProfile(
 pos_type p0,
 vel_type v0,
 acc_type a0,
 jerk_type j,
 vel_type vel,
 acc_type acc,
 CProfile& ret_profile
 ) const {
 time_type t0 = 0.0;
 ret_profile.clear(); ret_profile.reserve(10);
 
vel_type dv = vel-v0;
 
if (ABS(dv) < m_epsilon_v && ABS(a0) < m_epsilon_a) {
 if (dv == 0.0) {
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 } else {
 acc_type a0 = (dv<0.0)?-1.0:1.0;
 time_type dt = ABS(dv);
 pos_type p1 = p0 + v0*dt + 0.5*dv*dv;
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 ret_profile.push_back(CProfileStep(dt, p1, vel, 0.0, 0.0)); VALIDATEPROFILE(ret_profile);
 }
 G_BLOG_4("acc profile calc skiped ");
 return ret_profile.size();
 }
 if (v0 < vel) {
 acc = ABS(acc);
 } else if (v0 == vel) {
 acc = -SIGN(a0)*ABS(acc);
 } else {
 acc = -ABS(acc);
 }
 
if (j == 0.0) {
 return InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile);
 // <------------------------------ FAULTS DUE TO RETURNING TO ADDRESS 0x00000000 HERE
 }
 ...
 -----------------------
 Here all the *_type typedefs are doubles and CProfile is std::vector of CProfileStep structure.
 
I've built library with -fno-inline to be able to see function calls more clearly and here is the problem is assembler code.
 -----------------------
 Dump of assembler code for function CProfileGenerator::CalcAccProfile(double, double, double, double, double, double, CP
 rofileGenerator::CProfile&) const:
 0x100622e0 <+0>: push %ebp
 0x100622e1 <+1>: mov %ecx,%ebp
 0x100622e3 <+3>: push %edi
 0x100622e4 <+4>: push %esi
 0x100622e5 <+5>: push %ebx
 0x100622e6 <+6>: sub $0x14c,%esp
 ; <------------------------ Initial stack preparation ends here
 0x100622ec <+12>: mov 0x160(%esp),%eax
 0x100622f3 <+19>: mov 0x190(%esp),%ebx
 0x100622fa <+26>: fldl 0x188(%esp)
 0x10062301 <+33>: fstpl 0x98(%esp)
 ...
 ...
 ...
 0x1006254a <+618>: jbe 0x10062920 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+1600>
 0x10062550 <+624>: fldl 0x98(%esp)
 0x10062557 <+631>: fstpl (%esp)
 0x1006255a <+634>: call 0x1005f2e0 <ABS<double>(double const&)>
 0x1006255f <+639>: fldl 0xb0(%esp)
 0x10062566 <+646>: fldz
 0x10062568 <+648>: fld %st(0)
 0x1006256a <+650>: fxch %st(2)
 0x1006256c <+652>: fucomi %st(2),%st
 0x1006256e <+654>: fstp %st(2)
 0x10062570 <+656>: jnp 0x10062b00 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+2080>
 ...
 ...
 ...
 0x10062b00 <+2080>: jne 0x10062580 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+672>
 0x10062b06 <+2086>: fstp %st(1)
 0x10062b08 <+2088>: fxch %st(1)
 0x10062b0a <+2090>: fstpl 0x30(%esp)
 0x10062b0e <+2094>: mov %ebx,%ecx
 0x10062b10 <+2096>: fldl 0x90(%esp)
 0x10062b17 <+2103>: mov $0x1,%edx
 0x10062b1c <+2108>: mov $0x1,%eax
 0x10062b21 <+2113>: fstpl 0x28(%esp)
 0x10062b25 <+2117>: fstl 0x20(%esp)
 0x10062b29 <+2121>: fstl 0x18(%esp)
 0x10062b2d <+2125>: fldl 0x88(%esp)
 0x10062b34 <+2132>: fstpl 0x10(%esp)
 0x10062b38 <+2136>: fldl 0xc8(%esp)
 0x10062b3f <+2143>: fstpl 0x8(%esp)
 0x10062b43 <+2147>: fstpl (%esp)
 0x10062b46 <+2150>: call 0x10061890 <CProfileGenerator::InternalAccCalc(double, double, double, double, double, bo
 ol, bool, double, double, bool, CProfileGenerator::CProfile&) const>
 
0x10062b4b <+2155>: sub $0x38,%esp <----------------------------------------- THIS COMMAND CORRUPTS STACK POINTER WHICH OTHERWISE WOULD BE VALID
 
0x10062b4e <+2158>: add $0x14c,%esp
 0x10062b54 <+2164>: pop %ebx
 0x10062b55 <+2165>: pop %esi
 0x10062b56 <+2166>: pop %edi
 0x10062b57 <+2167>: pop %ebp
 0x10062b58 <+2168>: ret $0x34
 -----------------------

It looks like you reuse the same stack area for all the calls and just re-adjust stack pointer back to compensate ret <N> instruction in functions being called. With this, the cause of the problem is the following. It's all about the method CProfileGenerator::InternalAccCalc which is being invoked. In function faulting the method is called 4 times from different execution paths (the first one shown above and the other 3 further in the function). Actually, GCC has generated two instances of CProfileGenerator::InternalAccCalc: at 0x1005aa40 and 0x1005a660, - each of those two instances being called twice. For first instance the stack is adjusted by 0x38 in caller, while for second instance the stack is adjusted by 0x48. However if second instance contains correct "ret 0x48" exit instructions, the first one containg just plain "ret" which causes the stack corruption.
Attached is the method's source and disassembled text of two instances generated.
The instances are invoked as InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc1, false, ret_profile); // #2
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc2, false, ret_profile); // #2



 
The GCC was auto-installed by setup application from SourceForge
 H:\Projects\FTSI\other\GUI>"c:\Util\MinGW\bin\g++.exe" -v
 Using built-in specs.
 COLLECT_GCC=c:\Util\MinGW\bin\g++.exe
 COLLECT_LTO_WRAPPER=c:/util/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.e
 xe
 Target: mingw32
 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
 c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
 mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
 with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
 Thread model: win32
 gcc version 4.7.2 (GCC)
 
The file was compiled with following options
 g++ -D"USED_LIBS=" -D_NDEBUG -DNDEBUG -DNODEBUG -DNO_EXCEPTIONS -D__STL_THREADS
 -D_MT -DUSE_DELPHI_STRINGS -mwindows -mconsole -mthreads -malign-double -Wall -
 W -Wno-unused-function -Wno-unused-parameter -O3 -march=i686 -g -DLOGING -D_C
 ONSOLE -fno-exceptions -fno-rtti -Woverloaded-virtual -fno-inline ../../shared/pr
 ofiles/MoveProfileGenerator.cpp -c -o bin/release/MoveProfileGenerator.obj
 

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 10:35

Message:
OK, reported it for GCC. Let's see if I'll be able to win the fight with
them. ;)

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 10:15

Message:
It has to be either GCC or binutils or your source.  Since you're stating
the stack frame, then we need to eliminate either GCC or binutils.

If you don't open the bug reports you'll never convince them of a bug.  It
could be that the bug is yet undiscovered and not in 4.7.3 release or
discovered and not in 4.7.3 release.  I understand the testing on the
current release but it isn't provided to you yet as you already state. 
That doesn't mean the bug report isn't valuable.

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:30

Message:
Also, GCC has already release 4.7.3 available. The first thing they'll do
is going to be asking me to upgrade to 4.7.3. And I will not be able to do
that since MinGW is only 4.7.2 yet.

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:09

Message:
I've decided to report it against MinGW because the same source compiled
with the same version of compiler and similar options on QNX does not
produce this invalid code. How can I prove to GCC developers it's their
issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:14

Message:
Please file a bug report with GCC see gcc.gnu.org/bugs.html for
instructions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Bugs item #3594484, was opened at 2012-12-10 06:17
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: Remind
Priority: 5
Private: No
Submitted By: Oleh Derevenko (oleh_derevenko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect argument clearance in one of method instances

Initial Comment:

After upgrading to GCC 4.7.2 I'having an issue that release build of my DLL crashes. Debugging shows that this is due to bad code generated by GCC, Alas I can't provide small test case but here is the faulting function fragment itself.
 -----------------------
 int CProfileGenerator::CalcAccProfile(
 pos_type p0,
 vel_type v0,
 acc_type a0,
 jerk_type j,
 vel_type vel,
 acc_type acc,
 CProfile& ret_profile
 ) const {
 time_type t0 = 0.0;
 ret_profile.clear(); ret_profile.reserve(10);
 
vel_type dv = vel-v0;
 
if (ABS(dv) < m_epsilon_v && ABS(a0) < m_epsilon_a) {
 if (dv == 0.0) {
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 } else {
 acc_type a0 = (dv<0.0)?-1.0:1.0;
 time_type dt = ABS(dv);
 pos_type p1 = p0 + v0*dt + 0.5*dv*dv;
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 ret_profile.push_back(CProfileStep(dt, p1, vel, 0.0, 0.0)); VALIDATEPROFILE(ret_profile);
 }
 G_BLOG_4("acc profile calc skiped ");
 return ret_profile.size();
 }
 if (v0 < vel) {
 acc = ABS(acc);
 } else if (v0 == vel) {
 acc = -SIGN(a0)*ABS(acc);
 } else {
 acc = -ABS(acc);
 }
 
if (j == 0.0) {
 return InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile);
 // <------------------------------ FAULTS DUE TO RETURNING TO ADDRESS 0x00000000 HERE
 }
 ...
 -----------------------
 Here all the *_type typedefs are doubles and CProfile is std::vector of CProfileStep structure.
 
I've built library with -fno-inline to be able to see function calls more clearly and here is the problem is assembler code.
 -----------------------
 Dump of assembler code for function CProfileGenerator::CalcAccProfile(double, double, double, double, double, double, CP
 rofileGenerator::CProfile&) const:
 0x100622e0 <+0>: push %ebp
 0x100622e1 <+1>: mov %ecx,%ebp
 0x100622e3 <+3>: push %edi
 0x100622e4 <+4>: push %esi
 0x100622e5 <+5>: push %ebx
 0x100622e6 <+6>: sub $0x14c,%esp
 ; <------------------------ Initial stack preparation ends here
 0x100622ec <+12>: mov 0x160(%esp),%eax
 0x100622f3 <+19>: mov 0x190(%esp),%ebx
 0x100622fa <+26>: fldl 0x188(%esp)
 0x10062301 <+33>: fstpl 0x98(%esp)
 ...
 ...
 ...
 0x1006254a <+618>: jbe 0x10062920 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+1600>
 0x10062550 <+624>: fldl 0x98(%esp)
 0x10062557 <+631>: fstpl (%esp)
 0x1006255a <+634>: call 0x1005f2e0 <ABS<double>(double const&)>
 0x1006255f <+639>: fldl 0xb0(%esp)
 0x10062566 <+646>: fldz
 0x10062568 <+648>: fld %st(0)
 0x1006256a <+650>: fxch %st(2)
 0x1006256c <+652>: fucomi %st(2),%st
 0x1006256e <+654>: fstp %st(2)
 0x10062570 <+656>: jnp 0x10062b00 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+2080>
 ...
 ...
 ...
 0x10062b00 <+2080>: jne 0x10062580 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+672>
 0x10062b06 <+2086>: fstp %st(1)
 0x10062b08 <+2088>: fxch %st(1)
 0x10062b0a <+2090>: fstpl 0x30(%esp)
 0x10062b0e <+2094>: mov %ebx,%ecx
 0x10062b10 <+2096>: fldl 0x90(%esp)
 0x10062b17 <+2103>: mov $0x1,%edx
 0x10062b1c <+2108>: mov $0x1,%eax
 0x10062b21 <+2113>: fstpl 0x28(%esp)
 0x10062b25 <+2117>: fstl 0x20(%esp)
 0x10062b29 <+2121>: fstl 0x18(%esp)
 0x10062b2d <+2125>: fldl 0x88(%esp)
 0x10062b34 <+2132>: fstpl 0x10(%esp)
 0x10062b38 <+2136>: fldl 0xc8(%esp)
 0x10062b3f <+2143>: fstpl 0x8(%esp)
 0x10062b43 <+2147>: fstpl (%esp)
 0x10062b46 <+2150>: call 0x10061890 <CProfileGenerator::InternalAccCalc(double, double, double, double, double, bo
 ol, bool, double, double, bool, CProfileGenerator::CProfile&) const>
 
0x10062b4b <+2155>: sub $0x38,%esp <----------------------------------------- THIS COMMAND CORRUPTS STACK POINTER WHICH OTHERWISE WOULD BE VALID
 
0x10062b4e <+2158>: add $0x14c,%esp
 0x10062b54 <+2164>: pop %ebx
 0x10062b55 <+2165>: pop %esi
 0x10062b56 <+2166>: pop %edi
 0x10062b57 <+2167>: pop %ebp
 0x10062b58 <+2168>: ret $0x34
 -----------------------

It looks like you reuse the same stack area for all the calls and just re-adjust stack pointer back to compensate ret <N> instruction in functions being called. With this, the cause of the problem is the following. It's all about the method CProfileGenerator::InternalAccCalc which is being invoked. In function faulting the method is called 4 times from different execution paths (the first one shown above and the other 3 further in the function). Actually, GCC has generated two instances of CProfileGenerator::InternalAccCalc: at 0x1005aa40 and 0x1005a660, - each of those two instances being called twice. For first instance the stack is adjusted by 0x38 in caller, while for second instance the stack is adjusted by 0x48. However if second instance contains correct "ret 0x48" exit instructions, the first one containg just plain "ret" which causes the stack corruption.
Attached is the method's source and disassembled text of two instances generated.
The instances are invoked as InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc1, false, ret_profile); // #2
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc2, false, ret_profile); // #2



 
The GCC was auto-installed by setup application from SourceForge
 H:\Projects\FTSI\other\GUI>"c:\Util\MinGW\bin\g++.exe" -v
 Using built-in specs.
 COLLECT_GCC=c:\Util\MinGW\bin\g++.exe
 COLLECT_LTO_WRAPPER=c:/util/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.e
 xe
 Target: mingw32
 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
 c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
 mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
 with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
 Thread model: win32
 gcc version 4.7.2 (GCC)
 
The file was compiled with following options
 g++ -D"USED_LIBS=" -D_NDEBUG -DNDEBUG -DNODEBUG -DNO_EXCEPTIONS -D__STL_THREADS
 -D_MT -DUSE_DELPHI_STRINGS -mwindows -mconsole -mthreads -malign-double -Wall -
 W -Wno-unused-function -Wno-unused-parameter -O3 -march=i686 -g -DLOGING -D_C
 ONSOLE -fno-exceptions -fno-rtti -Woverloaded-virtual -fno-inline ../../shared/pr
 ofiles/MoveProfileGenerator.cpp -c -o bin/release/MoveProfileGenerator.obj
 

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 10:15

Message:
It has to be either GCC or binutils or your source.  Since you're stating
the stack frame, then we need to eliminate either GCC or binutils.

If you don't open the bug reports you'll never convince them of a bug.  It
could be that the bug is yet undiscovered and not in 4.7.3 release or
discovered and not in 4.7.3 release.  I understand the testing on the
current release but it isn't provided to you yet as you already state. 
That doesn't mean the bug report isn't valuable.

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:30

Message:
Also, GCC has already release 4.7.3 available. The first thing they'll do
is going to be asking me to upgrade to 4.7.3. And I will not be able to do
that since MinGW is only 4.7.2 yet.

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:09

Message:
I've decided to report it against MinGW because the same source compiled
with the same version of compiler and similar options on QNX does not
produce this invalid code. How can I prove to GCC developers it's their
issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:14

Message:
Please file a bug report with GCC see gcc.gnu.org/bugs.html for
instructions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Bugs item #3594484, was opened at 2012-12-10 06:17
Message generated for change (Comment added) made by oleh_derevenko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
Status: Open
Resolution: Remind
Priority: 5
Private: No
Submitted By: Oleh Derevenko (oleh_derevenko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect argument clearance in one of method instances

Initial Comment:

After upgrading to GCC 4.7.2 I'having an issue that release build of my DLL crashes. Debugging shows that this is due to bad code generated by GCC, Alas I can't provide small test case but here is the faulting function fragment itself.
 -----------------------
 int CProfileGenerator::CalcAccProfile(
 pos_type p0,
 vel_type v0,
 acc_type a0,
 jerk_type j,
 vel_type vel,
 acc_type acc,
 CProfile& ret_profile
 ) const {
 time_type t0 = 0.0;
 ret_profile.clear(); ret_profile.reserve(10);
 
vel_type dv = vel-v0;
 
if (ABS(dv) < m_epsilon_v && ABS(a0) < m_epsilon_a) {
 if (dv == 0.0) {
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 } else {
 acc_type a0 = (dv<0.0)?-1.0:1.0;
 time_type dt = ABS(dv);
 pos_type p1 = p0 + v0*dt + 0.5*dv*dv;
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 ret_profile.push_back(CProfileStep(dt, p1, vel, 0.0, 0.0)); VALIDATEPROFILE(ret_profile);
 }
 G_BLOG_4("acc profile calc skiped ");
 return ret_profile.size();
 }
 if (v0 < vel) {
 acc = ABS(acc);
 } else if (v0 == vel) {
 acc = -SIGN(a0)*ABS(acc);
 } else {
 acc = -ABS(acc);
 }
 
if (j == 0.0) {
 return InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile);
 // <------------------------------ FAULTS DUE TO RETURNING TO ADDRESS 0x00000000 HERE
 }
 ...
 -----------------------
 Here all the *_type typedefs are doubles and CProfile is std::vector of CProfileStep structure.
 
I've built library with -fno-inline to be able to see function calls more clearly and here is the problem is assembler code.
 -----------------------
 Dump of assembler code for function CProfileGenerator::CalcAccProfile(double, double, double, double, double, double, CP
 rofileGenerator::CProfile&) const:
 0x100622e0 <+0>: push %ebp
 0x100622e1 <+1>: mov %ecx,%ebp
 0x100622e3 <+3>: push %edi
 0x100622e4 <+4>: push %esi
 0x100622e5 <+5>: push %ebx
 0x100622e6 <+6>: sub $0x14c,%esp
 ; <------------------------ Initial stack preparation ends here
 0x100622ec <+12>: mov 0x160(%esp),%eax
 0x100622f3 <+19>: mov 0x190(%esp),%ebx
 0x100622fa <+26>: fldl 0x188(%esp)
 0x10062301 <+33>: fstpl 0x98(%esp)
 ...
 ...
 ...
 0x1006254a <+618>: jbe 0x10062920 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+1600>
 0x10062550 <+624>: fldl 0x98(%esp)
 0x10062557 <+631>: fstpl (%esp)
 0x1006255a <+634>: call 0x1005f2e0 <ABS<double>(double const&)>
 0x1006255f <+639>: fldl 0xb0(%esp)
 0x10062566 <+646>: fldz
 0x10062568 <+648>: fld %st(0)
 0x1006256a <+650>: fxch %st(2)
 0x1006256c <+652>: fucomi %st(2),%st
 0x1006256e <+654>: fstp %st(2)
 0x10062570 <+656>: jnp 0x10062b00 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+2080>
 ...
 ...
 ...
 0x10062b00 <+2080>: jne 0x10062580 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+672>
 0x10062b06 <+2086>: fstp %st(1)
 0x10062b08 <+2088>: fxch %st(1)
 0x10062b0a <+2090>: fstpl 0x30(%esp)
 0x10062b0e <+2094>: mov %ebx,%ecx
 0x10062b10 <+2096>: fldl 0x90(%esp)
 0x10062b17 <+2103>: mov $0x1,%edx
 0x10062b1c <+2108>: mov $0x1,%eax
 0x10062b21 <+2113>: fstpl 0x28(%esp)
 0x10062b25 <+2117>: fstl 0x20(%esp)
 0x10062b29 <+2121>: fstl 0x18(%esp)
 0x10062b2d <+2125>: fldl 0x88(%esp)
 0x10062b34 <+2132>: fstpl 0x10(%esp)
 0x10062b38 <+2136>: fldl 0xc8(%esp)
 0x10062b3f <+2143>: fstpl 0x8(%esp)
 0x10062b43 <+2147>: fstpl (%esp)
 0x10062b46 <+2150>: call 0x10061890 <CProfileGenerator::InternalAccCalc(double, double, double, double, double, bo
 ol, bool, double, double, bool, CProfileGenerator::CProfile&) const>
 
0x10062b4b <+2155>: sub $0x38,%esp <----------------------------------------- THIS COMMAND CORRUPTS STACK POINTER WHICH OTHERWISE WOULD BE VALID
 
0x10062b4e <+2158>: add $0x14c,%esp
 0x10062b54 <+2164>: pop %ebx
 0x10062b55 <+2165>: pop %esi
 0x10062b56 <+2166>: pop %edi
 0x10062b57 <+2167>: pop %ebp
 0x10062b58 <+2168>: ret $0x34
 -----------------------

It looks like you reuse the same stack area for all the calls and just re-adjust stack pointer back to compensate ret <N> instruction in functions being called. With this, the cause of the problem is the following. It's all about the method CProfileGenerator::InternalAccCalc which is being invoked. In function faulting the method is called 4 times from different execution paths (the first one shown above and the other 3 further in the function). Actually, GCC has generated two instances of CProfileGenerator::InternalAccCalc: at 0x1005aa40 and 0x1005a660, - each of those two instances being called twice. For first instance the stack is adjusted by 0x38 in caller, while for second instance the stack is adjusted by 0x48. However if second instance contains correct "ret 0x48" exit instructions, the first one containg just plain "ret" which causes the stack corruption.
Attached is the method's source and disassembled text of two instances generated.
The instances are invoked as InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc1, false, ret_profile); // #2
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc2, false, ret_profile); // #2



 
The GCC was auto-installed by setup application from SourceForge
 H:\Projects\FTSI\other\GUI>"c:\Util\MinGW\bin\g++.exe" -v
 Using built-in specs.
 COLLECT_GCC=c:\Util\MinGW\bin\g++.exe
 COLLECT_LTO_WRAPPER=c:/util/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.e
 xe
 Target: mingw32
 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
 c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
 mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
 with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
 Thread model: win32
 gcc version 4.7.2 (GCC)
 
The file was compiled with following options
 g++ -D"USED_LIBS=" -D_NDEBUG -DNDEBUG -DNODEBUG -DNO_EXCEPTIONS -D__STL_THREADS
 -D_MT -DUSE_DELPHI_STRINGS -mwindows -mconsole -mthreads -malign-double -Wall -
 W -Wno-unused-function -Wno-unused-parameter -O3 -march=i686 -g -DLOGING -D_C
 ONSOLE -fno-exceptions -fno-rtti -Woverloaded-virtual -fno-inline ../../shared/pr
 ofiles/MoveProfileGenerator.cpp -c -o bin/release/MoveProfileGenerator.obj
 

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:30

Message:
Also, GCC has already release 4.7.3 available. The first thing they'll do
is going to be asking me to upgrade to 4.7.3. And I will not be able to do
that since MinGW is only 4.7.2 yet.

----------------------------------------------------------------------

Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:09

Message:
I've decided to report it against MinGW because the same source compiled
with the same version of compiler and similar options on QNX does not
produce this invalid code. How can I prove to GCC developers it's their
issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:14

Message:
Please file a bug report with GCC see gcc.gnu.org/bugs.html for
instructions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Bugs item #3594484, was opened at 2012-12-10 06:17
Message generated for change (Comment added) made by oleh_derevenko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
>Status: Open
Resolution: Remind
Priority: 5
Private: No
Submitted By: Oleh Derevenko (oleh_derevenko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect argument clearance in one of method instances

Initial Comment:

After upgrading to GCC 4.7.2 I'having an issue that release build of my DLL crashes. Debugging shows that this is due to bad code generated by GCC, Alas I can't provide small test case but here is the faulting function fragment itself.
 -----------------------
 int CProfileGenerator::CalcAccProfile(
 pos_type p0,
 vel_type v0,
 acc_type a0,
 jerk_type j,
 vel_type vel,
 acc_type acc,
 CProfile& ret_profile
 ) const {
 time_type t0 = 0.0;
 ret_profile.clear(); ret_profile.reserve(10);
 
vel_type dv = vel-v0;
 
if (ABS(dv) < m_epsilon_v && ABS(a0) < m_epsilon_a) {
 if (dv == 0.0) {
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 } else {
 acc_type a0 = (dv<0.0)?-1.0:1.0;
 time_type dt = ABS(dv);
 pos_type p1 = p0 + v0*dt + 0.5*dv*dv;
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 ret_profile.push_back(CProfileStep(dt, p1, vel, 0.0, 0.0)); VALIDATEPROFILE(ret_profile);
 }
 G_BLOG_4("acc profile calc skiped ");
 return ret_profile.size();
 }
 if (v0 < vel) {
 acc = ABS(acc);
 } else if (v0 == vel) {
 acc = -SIGN(a0)*ABS(acc);
 } else {
 acc = -ABS(acc);
 }
 
if (j == 0.0) {
 return InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile);
 // <------------------------------ FAULTS DUE TO RETURNING TO ADDRESS 0x00000000 HERE
 }
 ...
 -----------------------
 Here all the *_type typedefs are doubles and CProfile is std::vector of CProfileStep structure.
 
I've built library with -fno-inline to be able to see function calls more clearly and here is the problem is assembler code.
 -----------------------
 Dump of assembler code for function CProfileGenerator::CalcAccProfile(double, double, double, double, double, double, CP
 rofileGenerator::CProfile&) const:
 0x100622e0 <+0>: push %ebp
 0x100622e1 <+1>: mov %ecx,%ebp
 0x100622e3 <+3>: push %edi
 0x100622e4 <+4>: push %esi
 0x100622e5 <+5>: push %ebx
 0x100622e6 <+6>: sub $0x14c,%esp
 ; <------------------------ Initial stack preparation ends here
 0x100622ec <+12>: mov 0x160(%esp),%eax
 0x100622f3 <+19>: mov 0x190(%esp),%ebx
 0x100622fa <+26>: fldl 0x188(%esp)
 0x10062301 <+33>: fstpl 0x98(%esp)
 ...
 ...
 ...
 0x1006254a <+618>: jbe 0x10062920 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+1600>
 0x10062550 <+624>: fldl 0x98(%esp)
 0x10062557 <+631>: fstpl (%esp)
 0x1006255a <+634>: call 0x1005f2e0 <ABS<double>(double const&)>
 0x1006255f <+639>: fldl 0xb0(%esp)
 0x10062566 <+646>: fldz
 0x10062568 <+648>: fld %st(0)
 0x1006256a <+650>: fxch %st(2)
 0x1006256c <+652>: fucomi %st(2),%st
 0x1006256e <+654>: fstp %st(2)
 0x10062570 <+656>: jnp 0x10062b00 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+2080>
 ...
 ...
 ...
 0x10062b00 <+2080>: jne 0x10062580 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+672>
 0x10062b06 <+2086>: fstp %st(1)
 0x10062b08 <+2088>: fxch %st(1)
 0x10062b0a <+2090>: fstpl 0x30(%esp)
 0x10062b0e <+2094>: mov %ebx,%ecx
 0x10062b10 <+2096>: fldl 0x90(%esp)
 0x10062b17 <+2103>: mov $0x1,%edx
 0x10062b1c <+2108>: mov $0x1,%eax
 0x10062b21 <+2113>: fstpl 0x28(%esp)
 0x10062b25 <+2117>: fstl 0x20(%esp)
 0x10062b29 <+2121>: fstl 0x18(%esp)
 0x10062b2d <+2125>: fldl 0x88(%esp)
 0x10062b34 <+2132>: fstpl 0x10(%esp)
 0x10062b38 <+2136>: fldl 0xc8(%esp)
 0x10062b3f <+2143>: fstpl 0x8(%esp)
 0x10062b43 <+2147>: fstpl (%esp)
 0x10062b46 <+2150>: call 0x10061890 <CProfileGenerator::InternalAccCalc(double, double, double, double, double, bo
 ol, bool, double, double, bool, CProfileGenerator::CProfile&) const>
 
0x10062b4b <+2155>: sub $0x38,%esp <----------------------------------------- THIS COMMAND CORRUPTS STACK POINTER WHICH OTHERWISE WOULD BE VALID
 
0x10062b4e <+2158>: add $0x14c,%esp
 0x10062b54 <+2164>: pop %ebx
 0x10062b55 <+2165>: pop %esi
 0x10062b56 <+2166>: pop %edi
 0x10062b57 <+2167>: pop %ebp
 0x10062b58 <+2168>: ret $0x34
 -----------------------

It looks like you reuse the same stack area for all the calls and just re-adjust stack pointer back to compensate ret <N> instruction in functions being called. With this, the cause of the problem is the following. It's all about the method CProfileGenerator::InternalAccCalc which is being invoked. In function faulting the method is called 4 times from different execution paths (the first one shown above and the other 3 further in the function). Actually, GCC has generated two instances of CProfileGenerator::InternalAccCalc: at 0x1005aa40 and 0x1005a660, - each of those two instances being called twice. For first instance the stack is adjusted by 0x38 in caller, while for second instance the stack is adjusted by 0x48. However if second instance contains correct "ret 0x48" exit instructions, the first one containg just plain "ret" which causes the stack corruption.
Attached is the method's source and disassembled text of two instances generated.
The instances are invoked as InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc1, false, ret_profile); // #2
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc2, false, ret_profile); // #2



 
The GCC was auto-installed by setup application from SourceForge
 H:\Projects\FTSI\other\GUI>"c:\Util\MinGW\bin\g++.exe" -v
 Using built-in specs.
 COLLECT_GCC=c:\Util\MinGW\bin\g++.exe
 COLLECT_LTO_WRAPPER=c:/util/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.e
 xe
 Target: mingw32
 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
 c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
 mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
 with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
 Thread model: win32
 gcc version 4.7.2 (GCC)
 
The file was compiled with following options
 g++ -D"USED_LIBS=" -D_NDEBUG -DNDEBUG -DNODEBUG -DNO_EXCEPTIONS -D__STL_THREADS
 -D_MT -DUSE_DELPHI_STRINGS -mwindows -mconsole -mthreads -malign-double -Wall -
 W -Wno-unused-function -Wno-unused-parameter -O3 -march=i686 -g -DLOGING -D_C
 ONSOLE -fno-exceptions -fno-rtti -Woverloaded-virtual -fno-inline ../../shared/pr
 ofiles/MoveProfileGenerator.cpp -c -o bin/release/MoveProfileGenerator.obj
 

----------------------------------------------------------------------

>Comment By: Oleh Derevenko (oleh_derevenko)
Date: 2013-01-08 09:09

Message:
I've decided to report it against MinGW because the same source compiled
with the same version of compiler and similar options on QNX does not
produce this invalid code. How can I prove to GCC developers it's their
issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:14

Message:
Please file a bug report with GCC see gcc.gnu.org/bugs.html for
instructions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Bugs item #3594484, was opened at 2012-12-10 06:17
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
Group: None
>Status: Pending
>Resolution: Remind
Priority: 5
Private: No
Submitted By: Oleh Derevenko (oleh_derevenko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect argument clearance in one of method instances

Initial Comment:

After upgrading to GCC 4.7.2 I'having an issue that release build of my DLL crashes. Debugging shows that this is due to bad code generated by GCC, Alas I can't provide small test case but here is the faulting function fragment itself.
 -----------------------
 int CProfileGenerator::CalcAccProfile(
 pos_type p0,
 vel_type v0,
 acc_type a0,
 jerk_type j,
 vel_type vel,
 acc_type acc,
 CProfile& ret_profile
 ) const {
 time_type t0 = 0.0;
 ret_profile.clear(); ret_profile.reserve(10);
 
vel_type dv = vel-v0;
 
if (ABS(dv) < m_epsilon_v && ABS(a0) < m_epsilon_a) {
 if (dv == 0.0) {
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 } else {
 acc_type a0 = (dv<0.0)?-1.0:1.0;
 time_type dt = ABS(dv);
 pos_type p1 = p0 + v0*dt + 0.5*dv*dv;
 ret_profile.push_back(CProfileStep(0.0, p0, v0, a0, 0.0)); VALIDATEPROFILE(ret_profile);
 ret_profile.push_back(CProfileStep(dt, p1, vel, 0.0, 0.0)); VALIDATEPROFILE(ret_profile);
 }
 G_BLOG_4("acc profile calc skiped ");
 return ret_profile.size();
 }
 if (v0 < vel) {
 acc = ABS(acc);
 } else if (v0 == vel) {
 acc = -SIGN(a0)*ABS(acc);
 } else {
 acc = -ABS(acc);
 }
 
if (j == 0.0) {
 return InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile);
 // <------------------------------ FAULTS DUE TO RETURNING TO ADDRESS 0x00000000 HERE
 }
 ...
 -----------------------
 Here all the *_type typedefs are doubles and CProfile is std::vector of CProfileStep structure.
 
I've built library with -fno-inline to be able to see function calls more clearly and here is the problem is assembler code.
 -----------------------
 Dump of assembler code for function CProfileGenerator::CalcAccProfile(double, double, double, double, double, double, CP
 rofileGenerator::CProfile&) const:
 0x100622e0 <+0>: push %ebp
 0x100622e1 <+1>: mov %ecx,%ebp
 0x100622e3 <+3>: push %edi
 0x100622e4 <+4>: push %esi
 0x100622e5 <+5>: push %ebx
 0x100622e6 <+6>: sub $0x14c,%esp
 ; <------------------------ Initial stack preparation ends here
 0x100622ec <+12>: mov 0x160(%esp),%eax
 0x100622f3 <+19>: mov 0x190(%esp),%ebx
 0x100622fa <+26>: fldl 0x188(%esp)
 0x10062301 <+33>: fstpl 0x98(%esp)
 ...
 ...
 ...
 0x1006254a <+618>: jbe 0x10062920 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+1600>
 0x10062550 <+624>: fldl 0x98(%esp)
 0x10062557 <+631>: fstpl (%esp)
 0x1006255a <+634>: call 0x1005f2e0 <ABS<double>(double const&)>
 0x1006255f <+639>: fldl 0xb0(%esp)
 0x10062566 <+646>: fldz
 0x10062568 <+648>: fld %st(0)
 0x1006256a <+650>: fxch %st(2)
 0x1006256c <+652>: fucomi %st(2),%st
 0x1006256e <+654>: fstp %st(2)
 0x10062570 <+656>: jnp 0x10062b00 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+2080>
 ...
 ...
 ...
 0x10062b00 <+2080>: jne 0x10062580 <CProfileGenerator::CalcAccProfile(double, double, double, double, double, dou
 ble, CProfileGenerator::CProfile&) const+672>
 0x10062b06 <+2086>: fstp %st(1)
 0x10062b08 <+2088>: fxch %st(1)
 0x10062b0a <+2090>: fstpl 0x30(%esp)
 0x10062b0e <+2094>: mov %ebx,%ecx
 0x10062b10 <+2096>: fldl 0x90(%esp)
 0x10062b17 <+2103>: mov $0x1,%edx
 0x10062b1c <+2108>: mov $0x1,%eax
 0x10062b21 <+2113>: fstpl 0x28(%esp)
 0x10062b25 <+2117>: fstl 0x20(%esp)
 0x10062b29 <+2121>: fstl 0x18(%esp)
 0x10062b2d <+2125>: fldl 0x88(%esp)
 0x10062b34 <+2132>: fstpl 0x10(%esp)
 0x10062b38 <+2136>: fldl 0xc8(%esp)
 0x10062b3f <+2143>: fstpl 0x8(%esp)
 0x10062b43 <+2147>: fstpl (%esp)
 0x10062b46 <+2150>: call 0x10061890 <CProfileGenerator::InternalAccCalc(double, double, double, double, double, bo
 ol, bool, double, double, bool, CProfileGenerator::CProfile&) const>
 
0x10062b4b <+2155>: sub $0x38,%esp <----------------------------------------- THIS COMMAND CORRUPTS STACK POINTER WHICH OTHERWISE WOULD BE VALID
 
0x10062b4e <+2158>: add $0x14c,%esp
 0x10062b54 <+2164>: pop %ebx
 0x10062b55 <+2165>: pop %esi
 0x10062b56 <+2166>: pop %edi
 0x10062b57 <+2167>: pop %ebp
 0x10062b58 <+2168>: ret $0x34
 -----------------------

It looks like you reuse the same stack area for all the calls and just re-adjust stack pointer back to compensate ret <N> instruction in functions being called. With this, the cause of the problem is the following. It's all about the method CProfileGenerator::InternalAccCalc which is being invoked. In function faulting the method is called 4 times from different execution paths (the first one shown above and the other 3 further in the function). Actually, GCC has generated two instances of CProfileGenerator::InternalAccCalc: at 0x1005aa40 and 0x1005a660, - each of those two instances being called twice. For first instance the stack is adjusted by 0x38 in caller, while for second instance the stack is adjusted by 0x48. However if second instance contains correct "ret 0x48" exit instructions, the first one containg just plain "ret" which causes the stack corruption.
Attached is the method's source and disassembled text of two instances generated.
The instances are invoked as InternalAccCalc(t0, p0, v0, 0.0, 0.0, true, true, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, acc, true, ret_profile); // #1
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc1, false, ret_profile); // #2
InternalAccCalc(t0, p0, v0, a0, j, z1, z2, vel, limit_acc2, false, ret_profile); // #2



 
The GCC was auto-installed by setup application from SourceForge
 H:\Projects\FTSI\other\GUI>"c:\Util\MinGW\bin\g++.exe" -v
 Using built-in specs.
 COLLECT_GCC=c:\Util\MinGW\bin\g++.exe
 COLLECT_LTO_WRAPPER=c:/util/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.e
 xe
 Target: mingw32
 Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
 c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
 mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
 with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
 Thread model: win32
 gcc version 4.7.2 (GCC)
 
The file was compiled with following options
 g++ -D"USED_LIBS=" -D_NDEBUG -DNDEBUG -DNODEBUG -DNO_EXCEPTIONS -D__STL_THREADS
 -D_MT -DUSE_DELPHI_STRINGS -mwindows -mconsole -mthreads -malign-double -Wall -
 W -Wno-unused-function -Wno-unused-parameter -O3 -march=i686 -g -DLOGING -D_C
 ONSOLE -fno-exceptions -fno-rtti -Woverloaded-virtual -fno-inline ../../shared/pr
 ofiles/MoveProfileGenerator.cpp -c -o bin/release/MoveProfileGenerator.obj
 

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:14

Message:
Please file a bug report with GCC see gcc.gnu.org/bugs.html for
instructions.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594484&group_id=2435

Bugs item #3594393, was opened at 2012-12-09 20:06
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594393&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc
>Group: component package
>Status: Pending
>Resolution: Remind
Priority: 3
Private: No
Submitted By: LH_Mouse (lhmouse)
Assigned to: Cesar Strauss (cstrauss)
Summary: Localization not working properly on Windows 

Initial Comment:
Platform: Windows Server 2003 Enterprise SP2 (Internal 3790), x86, Simplified Chinese
MinGW version: 20120426
GCC version: 4.7.2

Description: Locale language files are only searched in the same drive where gcc/g++/cc is started from CUI. If gcc is started from a drive that is different from that where mingw is installed, it fails to find locale files and falls back to en.

Steps to reproduce:
1. On Windows in East Asian language, install MinGW into E:\MinGW. Now there is a directory with the path E:\MinGW\share\locale.
2. Open cmd.exe, type PATH E:\MinGW\bin;%PATH% <enter>.
3. Type E: <enter>.
4. Type g++ -v <enter>. The message text is in Chinese.
5. Type D: <enter>.
6. Type g++ -v <enter>. The message text is in English.
7. Type md \MinGW\share <enter>.. This will make the directory D:\MinGW\share.
8. Type xcopy E:\MinGW\share\locale D:\MinGW\share\locale\ /e /c /y <enter>. This will recursively copy all locale files from drive E: to drive D:, without changing the full path of each file except the drive latter.
9. Type g++ -v <enter>. The message text is in Chinese now.

----------------------------------------------------------------------

Comment By: Cesar Strauss (cstrauss)
Date: 2012-12-19 15:36

Message:
The search path for the translation files seems to be hard-coded to \MinGW
in GCC source code. This code must be made relocatable. Please file a bug
at http://gcc.gnu.org/bugs.

Regards,
Cesar



----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-12-19 09:52

Message:
Cesar is there anything we can do about this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594393&group_id=2435

Bugs item #3594256, was opened at 2012-12-09 06:44
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594256&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: gcc-4.7.0
>Group: component package
>Status: Pending
>Resolution: Remind
Priority: 5
Private: No
Submitted By: Giles (giles314)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error unrecognizable insn

Initial Comment:
MinGW 4.7.1 fails to compile this code:

#include <stdio.h>
static FILE *volatile fd;
void f(void) { fd = stdout; }

Producing the following error:

D:\Sources\src\DE\Test.cpp: In function 'void f()':
D:\Sources\\src\DE\Test.cpp:3:52: error: unrecognizable insn:
(insn 8 7 9 3 (set (mem/v/f/c:SI (symbol_ref:SI ("_ZL2fd") [flags 0x2] <var_decl 050d88a0 fd>) [0 fd+0 S4 A32])
(const:SI (plus:SI (symbol_ref:SI ("_iob") [flags 0x440] <var_decl 05096c60 _iob>)
(const_int 32 [0x20])))) D:\DubEdit\src\DE\Test.cpp:3 -1
(nil))
D:\Sources\src\DE\Test.cpp:3:52: internal compiler error: in extract_insn, at recog.c:2123


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:09

Message:
Since this causes an internal error in GCC please file a bug report with
GCC.  See gcc.gnu.org/bugs.html for instructions on doing that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594256&group_id=2435

Bugs item #3594256, was opened at 2012-12-09 06:44
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594256&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Giles (giles314)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error unrecognizable insn

Initial Comment:
MinGW 4.7.1 fails to compile this code:

#include <stdio.h>
static FILE *volatile fd;
void f(void) { fd = stdout; }

Producing the following error:

D:\Sources\src\DE\Test.cpp: In function 'void f()':
D:\Sources\\src\DE\Test.cpp:3:52: error: unrecognizable insn:
(insn 8 7 9 3 (set (mem/v/f/c:SI (symbol_ref:SI ("_ZL2fd") [flags 0x2] <var_decl 050d88a0 fd>) [0 fd+0 S4 A32])
(const:SI (plus:SI (symbol_ref:SI ("_iob") [flags 0x440] <var_decl 05096c60 _iob>)
(const_int 32 [0x20])))) D:\DubEdit\src\DE\Test.cpp:3 -1
(nil))
D:\Sources\src\DE\Test.cpp:3:52: internal compiler error: in extract_insn, at recog.c:2123


----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:09

Message:
Since this causes an internal error in GCC please file a bug report with
GCC.  See gcc.gnu.org/bugs.html for instructions on doing that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3594256&group_id=2435

Bugs item #3591569, was opened at 2012-11-30 19:43
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3591569&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: SquallATF (squallatf)
Assigned to: Cesar Strauss (cstrauss)
Summary: msys can't malloc memory biger than 268169196

Initial Comment:
here is the test code

#include <stdio.h>
#include <stdlib.h>

int main()
{
  void *okmem = malloc(1024*1024*256 - 1024*260 -20); //ok size 268169196
  if(okmem) {
      printf("malloc ok\n");
  }
  void *failedmem = malloc(1024*1024*256 - 1024*260 -19); //failed size 268169197
  if(!okmem) {
      printf("malloc failed\n");
  }
  return 0;
}


----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-08 08:02

Message:
Ping, Cesar, any comment on this issue?

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-12-02 11:08

Message:
Okay, then I'll leave it to Cesar to figure out a fix.

----------------------------------------------------------------------

Comment By: SquallATF (squallatf)
Date: 2012-12-01 19:20

Message:
I'm sorry because too much time and I remember correctly.
The right is i use msys gcc complie subversion. I get this error

cc1.exe: out of memory allocation 172600 bytes after a total of 268120064
bytes

So I debug the msysCore then found in source\winsup\cygwin\heap.cc at line
120

  commitbytes = pround (newtop - (char *) cygheap->heaptop);
  if (VirtualAlloc(cygheap->heaptop, commitbytes, MEM_COMMIT,
PAGE_READWRITE) != NULL)
    goto good;

the VirtualAlloc failed.
If too large source code to compile will appear this error


----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-12-01 08:33

Message:
@squallatf: This has nothing to do with linking large programs.  Please use
the min...@li... list to discuss your issue and not
this ticket.

----------------------------------------------------------------------

Comment By: SquallATF (squallatf)
Date: 2012-11-30 19:46

Message:
so that when mingw link large program may failed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3591569&group_id=2435

Bugs item #3588678, was opened at 2012-11-19 22:07
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3588678&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gcc-4.7.0
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Shinobu Maehara (shinobu_maehara)
Assigned to: Nobody/Anonymous (nobody)
Summary: Crash in cout << endl

Initial Comment:
When I compile the following pogram;
========[ endl.cpp ]========
#include <iostream>

int main()
{
	std::cout << "X" << std::endl;
	return 0;
}
========[   eof   ]========
With: g++ endl.cpp
The resulting program crashes because cout << endl tries to execute "X" as if it were code, which it isn't, it's a char const *.

Details:
The first << executes correctly and is:
std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)
It displays an X on the terminal.
The next << is the one that fails and is:
std::ostream::operator<<(std::ostream& (*)(std::ostream&))
It performs a jmp to an address in the data section, to be precise the location where "X" is stored.

OS: Win7
$ gcc -v
Ingebouwde specs worden gebruikt.
COLLECT_GCC=C:\MinGW\bin\gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.7.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.2/configure --enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-
with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc versie 4.7.2 (GCC)
$ ld -v
GNU ld (GNU Binutils) 2.23.1
$ uname -a
MINGW32_NT-6.1 COMPUTERNAME 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

I updated MinGW today, so I believe I'm running the latest version, and the minimal test case above is just your basic hello world type program so I believe this is a bug.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-11-20 09:15

Message:
As I stated already WJFFM.

I have an I7 CPU laptop with 8 cores.  I use mingw-get on the command line
and execute within the MSYS console.

To ensure it isn't a 64bit to 32bit issue I start
/c/windows/sysnative/cmd.exe and in the new window execute the binary
without issue.

I've attached the temporary assembler file from the build process.  You'll
see that there is no jmp in it.

----------------------------------------------------------------------

Comment By: Shinobu Maehara (shinobu_maehara)
Date: 2012-11-20 06:04

Message:
I ran the uninstaller again and cleaned out C:\MinGW again and installed
4.7.2 again. I did this using the official installer and by then opting for
the most recent version (rather than the pre-packaged 4.6.2 version.
The problem manifests itself again.
Note that this problem shouldn't depend on hardware or operating system
configuration, since the problem is that a wrong executable is generated
which will fail regardless of where it is run. I have also through the
power of Google discovered that I am not the only one who stumbled upon
this problem.

$ g++ --version
g++.exe (GCC) 4.7.2
Copyright c 2012 Free Software Foundation, Inc.
Dit is vrije software; zie de broncode voor kopieercondities.  Er is GEEN
garantie; zelfs niet voor VERKOOPBAARHEID of GESCHIKTHEID voor een bepaald
doel.

Questions:
1) Is your install the vanilla install?
2) Are you sure it doesn't crash? If WER is turned off or something you may
not notice if it does since in this case the only difference would be a
missing blank line.
3) Does in your case the second << call jump to the stub rather than the
data section?
4) Is there an easy way to compare our setups without sending ~ 300 MB down
the wire?
5) Is there any other way I can help you diagnose this?

----------------------------------------------------------------------

Comment By: Shinobu Maehara (shinobu_maehara)
Date: 2012-11-20 05:13

Message:
Just now I uninstalled MinGW and installed the 4.6.2 version and the
problem appears to be absent in 4.6.2. In that version, the second << call
doesn't jump to "X" but to:
std::basic_ostream<char, std::char_traits<char> >& std::endl<char,
std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char>
>&)
Which is a thunk to:
libstdc++-6!_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_

Two further remarks:
1) The MinGW uninstall command didn't work, I had to manually delete the
files in C:\MinGW otherwise the install would fail.
2) There is really no need for the thunk. Rather than this sequence:
call thunk
jmp [import]
The following should be used:
call [import]

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-11-20 05:01

Message:
WJFFM.  I upgraded both GCC/G++ and binutils to current versions and your
test program executes without displaying errors.

You showed the GCC version but not the version of G++, they might be
different.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3588678&group_id=2435

Bugs item #3590842, was opened at 2012-11-28 16:05
Message generated for change (Comment added) made by gbburkhardt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: non-mingw
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Glenn Burkhardt (gbburkhardt)
Assigned to: Nobody/Anonymous (nobody)
Summary: stat/fstat inappropriately used in cp.exe, install.exe

Initial Comment:
MINGW32_NT-6.1 BOS0DT-1QLS1R1 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
gcc version 4.7.0 (GCC)
Windows 7 Enterprise SP1

I noticed this when trying to use the "cp" command in a Clearcase locally hosted dynamic view.  When trying to copy a view private file, the 'cp' command would fail with a message like

     skipping file `jj', as it was replaced while being copied

The problem is that the 'cp' command uses 'stat' on the source file initially, and then, when it's ready to copy, uses 'fstat' on it again, after the file has been opened for reading (about line 237 in copy.c from coreutils-5.97).  This works on a file that's on a local hard drive, but not on a Clearcase locally hosted dynamic view.  The 'install' command has the same problem.

This test really shouldn't be done on a Windows platform.  Microsoft's documentation describes different values for stat.st_dev returned by the 'stat()' and 'fstat()' functions.  There's also a note that the stat.st_ino value is meaningless for NTFS filesystems.

But then it gets interesting.  The 'cp' command is built with a different version of 'stat' and 'fstat' than one normally gets with a MinGW build environment.  The coreutils need the Msys build environment, and the 'stat/fstat' functions are pulled from libmsys-1.0.dll.a.  A build in regular MinGW environment with the current compiler gets the functions from libmoldname.a.  So were the coreutils built with gcc-4.7.0, and no libmsys-1.0.dll.a, the copy command would fail for files on the local hard drive, since stat.st_dev is different for stat() and fstat().

I've attached a small test program to show the stat()/fstat() output, and a patch for system.h in coreutils that allows a working version of 'cp.exe' and 'install.exe' to be built.

----------------------------------------------------------------------

>Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-08 06:11

Message:
The only reason I've been building Coreutils is because the release
versions have flaws, due to their expectation that a fully usable
implementation of stat/fstat is available.  If by design MinGW uses the
native MS versions without modification, then it would seem appropriate to
modify utilities that rely on stat/fstat to accommodate platform
idiosyncrasies.  I agree also that it would be best if the Coreutil
maintainers would incorporate the platform specific support.  But MinGW
builds do patch the standard utility code, and this might be another case
that needs to be handled.

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-07 07:43

Message:
I've looked at the conversation in the bug report.

The native runtime from MSVCRT.DLL is something we cannot control.  The
stat/fstat functions are supplied by Microsoft and cannot be changed.  If
you're building coreutils in a native environment requiring MSVCRT.DLL then
you'll need to resolve the issues brought up by that or apply some patches
you might find in other projects.  Note that libmoldname.a is a mapping of
things like _stat to a name without the underscore.  It was created in
light of the names normally used by POSIX anc can be eliminated by defining
_NO_OLDNAMES but then you'll need to make sure you use the underscore in
the function name.

This is not an issue we can help you with.

----------------------------------------------------------------------

Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-07 06:27

Message:
I'm not sure why you think the Coreutils maintainers should be contacted. 
The problem is with the MinGW implementation of 'stat' and 'fstat'.  A
secondary problem is that the tools are linked with a different
implementation of 'stat'/'fstat' than normal application use.

This affects a number of programs, include 'rm', 'chown', 'sort', and
'find'.

----------------------------------------------------------------------

Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-07 06:13

Message:
I logged a bug report with the Coreutils maintainers:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13347

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-11-29 08:22

Message:
You'll need to supply your patch to the coreutils maintainers.  Report back
here with the results of you submission, either applied or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Bugs item #3590842, was opened at 2012-11-28 16:05
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: non-mingw
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Glenn Burkhardt (gbburkhardt)
Assigned to: Nobody/Anonymous (nobody)
Summary: stat/fstat inappropriately used in cp.exe, install.exe

Initial Comment:
MINGW32_NT-6.1 BOS0DT-1QLS1R1 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
gcc version 4.7.0 (GCC)
Windows 7 Enterprise SP1

I noticed this when trying to use the "cp" command in a Clearcase locally hosted dynamic view.  When trying to copy a view private file, the 'cp' command would fail with a message like

     skipping file `jj', as it was replaced while being copied

The problem is that the 'cp' command uses 'stat' on the source file initially, and then, when it's ready to copy, uses 'fstat' on it again, after the file has been opened for reading (about line 237 in copy.c from coreutils-5.97).  This works on a file that's on a local hard drive, but not on a Clearcase locally hosted dynamic view.  The 'install' command has the same problem.

This test really shouldn't be done on a Windows platform.  Microsoft's documentation describes different values for stat.st_dev returned by the 'stat()' and 'fstat()' functions.  There's also a note that the stat.st_ino value is meaningless for NTFS filesystems.

But then it gets interesting.  The 'cp' command is built with a different version of 'stat' and 'fstat' than one normally gets with a MinGW build environment.  The coreutils need the Msys build environment, and the 'stat/fstat' functions are pulled from libmsys-1.0.dll.a.  A build in regular MinGW environment with the current compiler gets the functions from libmoldname.a.  So were the coreutils built with gcc-4.7.0, and no libmsys-1.0.dll.a, the copy command would fail for files on the local hard drive, since stat.st_dev is different for stat() and fstat().

I've attached a small test program to show the stat()/fstat() output, and a patch for system.h in coreutils that allows a working version of 'cp.exe' and 'install.exe' to be built.

----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-07 07:43

Message:
I've looked at the conversation in the bug report.

The native runtime from MSVCRT.DLL is something we cannot control.  The
stat/fstat functions are supplied by Microsoft and cannot be changed.  If
you're building coreutils in a native environment requiring MSVCRT.DLL then
you'll need to resolve the issues brought up by that or apply some patches
you might find in other projects.  Note that libmoldname.a is a mapping of
things like _stat to a name without the underscore.  It was created in
light of the names normally used by POSIX anc can be eliminated by defining
_NO_OLDNAMES but then you'll need to make sure you use the underscore in
the function name.

This is not an issue we can help you with.

----------------------------------------------------------------------

Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-07 06:27

Message:
I'm not sure why you think the Coreutils maintainers should be contacted. 
The problem is with the MinGW implementation of 'stat' and 'fstat'.  A
secondary problem is that the tools are linked with a different
implementation of 'stat'/'fstat' than normal application use.

This affects a number of programs, include 'rm', 'chown', 'sort', and
'find'.

----------------------------------------------------------------------

Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-07 06:13

Message:
I logged a bug report with the Coreutils maintainers:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13347

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-11-29 08:22

Message:
You'll need to supply your patch to the coreutils maintainers.  Report back
here with the results of you submission, either applied or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Support Requests item #3599197, was opened at 2013-01-02 03:26
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3599197&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: non-mingw
Group: Not MinGW related
Status: Closed
Priority: 5
Private: No
Submitted By: Fabian Greffrath (fabian_deb)
Assigned to: Nobody/Anonymous (nobody)
Summary: mingw32-make does not set $(RM) to "del"

Initial Comment:
Hello,

occationally, I use mingw32-make for building very simple projects. However, it fails to call the clean: rules, because they remove the object files with "(RM) *.o" (similar). However, $(RM) is still set to "rm -f", which does not exist outside MSYS. Please fall back to Windows' own "del" in such case.

 - Fabian


----------------------------------------------------------------------

>Comment By: Keith Marshall (keithmarshall)
Date: 2013-01-07 06:43

Message:
FWIW, I think it's a bug in your makefile, that it doesn't set RM itself;
try to run it through any make, other than GNU make, and it will probably
blow up because $(RM) expands to nothing at all.

As a non-standard extension, GNU make DOES supply a default expansion for
$(RM), so it would make sense for that to be a sane expansion.  However, as
Earnie has already said, you'll need to take that up with the folks who
actually maintain it, at mak...@gn...

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2013-01-02 05:23

Message:
You'll need to make your request to mak...@gn....

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3599197&group_id=2435

Bugs item #3590842, was opened at 2012-11-28 16:05
Message generated for change (Comment added) made by gbburkhardt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: non-mingw
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Glenn Burkhardt (gbburkhardt)
Assigned to: Nobody/Anonymous (nobody)
Summary: stat/fstat inappropriately used in cp.exe, install.exe

Initial Comment:
MINGW32_NT-6.1 BOS0DT-1QLS1R1 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
gcc version 4.7.0 (GCC)
Windows 7 Enterprise SP1

I noticed this when trying to use the "cp" command in a Clearcase locally hosted dynamic view.  When trying to copy a view private file, the 'cp' command would fail with a message like

     skipping file `jj', as it was replaced while being copied

The problem is that the 'cp' command uses 'stat' on the source file initially, and then, when it's ready to copy, uses 'fstat' on it again, after the file has been opened for reading (about line 237 in copy.c from coreutils-5.97).  This works on a file that's on a local hard drive, but not on a Clearcase locally hosted dynamic view.  The 'install' command has the same problem.

This test really shouldn't be done on a Windows platform.  Microsoft's documentation describes different values for stat.st_dev returned by the 'stat()' and 'fstat()' functions.  There's also a note that the stat.st_ino value is meaningless for NTFS filesystems.

But then it gets interesting.  The 'cp' command is built with a different version of 'stat' and 'fstat' than one normally gets with a MinGW build environment.  The coreutils need the Msys build environment, and the 'stat/fstat' functions are pulled from libmsys-1.0.dll.a.  A build in regular MinGW environment with the current compiler gets the functions from libmoldname.a.  So were the coreutils built with gcc-4.7.0, and no libmsys-1.0.dll.a, the copy command would fail for files on the local hard drive, since stat.st_dev is different for stat() and fstat().

I've attached a small test program to show the stat()/fstat() output, and a patch for system.h in coreutils that allows a working version of 'cp.exe' and 'install.exe' to be built.

----------------------------------------------------------------------

>Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-07 06:27

Message:
I'm not sure why you think the Coreutils maintainers should be contacted. 
The problem is with the MinGW implementation of 'stat' and 'fstat'.  A
secondary problem is that the tools are linked with a different
implementation of 'stat'/'fstat' than normal application use.

This affects a number of programs, include 'rm', 'chown', 'sort', and
'find'.

----------------------------------------------------------------------

Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-07 06:13

Message:
I logged a bug report with the Coreutils maintainers:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13347

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-11-29 08:22

Message:
You'll need to supply your patch to the coreutils maintainers.  Report back
here with the results of you submission, either applied or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Bugs item #3590842, was opened at 2012-11-28 16:05
Message generated for change (Comment added) made by gbburkhardt
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: non-mingw
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Glenn Burkhardt (gbburkhardt)
Assigned to: Nobody/Anonymous (nobody)
Summary: stat/fstat inappropriately used in cp.exe, install.exe

Initial Comment:
MINGW32_NT-6.1 BOS0DT-1QLS1R1 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys
gcc version 4.7.0 (GCC)
Windows 7 Enterprise SP1

I noticed this when trying to use the "cp" command in a Clearcase locally hosted dynamic view.  When trying to copy a view private file, the 'cp' command would fail with a message like

     skipping file `jj', as it was replaced while being copied

The problem is that the 'cp' command uses 'stat' on the source file initially, and then, when it's ready to copy, uses 'fstat' on it again, after the file has been opened for reading (about line 237 in copy.c from coreutils-5.97).  This works on a file that's on a local hard drive, but not on a Clearcase locally hosted dynamic view.  The 'install' command has the same problem.

This test really shouldn't be done on a Windows platform.  Microsoft's documentation describes different values for stat.st_dev returned by the 'stat()' and 'fstat()' functions.  There's also a note that the stat.st_ino value is meaningless for NTFS filesystems.

But then it gets interesting.  The 'cp' command is built with a different version of 'stat' and 'fstat' than one normally gets with a MinGW build environment.  The coreutils need the Msys build environment, and the 'stat/fstat' functions are pulled from libmsys-1.0.dll.a.  A build in regular MinGW environment with the current compiler gets the functions from libmoldname.a.  So were the coreutils built with gcc-4.7.0, and no libmsys-1.0.dll.a, the copy command would fail for files on the local hard drive, since stat.st_dev is different for stat() and fstat().

I've attached a small test program to show the stat()/fstat() output, and a patch for system.h in coreutils that allows a working version of 'cp.exe' and 'install.exe' to be built.

----------------------------------------------------------------------

>Comment By: Glenn Burkhardt (gbburkhardt)
Date: 2013-01-07 06:13

Message:
I logged a bug report with the Coreutils maintainers:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13347

----------------------------------------------------------------------

Comment By: Earnie Boyd (earnie)
Date: 2012-11-29 08:22

Message:
You'll need to supply your patch to the coreutils maintainers.  Report back
here with the results of you submission, either applied or not.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3590842&group_id=2435

Bugs item #3599197, was opened at 2013-01-02 03:26
Message generated for change (Tracker Item Submitted) made by fabian_deb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3599197&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MinGW
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Fabian Greffrath (fabian_deb)
Assigned to: Nobody/Anonymous (nobody)
Summary: mingw32-make does not set $(RM) to "del"

Initial Comment:
Hello,

occationally, I use mingw32-make for building very simple projects. However, it fails to call the clean: rules, because they remove the object files with "(RM) *.o" (similar). However, $(RM) is still set to "rm -f", which does not exist outside MSYS. Please fall back to Windows' own "del" in such case.

 - Fabian


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3599197&group_id=2435

Support Requests item #3599110, was opened at 2013-01-01 06:49
Message generated for change (Comment added) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3599110&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
>Group: Not MinGW related
>Status: Closed
Priority: 5
Private: No
Submitted By: Vaclav (vaclavpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure: error: could not make

Initial Comment:
Hello, I have following MSYS:
$ uname -a
MINGW32_NT-5.1 mypc 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

I can not run ./configure script for SDCC project in this environment. It ends with message \"configure: error: could not make\" at the place where CONFIG_HEADERS are to be printed out.

I was told that on other systems ( Linux, Cygwin), this script works properly.

Attached are both configure and config.log scripts packed in the ZIP file.


----------------------------------------------------------------------

>Comment By: Earnie Boyd (earnie)
Date: 2013-01-01 07:26

Message:
It appears to fail due to the lack of POSIX support on Windows.  You'll
need to convert the package to Windows semantics.

It works on Cygwin because it is the scope of Cygwin to provide POSIX
support on Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3599110&group_id=2435

Support Requests item #3599110, was opened at 2013-01-01 06:49
Message generated for change (Settings changed) made by earnie
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3599110&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: MSYS
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Vaclav (vaclavpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure: error: could not make

Initial Comment:
Hello, I have following MSYS:
$ uname -a
MINGW32_NT-5.1 mypc 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

I can not run ./configure script for SDCC project in this environment. It ends with message \"configure: error: could not make\" at the place where CONFIG_HEADERS are to be printed out.

I was told that on other systems ( Linux, Cygwin), this script works properly.

Attached are both configure and config.log scripts packed in the ZIP file.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3599110&group_id=2435

Bugs item #3599110, was opened at 2013-01-01 06:49
Message generated for change (Tracker Item Submitted) made by vaclavpe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3599110&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: MSYS
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Vaclav (vaclavpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure: error: could not make

Initial Comment:
Hello, I have following MSYS:
$ uname -a
MINGW32_NT-5.1 mypc 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

I can not run ./configure script for SDCC project in this environment. It ends with message \"configure: error: could not make\" at the place where CONFIG_HEADERS are to be printed out.

I was told that on other systems ( Linux, Cygwin), this script works properly.

Attached are both configure and config.log scripts packed in the ZIP file.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3599110&group_id=2435

Feature Requests item #3598804, was opened at 2012-12-28 14:55
Message generated for change (Tracker Item Submitted) made by modernskyangel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=352435&aid=3598804&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Vasyl Khrystyuk (modernskyangel)
Assigned to: Nobody/Anonymous (nobody)
Summary: git instalation via mingw-get

Initial Comment:
Currently I have two versions of migw; one come with git(msysgit) and are simplified mingw and the second i unstall manually using  mingw-get-inst. Second  one came with normal C/C++ compiller, make util and other.

Its cause me to switch version to current mingw every time i need. (Just change path in my PATH environment variable) 

So i'd like install mingw via mingw-get-inst and then make:
mingw-get install git
and all git with all will be installed to my mingw folder.
Or there is standart solution of given problem?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=352435&aid=3598804&group_id=2435

Bugs item #3598072, was opened at 2012-12-21 08:25
Message generated for change (Comment added) made by giles314
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3598072&group_id=2435

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: gdb
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Giles (giles314)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot insert breakpoint <negative value>

Initial Comment:
Under Windows 7-64 trying to debug my application compiled with MinGW 4.7.1 I get the following result:

D:\Sources\DE>gdb Test.exe
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
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 "i686-pc-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from D:\Sources\DE\Test.exe...done.
(gdb) b DialogPanel.cpp:681
Breakpoint 1 at 0x4a8f44: file D:\Sources\DE\src\DE\Wnd\DialogPanel.cpp, line 681.
(gdb) r
Starting program: D:\Sources\DE\Test.exe
[New Thread 21320.0x7540]
BFD: C:\Windows\SysWOW64\WMVCORE.DLL: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
[New Thread 21320.0x79fc]
[New Thread 21320.0x2e18]
BFD: C:\Windows\SysWOW64\WMVCORE.DLL: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
[New Thread 21320.0x606c]
[New Thread 21320.0x8a84]
[New Thread 21320.0x7230]
[New Thread 21320.0x8050]
[New Thread 21320.0x68cc]
[New Thread 21320.0x53bc]
[New Thread 21320.0x7be0]
[New Thread 21320.0x845c]
[New Thread 21320.0x6d88]
[New Thread 21320.0x85c4]
[New Thread 21320.0x7558]
[New Thread 21320.0x69b8]
[New Thread 21320.0x79b0]
[New Thread 21320.0x1528]
BFD: C:\Windows\SysWOW64\WMVCORE.DLL: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
[New Thread 21320.0x7848]
[New Thread 21320.0x76f4]
[New Thread 21320.0x69a8]
[New Thread 21320.0x7738]
[New Thread 21320.0x2a78]
[New Thread 21320.0x6eb8]

Breakpoint 1, TDEStreamDialogPanel::DisplayDialog (this=0x86e54b0, pStreamRow=0xd171468, pTime=0, pKeySide=0x8666224,
    pLeftPreferred=0x8666220) at D:\Sources\DE\src\DE\Wnd\DialogPanel.cpp:681
681     D:\Sources\DubEdit\src\DE\Wnd\DialogPanel.cpp: No such file or directory.
(gdb) c
Continuing.

Breakpoint 1, TDEStreamDialogPanel::DisplayDialog (this=0x86e54b0, pStreamRow=0xd171468, pTime=1007, pKeySide=0x8666224,
    pLeftPreferred=0x8666220) at D:\Sources\DE\src\DE\Wnd\DialogPanel.cpp:681
681     in D:\Sources\DE\src\DE\Wnd\DialogPanel.cpp
(gdb) s
Warning:
Cannot insert breakpoint -753.
Error accessing memory address 0x61187280: Input/output error.

0x004a8f47 in TDEStreamDialogPanel::DisplayDialog (this=0x86e54b0, pStreamRow=0xd171468, pTime=1007, pKeySide=0x8666224,
    pLeftPreferred=0x8666220) at D:\Sources\DE\src\DE\Wnd\DialogPanel.cpp:681
681     in D:\Sources\DE\src\DE\Wnd\DialogPanel.cpp
(gdb) s
Warning:
Cannot insert breakpoint -758.
Error accessing memory address 0x61187280: Input/output error.

(gdb) s
Warning:
Cannot insert breakpoint -763.
Error accessing memory address 0x61187280: Input/output error.

(gdb) s
Warning:
Cannot insert breakpoint -768.
Error accessing memory address 0x61187280: Input/output error.

(gdb) s
Warning:
Cannot insert breakpoint -773.
Error accessing memory address 0x61187280: Input/output error.

(gdb)

----------------------------------------------------------------------

>Comment By: Giles (giles314)
Date: 2012-12-22 02:56

Message:
Following investigations on the issue with other versions:
Tried with same binary and previous version of GDB:
7.4 --> Same error
7.0 --> Same error
6.8 --> Cannot set the breakpoint (probable incompatibility of debug
information) but running the program raises the following error that looks
a lot like what occurs with version 7:
Error accessing memory address 0x6: Input/output error.

Assuming the problems comes from debug data that cause the debuggers to
fail I tried to recompile with different versions of MinGW (my binary was
compiled with 4.7)
4.6 --> same error
4.5 --> same error (had to remove a lot of new C++11 code to compile)
Return to the good old 4.4 version I was still using few days ago --> the
error disappears (had to remove the remaining C++11 code (constexpr) and to
bring back some missing windows header).
Note that this MinGW 4.4 is not the official one but the TDM release. But I
tried also the 4.7 release from TDM and it has the same issue as the
official 4.7.
So the problem must have been introduced somewhere in version 4.5. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=3598072&group_id=2435