Bug 27093 - [4.2 Regression] verify_ssa failed: definition does not dominate use
Summary: [4.2 Regression] verify_ssa failed: definition does not dominate use
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: 4.2.0
Assignee: Daniel Berlin
URL:
Keywords: ice-on-valid-code
: 26771 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-04-09 14:46 UTC by Debian GCC Maintainers
Modified: 2006-05-09 08:51 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.1.0
Known to fail: 4.2.0
Last reconfirmed: 2006-05-07 18:18:00


Attachments
27093.diff (803 bytes, patch)
2006-05-04 16:57 UTC, Daniel Berlin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Debian GCC Maintainers 2006-04-09 14:46:40 UTC
[ forwarded from http://bugs.debian.org/361591 ]

falk@juist:/tmp% cat 309.c           
struct mark_entry { int num; };
void *t1(void);
int t2(int*);
void t3(int);
void g(void);

static void *f(void) {
    if (t1())
        return 0;    
    void *seen_numbers = 0;
    int bytes_left;
    if (t2(&bytes_left)) {
        if (bytes_left) {
            struct mark_entry *entry = t1();
            seen_numbers = t1();
            while (bytes_left) {
                t3(entry->num);
                entry++;
            }
        }
        t1();
    }
    return seen_numbers;
}

void g(void) {
    void *seen_numbers = f();
    if (!seen_numbers)
        t1();    
}

falk@juist:/tmp% gcc -O -c 309.c     
falk@juist:/tmp% gcc -O2 -c 309.c 
309.c: In function 'g':
309.c:26: error: definition in block 8 does not dominate use in block 11
for SSA_NAME: SMT.5_37 in statement:
SMT.5_20 = PHI <SMT.5_37(8), SMT.5_31(2), SMT.5_35(3), SMT.5_37(11)>;
PHI argument
SMT.5_37
for PHI node
SMT.5_20 = PHI <SMT.5_37(8), SMT.5_31(2), SMT.5_35(3), SMT.5_37(11)>;
309.c:26: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

I don't have 4.1 or earlier with checking enabled, so I cannot check 
whether the problem is present there.

    Falk
Comment 1 Andrew Pinski 2006-04-09 17:50:01 UTC
Confirmed, this is a regression.  There might be already a dup of this but I don't have time to find it right now.
Comment 2 Andrew Pinski 2006-05-02 07:56:58 UTC
Janis, could you do a regression hunt on this one also, testcase from comment #0 with -O2.
Thanks,
Pinski
Comment 3 Richard Biener 2006-05-02 08:04:05 UTC
    VRP causes the definition for SMT.5_37 to vanish, but it doesn't update the PHI node.  After reassoc we have:


      # SMT.5_26 = PHI <SMT.5_35(4), SMT.5_43(7), SMT.5_41(5)>;
      # bytes_left_22 = PHI <bytes_left_34(4), bytes_left_42(7), bytes_left_40(5)>;
      # seen_numbers_1 = PHI <0B(4), seen_numbers_15(7), seen_numbers_15(5)>;
    <L8>:;
      #   bytes_left_36 = V_MAY_DEF <bytes_left_22>;
      #   SMT.5_37 = V_MAY_DEF <SMT.5_26>;
      t1 ();
      if (seen_numbers_1 == 0B) goto <L0>; else goto <L1>;

    Invalid sum of incoming frequencies 9051, should be 8714
      # SMT.5_20 = PHI <SMT.5_37(8), SMT.5_31(2), SMT.5_35(3)>;
      # bytes_left_16 = PHI <bytes_left_36(8), bytes_left_30(2), bytes_left_34(3)>;
    <L0>:;
      #   bytes_left_32 = V_MAY_DEF <bytes_left_16>;
      #   SMT.5_33 = V_MAY_DEF <SMT.5_20>;
      t1 ();

    while after VRP, the def for SMT.5_37 vanished:

      # SMT.5_26 = PHI <SMT.5_35(4), SMT.5_43(7), SMT.5_41(5)>;
      # bytes_left_22 = PHI <bytes_left_34(4), bytes_left_42(7), bytes_left_40(5)>;
      # seen_numbers_1 = PHI <0B(4), seen_numbers_15(7), seen_numbers_15(5)>;
    <L8>:;
      #   bytes_left_36 = V_MAY_DEF <bytes_left_22>;
      t1 ();
      if (seen_numbers_1 == 0B) goto <L0>; else goto <L1>;

    Invalid sum of incoming frequencies 9051, should be 8714
      # SMT.5_20 = PHI <SMT.5_37(8), SMT.5_31(2), SMT.5_35(3)>;
      # bytes_left_16 = PHI <bytes_left_36(8), bytes_left_30(2), bytes_left_34(3)>;
    <L0>:;
      #   bytes_left_32 = V_MAY_DEF <bytes_left_16>;
      t1 ();

    but we didn't update the PHI node.

Comment 4 Richard Biener 2006-05-02 08:36:49 UTC
Now, this is more like caused by cfg_cleanup.  loop_optimizer_init () inserts a basic block 11, so we have

(gdb) call debug_bb_n(6)
;; basic block 6, loop depth 0, count 0
;; prev block 5, next block 7
;; pred:       5 [90.0%]  (true,exec)
;; succ:       7 [100.0%]  (fallthru,exec)
<L19>:;
entry_14 = (struct mark_entry *) D.1574_13;

(gdb) call debug_bb_n(7)
;; basic block 7, loop depth 1, count 0
;; prev block 6, next block 11
;; pred:       11 [100.0%]  (fallthru,dfs_back,exec) 6 [100.0%]  (fallthru,exec)
;; succ:       11 [90.0%]  (true,exec) 8 [10.0%]  (loop_exit,false,exec)
# SMT.5_44 = PHI <SMT.5_43(11), SMT.5_41(6)>;
# bytes_left_7 = PHI <bytes_left_42(11), bytes_left_40(6)>;
# entry_6 = PHI <entry_19(11), entry_14(6)>;
<L6>:;
D.1625_2 = (int *) entry_6;
#   VUSE <bytes_left_7>;
D.1577_18 = MEM[base: D.1625_2];
#   bytes_left_42 = V_MAY_DEF <bytes_left_7>;
#   SMT.5_43 = V_MAY_DEF <SMT.5_44>;
t3 (D.1577_18);
entry_19 = entry_6 + 4B;
#   VUSE <bytes_left_42>;
bytes_left.0_17 = bytes_left;
if (bytes_left.0_17 != 0) goto <L25>; else goto <L8>;

(gdb) call debug_bb_n(11)
;; basic block 11, loop depth 1, count 0
;; prev block 7, next block 8
;; pred:       7 [90.0%]  (true,exec)
;; succ:       7 [100.0%]  (fallthru,dfs_back,exec)
<L25>:;
goto <bb 7> (<L6>);


after VRP, cfg_cleanup removes that block again and leaves us with the broken

(gdb) call debug_bb_n(6)
;; basic block 6, loop depth 0, count 0
;; prev block 5, next block 7
;; pred:       5 [90.0%]  (true,exec)
;; succ:       7 [100.0%]  (fallthru,exec)
<L19>:;
entry_14 = (struct mark_entry *) D.1574_13;

$23 = (struct basic_block_def *) 0xb7ce6f00
(gdb) call debug_bb_n(7)
;; basic block 7, loop depth 1, count 0
;; prev block 6, next block 8
;; pred:       7 [90.0%]  (true,exec) 6 [100.0%]  (fallthru,exec)
;; succ:       7 [90.0%]  (true,exec) 8 [10.0%]  (loop_exit,false,exec)
# SMT.5_44 = PHI <SMT.5_43(7), SMT.5_41(6)>;
# bytes_left_7 = PHI <bytes_left_42(7), bytes_left_40(6)>;
# entry_6 = PHI <entry_19(7), entry_14(6)>;
<L6>:;
D.1625_2 = (int *) entry_6;
#   VUSE <bytes_left_7>;
D.1577_18 = MEM[base: D.1625_2];
#   bytes_left_42 = V_MAY_DEF <bytes_left_7>;
t3 (D.1577_18);
entry_19 = entry_6 + 4B;
#   VUSE <bytes_left_42>;
bytes_left.0_17 = bytes_left;
if (bytes_left.0_17 != 0) goto <L6>; else goto <L8>;
Comment 5 Janis Johnson 2006-05-02 23:04:14 UTC
A regression hunt on powerpc-linux using the test from comment #0 identified this patch:

    http://gcc.gnu.org/viewcvs?view=rev&rev=111608

    r111608 | dberlin | 2006-03-01 17:46:56 +0000 (Wed, 01 Mar 2006)
Comment 6 Daniel Berlin 2006-05-04 16:52:10 UTC
Grrrr. These phi nodes are all dead, but it still is verifying them anyway.

Comment 7 Daniel Berlin 2006-05-04 16:57:44 UTC
Subject: Bug 27093

This should fix it.

Comment 8 Daniel Berlin 2006-05-04 16:57:44 UTC
Created attachment 11374 [details]
27093.diff
Comment 9 Daniel Berlin 2006-05-07 18:18:00 UTC
Mine
Comment 10 Daniel Berlin 2006-05-09 01:28:55 UTC
Subject: Bug 27093

Author: dberlin
Date: Tue May  9 01:28:47 2006
New Revision: 113641

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113641
Log:
2006-05-08  Daniel Berlin  <dberlin@dberlin.org>

	Fix PR tree-optimization/27093
	* tree-ssa-alias.c (recalculate_used_alone): Mark variables for 
	renaming when they become not-used_alone.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-alias.c

Comment 11 Daniel Berlin 2006-05-09 02:08:30 UTC
Fixed
Comment 12 Volker Reichelt 2006-05-09 08:51:09 UTC
*** Bug 26771 has been marked as a duplicate of this bug. ***