--- Comment #21 from jakub at gcc dot gnu dot org 2009-01-28 10:40 ---
Subject: Bug 38934
Author: jakub
Date: Wed Jan 28 10:40:06 2009
New Revision: 143723
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143723
Log:
PR middle-end/38934
* tree-vrp.c
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-27 10:25 ---
So, what should we do for 4.4 then?
--- tree-vrp.c.jj2009-01-02 09:32:55.0 +0100
+++ tree-vrp.c2009-01-27 11:16:57.0 +0100
@@ -1620,7 +1620,8 @@ extract_range_from_assert (value_range_t
--- Comment #10 from rguenther at suse dot de 2009-01-27 10:29 ---
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:
--- Comment #9 from jakub at gcc dot gnu dot org 2009-01-27 10:25 ---
--- Comment #11 from bonzini at gnu dot org 2009-01-27 10:33 ---
integer overflow in expression
is emitted only for 32-bit HWI gcc, for x86_64 -m32 as well as -m64 only the
first warning is emitted.
If the warning should be there in 64-bit HWI gcc too, that's a separate bug.
But if
--- Comment #12 from jakub at gcc dot gnu dot org 2009-01-27 11:29 ---
The difference is in interpret_integer:
579 if (itk == itk_none)
580/* cpplib has already issued a warning for overflow. */
581type = ((flags CPP_N_UNSIGNED)
582? widest_unsigned_literal_type_node
583
--- Comment #13 from jakub at gcc dot gnu dot org 2009-01-27 11:59 ---
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
--- Comment #14 from bonzini at gnu dot org 2009-01-27 12:32 ---
Yes, for the record those were my thoughts too when I prepared the --std=c99
testcase.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
--- 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
--- Comment #16 from bonzini at gnu dot org 2009-01-27 13:44 ---
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.
--- Comment #17 from joseph at codesourcery dot com 2009-01-27 14:55
---
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:
It's very clear to me by now that HOST_WIDE_INT should only depend on the
--- Comment #18 from jakub at gcc dot gnu dot org 2009-01-27 15:14 ---
The problem on ix86 is I believe that on such a register starved host, using
long long in many places will mean very noticeable performance degradation.
In any case, I'd prefer to change tree-vrp.c at this point (am
--- Comment #19 from bonzini at gnu dot org 2009-01-27 15:21 ---
The problem on ix86 is I believe that on such a register starved host, using
long long in many places will mean very noticeable performance degradation.
Probably noticeable; however, Debian and Apple are already
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #20 from rob1weld at aol dot com 2009-01-28 06:23 ---
(In reply to comment #17)
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
On Tue, 27 Jan 2009, bonzini at gnu dot org wrote:
It's very clear to me by now that HOST_WIDE_INT should only depend on the
--- Comment #4 from bonzini at gnu dot org 2009-01-26 15:56 ---
This only happens with 32bit HWI.
Does this mean it is a front-end bug that TREE_OVERFLOW is set?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
--- Comment #5 from rguenther at suse dot de 2009-01-26 15:57 ---
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Mon, 26 Jan 2009, bonzini at gnu dot org wrote:
--- Comment #4 from bonzini at gnu dot org 2009-01-26 15:56 ---
This only
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-26 16:02 ---
That brings us back to http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00532.html
If the gimplifier shouldn't drop TREE_OVERFLOW bits from the IL, then it is
valid to have TREE_OVERFLOWs set and tree-vrp.c needs to deal
--- Comment #7 from rguenther at suse dot de 2009-01-26 16:07 ---
Subject: Re: [4.3/4.4 Regression] ICE in set_value_range,
at tree-vrp.c:398
On Mon, 26 Jan 2009, jakub at gcc dot gnu dot org wrote:
--- Comment #6 from jakub at gcc dot gnu dot org 2009-01-26 16:02 ---
--- Comment #8 from bonzini at gnu dot org 2009-01-26 16:48 ---
I disagree with this:
working around these issues where they pop up is the way
to go in the near future.
I think we need to be a bit more ambitious, and that does not mean separating
overflow/non-overflow tree codes.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
20 matches
Mail list logo
