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

[Kaveh R. Ghazi]

 > From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
 > 
 > Secondly, I am not convinced that gcc should be warning in this situation.
 > Gcc does not warn for this code
 > 
 > int
 > foo (unsigned int x)
 > {
 >   return x ? x : (int) 1;
 > }
 > 
 > However, it does warn for this code
 > 
 > foo (int x)
 > {
 >   return x ? (unsigned) 1 : x;
 > }
 > 
 > So, the behavior is asymmetric.  As far as I know, it is guaranteed
 > that the representations for "1" are identical, signed and unsigned.
 > Thus, I don't think there is a need to warn in the second case.

I'm no C standards guru, but I've done a fair amount of work getting
the sign/unsigned warnings to avoid as much spurious blather as
possible.  My understanding of the situation is as follows:

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
(unsigned)1.  GCC has code which knows this is a safe transformation.
In case two, (int) x is turned into (unsigned) x.  There is no way to
know that this is safe (in the general case) because x can be
originally negative and the cast changes it's meaning.


 > The warning from the HP header involves an "&" but still gcc has all the
 > information it needs to determine that the unsigned expression evaluates
 > to value in the set of signed integers.  As far as I can tell, identical
 > arithmetic types are not a requirement of the standard for the "?"
 > operator.  So, I am of the opinion that this is a problem with gcc's
 > warnings.
 > Dave

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

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.)

This is why I believe a fixincl hack to cast the _isspace to unsigned
is the appropriate fix.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu