[Bug c++/21932] New: -fno-unit-at-a-time causes ICE in gcc-3.4.4 on solaris2.8

2005-06-06 Thread magerman at rentec dot com
The following sequence produces an ICE in gcc-3.4.4:

$ cat > foo.C < search starts here:
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.8
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/local/include
 /work/external/wwc/prgcc/include
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/include
 /usr/include
End of search list.
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus
-fpreprocessed foo.ii -quiet -dumpbase foo.C -mcpu=v7 -auxbase foo -g -O3
-version -fno-unit-at-a-time -o foo.s
GNU C++ version 3.4.4 (sparc-sun-solaris2.8)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
foo.C: In function `void N::a()':
foo.C:5: internal compiler error: in gen_subprogram_die, at dwarf2out.c:10854
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$ cat foo.s
.file   "foo.C"
.section".debug_abbrev"
.LLdebug_abbrev0:
.section".debug_info"
.LLdebug_info0:
.section".debug_line"
.LLdebug_line0:
.section".text"
.LLtext0:
.align 4
.global _ZN1N1aEv
.type   _ZN1N1aEv, #function
.proc   020
_ZN1N1aEv:
.LLFB2:
.LLM1:
!#PROLOGUE# 0
!#PROLOGUE# 1
.LLBB2:
.LLBB3:
or  %o7, %g0, %g1
call_ZN1N1bEv, 0
 or %g1, %g0, %o7
.LLBE3:
.LLBE2:
nop
.LLFE2:
.size   _ZN1N1aEv, .-_ZN1N1aEv

Let me know if you need more information.

-- David Magerman
[EMAIL PROTECTED]

-- 
   Summary: -fno-unit-at-a-time causes ICE in gcc-3.4.4 on
solaris2.8
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: magerman at rentec dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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


[Bug c++/21939] New: Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread magerman at rentec dot com
It took me a long time to whittle this down to a small example, but here it is:

#include 
#include 
#include 

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

struct A { long x; char y; A() : x(0) {} };

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

int main(int argc, char **argv) 
{
  auto_ptr > d = foo(atoi(argv[1]));
  A a, b, c;
  for (deque::iterator i = d->begin(); i != d->end(); i++) {
std::cerr << (*i).x << std::endl;
  }
  return 0;
}

$ /work/external/wwc/bin/g++-3.4.4 -v -save-temps -Wall -fno-strict-aliasing -O2
/work/nova/6067/src/foo.C
Reading specs from 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --prefix=/work/external/wwc/prgcc
--program-suffix=-3.4.4 --enable-threads --with-included-gettext
--enable-languages=c,c++,f77 --with-gnu-as
--with-as=/work/external/wwc/prodbinu216/bin/as --with-gnu-ld
--with-ld=/work/external/wwc/prodbinu216/bin/ld : (reconfigured)
../gcc-3.4.4/configure --prefix=/work/external/wwc/prgcc --program-suffix=-3.4.4
--enable-threads --with-included-gettext --enable-languages=c,c++,f77
--with-gnu-as --with-as=/work/external/wwc/prodbinu216/bin/as --with-gnu-ld
--with-ld=/work/external/wwc/prodbinu216/bin/ld
Thread model: posix
gcc version 3.4.4
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus -E
-quiet -v /work/nova/6067/src/foo.C -mcpu=v7 -Wall -fno-strict-aliasing -O2 -o
foo.ii
ignoring nonexistent directory
"/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.8
 
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/local/include
 /work/external/wwc/prgcc/include
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/include
 /usr/include
End of search list.
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus
-fpreprocessed foo.ii -quiet -dumpbase foo.C -mcpu=v7 -auxbase foo -O2 -Wall
-version -fno-strict-aliasing -o foo.s
GNU C++ version 3.4.4 (sparc-sun-solaris2.8)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /work/external/wwc/prodbinu216/bin/as --traditional-format -V -Qy -s -xarch=v8
-o foo.o foo.s
GNU assembler version 2.16 (sparc-sun-solaris2.8) using BFD version 2.16
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crt1.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crti.o
/usr/ccs/lib/values-Xa.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtbegin.o
-L/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../.. foo.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtend.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtn.o
GNU ld version 2.16
  Supported emulations:
   elf32_sparc
   elf64_sparc

$

If I run this program with the argument greater than 64, it prints out 63 zeros,
followed by the number 513, followed by more zeros.  If I run it with the
argument 64, it does the same and then SEGVs.

This is as simple an example as I can produce.  The following simplifications
cause the program to behave properly:
1. removing the auto_ptr
2. removing the -fno-strict-aliasing
3. removing any of the unused local variables
4. moving the code from foo() into main
5. making the iterator a const_iterator
6. using -fno-unit-at-a-time
7. replacing -O2 with -O1

Please let me know if you need any more information.

-- David Magerman
[EMAIL PROTECTED]

-- 
   Summary: Corrupted memory with deque of >63 items under gcc-3.4.4
   Product: gcc
   Version: 3.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: magerman at rentec dot com
CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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


[Bug c++/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread magerman at rentec dot com

--- Additional Comments From magerman at rentec dot com  2005-06-06 21:25 
---
Created an attachment (id=9043)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9043&action=view)
the preprocessed file that triggers the bug


-- 


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


[Bug middle-end/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

2005-06-06 Thread magerman at rentec dot com

--- Additional Comments From magerman at rentec dot com  2005-06-06 22:46 
---
(In reply to comment #2)
> The last time I saw a bug like this, it was actually a bug in the person's 
> code.

I wish it were true.  We've got this code (well, a more complicated version of
it) working optimized (-O3) and unoptimized under two different compilers
(gcc-2.9.5.2 and gcc-3.2) on two different OSes (Linux and Solaris).  The
example is pretty simple and straight-forward.  It's hard to see where there can
be a bug in the code.


-- 


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