java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Graham Stott]

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

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Diego Novillo]

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.

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Graham Stott]

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

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Graham Stott]

Diego,

> Diego Novillo wrote:
> 
>> Can you reproduce this with -fno-ivopts?
> 
no it compiles fine with -fno-ivopts

Graham

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Diego Novillo]

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.

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Daniel Berlin]

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.
> 
-- 

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Zdenek Dvorak]

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

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Daniel Berlin]

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

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Zdenek Dvorak]

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

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[Daniel Berlin]

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
>

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[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.
> 

Re: java/io/natFile.cc:106: internal compiler error: verify_ssa failed.

[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.

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)++);