Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
On Thu, 14 Apr 2005, Dale Johannesen wrote: On Apr 14, 2005, at 7:14 AM, Andrew Pinski wrote: Does this bug look familiar? 20629 is ICEing in the same spot, but it looks like theirs was reproducible after preprocessing. Is there any more information that I provide that would be helpful? I've attached the command line, specs and a stacktrace from cc1plus. I think this was fixed on the mainline by: 2005-03-18 Dale Johannese [EMAIL PROTECTED] * cp/tree.c (cp_tree_equal): Handle SSA_NAME. Yep, and I didn't put it in the release branch. Bad Dale. OK to do that? If this is the same problem, changing the VN hashtable size to 1 should make it show up reproducibly. The released 4.0.0 successfully compiles the code that was having problems before. -nick
re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
Nick Rasmussen [EMAIL PROTECTED] wrote: I'm running into an ICE in the prerelease, that is proving to be very difficult in reducing to a small testcase. If I preprocess the source (via -E or -save-temps) the code successfully compiles. ... Does this bug look familiar? 20629 is ICEing in the same spot, but it looks like theirs was reproducible after preprocessing. Comment #4 in http://gcc.gnu.org/PR20629 makes it looks like they had the same sort of trouble reproducing from preprocessed source: I'm still seeing this, but some info... a) I'm only seeing this with LANG=C, export LANG=en_US.UTF-8 and there is no crash b) compiling the dumped proprocessed code isn't crashing in either LANG So maybe you are in fact running into the same issue. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
On Apr 13, 2005, at 9:25 PM, Nick Rasmussen wrote: I'm running into an ICE in the prerelease, that is proving to be very difficult in reducing to a small testcase. If I preprocess the source (via -E or -save-temps) the code successfully compiles. If I minimally change the source file in some ways(like adding a static integer in the global scope) the code compiles. I've been able to delete some lines from the source file that's triggering the bug, including some from within the function that is triggering the ICE, but I'm down to a point where I can't easily reduce it further, or even get it into a single source file. Does this bug look familiar? 20629 is ICEing in the same spot, but it looks like theirs was reproducible after preprocessing. Is there any more information that I provide that would be helpful? I've attached the command line, specs and a stacktrace from cc1plus. I think this was fixed on the mainline by: 2005-03-18 Dale Johannese [EMAIL PROTECTED] * cp/tree.c (cp_tree_equal): Handle SSA_NAME. -- Pinski
Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
On Apr 14, 2005, at 7:14 AM, Andrew Pinski wrote: Does this bug look familiar? 20629 is ICEing in the same spot, but it looks like theirs was reproducible after preprocessing. Is there any more information that I provide that would be helpful? I've attached the command line, specs and a stacktrace from cc1plus. I think this was fixed on the mainline by: 2005-03-18 Dale Johannese [EMAIL PROTECTED] * cp/tree.c (cp_tree_equal): Handle SSA_NAME. Yep, and I didn't put it in the release branch. Bad Dale. OK to do that? If this is the same problem, changing the VN hashtable size to 1 should make it show up reproducibly.
Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
Hi, On Wed, 13 Apr 2005, Nick Rasmussen wrote: I'm running into an ICE in the prerelease, that is proving to be very difficult in reducing to a small testcase. If I preprocess the source (via -E or -save-temps) the code successfully compiles. If I minimally change the source file in some ways(like adding a static integer in the global scope) the code compiles. I've been able to delete some lines from the source file that's triggering the bug, including some from within the function that is triggering the ICE, but I'm down to a point where I can't easily reduce it further, or even get it into a single source file. If possible you could tar eveything needed together with a small Makefile, for others to look at. Otherwise it's will be difficult. You can also compile cc1plus with debugging (just do a make CFLAGS=-g after configuring gcc, no bootstrap), and try to come up with some more info yourself. For instance by printing the two trees which are impossible, by going to the cp_tree_equal frame and doing (gdb) p debug_tree(t1) in gdb (and for t2). /dept/rnd/vendor/gcc-4.0.0pre1-amd64/bin/g++ -fno-builtin -O2 -g -DHAVE_X86_64 -DHAVE_LITTLE_ENDIAN -DHAVE_BYTESWAP_H -DHAVE_64BIT_POINTER -DHAVE_VA_COPY -DHAVE_XINERAMA -DPLATFORM_LINUX -D_FILE_OFFSET_BITS=64 -DHAVE_STL_LIMITS -DHAVE_IOS_BASE -Drestrict=__restrict__ -DPLATFORM_LINUX_AMD64 -DPLATFORM=LINUX_AMD64 -DBUILD=LINUX_AMD64_GCC400pre1_OPT_DEBUG -DDISTRO_SUSE -DDISTRO=SUSE -DDISTRO_VERSION=91 -DNVIDIA_VERSION_6111 -DNVIDIA_VERSION=6111 -DGCC_VERSION_400pre1 -DNDEBUG -I/usr/share/doc/NVIDIA_GLX-1.0/include -I. -I/dept/rnd/home/nick/work/build-zeno2/SUSE_AMD64_GCC400pre1_OPT_DEBUG/include -I/usr/X11R6/include -c bug.C -o /dev/null bug.C: In member function 'void EzFleshMesh::buildNodeArrays()': bug.C:411: internal compiler error: in cp_tree_equal, at cp/tree.c:1552 And give the context of that line. Although it more seems like overwriting memory inside the compiler or something like this, as otherwise it would be more deterministic. #2 0x00473171 in cp_tree_equal (t1=0x2a9a1c94b0, t2=0x2a9a1cbb90) at ../../gcc-4.0.0-20050410/gcc/cp/tree.c:1552 #3 0x00473198 in cp_tree_equal (t1=0x2a9a013820, t2=0x2a9a031460) at ../../gcc-4.0.0-20050410/gcc/cp/tree.c:1543 #4 0x004590b3 in comptypes (t1=0x2a9a00ea90, t2=0x2a9a02bdd0, strict=Variable strict is not available. ) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:912 #5 0x00458ede in comptypes (t1=0x2a9a00ec30, t2=0x2a9a032000, strict=0) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:1034 #6 0x0047b0b9 in cxx_types_compatible_p (x=0x2a9a00ec30, y=0x2a9a032000) at ../../gcc-4.0.0-20050410/gcc/cp/cp-objcp-common.c:173 #7 0x007776bd in expressions_equal_p (e1=0x2a9a1c9640, e2=0x2a9a1cbd20) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:127 #8 0x007776f7 in val_expr_pair_expr_eq (p1=0xc16b90, p2=0xcd25e0) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:153 #9 0x007ffcba in htab_find_slot_with_hash (htab=0xca98a0, element=0x81c3b9, hash=8504885, insert=INSERT) at ../../gcc-4.0.0-20050410/libiberty/hashtab.c:660 #10 0x0077794f in vn_add (expr=0x2a9a1cbd20, val=0x2a9a240330, vuses=0x0) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:199 #11 0x004e09c1 in execute_pre (do_fre=0 '\0') at ../../gcc-4.0.0-20050410/gcc/tree-ssa-pre.c:1742 So PRE is trying to compare two types, and they contains something which can't be handled. Either because they were silently overwritten, or because of a logical error. Ciao, Michael.
