[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

2006-02-28 Thread gdr at gcc dot gnu dot org 


--- Comment #9 from gdr at gcc dot gnu dot org  2006-02-28 15:47 ---
This is unlikely to be fixed for 3.4.6. 


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

2005-11-20 Thread gdr at gcc dot gnu dot org 


--- Comment #8 from gdr at gcc dot gnu dot org  2005-11-21 02:33 ---
Postponed untill GCC 3.4.6


-- 

gdr at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||gdr at gcc dot gnu dot org
   Target Milestone|3.4.5   |3.4.6


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

2005-10-27 Thread pinskia at gcc dot gnu dot org 


-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|--- |3.4.5


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

2005-06-10 Thread magerman at rentec dot com 

--- Additional Comments From magerman at rentec dot com  2005-06-10 18:29 
---
On sun-sparc-solaris2.8:

Compiling with -fno-gcse eliminates the problem for both sample programs.

Compiling with -fno-gcse-las eliminates the problem for both sample programs.

Compiling with -fno-gcse-lm causes the original program to infinite loop.

Compiling with -fno-gcse-lm causes Wolfgang Wander's program to always go
one entry past the end of the list, i.e. ./runtest 3 produces the following
output:
  0x22570 0x22588 3
  0 0 v=0x22570 cur=0x22570 first=0x22570 last=0x22770 node=0x21b7c
  0 1 v=0x22578 cur=0x22578 first=0x22570 last=0x22770 node=0x21b7c
  0 2 v=0x22580 cur=0x22580 first=0x22570 last=0x22770 node=0x21b7c
  0 0 v=0x22588 cur=0x22588 first=0x22570 last=0x22770 node=0x21b7c

-- 


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

2005-06-07 Thread fuzzypoint at yahoo dot com 

--- Additional Comments From fuzzypoint at yahoo dot com  2005-06-07 22:19 
---
(In reply to comment #5)
> Yup, segfaults for 64 on x86-64 too with 3.4.5pre:
> 
> Program received signal SIGSEGV, Segmentation fault.
> main (argc=-1781549440, argv=0x0) at stl_deque.h:134
> 134   { return *_M_cur; }
> 

I'm having similar trouble in x86_64 as well.
Tried the above sample on x86_64 and can confirm.  
I modified the program above
a bit and it seems like deque::operator++ is at fault (or badly compiled).

First the modified sample program

#include 
#include 
#include 

using std::deque;
using std::auto_ptr;

static char c = 0;
struct A { long x; char y; A() : x(0),y(c++) {} };

auto_ptr > foo(int l){
  auto_ptr > d(new deque);
  for (int i=0; ipush_back(A());
  return d;
}

struct v { void *a, *b, *c, *d; };

void foo();

int main(int argc, char **argv) 
{
  auto_ptr > d = foo(atoi(argv[1]));
  A a;
  std::cerr << &*d->begin() << " " << &*d->end() << " "
<< &*d->end()-&*d->begin() << std::endl;
  for (deque::iterator i = d->begin(); i != d->end(); ++i) {
std::cerr << i->x << ' ' << (int)i->y
  << " v=" << &*i  
  << " cur=" << ((v*)&i)->a 
  << " first=" << ((v*)&i)->b 
  << " last=" << ((v*)&i)->c 
  << " node=" << ((v*)&i)->d 
  << std::endl;
if( i->y == 31 )
  foo();
  }
  return 0;
}

void foo() { std::cerr << "faulty ++ is next" << std::endl;}
-

compiled on x86_64 with g++-3.4.4 -O2 -fno-strict-aliasing I get
$ ./runtest 32
0x6007c0 0x6009d0 33
0 0 v=0x6007c0 cur=0x6007c0 first=0x6007c0 last=0x6009c0 node=0x600788
0 1 v=0x6007d0 cur=0x6007d0 first=0x6007c0 last=0x6009c0 node=0x600788
0 2 v=0x6007e0 cur=0x6007e0 first=0x6007c0 last=0x6009c0 node=0x600788
[...]
0 30 v=0x6009a0 cur=0x6009a0 first=0x6007c0 last=0x6009c0 node=0x600788
0 31 v=0x6009b0 cur=0x6009b0 first=0x6007c0 last=0x6009c0 node=0x600788
faulty ++ is next
0 0 v=0x6009c0 cur=0x6009d0 first=0x6009d0 last=0x600bd0 node=0x600790
0 0 v=0x6009e0 cur=0x6009e0 first=0x6009d0 last=0x600bd0 node=0x600790
[...]
0 0 v=0x600bc0 cur=0x600bc0 first=0x6009d0 last=0x600bd0 node=0x600790
0 Segmentation fault


Looks like operator++ somehow jumps over d->end() and continues counting.

Without -fno-strict-aliasing everything seems just fine:

$ ./runtest 32
0x6007c0 0x6009d0 33
0 0 v=0x6007c0 cur=0x6007c0 first=0x6007c0 last=0x6009c0 node=0x600788
0 1 v=0x6007d0 cur=0x6007d0 first=0x6007c0 last=0x6009c0 node=0x600788
[...]
0 30 v=0x6009a0 cur=0x6009a0 first=0x6007c0 last=0x6009c0 node=0x600788
0 31 v=0x6009b0 cur=0x6009b0 first=0x6007c0 last=0x6009c0 node=0x600788
faulty ++ is next

Seems to me like _M_cur = _M_first is forgotten (or evaluated too late?) in
std::deque::operator++()

stl_deque.h:140
  _Self&
  operator++()
  {
++_M_cur;
if (_M_cur == _M_last)
  {
_M_set_node(_M_node + 1);
_M_cur = _M_first;
  }
return *this;
  }


-- 


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

2005-06-06 Thread ebotcazou at gcc dot gnu dot org 

--- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-06-07 
06:46 ---
Yup, segfaults for 64 on x86-64 too with 3.4.5pre:

Program received signal SIGSEGV, Segmentation fault.
main (argc=-1781549440, argv=0x0) at stl_deque.h:134
134   { return *_M_cur; }


-- 
   What|Removed |Added

 CC||ebotcazou at gcc dot gnu dot
   ||org
 Status|UNCONFIRMED |NEW
 Ever Confirmed||1
  GCC build triplet|sparc-sun-solaris2.8|
   GCC host triplet|sparc-sun-solaris2.8|
 GCC target triplet|sparc-sun-solaris2.8|
  Known to fail||3.4.5
  Known to work||3.3.2 4.0.0 4.1.0
   Last reconfirmed|-00-00 00:00:00 |2005-06-07 06:46:35
   date||
Summary|Corrupted memory with deque |[3.4 Regression] corrupted
   |of >63 items under gcc-3.4.4|memory with deque of >63
   ||items


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