This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 27 Jan 2009 13:33:19 -0000
- Subject: [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
- References: <bug-38934-7849@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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