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
