* [Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
@ 2006-02-18 8:37 ` ebotcazou at gcc dot gnu dot org
2006-02-18 11:09 ` schwab at suse dot de
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-02-18 8:37 UTC (permalink / raw)
To: gcc-bugs
--
ebotcazou at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu dot
| |org
Severity|normal |critical
Summary|Ada gnatlib a-textio.o ICE |ICE compiling a-textio.adb
|because of too much RAM, |at -O1 -ftree-vrp
|tree-vrp? |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
2006-02-18 8:37 ` [Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp ebotcazou at gcc dot gnu dot org
@ 2006-02-18 11:09 ` schwab at suse dot de
2006-02-18 11:15 ` laurent at guerby dot net
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: schwab at suse dot de @ 2006-02-18 11:09 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from schwab at suse dot de 2006-02-18 11:09 -------
Also seen on ia64, 2GB is not enough to compile this file.
--
schwab at suse dot de changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2006-02-18 11:09:14
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
2006-02-18 8:37 ` [Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp ebotcazou at gcc dot gnu dot org
2006-02-18 11:09 ` schwab at suse dot de
@ 2006-02-18 11:15 ` laurent at guerby dot net
2006-02-18 14:47 ` law at redhat dot com
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: laurent at guerby dot net @ 2006-02-18 11:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from laurent at guerby dot net 2006-02-18 11:15 -------
Jeff mentionned "ping pong" between passes, I believe it's an infinite
ping-pong loop between two things with memory usage increasing linearly (either
leak or data structures) until the system kills the process. gdb traces do not
show backtrace grow. My amd64 machine with 2GB RAM and 6GB swap failed on it
too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (2 preceding siblings ...)
2006-02-18 11:15 ` laurent at guerby dot net
@ 2006-02-18 14:47 ` law at redhat dot com
2006-02-18 16:41 ` danglin at gcc dot gnu dot org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: law at redhat dot com @ 2006-02-18 14:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from law at redhat dot com 2006-02-18 14:47 -------
Subject: Re: ICE compiling a-textio.adb at -O1 -ftree-vrp
On Sat, 2006-02-18 at 11:15 +0000, laurent at guerby dot net wrote:
>
> ------- Comment #2 from laurent at guerby dot net 2006-02-18 11:15 -------
> Jeff mentionned "ping pong" between passes, I believe it's an infinite
> ping-pong loop between two things with memory usage increasing linearly (either
> leak or data structures) until the system kills the process. gdb traces do not
> show backtrace grow. My amd64 machine with 2GB RAM and 6GB swap failed on it
> too.
The only way the ping-pong would lead to this behavior woudl be
if you had a self-referring (ie recursive) expression. ie,
a PLUS_EXPR where one of the operands is the PLUS_EXPR itself.
More likely it's something wonky elsewhere. That's been the
pattern so far.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (3 preceding siblings ...)
2006-02-18 14:47 ` law at redhat dot com
@ 2006-02-18 16:41 ` danglin at gcc dot gnu dot org
2006-02-18 17:02 ` [Bug ada/26348] [4.2 Regression] " pinskia at gcc dot gnu dot org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: danglin at gcc dot gnu dot org @ 2006-02-18 16:41 UTC (permalink / raw)
To: gcc-bugs
------- Comment #4 from danglin at gcc dot gnu dot org 2006-02-18 16:41 -------
Also seen on hppa-unknown-linux-gnu:
/home/dave/gnu/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gnu/gcc-4.2/objdir/./gcc/
-B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/
-B/home/dave/opt/gnu/gcc/gcc-
4.2.0/hppa-linux/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include -c -g -O2
-f
PIC -DELF=1 -DLINUX=1 -W -Wall -gnatpg a-textio.adb -o a-textio.o
virtual memory exhausted: Cannot allocate memory
--
danglin at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |danglin at gcc dot gnu dot
| |org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (4 preceding siblings ...)
2006-02-18 16:41 ` danglin at gcc dot gnu dot org
@ 2006-02-18 17:02 ` pinskia at gcc dot gnu dot org
2006-02-18 21:36 ` law at redhat dot com
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-02-18 17:02 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 -------
Saw it too.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pinskia at gcc dot gnu dot
| |org
Summary|ICE compiling a-textio.adb |[4.2 Regression] ICE
|at -O1 -ftree-vrp |compiling a-textio.adb at -
| |O1 -ftree-vrp
Target Milestone|--- |4.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (5 preceding siblings ...)
2006-02-18 17:02 ` [Bug ada/26348] [4.2 Regression] " pinskia at gcc dot gnu dot org
@ 2006-02-18 21:36 ` law at redhat dot com
2006-02-18 21:50 ` law at redhat dot com
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: law at redhat dot com @ 2006-02-18 21:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #6 from law at redhat dot com 2006-02-18 21:36 -------
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +0000, pinskia at gcc dot gnu dot org wrote:
>
> ------- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 -------
> Saw it too.
Basically we're simulating a set of 6 statements over and over
for reasons unknown.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (6 preceding siblings ...)
2006-02-18 21:36 ` law at redhat dot com
@ 2006-02-18 21:50 ` law at redhat dot com
2006-02-19 0:16 ` law at redhat dot com
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: law at redhat dot com @ 2006-02-18 21:50 UTC (permalink / raw)
To: gcc-bugs
------- Comment #7 from law at redhat dot com 2006-02-18 21:49 -------
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +0000, pinskia at gcc dot gnu dot org wrote:
>
> ------- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 -------
> Saw it too.
I think I know what's going on here. Probably can't get a good fix
in until tues/wed.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (7 preceding siblings ...)
2006-02-18 21:50 ` law at redhat dot com
@ 2006-02-19 0:16 ` law at redhat dot com
2006-02-19 0:23 ` laurent at guerby dot net
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: law at redhat dot com @ 2006-02-19 0:16 UTC (permalink / raw)
To: gcc-bugs
------- Comment #8 from law at redhat dot com 2006-02-19 00:16 -------
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sat, 2006-02-18 at 17:02 +0000, pinskia at gcc dot gnu dot org wrote:
>
> ------- Comment #5 from pinskia at gcc dot gnu dot org 2006-02-18 17:02 -------
> Saw it too.
Ignore my last post about an initial theory. It looks like
some code, somewhere is goofing up types in a very unpleasant
way. If I had to point a finger, I'd have to guess it's
somewhere in the Ada front-end and an Ada person is going to have
to look at this. It's highly unlikely with my total lack of
knowledge about the Ada front-end that have any chance of fixing
it.
Our little odyssey starts with visiting this PHI node:
[ The first visit is uninteresting, ignore it. I'm starting my
analysis with the second visit. ]
lastD.2483_148 = PHI <lastD.2483_60(28), lastD.2483_15(14)>;
Only the edge from block #14 is executable, so the result of the
PHI will be equivalent to the current range for last_15. The
range we record is [0, 0x7fffffff].
We then proceed to the uses of last_148. One of which is:
lastD.2483_86 = lastD.2483_148 + 1;
Now for the first "oddity". If we look at the underlying type
for last we have a type "natural___XDLU_0__2147483647". What's
interesting about it is that it has a 32bit type precision, but
the min/max values only specify 31 bits. ie, the min/max values
are 0, 0x7fffffff.
So anyway, we proceed to add the current range for last_148
[0, 0x7fffffff] to the constant 1. This results in
[1, 0x80000000]. Second oddity. This is clearly outside the
type's min/max values, but because the value is inside the
type's precision, no overflow is signaled and no bits are
zero'd out.
We then encounter this statement:
lastD.2483_60 = lastD.2483_86;
So we copy the current range for last_86 to last_60. [1, 0x80000000]
which I'll note again is outside the min/max values associated with
last's type.
We now return to the PHI node:
lastD.2483_148 = PHI <lastD.2483_60(28), lastD.2483_15(14)>;
We still only have one edge (from block #14) marked executable,
so nothing interesting happens yet.
We then visit the PHI node a 4th time. This time both edges are
marked as executable. So we're going to have to meet the ranges
for last_60 [0x1, 0x80000000] and last_15 [0x0, 0x7fffffff].
Now with the range for last_60 being outside the type's min/max values
I don't think we can meaningfully merge these ranges. We've clearly
gone off the reservation already, but just for fun let's see what
happens.
The min value is computed as 0x0, which is exactly what we would
expect. Nothing fun or interesting here.
What's fun is meeting the max values of 0x8000000 and 0x7fffffff.
vrp_meet returns 0x80000000 as the meet value. OK, that's plausible,
I don't think vrp_meet tries to clamp values at min/max for the type.
We then fallinto this hunk of code:
3995 if (lhs_vr->type == VR_RANGE && vr_result.type == VR_RANGE)
3996 {
3997 if (!POINTER_TYPE_P (TREE_TYPE (lhs)))
3998 {
3999 int cmp_min = compare_values (lhs_vr->min,
vr_result.min);
4000 int cmp_max = compare_values (lhs_vr->max,
vr_result.max);
4001
4002 /* If the new minimum is smaller or larger than the
previous
4003 one, go all the way to -INF. In the first case, to
avoid
4004 iterating millions of times to reach -INF, and in
the
(gdb)
4005 other case to avoid infinite bouncing between
different
4006 minimums. */
4007 if (cmp_min > 0 || cmp_min < 0)
4008 vr_result.min = TYPE_MIN_VALUE (TREE_TYPE
(vr_result.min));
4009
4010 /* Similarly, if the new maximum is smaller or larger
than
4011 the previous one, go all the way to +INF. */
4012 if (cmp_max < 0 || cmp_max > 0)
4013 vr_result.max = TYPE_MAX_VALUE (TREE_TYPE
(vr_result.max));
4014
(gdb)
4015 /* If we ended up with a (-INF, +INF) range, set it to
4016 VARYING. */
4017 if (vr_result.min == TYPE_MIN_VALUE (TREE_TYPE
(vr_result.min))
4018 && vr_result.max == TYPE_MAX_VALUE (TREE_TYPE
(vr_result.max)))
4019 goto varying;
lhs_vr->max is 0x7fffffff and vr_result->max is 0x80000000, so cmp_max
is -1. Which indicates we should set a new maximum to be the maximum
for the type. The maximum for the type is 0x7fffffff. But just as
important, this ends up changing the underlying type for vr_result.max,
instead of being "natural___XDLU_0__2147483647" it's a more generic
integer type. Ugh! Now we go to update the range for the result
using update_value_range. We determine the range is new, even though
the underlying values are unchanged because we're using pointer
equality for all our tests (this is bad).
So we consider the PHI node's result as being new, so we re-simulate
the uses of the PHI result and we end up ping-ponging back and
forth betwen 0x7fffffff and 0x80000000 as its upper value due to
the type inconsistencies. And and because of the pointer equality
tests in update_value_range we keep thinking we've got a new range
for the result of the PHI every time. Net result is an infinite loop.
So what needs to be fixed.
First, the inconsistency between the type's precision in its min/max
values needs to be fixed. Most likely this is an Ada FE problem.
Second, for a given integer type (such as natural___XDLU_0_2147483647,
the type for the nodes in TYPE_MIN_VALUE and TYPE_MAX_VALUE really
should be a natural___XDLU_0_2147483647. ie, the type of an integer
constant should be the same as the type of its min/max values.
Otherwise we're a lot more likely to ping pong because the
anti-ping-pong tests use pointer equality to check and see if
a range's type, min or max values have changed. When an integer
type's min/max values are of a different type, we can think that
a value changed when in fact it did not change at all.
Again, both of these are issues an Ada maintainer is going to
need to look at in depth.
Jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (8 preceding siblings ...)
2006-02-19 0:16 ` law at redhat dot com
@ 2006-02-19 0:23 ` laurent at guerby dot net
2006-02-25 17:08 ` pinskia at gcc dot gnu dot org
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: laurent at guerby dot net @ 2006-02-19 0:23 UTC (permalink / raw)
To: gcc-bugs
------- Comment #9 from laurent at guerby dot net 2006-02-19 00:23 -------
May be Richard Kenner could help here?
--
laurent at guerby dot net changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kenner at vlsi1 dot ultra
| |dot nyu dot edu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (9 preceding siblings ...)
2006-02-19 0:23 ` laurent at guerby dot net
@ 2006-02-25 17:08 ` pinskia at gcc dot gnu dot org
2006-02-28 16:54 ` law at redhat dot com
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-02-25 17:08 UTC (permalink / raw)
To: gcc-bugs
------- Comment #10 from pinskia at gcc dot gnu dot org 2006-02-25 17:07 -------
This blocks PR 26338 getting fixed.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
OtherBugsDependingO| |26338
nThis| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (10 preceding siblings ...)
2006-02-25 17:08 ` pinskia at gcc dot gnu dot org
@ 2006-02-28 16:54 ` law at redhat dot com
2006-02-28 17:29 ` law at redhat dot com
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: law at redhat dot com @ 2006-02-28 16:54 UTC (permalink / raw)
To: gcc-bugs
------- Comment #11 from law at redhat dot com 2006-02-28 16:53 -------
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Sun, 2006-02-19 at 00:16 +0000, law at redhat dot com wrote:
>
> ------- Comment #8 from law at redhat dot com 2006-02-19 00:16 -------
> Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
> -O1 -ftree-vrp
This patch works around the problems with Ada's setting of
TYPE_MIN_VALUE/TYPE_MAX_VALUE and allows Ada to bootstrap.
I still think Ada is abusing our type system, but I'm in
no position to fix the Ada front-end.
There's still some problems in the acats testsuite that I
suspect are related to the VRP improvements. I'll be looking
at those next.
This patch bootstraps and has been regression tested. Again,
there are Ada testsuite failures related to the VRP improvements
which are neither fixed nor made worse by this patch. I'm
going to suggest we keep this PR open for now.
------- Comment #12 from law at redhat dot com 2006-02-28 16:53 -------
Created an attachment (id=10940)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10940&action=view)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (11 preceding siblings ...)
2006-02-28 16:54 ` law at redhat dot com
@ 2006-02-28 17:29 ` law at redhat dot com
2006-02-28 17:29 ` rguenth at gcc dot gnu dot org
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: law at redhat dot com @ 2006-02-28 17:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #14 from law at redhat dot com 2006-02-28 17:29 -------
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Tue, 2006-02-28 at 17:21 +0000, rguenth at gcc dot gnu dot org wrote:
> sounds odd - adding 1 to the range [0, 0x7fffffff] for a type
> with the said min/max value should result in [1, 0x7fffffff],
> not [1, 0x80000000]. Why is the resulting range not clipped to
> the types min/max value? I can see no difference with this "special"
> case specifying 31bit precision to any other "non-special" min/max
> range like [5, 8]. But I must miss something.
The fold routines use TYPE_PRECISION for clipping, not
TYPE_MIN_VALUE/TYPE_MAX_VALUE. If you think about it for
a little while, it actually makes sense as they are basically
mimicking what's going to happen at the hardware level.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (12 preceding siblings ...)
2006-02-28 17:29 ` law at redhat dot com
@ 2006-02-28 17:29 ` rguenth at gcc dot gnu dot org
2006-02-28 17:39 ` ebotcazou at gcc dot gnu dot org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: rguenth at gcc dot gnu dot org @ 2006-02-28 17:29 UTC (permalink / raw)
To: gcc-bugs
------- Comment #13 from rguenth at gcc dot gnu dot org 2006-02-28 17:21 -------
The following
-----------
Only the edge from block #14 is executable, so the result of the
PHI will be equivalent to the current range for last_15. The
range we record is [0, 0x7fffffff].
We then proceed to the uses of last_148. One of which is:
lastD.2483_86 = lastD.2483_148 + 1;
Now for the first "oddity". If we look at the underlying type
for last we have a type "natural___XDLU_0__2147483647". What's
interesting about it is that it has a 32bit type precision, but
the min/max values only specify 31 bits. ie, the min/max values
are 0, 0x7fffffff.
So anyway, we proceed to add the current range for last_148
[0, 0x7fffffff] to the constant 1. This results in
[1, 0x80000000]. Second oddity. This is clearly outside the
type's min/max values, but because the value is inside the
type's precision, no overflow is signaled and no bits are
zero'd out.
-----------
sounds odd - adding 1 to the range [0, 0x7fffffff] for a type
with the said min/max value should result in [1, 0x7fffffff],
not [1, 0x80000000]. Why is the resulting range not clipped to
the types min/max value? I can see no difference with this "special"
case specifying 31bit precision to any other "non-special" min/max
range like [5, 8]. But I must miss something.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (13 preceding siblings ...)
2006-02-28 17:29 ` rguenth at gcc dot gnu dot org
@ 2006-02-28 17:39 ` ebotcazou at gcc dot gnu dot org
2006-02-28 18:47 ` law at redhat dot com
2006-03-04 18:30 ` pinskia at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: ebotcazou at gcc dot gnu dot org @ 2006-02-28 17:39 UTC (permalink / raw)
To: gcc-bugs
------- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-02-28 17:29 -------
> There's still some problems in the acats testsuite that I
> suspect are related to the VRP improvements. I'll be looking
> at those next.
I can lend a hand at this point if you're fed up with Ada. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (14 preceding siblings ...)
2006-02-28 17:39 ` ebotcazou at gcc dot gnu dot org
@ 2006-02-28 18:47 ` law at redhat dot com
2006-03-04 18:30 ` pinskia at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: law at redhat dot com @ 2006-02-28 18:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #16 from law at redhat dot com 2006-02-28 18:31 -------
Subject: Re: [4.2 Regression] ICE compiling a-textio.adb at
-O1 -ftree-vrp
On Tue, 2006-02-28 at 17:29 +0000, ebotcazou at gcc dot gnu dot org
wrote:
>
> ------- Comment #15 from ebotcazou at gcc dot gnu dot org 2006-02-28 17:29 -------
> > There's still some problems in the acats testsuite that I
> > suspect are related to the VRP improvements. I'll be looking
> > at those next.
>
> I can lend a hand at this point if you're fed up with Ada. :-)
Well, I'm going to start with the testsuite hang, with any luck it'll
be the same kind of problem we've been fighting the last week and I
won't actually have to do anything with the Ada FE, just track down
another place that needs a hack like we installed in tree-chrec.c.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp
2006-02-18 7:43 [Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp? laurent at guerby dot net
` (15 preceding siblings ...)
2006-02-28 18:47 ` law at redhat dot com
@ 2006-03-04 18:30 ` pinskia at gcc dot gnu dot org
16 siblings, 0 replies; 18+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-03-04 18:30 UTC (permalink / raw)
To: gcc-bugs
------- Comment #17 from pinskia at gcc dot gnu dot org 2006-03-04 18:30 -------
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26348
^ permalink raw reply [flat|nested] 18+ messages in thread