patch for compare1.c test failure

Zack Weinberg zack@bitmover.com
Sun Oct 31 23:33:00 GMT 1999


Richard Henderson wrote:
> On Mon, Oct 25, 1999 at 10:17:11PM -0700, Zack Weinberg wrote:
> > It does not distinguish this from the other case.  As passed to
> > build_binary_op, "target_flags ? a : b" always has signed type.  The
> > warning triggers because mode has unsigned type.
> 
> My thought when I looked at this before was that the bug
> is that the expression (p ? DImode : SImode) does not have
> type enum machine_mode. 
> 
> My reading of the standard suggests that this is a valid
> interpretation.  If the result of the ?: expression is used
> in a context that warrents default conversions, it can 
> happen then.

I did some more investigations, and it appears that this was intended
to occur, but not happening because of a silly bug in the parser.  If
you look around line 673 of c-parse.y you will see something like this:

		  if (TREE_CODE ($$) == CONST_DECL)
		    {
		      /* Preserve the type of an enumeration constant.  */
		      $$ = DECL_INITIAL ($$)
		      $$ = build1 (NOP_EXPR, TREE_TYPE ($$), $$);
		      TREE_CONSTANT ($$) = 1;
		    }

The CONST_DECL has type <enum foo> but its DECL_INITIAL has type <int>.
The NOP_EXPR is useless.  If you change it to read

		  if (TREE_CODE ($$) == CONST_DECL)
		    {
		      /* Preserve the type of an enumeration constant.  */
		      $$ = build1 (NOP_EXPR, TREE_TYPE ($$),
				   DECL_INITIAL ($$));
		      TREE_CONSTANT ($$) = 1;
		    }

then the tree passed back is effectively ((enum foo) 12).  This
suffices to get us unsigned quantities on either side of 
mode == (p ? DImode : SImode).

Warning for mode == (p ? DImode : -1) has to be done elsewhere - I put
it in build_conditional_expr.

The change also breaks a bunch of places that are using
STRIP_TYPE_NOPS when they should've been using STRIP_NOPS, such as
grokdeclarator.  I am still working on this.

zw



More information about the Gcc-patches mailing list