public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
@ 2009-01-22 13:17 bonzini at gnu dot org
2009-01-22 13:17 ` [Bug middle-end/38934] " bonzini at gnu dot org
` (29 more replies)
0 siblings, 30 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-22 13:17 UTC (permalink / raw)
To: gcc-bugs
This failure is not "worked around" by FRE unlike 38932.
/* { dg-do compile } */
/* { dg-options "-O2 --std=gnu99" } */
/* This variable needed only to work around earlier optimizations than VRP. */
unsigned char g;
extern void abort();
void f (long long int p)
{
g = 255;
/* { dg-warning "constant is" "" { target *-*-* } 14 } */
/* { dg-warning "overflow" "" { target *-*-* } 14 } */
if (p >= -9223372036854775808LL - (signed char) g)
p = 1;
if (p)
abort ();
}
--
Summary: [4.4 Regression] ICE in set_value_range, at tree-
vrp.c:398
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, patch
Severity: critical
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: i686-pc-linux-gnu
BugsThisDependsOn: 38932
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
@ 2009-01-22 13:17 ` bonzini at gnu dot org
2009-01-22 15:53 ` hjl dot tools at gmail dot com
` (28 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-22 13:17 UTC (permalink / raw)
To: gcc-bugs
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-01-22 13:17:43
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
2009-01-22 13:17 ` [Bug middle-end/38934] " bonzini at gnu dot org
@ 2009-01-22 15:53 ` hjl dot tools at gmail dot com
2009-01-22 21:30 ` pinskia at gcc dot gnu dot org
` (27 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-01-22 15:53 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from hjl dot tools at gmail dot com 2009-01-22 15:53 -------
It won't ICE for me with revision 143448 on Linux/x86-64:
[hjl@gnu-27 rrs]$ ./143448/usr/bin/gcc -O2 -S pr38934.c -m32 --std=gnu99
pr38934.c:14:13: warning: integer constant is so large that it is unsigned
[hjl@gnu-27 rrs]$
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
2009-01-22 13:17 ` [Bug middle-end/38934] " bonzini at gnu dot org
2009-01-22 15:53 ` hjl dot tools at gmail dot com
@ 2009-01-22 21:30 ` pinskia at gcc dot gnu dot org
2009-01-23 0:07 ` hjl dot tools at gmail dot com
` (26 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2009-01-22 21:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from pinskia at gcc dot gnu dot org 2009-01-22 21:30 -------
(In reply to comment #1)
> It won't ICE for me with revision 143448 on Linux/x86-64:
Most likely this is HWI 32 only issue as this works on i386-darwin which
defaults HWI to be 64bits.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
Status|WAITING |NEW
Last reconfirmed|2009-01-22 13:17:43 |2009-01-22 21:30:48
date| |
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (2 preceding siblings ...)
2009-01-22 21:30 ` pinskia at gcc dot gnu dot org
@ 2009-01-23 0:07 ` hjl dot tools at gmail dot com
2009-01-25 18:03 ` [Bug middle-end/38934] [4.3/4.4 " rguenth at gcc dot gnu dot org
` (25 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: hjl dot tools at gmail dot com @ 2009-01-23 0:07 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from hjl dot tools at gmail dot com 2009-01-23 00:06 -------
(In reply to comment #2)
> (In reply to comment #1)
> > It won't ICE for me with revision 143448 on Linux/x86-64:
>
> Most likely this is HWI 32 only issue as this works on i386-darwin which
> defaults HWI to be 64bits.
That is true. This only happens with 32bit HWI. This is caused by
revision 122487:
http://gcc.gnu.org/ml/gcc-cvs/2007-03/msg00070.html
--
hjl dot tools at gmail dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |iant at google dot com
Known to fail|4.4.0 |4.3.3 4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (3 preceding siblings ...)
2009-01-23 0:07 ` hjl dot tools at gmail dot com
@ 2009-01-25 18:03 ` rguenth at gcc dot gnu dot org
2009-01-26 15:56 ` bonzini at gnu dot org
` (24 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-01-25 18:03 UTC (permalink / raw)
To: gcc-bugs
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (4 preceding siblings ...)
2009-01-25 18:03 ` [Bug middle-end/38934] [4.3/4.4 " rguenth at gcc dot gnu dot org
@ 2009-01-26 15:56 ` bonzini at gnu dot org
2009-01-26 15:57 ` rguenther at suse dot de
` (23 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-26 15:56 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (5 preceding siblings ...)
2009-01-26 15:56 ` bonzini at gnu dot org
@ 2009-01-26 15:57 ` rguenther at suse dot de
2009-01-26 16:02 ` jakub at gcc dot gnu dot org
` (22 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rguenther at suse dot de @ 2009-01-26 15:57 UTC (permalink / raw)
To: gcc-bugs
------- 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 happens with 32bit HWI.
>
> Does this mean it is a front-end bug that TREE_OVERFLOW is set?
Yes. In general TREE_OVERFLOW leaking into the IL is always a bug.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (6 preceding siblings ...)
2009-01-26 15:57 ` rguenther at suse dot de
@ 2009-01-26 16:02 ` jakub at gcc dot gnu dot org
2009-01-26 16:07 ` rguenther at suse dot de
` (21 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-26 16:02 UTC (permalink / raw)
To: gcc-bugs
------- 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 with it (use
VARYING range or something similar).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (7 preceding siblings ...)
2009-01-26 16:02 ` jakub at gcc dot gnu dot org
@ 2009-01-26 16:07 ` rguenther at suse dot de
2009-01-26 16:48 ` bonzini at gnu dot org
` (20 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rguenther at suse dot de @ 2009-01-26 16:07 UTC (permalink / raw)
To: gcc-bugs
------- 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 -------
> 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 with it (use
> VARYING range or something similar).
Not exactly. Your patch was correct in principle but exposed latent
bugs elsewhere. Difficult ones, because fold is shared between FEs
and the middle-end and fold and the FEs _do_ care about TREE_OVERFLOW.
...
So indeed, working around these issues where they pop up is the way
to go in the near future.
(this doesn't mean a TREE_OVERFLOW in the IL is valid ...)
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (8 preceding siblings ...)
2009-01-26 16:07 ` rguenther at suse dot de
@ 2009-01-26 16:48 ` bonzini at gnu dot org
2009-01-27 10:25 ` jakub at gcc dot gnu dot org
` (19 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-26 16:48 UTC (permalink / raw)
To: gcc-bugs
------- 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. For example in Eric's testcase, the way to
go would have been not to reassociate if there was a TREE_OVERFLOW on resulting
constant operands. It might even be as easy as
if (con0 && TREE_OVERFLOW (con0))
return NULL_TREE;
(search for "con0 =" in fold-const.c to get the context).
For 4.5, I suggest applying Jakub's patch very early and fixing bugs that
result. If it turns out it's a huge Pandora's box, we can always re-revert the
patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (9 preceding siblings ...)
2009-01-26 16:48 ` bonzini at gnu dot org
@ 2009-01-27 10:25 ` jakub at gcc dot gnu dot org
2009-01-27 10:30 ` rguenther at suse dot de
` (18 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-27 10:25 UTC (permalink / raw)
To: gcc-bugs
------- 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.jj 2009-01-02 09:32:55.000000000 +0100
+++ tree-vrp.c 2009-01-27 11:16:57.000000000 +0100
@@ -1620,7 +1620,8 @@ extract_range_from_assert (value_range_t
all should be optimized away above us. */
if ((cond_code == LT_EXPR
&& compare_values (max, min) == 0)
- || is_overflow_infinity (max))
+ || is_overflow_infinity (max)
+ || TREE_OVERFLOW (max))
set_value_range_to_varying (vr_p);
else
{
@@ -1655,7 +1656,8 @@ extract_range_from_assert (value_range_t
all should be optimized away above us. */
if ((cond_code == GT_EXPR
&& compare_values (min, max) == 0)
- || is_overflow_infinity (min))
+ || is_overflow_infinity (min)
+ || TREE_OVERFLOW (min))
set_value_range_to_varying (vr_p);
else
{
fixes this for me (and, is_overflow_infinity check could be actually dropped).
There is a problem with the testcase also - while the
integer constant is so large that it is unsigned
warning is emitted always,
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (10 preceding siblings ...)
2009-01-27 10:25 ` jakub at gcc dot gnu dot org
@ 2009-01-27 10:30 ` rguenther at suse dot de
2009-01-27 10:34 ` bonzini at gnu dot org
` (17 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rguenther at suse dot de @ 2009-01-27 10:30 UTC (permalink / raw)
To: gcc-bugs
------- 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 -------
> So, what should we do for 4.4 then?
> --- tree-vrp.c.jj 2009-01-02 09:32:55.000000000 +0100
> +++ tree-vrp.c 2009-01-27 11:16:57.000000000 +0100
> @@ -1620,7 +1620,8 @@ extract_range_from_assert (value_range_t
> all should be optimized away above us. */
> if ((cond_code == LT_EXPR
> && compare_values (max, min) == 0)
> - || is_overflow_infinity (max))
> + || is_overflow_infinity (max)
> + || TREE_OVERFLOW (max))
> set_value_range_to_varying (vr_p);
> else
> {
> @@ -1655,7 +1656,8 @@ extract_range_from_assert (value_range_t
> all should be optimized away above us. */
> if ((cond_code == GT_EXPR
> && compare_values (min, max) == 0)
> - || is_overflow_infinity (min))
> + || is_overflow_infinity (min)
> + || TREE_OVERFLOW (min))
> set_value_range_to_varying (vr_p);
> else
> {
That looks reasonable to me.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (11 preceding siblings ...)
2009-01-27 10:30 ` rguenther at suse dot de
@ 2009-01-27 10:34 ` bonzini at gnu dot org
2009-01-27 11:30 ` jakub at gcc dot gnu dot org
` (16 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-27 10:34 UTC (permalink / raw)
To: gcc-bugs
------- 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 (as I think it should be) it should not be there, the front-end bug is
the root cause of this PR and fixing it will remove the need for the VRP fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (12 preceding siblings ...)
2009-01-27 10:34 ` bonzini at gnu dot org
@ 2009-01-27 11:30 ` jakub at gcc dot gnu dot org
2009-01-27 12:00 ` jakub at gcc dot gnu dot org
` (15 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-27 11:30 UTC (permalink / raw)
To: gcc-bugs
------- 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. */
581 type = ((flags & CPP_N_UNSIGNED)
582 ? widest_unsigned_literal_type_node
583 : widest_integer_literal_type_node);
584 else
585 type = integer_types[itk];
in both cases the overflow warning has been issued, but
widest_integer_literal_type_node differs between 32-bit HWI and 64-bit HWI -
in the former case it is signed DImode, in the latter case signed TImode.
Negating TImode 0x8000000000000000 doesn't overflow, but negating
DImode 0x8000000000000000 does and thus the warning in 32-bit HWI case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (13 preceding siblings ...)
2009-01-27 11:30 ` jakub at gcc dot gnu dot org
@ 2009-01-27 12:00 ` jakub at gcc dot gnu dot org
2009-01-27 12:32 ` bonzini at gnu dot org
` (14 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-27 12:00 UTC (permalink / raw)
To: gcc-bugs
------- 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 extended type, not
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.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (14 preceding siblings ...)
2009-01-27 12:00 ` jakub at gcc dot gnu dot org
@ 2009-01-27 12:32 ` bonzini at gnu dot org
2009-01-27 13:33 ` joseph at codesourcery dot com
` (13 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-27 12:32 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (15 preceding siblings ...)
2009-01-27 12:32 ` bonzini at gnu dot org
@ 2009-01-27 13:33 ` joseph at codesourcery dot com
2009-01-27 13:44 ` bonzini at gnu dot org
` (12 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: joseph at codesourcery dot com @ 2009-01-27 13:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (16 preceding siblings ...)
2009-01-27 13:33 ` joseph at codesourcery dot com
@ 2009-01-27 13:44 ` bonzini at gnu dot org
2009-01-27 14:55 ` joseph at codesourcery dot com
` (11 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-27 13:44 UTC (permalink / raw)
To: gcc-bugs
------- 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.
It wouldn't actually be very hard to do that. I'm almost sure that it would
"just work".
But the (sub)problem here is that the same target architecture (32-bit i386)
has different HOST_WIDE_INT size depending on whether GCC is a 32-bit
single-arch or a 32-/64-bit bi-arch compiler.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (17 preceding siblings ...)
2009-01-27 13:44 ` bonzini at gnu dot org
@ 2009-01-27 14:55 ` joseph at codesourcery dot com
2009-01-27 15:14 ` jakub at gcc dot gnu dot org
` (10 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: joseph at codesourcery dot com @ 2009-01-27 14:55 UTC (permalink / raw)
To: gcc-bugs
------- 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
> > target (probably only on the target architecture), not the host; that's
> > the only way to ensure consistency between hosts for the same target.
>
> It wouldn't actually be very hard to do that. I'm almost sure that it would
> "just work".
>
> But the (sub)problem here is that the same target architecture (32-bit i386)
> has different HOST_WIDE_INT size depending on whether GCC is a 32-bit
> single-arch or a 32-/64-bit bi-arch compiler.
My claim is that we should stop doing this: it should always be 64-bit for
x86 and ARM, rather than depending on whether the target is biarch (x86)
or whether it is EABI (ARM), just as it is for other targets that may or
may not be biarch (MIPS, Power, SPARC).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (18 preceding siblings ...)
2009-01-27 14:55 ` joseph at codesourcery dot com
@ 2009-01-27 15:14 ` jakub at gcc dot gnu dot org
2009-01-27 15:21 ` bonzini at gnu dot org
` (9 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-27 15:14 UTC (permalink / raw)
To: gcc-bugs
------- 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 going to
bootstrap/regtest it), with the testcase with -w in dg-options, and handle the
rest separately, as P2. The rest is certainly not a recent regression (3.4.0
behaves the same way between i386 cc1 and x86_64 cc1 -m32).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (19 preceding siblings ...)
2009-01-27 15:14 ` jakub at gcc dot gnu dot org
@ 2009-01-27 15:21 ` bonzini at gnu dot org
2009-01-27 22:38 ` jakub at gcc dot gnu dot org
` (8 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-01-27 15:21 UTC (permalink / raw)
To: gcc-bugs
------- 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 distributing bi-arch
compilers, and something has been done to improve the situation
(HOST_WIDEST_FAST_INT, the -fsplit-wide-types pass, ...).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (20 preceding siblings ...)
2009-01-27 15:21 ` bonzini at gnu dot org
@ 2009-01-27 22:38 ` jakub at gcc dot gnu dot org
2009-01-28 6:23 ` rob1weld at aol dot com
` (7 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-27 22:38 UTC (permalink / raw)
To: gcc-bugs
--
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 |
Status|NEW |ASSIGNED
Last reconfirmed|2009-01-22 21:30:48 |2009-01-27 22:37:53
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (21 preceding siblings ...)
2009-01-27 22:38 ` jakub at gcc dot gnu dot org
@ 2009-01-28 6:23 ` rob1weld at aol dot com
2009-01-28 10:40 ` jakub at gcc dot gnu dot org
` (6 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: rob1weld at aol dot com @ 2009-01-28 6:23 UTC (permalink / raw)
To: gcc-bugs
------- 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
> > > target (probably only on the target architecture), not the host; that's
> > > the only way to ensure consistency between hosts for the same target.
Yes.
> > But the (sub)problem here is that the same target architecture (32-bit i386)
> > has different HOST_WIDE_INT size depending on whether GCC is a 32-bit
> > single-arch or a 32-/64-bit bi-arch compiler.
>
> My claim is that we should stop doing this: it should always be 64-bit for
> x86 and ARM, rather than depending on whether the target is biarch (x86)
> or whether it is EABI (ARM), just as it is for other targets that may or
> may not be biarch (MIPS, Power, SPARC).
(In reply to comment #18)
>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.
Whether the value ought to be 64 or 32 bit depends on the "boot mode" of the
Target and which size code runs fastest. Register usage may be considered
but memory usage is usually not considered since ram (or HD space) is cheap.
In the event that the Target has an abnormally small amount of memory
(Picochip?) or is truly short of registers (386) then you ought to go 32
bit even if 64 bit were quicker due to this being a bigger win in the end.
In architectures where you could be in either boat a compiler switch
would be a great feature. A Pragma with the ability to set mode on
a function by function basis would be great for writing Drivers.
If I had a Desktop computer with a MIPS or Arm uP I would likely want
64 bits but if I was trying to cross-compile for my Router (MIPS Linux
2.6 with 64 M) or my Cell Phone (Arm Symbian with 96 M) then I would
likely want 32 bit as the memory available is scarce.
In Fedora 10 this seems to be well handled by the OS's header's:
/usr/include/inttypes.h
#if __WORDSIZE == 64
/* We have to define the `uintmax_t' type using `ldiv_t'. */
typedef struct
{
long int quot; /* Quotient. */
long int rem; /* Remainder. */
} imaxdiv_t;
#else
/* We have to define the `uintmax_t' type using `lldiv_t'. */
typedef struct
{
long long int quot; /* Quotient. */
long long int rem; /* Remainder. */
} imaxdiv_t;
#endif
Make it fast, make it practical, make it work,
Rob
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3/4.4 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (22 preceding siblings ...)
2009-01-28 6:23 ` rob1weld at aol dot com
@ 2009-01-28 10:40 ` jakub at gcc dot gnu dot org
2009-01-28 11:21 ` [Bug middle-end/38934] [4.3 " jakub at gcc dot gnu dot org
` (5 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-28 10:40 UTC (permalink / raw)
To: gcc-bugs
------- 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=gcc&view=rev&rev=143723
Log:
PR middle-end/38934
* tree-vrp.c (extract_range_from_assert): For LE_EXPR and LT_EXPR
set to varying whenever max has TREE_OVERFLOW set, similarly
for GE_EXPR and GT_EXPR and TREE_OVERFLOW min.
* gcc.dg/pr38934.c: New test.
Added:
trunk/gcc/testsuite/gcc.dg/pr38934.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (23 preceding siblings ...)
2009-01-28 10:40 ` jakub at gcc dot gnu dot org
@ 2009-01-28 11:21 ` jakub at gcc dot gnu dot org
2009-04-21 15:56 ` jakub at gcc dot gnu dot org
` (4 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-01-28 11:21 UTC (permalink / raw)
To: gcc-bugs
------- Comment #22 from jakub at gcc dot gnu dot org 2009-01-28 11:20 -------
The ICE is fixed on the trunk, for the different warning behavior between
32-bit HWI and 64-bit HWI configured gcc I've opened PR38999.
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail|4.3.3 4.4.0 |4.3.3
Known to work|4.2.1 |4.2.1 4.4.0
Summary|[4.3/4.4 Regression] ICE in |[4.3 Regression] ICE in
|set_value_range, at tree- |set_value_range, at tree-
|vrp.c:398 |vrp.c:398
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (24 preceding siblings ...)
2009-01-28 11:21 ` [Bug middle-end/38934] [4.3 " jakub at gcc dot gnu dot org
@ 2009-04-21 15:56 ` jakub at gcc dot gnu dot org
2009-04-21 16:12 ` bonzini at gnu dot org
` (3 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: jakub at gcc dot gnu dot org @ 2009-04-21 15:56 UTC (permalink / raw)
To: gcc-bugs
--
jakub at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.4.0 |4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (25 preceding siblings ...)
2009-04-21 15:56 ` jakub at gcc dot gnu dot org
@ 2009-04-21 16:12 ` bonzini at gnu dot org
2009-04-22 10:39 ` rguenth at gcc dot gnu dot org
` (2 subsequent siblings)
29 siblings, 0 replies; 31+ messages in thread
From: bonzini at gnu dot org @ 2009-04-21 16:12 UTC (permalink / raw)
To: gcc-bugs
--
bonzini at gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|4.4.1 |4.3.4
Version|4.4.0 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (26 preceding siblings ...)
2009-04-21 16:12 ` bonzini at gnu dot org
@ 2009-04-22 10:39 ` rguenth at gcc dot gnu dot org
2009-07-10 16:00 ` rguenth at gcc dot gnu dot org
2009-07-10 16:04 ` rguenth at gcc dot gnu dot org
29 siblings, 0 replies; 31+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-04-22 10:39 UTC (permalink / raw)
To: gcc-bugs
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (27 preceding siblings ...)
2009-04-22 10:39 ` rguenth at gcc dot gnu dot org
@ 2009-07-10 16:00 ` rguenth at gcc dot gnu dot org
2009-07-10 16:04 ` rguenth at gcc dot gnu dot org
29 siblings, 0 replies; 31+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-10 16:00 UTC (permalink / raw)
To: gcc-bugs
------- Comment #23 from rguenth at gcc dot gnu dot org 2009-07-10 16:00 -------
Subject: Bug 38934
Author: rguenth
Date: Fri Jul 10 16:00:13 2009
New Revision: 149486
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149486
Log:
2009-07-10 Richard Guenther <rguenther@suse.de>
Backport from mainline
2009-01-28 Jakub Jelinek <jakub@redhat.com>
PR middle-end/38934
* tree-vrp.c (extract_range_from_assert): For LE_EXPR and LT_EXPR
set to varying whenever max has TREE_OVERFLOW set, similarly
for GE_EXPR and GT_EXPR and TREE_OVERFLOW min.
* gcc.dg/pr38934.c: New test.
Added:
branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr38934.c
Modified:
branches/gcc-4_3-branch/gcc/ChangeLog
branches/gcc-4_3-branch/gcc/testsuite/ChangeLog
branches/gcc-4_3-branch/gcc/tree-vrp.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
* [Bug middle-end/38934] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:398
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
` (28 preceding siblings ...)
2009-07-10 16:00 ` rguenth at gcc dot gnu dot org
@ 2009-07-10 16:04 ` rguenth at gcc dot gnu dot org
29 siblings, 0 replies; 31+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2009-07-10 16:04 UTC (permalink / raw)
To: gcc-bugs
------- Comment #24 from rguenth at gcc dot gnu dot org 2009-07-10 16:04 -------
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Known to work|4.2.1 4.4.0 |4.2.1 4.3.4 4.4.0
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38934
^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2009-07-10 16:04 UTC | newest]
Thread overview: 31+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-01-22 13:17 [Bug middle-end/38934] New: [4.4 Regression] ICE in set_value_range, at tree-vrp.c:398 bonzini at gnu dot org
2009-01-22 13:17 ` [Bug middle-end/38934] " bonzini at gnu dot org
2009-01-22 15:53 ` hjl dot tools at gmail dot com
2009-01-22 21:30 ` pinskia at gcc dot gnu dot org
2009-01-23 0:07 ` hjl dot tools at gmail dot com
2009-01-25 18:03 ` [Bug middle-end/38934] [4.3/4.4 " rguenth at gcc dot gnu dot org
2009-01-26 15:56 ` bonzini at gnu dot org
2009-01-26 15:57 ` rguenther at suse dot de
2009-01-26 16:02 ` jakub at gcc dot gnu dot org
2009-01-26 16:07 ` rguenther at suse dot de
2009-01-26 16:48 ` bonzini at gnu dot org
2009-01-27 10:25 ` jakub at gcc dot gnu dot org
2009-01-27 10:30 ` rguenther at suse dot de
2009-01-27 10:34 ` bonzini at gnu dot org
2009-01-27 11:30 ` jakub at gcc dot gnu dot org
2009-01-27 12:00 ` jakub at gcc dot gnu dot org
2009-01-27 12:32 ` bonzini at gnu dot org
2009-01-27 13:33 ` joseph at codesourcery dot com
2009-01-27 13:44 ` bonzini at gnu dot org
2009-01-27 14:55 ` joseph at codesourcery dot com
2009-01-27 15:14 ` jakub at gcc dot gnu dot org
2009-01-27 15:21 ` bonzini at gnu dot org
2009-01-27 22:38 ` jakub at gcc dot gnu dot org
2009-01-28 6:23 ` rob1weld at aol dot com
2009-01-28 10:40 ` jakub at gcc dot gnu dot org
2009-01-28 11:21 ` [Bug middle-end/38934] [4.3 " jakub at gcc dot gnu dot org
2009-04-21 15:56 ` jakub at gcc dot gnu dot org
2009-04-21 16:12 ` bonzini at gnu dot org
2009-04-22 10:39 ` rguenth at gcc dot gnu dot org
2009-07-10 16:00 ` rguenth at gcc dot gnu dot org
2009-07-10 16:04 ` rguenth at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).