Re: [PATCH] Handle BOOLEAN_TYPEs in c_common_type

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 16 May 2005, Roger Sayle wrote:

> With my local changes to the tree, the failing testcase is
> gcc.c-torture/execute/20030714-1.c.  The sequence of events is that
> build_binary_op attempts to construct a NE_EXPR operation on two
> QImode Boolean values that have been promoted to SImode integers
> following the usual conversion rules.  Line 7857 of build_binary_op
> calls shorten_compare on the integer operands, and then in
> c-common.c:shorten_compare, we call get_narrower to reduce the
> promoted arguments to their unwidened forms.  In this case, although
> op0 and op1 are integer types, the results of get_narrower, primop0
> and primop1 are now Boolean types.
> 
> Finally, on line 2158 of shorten_compare, we end up calling
> type = common_type (TREE_TYPE (primop0), TREE_TYPE (primop1));
> 
> And by passing two unpromoted Booleans to c_common_type, we ICE.

I think the real underlying problem is that the optimizations in 
shorten_compare are language-dependent and call language-dependent 
functions such as common_type.  It ought to be possible to do such 
optimizations in language-independent code.  But this is a separate issue.

> The possible solutions are (i) that get_narrower shouldn't strip
> the Boolean to integer conversions, (ii) shorten_compare should
> guard against BOOLEAN_TYPE before calling common_type, (iii)
> that common_type and not c_common_type should handle Booleans
> (as proposed by Joseph) or (iv) my original patch that extends
> the functionality of c_common_type.

c_common_type has a well-defined interface.  common_type is a kludge 
wrapping around that to deal with the requirements of shorten_compare.  So 
I think common_type is the right place.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)