------- Comment #15 from joseph at codesourcery dot com  2009-01-27 13:33 
-------
Subject: Re:  [4.3/4.4 Regression] ICE in set_value_range,
 at tree-vrp.c:398

On Tue, 27 Jan 2009, jakub at gcc dot gnu dot org wrote:

> I wonder if the libcpp warning is correct in this case for 
> -std=c99/-std=gnu99,
> saying that the constant is too large that it is unsigned doesn't match the 
> C99
> wording, which says that the constant may have a signed extended type, not

I'm not clear what the issue here is supposed to be.

Anything that involves a type wider than intmax_t in a program should 
yield a pedwarn, not just a warning, for C99.  That was part of the 
intended effect of my patch 
<http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00816.html>.  The part for 
"mode" attributes was lost with 
<http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00887.html> - since the 
relevant code is now in c-common.c again, it could be restored.  I don't 
know offhand when the check for integer constants was lost, although I 
don't see it in c-lex.c.  Unfortunately my original patch didn't have 
testcases for these diagnostics, probably because making them 
target-independent is hard and we didn't have the effective-target 
infrastructure back then.

> unsigned.  For 32-bit HWI, unfortunately I don't see how we could have a 
> larger
> type than 2 * HOST_BITS_PER_WIDE_INT, as there would be no way to represet
> TYPE_MIN_VALUE and TYPE_MAX_VALUE.

It's very clear to me by now that HOST_WIDE_INT should only depend on the 
target (probably only on the target architecture), not the host; that's 
the only way to ensure consistency between hosts for the same target.  
And so all the cases that really mean something related to the target 
should use some other name.  (There may be cases where the host not the 
target really is relevant, though there may also be better host types such 
as size_t to use in some of those cases.  Unfortunately there are nearly 
5000 uses of HOST_WIDE_INT in the compiler, so a huge task for anyone 
cleaning this up.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934

Reply via email to