Mainline bootstrap failure on hppa2.0w-hp-hpux11.00

[John David Anglin]

> The promotion rules for C mandate that these cases are asymmetric.  In
> cases where signed and unsigned are mixed, the expression is promoted
> to unsigned.  In case one, the promotion turns (int)1 into

I read in 6.3.1.8 which discusses the usual arithmetic conversions,

	Otherwise, if the type of the operand with the signed integer
	can represent all of the values of the type of the operand
	with unsigned integer type, then the operand with unsigned
	integer type is converted to the type of the operand with
	signed integer type.

It seems as if this would apply to the case in question.  Do we
support this?  The following conversion is

	Otherwise, both operands are converted to the unsigned integer
	type corresponding to the type of the operand with signed
	integer type.

which is the conversion that you mention.  I would argue that we only
want to warn about the later conversion.

> Well I don't know that we have a value-range propagation information
> working in the trunk.  

Ok.

> Leaving that aside, even though the & expression evaluates to a value
> in the range of signed integers, it is still an unsigned quantity as
> written in the example given.  This means that the signed portion of
> the ?: (an _isspace call) gets promoted to unsigned.  In the general
> case, GCC has no way to know that this is harmless given the
> information it has when evaluating the expression.  You and I as
> humans know that _isspace is a truth value and returns 0/1, but GCC
> doesn't have a way to know this.  (Please correct me if I'm wrong.)

I don't have exact information but I assume that it is the same as
isspace.  It returns a non zero integer, not necessarily 1.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)