On 11/10/2017 09:03 AM, Richard Biener wrote:
On Fri, Nov 10, 2017 at 2:49 PM, Andrew MacLeod wrote:
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
On Fri, Nov 10, 2017 at 08:59:41AM -0500, Andrew MacLeod wrote:
> On 11/10/2017 08:49 AM, Andrew MacLeod wrote:
> >
> > The IL is comparing
> > ptr == 0B
> >
> > and I see:
> > Type op1 : 0x7fd8e312df18 -> integer(kind=4) (*) (void)
> > Type op2 : 0x7fd8e2fa10a8 -> void *
> >
> > These 2 ty
On Fri, Nov 10, 2017 at 2:49 PM, Andrew MacLeod wrote:
> 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 :
>
> _1
On 11/10/2017 08:49 AM, Andrew MacLeod wrote:
The IL is comparing
ptr == 0B
and I see:
Type op1 : 0x7fd8e312df18 -> integer(kind=4) (*) (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
Interesting, in
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 compat
