Re: [tree-ssa] cfg_remove_useless_stmts and invert_truthval

[Andrew MacLeod <amacleod at redhat dot com>]

On Thu, 2003-11-13 at 16:10, law@redhat.com wrote:
> In message <1068753078.26945.62.camel@p4>, Andrew MacLeod writes:
>  >
>  >I just checked out a new branch today, applied the expression
>  >replacement code and tried a build.
>  >
>  >Im getting an abort in invert_truthval now building target libiberty
>  >because I have a condition that looks like:
>  >
>  >
>  >if ((_Bool)iftmp.1182)
>  >
>  >Since it's casted, invert_truthval executes this sequence:
>  >    case NOP_EXPR:
>  >    case CONVERT_EXPR:
>  >    case FLOAT_EXPR:
>  >      return build1 (TREE_CODE (arg), type,
>  >                     invert_truthvalue (TREE_OPERAND (arg, 0)));
>  >
>  >which calls itself on the 'iftmp.1182' VAR_DECL, which is not of type
>  >boolean, so invert_truthval aborts at the end:
>  >  if (TREE_CODE (TREE_TYPE (arg)) != BOOLEAN_TYPE)
>  >    abort ();
>  >
>  >Well of course it isn't boolean, since the cast was removed in the
>  >previous iteration...
>  >
>  >This doesnt seem quite right?... Whats the right thing here?  This didnt
>  >happen a couple of days ago, presumably because of the new
>  >remove_useless... code.
> Presumably this is happening from a call within cfg_remove_useless_stmts?
> 

Yes.

> It certainly calls invert_truthval in a place where it hadn't been
> called before.  

It certainly appears to be making an assumption we cannot afford to
make. Or the code which ignores the cast to _Bool is wrong. one or the
other. I cant go forward without a resolution.


> My question would be why isn't an iftmp variable a boolean to start with!
> 
Well, I dont care about that myself, since this could arbitrarily happen
anywhere we use a non-boolean in a COND_EXPR. The expression combiner
would do the exact thing it did above, move the expression and the cast
into the COND_EXPR.

It looks like GENERIC generates iftmp as ints, and we get GIMPLE temps
which cast them to booleans. I now move those casts into the COND_EXPR,
and cfg_remove_useless_stmts_bb craps out here.

Shouldn't invert_truthval() look for the case where it has a cast to a
boolean, and simply invert the expression at that point instead of
continuing to strip the cast off and try to invert it? 

I tried the following patchlet, and it seems to work fine...Is something
like this OK?

Andrew

Index: fold-const.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/fold-const.c,v
retrieving revision 1.213.2.62
diff -c -p -r1.213.2.62 fold-const.c
*** fold-const.c	13 Nov 2003 02:37:53 -0000	1.213.2.62
--- fold-const.c	13 Nov 2003 21:39:56 -0000
*************** invert_truthvalue (tree arg)
*** 2527,2532 ****
--- 2527,2535 ----
        return invert_truthvalue (TREE_OPERAND (arg, 0));
  
      case NOP_EXPR:
+       if (TREE_CODE (TREE_TYPE (arg)) == BOOLEAN_TYPE)
+         break;
+ 
      case CONVERT_EXPR:
      case FLOAT_EXPR:
        return build1 (TREE_CODE (arg), type,