Fwd: [PATCH] Fix PR C/35430, C++/35430 ICE with complex int and comparision

[Jakub Jelinek]

On Wed, Jun 04, 2008 at 11:01:28AM -0700, Mark Mitchell wrote:
> This doesn't look like a complete fix.  For example, a bit further 
> along, I see:

I don't believe you can hit that with a complex result_type.
The warning is supposed to warn about say:
unsigned short i;
unsigned char c;
int r[2];

void f1 ()
{
  r[0] = i != ~c;
  r[1] = 6 != ~c;
}

but when one or both of the operands are _Complex, then both
operands will be COMPLEX_EXPRs and so this code isn't hit (neither
operand is BIT_NOT_EXPR, but BIT_NOT_EXPR is applied to the real
part only and the imaginary part is left untouched).

> 
>                  if (bits < TYPE_PRECISION (result_type)
>                       && bits < HOST_BITS_PER_LONG && unsignedp)

What should be probably changed though is
s/HOST_BITS_PER_LONG/HOST_BITS_PER_WIDE_INT/ here, both MASK and
CONSTANT are HOST_WIDE_INTs rather than longs.  But that is unrelated to
this patch.

> Also, I'd suggest breaking the entire body of the conditional under:
> 
>       if ((short_compare || code == MIN_EXPR || code == MAX_EXPR)
>           && warn_sign_compare
>           /* Do not warn until the template is instantiated; we cannot 
> 
>              bound the ranges of the arguments until that point.  */
>           && !processing_template_decl)
> 
> into a separate function, and passing in what it needs.

I'm not convinced that's a cleanup, there are many such blocks in the
function, so either none of them should be changed, or all of them.

> And, passing in 
> result_type as either the real result_type, or the TREE_TYPE of the 
> COMPLEX_TYPE as appropriately.  But, if you don't think that's a 
> cleanup, then please rename "undertype" as "basetype" when you resubmit.

Wouldn't scalar_type be better?

	Jakub