public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* java/io/natFile.cc:106: internal compiler error: verify_ssa failed. @ 2004-09-05 14:31 Graham Stott 2004-09-05 14:50 ` Diego Novillo 0 siblings, 1 reply; 12+ messages in thread From: Graham Stott @ 2004-09-05 14:31 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc-bugs Hi Diego, This is usually your area Todays bootstrap on i686-pc-linux-gnu gives: java/io/natFile.cc: In member function `virtual java::lang::String* java::io::File::getCanonicalPath()': java/io/natFile.cc:106: error: Definition in block 34 does not dominate use in block 9 for SSA_NAME: T.1719<D12968>_164 in statement: T.1731<D12980>_179 = buf<D12297>_27 + T.1719<D12968>_164; java/io/natFile.cc:106: internal compiler error: verify_ssa failed. Note bootstrap done with the new tree_if_conversion pass disabled Graham ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-05 14:31 java/io/natFile.cc:106: internal compiler error: verify_ssa failed Graham Stott @ 2004-09-05 14:50 ` Diego Novillo 2004-09-05 15:11 ` Graham Stott 0 siblings, 1 reply; 12+ messages in thread From: Diego Novillo @ 2004-09-05 14:50 UTC (permalink / raw) To: Graham Stott; +Cc: gcc-bugs On Sun, 2004-09-05 at 10:30, Graham Stott wrote: > java/io/natFile.cc: In member function `virtual java::lang::String* java::io::File::getCanonicalPath()': > java/io/natFile.cc:106: error: Definition in block 34 does not dominate use in block 9 > for SSA_NAME: T.1719<D12968>_164 > in statement: > T.1731<D12980>_179 = buf<D12297>_27 + T.1719<D12968>_164; > > java/io/natFile.cc:106: internal compiler error: verify_ssa failed. > I don't even get that far. libjava fails in add_standard_iv_candidates. See http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00523.html Can you reproduce this with -fno-ivopts? This is typically the result of a motion pass that didn't check everything it had to check. To discover it, - Set a breakpoint at the verifier's - See which pass is triggering it (go up a few stack frames) - Diff pass - 1 and pass and grep for T.1719_164 Diego. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-05 14:50 ` Diego Novillo @ 2004-09-05 15:11 ` Graham Stott 2004-09-05 17:18 ` Graham Stott 0 siblings, 1 reply; 12+ messages in thread From: Graham Stott @ 2004-09-05 15:11 UTC (permalink / raw) To: Diego Novillo; +Cc: gcc-bugs Diego Novillo wrote: > On Sun, 2004-09-05 at 10:30, Graham Stott wrote: > > >>java/io/natFile.cc: In member function `virtual java::lang::String* java::io::File::getCanonicalPath()': >>java/io/natFile.cc:106: error: Definition in block 34 does not dominate use in block 9 >>for SSA_NAME: T.1719<D12968>_164 >>in statement: >>T.1731<D12980>_179 = buf<D12297>_27 + T.1719<D12968>_164; >> >>java/io/natFile.cc:106: internal compiler error: verify_ssa failed. >> > > I don't even get that far. libjava fails in > add_standard_iv_candidates. See > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00523.html I'm not sure how my bootstrap manages to get passed that failure. > > Can you reproduce this with -fno-ivopts? I'll see what happens > > This is typically the result of a motion pass that didn't check > everything it had to check. To discover it, > > - Set a breakpoint at the verifier's > - See which pass is triggering it (go up a few stack frames) > - Diff pass - 1 and pass and grep for T.1719_164 > > Diego. > > Graham ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-05 15:11 ` Graham Stott @ 2004-09-05 17:18 ` Graham Stott 2004-09-05 17:54 ` Diego Novillo 0 siblings, 1 reply; 12+ messages in thread From: Graham Stott @ 2004-09-05 17:18 UTC (permalink / raw) To: Graham Stott; +Cc: Diego Novillo, gcc-bugs Diego, > Diego Novillo wrote: > >> Can you reproduce this with -fno-ivopts? > no it compiles fine with -fno-ivopts Graham ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-05 17:18 ` Graham Stott @ 2004-09-05 17:54 ` Diego Novillo 2004-09-05 18:22 ` Daniel Berlin 2004-09-06 8:47 ` Jan Hubicka 0 siblings, 2 replies; 12+ messages in thread From: Diego Novillo @ 2004-09-05 17:54 UTC (permalink / raw) To: Graham Stott; +Cc: gcc-bugs, Zdenek Dvorak, Jan Hubicka On Sun, 2004-09-05 at 13:18, Graham Stott wrote: > Diego, > > > Diego Novillo wrote: > > > >> Can you reproduce this with -fno-ivopts? > > > no it compiles fine with -fno-ivopts > Then Zdenek needs to fix this problem as well. Honza, since Zdenek is out could you please take care of this problem and the other one I reported earlier today? http://gcc.gnu.org/ml/gcc-bugs/2004-09/msg00419.html http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00523.html Thanks. Diego. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-05 17:54 ` Diego Novillo @ 2004-09-05 18:22 ` Daniel Berlin 2004-09-11 11:45 ` Zdenek Dvorak 2004-09-06 8:47 ` Jan Hubicka 1 sibling, 1 reply; 12+ messages in thread From: Daniel Berlin @ 2004-09-05 18:22 UTC (permalink / raw) To: Diego Novillo; +Cc: Graham Stott, gcc-bugs, Zdenek Dvorak, Jan Hubicka On Sun, 2004-09-05 at 13:54 -0400, Diego Novillo wrote: > On Sun, 2004-09-05 at 13:18, Graham Stott wrote: > > Diego, > > > > > Diego Novillo wrote: > > > > > >> Can you reproduce this with -fno-ivopts? > > > > > no it compiles fine with -fno-ivopts > > > Then Zdenek needs to fix this problem as well. Honza, since Zdenek is > out could you please take care of this problem and the other one I > reported earlier today? > > http://gcc.gnu.org/ml/gcc-bugs/2004-09/msg00419.html > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00523.html > While you are around there, can you rename it to tree-loop-ivopts? (I have no idea why zdenek keeps naming switches in ways that are completely different than how we've been naming them :P). > > Thanks. Diego. > -- ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-05 18:22 ` Daniel Berlin @ 2004-09-11 11:45 ` Zdenek Dvorak 2004-09-11 11:54 ` Daniel Berlin 0 siblings, 1 reply; 12+ messages in thread From: Zdenek Dvorak @ 2004-09-11 11:45 UTC (permalink / raw) To: Daniel Berlin; +Cc: Diego Novillo, Graham Stott, gcc-bugs, Jan Hubicka Hello, > While you are around there, can you rename it to tree-loop-ivopts? > > (I have no idea why zdenek keeps naming switches in ways that are > completely different than how we've been naming them :P). since I do not like the convention. At least the tree- prefix is completely useless. The switches are here for users, and I do not see any reason for users to be aware of on what infrastructure a given pass runs. I am fairly sure that 99% of users will not know what the tree- prefix signifies, anyway. Zdenek ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-11 11:45 ` Zdenek Dvorak @ 2004-09-11 11:54 ` Daniel Berlin 2004-09-11 11:58 ` Zdenek Dvorak 0 siblings, 1 reply; 12+ messages in thread From: Daniel Berlin @ 2004-09-11 11:54 UTC (permalink / raw) To: Zdenek Dvorak; +Cc: Diego Novillo, Graham Stott, gcc-bugs, Jan Hubicka On Sat, 11 Sep 2004, Zdenek Dvorak wrote: > Hello, > >> While you are around there, can you rename it to tree-loop-ivopts? >> >> (I have no idea why zdenek keeps naming switches in ways that are >> completely different than how we've been naming them :P). > > since I do not like the convention. This is not a good reason. If you want to convert *all* the switches, do so. If not, the new switches should be consistent with the old ones. Understand that I could care less whether it's -fivopts or -fivcanon. I care that it's not consistent with the existing options. Being consistent in our interface to the user is important. Simply because you don't like the existing convention doesn't mean you should just start using your own. --Dan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-11 11:54 ` Daniel Berlin @ 2004-09-11 11:58 ` Zdenek Dvorak 2004-09-11 12:02 ` Daniel Berlin 0 siblings, 1 reply; 12+ messages in thread From: Zdenek Dvorak @ 2004-09-11 11:58 UTC (permalink / raw) To: Daniel Berlin; +Cc: Diego Novillo, Graham Stott, gcc-bugs, Jan Hubicka Hello, > >>While you are around there, can you rename it to tree-loop-ivopts? > >> > >>(I have no idea why zdenek keeps naming switches in ways that are > >>completely different than how we've been naming them :P). > > > >since I do not like the convention. > > This is not a good reason. > > If you want to convert *all* the switches, do so. > If not, the new switches should be consistent with the old ones. > > Understand that I could care less whether it's -fivopts or -fivcanon. I > care that it's not consistent with the existing options. > > Being consistent in our interface to the user is important. > Simply because you don't like the existing convention doesn't mean you > should just start using your own. should not this remark apply to the first person creating a -ftree-anything switch? I just (unlike this first person) stick with the older convention that there is no such convention and everyone just names the switches the way he likes :-). Zdenek ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-11 11:58 ` Zdenek Dvorak @ 2004-09-11 12:02 ` Daniel Berlin 0 siblings, 0 replies; 12+ messages in thread From: Daniel Berlin @ 2004-09-11 12:02 UTC (permalink / raw) To: Zdenek Dvorak; +Cc: Diego Novillo, Graham Stott, gcc-bugs, Jan Hubicka On Sat, 11 Sep 2004, Zdenek Dvorak wrote: > Hello, > >>>> While you are around there, can you rename it to tree-loop-ivopts? >>>> >>>> (I have no idea why zdenek keeps naming switches in ways that are >>>> completely different than how we've been naming them :P). >>> >>> since I do not like the convention. >> >> This is not a good reason. >> >> If you want to convert *all* the switches, do so. >> If not, the new switches should be consistent with the old ones. >> >> Understand that I could care less whether it's -fivopts or -fivcanon. I >> care that it's not consistent with the existing options. >> >> Being consistent in our interface to the user is important. >> Simply because you don't like the existing convention doesn't mean you >> should just start using your own. > > should not this remark apply to the first person creating a > -ftree-anything switch? Unlike what you are doing, this was actually discussed on the mailing list. If you look at the archives, you'll see there was a discussion about what to name the tree optimization options. > the older convention that there is no such convention and everyone just > names the switches the way he likes :-). Sigh. > > Zdenek > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-05 17:54 ` Diego Novillo 2004-09-05 18:22 ` Daniel Berlin @ 2004-09-06 8:47 ` Jan Hubicka 2004-09-06 12:21 ` Jan Hubicka 1 sibling, 1 reply; 12+ messages in thread From: Jan Hubicka @ 2004-09-06 8:47 UTC (permalink / raw) To: Diego Novillo; +Cc: Graham Stott, gcc-bugs, Zdenek Dvorak, Jan Hubicka > On Sun, 2004-09-05 at 13:18, Graham Stott wrote: > > Diego, > > > > > Diego Novillo wrote: > > > > > >> Can you reproduce this with -fno-ivopts? > > > > > no it compiles fine with -fno-ivopts > > > Then Zdenek needs to fix this problem as well. Honza, since Zdenek is > out could you please take care of this problem and the other one I > reported earlier today? > > http://gcc.gnu.org/ml/gcc-bugs/2004-09/msg00419.html > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00523.html Yes, I am looking into it. Honza > > > Thanks. Diego. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed. 2004-09-06 8:47 ` Jan Hubicka @ 2004-09-06 12:21 ` Jan Hubicka 0 siblings, 0 replies; 12+ messages in thread From: Jan Hubicka @ 2004-09-06 12:21 UTC (permalink / raw) To: Jan Hubicka; +Cc: Diego Novillo, Graham Stott, gcc-bugs, Zdenek Dvorak > > On Sun, 2004-09-05 at 13:18, Graham Stott wrote: > > > Diego, > > > > > > > Diego Novillo wrote: > > > > > > > >> Can you reproduce this with -fno-ivopts? > > > > > > > no it compiles fine with -fno-ivopts > > > > > Then Zdenek needs to fix this problem as well. Honza, since Zdenek is > > out could you please take care of this problem and the other one I > > reported earlier today? > > > > http://gcc.gnu.org/ml/gcc-bugs/2004-09/msg00419.html > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00523.html > > Yes, I am looking into it. Hi, I am testing the attached patch. So far I found two problems: Java does not initialize the unsigned_type_node but it seems to be sanier to not use the frontend types anyway so I repleaced them with intSI/intDI nodes. Other problem is in cost computing code that needs to put in fake DECL_RTL in order to expand the expression and compute the cost. THe failing case is when address is taken of something and Zdenek just puts in the DECL_RTL. I intend to commit the patches if the testing suceeds to unbreak the bootstrap but I will send proper email to patches list about this. This is just in case someone sees something obvious with it. Index: tree-ssa-loop-ivopts.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/tree-ssa-loop-ivopts.c,v retrieving revision 2.2 diff -c -3 -p -r2.2 tree-ssa-loop-ivopts.c *** tree-ssa-loop-ivopts.c 5 Sep 2004 15:24:15 -0000 2.2 --- tree-ssa-loop-ivopts.c 6 Sep 2004 12:15:37 -0000 *************** add_standard_iv_candidates (struct ivopt *** 1561,1574 **** { /* Add 0 + 1 * iteration candidate. */ add_candidate (data, ! fold_convert (unsigned_type_node, integer_zero_node), ! fold_convert (unsigned_type_node, integer_one_node), true, NULL); /* The same for a long type. */ add_candidate (data, ! fold_convert (long_unsigned_type_node, integer_zero_node), ! fold_convert (long_unsigned_type_node, integer_one_node), true, NULL); } --- 1561,1574 ---- { /* Add 0 + 1 * iteration candidate. */ add_candidate (data, ! fold_convert (unsigned_intSI_type_node, integer_zero_node), ! fold_convert (unsigned_intSI_type_node, integer_one_node), true, NULL); /* The same for a long type. */ add_candidate (data, ! fold_convert (unsigned_intDI_type_node, integer_zero_node), ! fold_convert (unsigned_intDI_type_node, integer_one_node), true, NULL); } *************** seq_cost (rtx seq) *** 1883,1888 **** --- 1883,1906 ---- return cost; } + /* Produce DECL_RTL for object obj so it looks like it is stored in memory. */ + static rtx + produce_memory_decl_rtl (tree obj, int *regno) + { + rtx x; + if (!obj) + abort (); + if (TREE_STATIC (obj) || DECL_EXTERNAL (obj)) + { + const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (obj)); + x = gen_rtx_SYMBOL_REF (Pmode, name); + } + else + x = gen_raw_REG (Pmode, (*regno)++); + + return gen_rtx_MEM (DECL_MODE (obj), x); + } + /* Prepares decl_rtl for variables referred in *EXPR_P. Callback for walk_tree. DATA contains the actual fake register number. */ *************** prepare_decl_rtl (tree *expr_p, int *ws, *** 1895,1900 **** --- 1913,1929 ---- switch (TREE_CODE (*expr_p)) { + case ADDR_EXPR: + for (expr_p = &TREE_OPERAND (*expr_p, 0); + (handled_component_p (*expr_p) + || TREE_CODE (*expr_p) == REALPART_EXPR + || TREE_CODE (*expr_p) == IMAGPART_EXPR); + expr_p = &TREE_OPERAND (*expr_p, 0)); + obj = *expr_p; + if (DECL_P (obj)) + x = produce_memory_decl_rtl (obj, regno); + break; + case SSA_NAME: *ws = 0; obj = SSA_NAME_VAR (*expr_p); *************** prepare_decl_rtl (tree *expr_p, int *ws, *** 1912,1929 **** break; if (DECL_MODE (obj) == BLKmode) ! { ! if (TREE_STATIC (obj) ! || DECL_EXTERNAL (obj)) ! { ! const char *name = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (obj)); ! x = gen_rtx_SYMBOL_REF (Pmode, name); ! } ! else ! x = gen_raw_REG (Pmode, (*regno)++); ! ! x = gen_rtx_MEM (DECL_MODE (obj), x); ! } else x = gen_raw_REG (DECL_MODE (obj), (*regno)++); --- 1941,1947 ---- break; if (DECL_MODE (obj) == BLKmode) ! x = produce_memory_decl_rtl (obj, regno); else x = gen_raw_REG (DECL_MODE (obj), (*regno)++); ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2004-09-11 12:02 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-09-05 14:31 java/io/natFile.cc:106: internal compiler error: verify_ssa failed Graham Stott 2004-09-05 14:50 ` Diego Novillo 2004-09-05 15:11 ` Graham Stott 2004-09-05 17:18 ` Graham Stott 2004-09-05 17:54 ` Diego Novillo 2004-09-05 18:22 ` Daniel Berlin 2004-09-11 11:45 ` Zdenek Dvorak 2004-09-11 11:54 ` Daniel Berlin 2004-09-11 11:58 ` Zdenek Dvorak 2004-09-11 12:02 ` Daniel Berlin 2004-09-06 8:47 ` Jan Hubicka 2004-09-06 12:21 ` Jan Hubicka
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).