Types of operands in a gimple equality operation

[Andrew MacLeod]

Before I open a PR, I want to confirm my beliefs.


Is it not true that both operations of a gimple operation such as == or 
!= must satisfy types_compatible_p (op1_type, op2_type)  ?  Even when 
one is a constant?

given :

   _10 = _2 != 0

so the generic node for the 0 needs to be a type compatible with _2?

I ask because I tripped over a fortran test where that is not true. It 
is comparing a function pointer of some sort with a (void *)0, and the 
types_compatible_p check fails.

I hacked the compiler to check when building a gimple assign to verify 
that the types are compatible.  It succeeds and entire bootstrap cycle, 
which leads me to believe my assertion is true. For some reason I 
thought there was gimple verification that would catch things like 
this.. apparently not?

Index: gimple.c
===================================================================
*** gimple.c    (revision 254327)
--- gimple.c    (working copy)
*************** gimple_build_assign_1 (tree lhs, enum tr
*** 423,428 ****
--- 423,430 ----
       {
         gcc_assert (num_ops > 2);
         gimple_assign_set_rhs2 (p, op2);
+       if (subcode == EQ_EXPR || subcode == NE_EXPR)
+     gcc_assert (types_compatible_p (TREE_TYPE (op1), TREE_TYPE (op2)));
       }


and when I run it on this small program:

   interface
     integer function foo ()
     end function
     integer function baz ()
     end function
   end interface
   procedure(foo), pointer :: ptr
   ptr => baz
   if (.not.associated (ptr, baz)) call abort
end

I get a trap on this statement:

  if (.not.associated (ptr, baz)) call abort

internal compiler error: in gimple_build_assign_1, at gimple.c:443

The IL is comparing
      ptr == 0B

and I see:
Type op1 : 0x7fd8e312df18 -> integer(kind=4) (*<T561>) (void)
Type op2 : 0x7fd8e2fa10a8 -> void *

These 2 types fail the types_compatible_p test.

So is this a bug like I think it is?
Andrew