User account creation filtered due to spam.

Bug 19217 - [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit not set
Summary: [4.0 Regression] ICE: verify_stmts failed: address taken, but ADDRESSABLE bit...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Not yet assigned to anyone
URL:
Keywords: alias, ice-checking, ice-on-valid-code, patch
Depends on:
Blocks:
 
Reported: 2005-01-01 06:55 UTC by Andreas Jaeger
Modified: 2005-02-01 22:51 UTC (History)
4 users (show)

See Also:
Host: i586-pc-linux-gnu
Target: i586-pc-linux-gnu
Build: i586-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2005-02-01 09:38:01


Attachments
Preprocessed source file (37.16 KB, application/octet-stream)
2005-01-01 06:56 UTC, Andreas Jaeger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Jaeger 2005-01-01 06:55:48 UTC
I received the following ICE with current GCC CVS: 
 
$ /usr/lib/gcc/i586-suse-linux/4.0.0/cc1 -fpreprocessed splinesave.i -quiet 
-dumpbase splinesave.c -march=i686 -mtune=i686 -auxbase-strip splinesave.o -O2 
-Wall-Wmissing-prototypes -Wunused -Wimplicit -Wreturn-type -Wparentheses 
-Wformat -Wchar-subscripts -version -fmessage-length=0 -fno-strict-aliasing -o 
splinesave.s 
GNU C version 4.0.0 20041231 (experimental) (SUSE Linux) (i586-suse-linux) 
        compiled by GNU C version 4.0.0 20041231 (experimental) (SUSE Linux). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
splinesave.c: In function ?NumberHints?: 
splinesave.c:92: warning: ?i? may be used uninitialized in this function 
splinesave.c: In function ?_CvtPsSplineSet?: 
splinesave.c:862: error: address taken, but ADDRESSABLE bit not set 
temp3D.13981 
 
splinesave.c:862: internal compiler error: verify_stmts failed. 
Please submit a full bug report, 
with preprocessed source if appropriate. 
 
I reduced the testcase a little bit and get on Linux/x86-64 with -m32 the 
following additional information: 
(gdb) r -m32 -fpreprocessed splinesave.i -quiet -dumpbase splinesave.c 
-march=i686 -mtune=i686 -auxbase-strip splinesave.o -O2 -Wall 
-Wmissing-prototypes -Wunused -Wimplicit -Wreturn-type -Wparentheses -Wformat 
-Wchar-subscripts -version -fmessage-length=0 -fno-strict-aliasing -o 
splinesave.s 
GNU C version 4.0.0 20041231 (experimental) (x86_64-suse-linux-gnu) 
        compiled by GNU C version 4.0.0 20041231 (experimental). 
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 
splinesave.i: In function ?_CvtPsSplineSet?: 
splinesave.i:6402: error: address taken, but ADDRESSABLE bit not set 
temp3D.12084 
 
 
Breakpoint 2, internal_error (msgid=0x850fdd "verify_stmts failed.") 
    at /cvs/gcc/gcc/diagnostic.c:496 
496     { 
(gdb) bt 
#0  internal_error (msgid=0x850fdd "verify_stmts failed.") 
    at /cvs/gcc/gcc/diagnostic.c:496 
#1  0x000000000046b1ae in verify_stmts () at /cvs/gcc/gcc/tree-cfg.c:3547 
#2  0x00000000004f242b in tree_ssa_iv_optimize (loops=0xb7e1d0) 
    at /cvs/gcc/gcc/tree-ssa-loop-ivopts.c:5155 
#3  0x000000000047bc46 in execute_pass_list (pass=0xa72d80) 
    at /cvs/gcc/gcc/tree-optimize.c:525 
#4  0x000000000047bcdb in execute_pass_list (pass=0xa730e0) 
    at /cvs/gcc/gcc/tree-optimize.c:563 
#5  0x000000000047bcdb in execute_pass_list (pass=0xa6e0c0) 
    at /cvs/gcc/gcc/tree-optimize.c:563 
#6  0x000000000047bf39 in tree_rest_of_compilation (fndecl=0x2a95a76b60) 
    at /cvs/gcc/gcc/tree-optimize.c:661 
#7  0x0000000000419c73 in c_expand_body (fndecl=0x2a95a76b60) 
    at /cvs/gcc/gcc/c-decl.c:6383 
#8  0x000000000078af50 in cgraph_expand_function (node=0x2a95a7b000) 
    at /cvs/gcc/gcc/cgraphunit.c:822 
#9  0x000000000078c5b1 in cgraph_optimize () at /cvs/gcc/gcc/cgraphunit.c:1689 
#10 0x00000000007381b1 in toplev_main (argc=Variable "argc" is not available. 
) at /cvs/gcc/gcc/toplev.c:1005 
#11 0x0000002a9568900d in __libc_start_main () from /lib64/tls/libc.so.6 
#12 0x00000000004025ea in _start () at start.S:113
Comment 1 Andreas Jaeger 2005-01-01 06:56:37 UTC
Created attachment 7857 [details]
Preprocessed source file
Comment 2 Andrew Pinski 2005-01-01 07:28:16 UTC
Confirmed, reduced testcase:
void flexto(int *current,int instance_count)
{
  int *end, temp, j;
  for ( j=0; j<instance_count; ++j )
    end = &temp;
  *current = *end;
}
Comment 3 Andrew Pinski 2005-01-01 07:38:48 UTC
(In reply to comment #2)
> Confirmed, reduced testcase:
> void flexto(int *current,int instance_count)
> {
>   int *end, temp, j;
>   for ( j=0; j<instance_count; ++j )
>     end = &temp;
>   *current = *end;
> }

Just a note, this is broken before the loop optimizations are run and it looks like it was caused by (my 
patch):
2004-11-30  Andrew Pinski  <pinskia@physics.uc.edu>

        PR tree-opt/18298
        * tree-optimize.c (init_tree_optimization_passes): Add a may_alias
        pass right after fold builtins.

But It just exposes a latent bug in may_alias as we don't keep temp marked as a non gimple register 
even though the variable has its address taken still  (yes adding a dce pass right before may_alias will 
work around the problem but that does not fix the other problem, we should be able to call may_alias 
even without calling dce).
Comment 4 Andrew Pinski 2005-01-01 07:53:38 UTC
(In reply to comment #3)
One more note, this does not happen on the tcb but that is because we call dce after the first ccp and 
before the next may_alias.
Comment 5 Andrew Pinski 2005-01-01 15:31:06 UTC
I think the problem is that we don't see the the address taken at all because we don't walk over the PHI 
nodes in compute_points_to_and_addr_escape so when we have dead code in PHIs we miss them.
Note this comment is wrong with respect with dead code:
	  /* Mark all the variables whose address are taken by the
	     statement.  Note that this will miss all the addresses taken
	     in PHI nodes (those are discovered while following the use-def
	     chains).  */
Comment 6 Andrew Pinski 2005-01-01 15:44:23 UTC
You can see the problem with this testcase (but we don't ICE because we only call verify_stmts in IV-
OPTS :( ):
void flexto(int *current,int instance_count)
{
  int *end, temp, j;
  if (0<instance_count)
    end = &temp;
  *current = *end;
} 
Comment 7 Andrew Pinski 2005-01-04 15:48:46 UTC
: Search converges between 2004-11-30-014001-trunk (#665) and 2004-12-01-014001-trunk 
(#666).
Comment 8 Steven Bosscher 2005-01-24 09:51:39 UTC
I cannot reproduce this with the original test case and yesterday's 
CVS HEAD. 
 
Comment 9 Andrew Pinski 2005-01-24 13:24:09 UTC
(In reply to comment #8)
> I cannot reproduce this with the original test case and yesterday's 
> CVS HEAD. 
Did you use --disable-checking (please look at the keywords)?
Comment 10 Steven Bosscher 2005-01-24 13:43:27 UTC
This should be a checking compiler, or at least I didn't disable checking 
explicitly.  I did use a non-gcc to build it, perhaps that turned off 
checking... 
 
Comment 11 Steven Bosscher 2005-02-01 09:37:59 UTC
Neh, still there.  I forgot to add the proper flags to the test case 
(which runs in a DejaGNU framework on my home box along with other PR 
test cases).  Still a problem, so reconfirming. 
Comment 12 Steven Bosscher 2005-02-01 11:35:20 UTC
I think we should just not do this non-statement-related check in 
verify_stmts.  Patch posted for that: 
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00049.html 
Comment 13 CVS Commits 2005-02-01 22:50:40 UTC
Subject: Bug 19217

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	steven@gcc.gnu.org	2005-02-01 22:50:21

Modified files:
	gcc            : ChangeLog tree-cfg.c 

Log message:
	PR tree-optimization/19217
	* tree-cfg.c (verify_expr): Use the data field to see if TP was
	seen inside a PHI node.  Do not do the ADDR_EXPR check if it was.
	(verify_stmts): Pass (void*)1 as data to verify_expr to signal
	that it is walking a PHI node.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.7368&r2=2.7369
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.147&r2=2.148

Comment 14 Steven Bosscher 2005-02-01 22:51:22 UTC
.