[Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp?

[Bug ada/26348] New: Ada gnatlib a-textio.o ICE because of too much RAM, tree-vrp?

[laurent at guerby dot net]

I'm seeing bootstrap failing on x86 and amd64-linux:
WORK Thu Feb 16 21:06:28 UTC 2006 (revision 111151)
FAIL Fri Feb 17 12:16:43 UTC 2006 (revision 111180)
FAIL Fri Feb 17 20:56:47 UTC 2006 (revision 111208)

...
/home/guerby/work/gcc/build/build-head-20060217T133449/./gcc/xgcc
-B/home/guerby/work/gcc/build/build-head-20060217T133449/./gcc/
-B/home/guerby/work/gcc/install/install-head-20060217T133449/x86_64-unknown-linux-gnu/bin/
-B/home/guerby/work/gcc/install/install-head-20060217T133449/x86_64-unknown-linux-gnu/lib/
-isystem
/home/guerby/work/gcc/install/install-head-20060217T133449/x86_64-unknown-linux-gnu/include
-isystem
/home/guerby/work/gcc/install/install-head-20060217T133449/x86_64-unknown-linux-gnu/sys-include
-c -g -O2 -fPIC      -W -Wall -gnatpg  a-textio.adb -o a-textio.o
xgcc: Internal error: Killed (program gnat1)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
make[7]: *** [a-textio.o] Error 1
make[7]: Leaving directory
`/home/guerby/work/gcc/build/build-head-20060217T133449/gcc/ada/rts'
make[6]: *** [gnatlib] Error 2
make[6]: Leaving directory
`/home/guerby/work/gcc/build/build-head-20060217T133449/gcc/ada'
make[5]: *** [gnatlib-shared-default] Error 2
make[5]: Leaving directory
`/home/guerby/work/gcc/build/build-head-20060217T133449/gcc/ada'
make[4]: *** [gnatlib-shared-dual] Error 2
make[4]: Leaving directory
`/home/guerby/work/gcc/build/build-head-20060217T133449/gcc/ada'
make[3]: *** [gnatlib-shared] Error 2
make[3]: Leaving directory
`/home/guerby/work/gcc/build/build-head-20060217T133449/gcc/ada'
make[2]: *** [gnatlib-shared] Error 2
make[2]: Leaving directory
`/home/guerby/work/gcc/build/build-head-20060217T133449/x86_64-unknown-linux-gnu/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory
`/home/guerby/work/gcc/build/build-head-20060217T133449'
make: *** [bootstrap] Error 2

gnat1 goes up in RAM until a SEGV. At 700MB here is a backtrace

0x085d480c in build_int_cst_wide (type=0x4016c284, low=1, hi=0) at
/home/guerby/work/gcc/version-head/gcc/tree.c:861
861           t = TREE_VEC_ELT (TYPE_CACHED_VALUES (type), ix);
(gdb) bt
#0  0x085d480c in build_int_cst_wide (type=0x4016c284, low=1, hi=0) at
/home/guerby/work/gcc/version-head/gcc/tree.c:861
#1  0x085d5140 in build_int_cst (type=0x0, low=1) at
/home/guerby/work/gcc/version-head/gcc/tree.c:695
#2  0x08664915 in instantiate_parameters_1 (loop=0x8eed060, chrec=<value
optimized out>, flags=<value optimized out>, cache=0xb78b058, size_expr=0)
    at tree-chrec.h:108
#3  0x0866585e in instantiate_parameters (loop=0x8eed060, chrec=0x410f1cf8) at
/home/guerby/work/gcc/version-head/gcc/tree-scalar-evolution.c:2209
#4  0x08604abe in vrp_visit_assignment (stmt=0x40f119b4, output_p=0xbfffec88)
at /home/guerby/work/gcc/version-head/gcc/tree-vrp.c:1970
#5  0x0834b996 in simulate_stmt (stmt=0x40f119b4) at
/home/guerby/work/gcc/version-head/gcc/tree-ssa-propagate.c:306
#6  0x0834bba7 in process_ssa_edge_worklist (worklist=0x8ce6e98) at
/home/guerby/work/gcc/version-head/gcc/tree-ssa-propagate.c:380
#7  0x0834bff2 in ssa_propagate (visit_stmt=0x86050a0 <vrp_visit_stmt>,
visit_phi=0x86009f0 <vrp_visit_phi_node>)
    at /home/guerby/work/gcc/version-head/gcc/tree-ssa-propagate.c:683
#8  0x086067e0 in execute_vrp () at
/home/guerby/work/gcc/version-head/gcc/tree-vrp.c:4569
#9  0x085f6369 in execute_one_pass (pass=0x8d8c710) at
/home/guerby/work/gcc/version-head/gcc/passes.c:854
#10 0x085f64ff in execute_pass_list (pass=0x8d8c710) at
/home/guerby/work/gcc/version-head/gcc/passes.c:898
#11 0x085f6512 in execute_pass_list (pass=0x88874e0) at
/home/guerby/work/gcc/version-head/gcc/passes.c:899
#12 0x082f5272 in tree_rest_of_compilation (fndecl=0x4020c600) at
/home/guerby/work/gcc/version-head/gcc/tree-optimize.c:412
#13 0x080647e4 in gnat_expand_body (gnu_decl=0x4020c600) at
/home/guerby/work/gcc/version-head/gcc/ada/misc.c:653
#14 0x0864c392 in cgraph_expand_function (node=0x40f09380) at
/home/guerby/work/gcc/version-head/gcc/cgraphunit.c:1101
#15 0x0864ecbd in cgraph_optimize () at
/home/guerby/work/gcc/version-head/gcc/cgraphunit.c:1166
#16 0x080651ef in gnat_parse_file (set_yydebug=0) at
/home/guerby/work/gcc/version-head/gcc/ada/misc.c:245
#17 0x085c3265 in toplev_main (argc=16, argv=0xbfffef74) at
/home/guerby/work/gcc/version-head/gcc/toplev.c:999
#18 0x082eb57f in main (argc=Cannot access memory at address 0x8
) at /home/guerby/work/gcc/version-head/gcc/main.c:35


At 900MB

fold_binary (code=PLUS_EXPR, type=0x4019e8fc, op0=0x7568fa68, op1=0x4020fdb0)
at /home/guerby/work/gcc/version-head/gcc/fold-const.c:7236
7236      enum tree_code_class kind = TREE_CODE_CLASS (code);
(gdb) bt
#0  fold_binary (code=PLUS_EXPR, type=0x4019e8fc, op0=0x7568fa68,
op1=0x4020fdb0) at /home/guerby/work/gcc/version-head/gcc/fold-const.c:7236
#1  0x08441777 in fold_build2_stat (code=PLUS_EXPR, type=0x4019e8fc,
op0=0x7568fa68, op1=0x4020fdb0)
    at /home/guerby/work/gcc/version-head/gcc/fold-const.c:10781
#2  0x086c0db0 in scev_probably_wraps_p (type=0x4019e8fc, base=0x7568fa44,
step=0x4020fdb0, at_stmt=0x4114c0d8, loop=0x8eed060,
    init_is_max=0xbfffec4b "", unknown_max=0xbfffec4a "") at
/home/guerby/work/gcc/version-head/gcc/tree-ssa-loop-niter.c:1926
#3  0x08604cb5 in vrp_visit_assignment (stmt=0x4114c0d8, output_p=0xbfffec88)
at /home/guerby/work/gcc/version-head/gcc/tree-vrp.c:1984
#4  0x0834b996 in simulate_stmt (stmt=0x4114c0d8) at
/home/guerby/work/gcc/version-head/gcc/tree-ssa-propagate.c:306
#5  0x0834bba7 in process_ssa_edge_worklist (worklist=0x8ce6e98) at
/home/guerby/work/gcc/version-head/gcc/tree-ssa-propagate.c:380
#6  0x0834bff2 in ssa_propagate (visit_stmt=0x86050a0 <vrp_visit_stmt>,
visit_phi=0x86009f0 <vrp_visit_phi_node>)
    at /home/guerby/work/gcc/version-head/gcc/tree-ssa-propagate.c:683
#7  0x086067e0 in execute_vrp () at
/home/guerby/work/gcc/version-head/gcc/tree-vrp.c:4569
#8  0x085f6369 in execute_one_pass (pass=0x8d8c710) at
/home/guerby/work/gcc/version-head/gcc/passes.c:854
#9  0x085f64ff in execute_pass_list (pass=0x8d8c710) at
/home/guerby/work/gcc/version-head/gcc/passes.c:898
#10 0x085f6512 in execute_pass_list (pass=0x88874e0) at
/home/guerby/work/gcc/version-head/gcc/passes.c:899
#11 0x082f5272 in tree_rest_of_compilation (fndecl=0x4020c600) at
/home/guerby/work/gcc/version-head/gcc/tree-optimize.c:412
#12 0x080647e4 in gnat_expand_body (gnu_decl=0x4020c600) at
/home/guerby/work/gcc/version-head/gcc/ada/misc.c:653
#13 0x0864c392 in cgraph_expand_function (node=0x40f09380) at
/home/guerby/work/gcc/version-head/gcc/cgraphunit.c:1101
#14 0x0864ecbd in cgraph_optimize () at
/home/guerby/work/gcc/version-head/gcc/cgraphunit.c:1166
#15 0x080651ef in gnat_parse_file (set_yydebug=0) at
/home/guerby/work/gcc/version-head/gcc/ada/misc.c:245
#16 0x085c3265 in toplev_main (argc=16, argv=0xbfffef74) at
/home/guerby/work/gcc/version-head/gcc/toplev.c:999
#17 0x082eb57f in main (argc=Cannot access memory at address 0x0
) at /home/guerby/work/gcc/version-head/gcc/main.c:35

At -O1 the compilation is successfull, at -O1 -ftree-vrp it doesn't.

The only explicit VRP change in the revision range is:

r111175 | law | 2006-02-17 05:15:32 +0100 (Fri, 17 Feb 2006) | 33 lines


        * tree-vrp.c (set_value_range_to_nonnegative): New function.
        (vrp_expr_computes_nonnegative, ssa_name_nonnegative_p): Likewise.
        (ssa_name_nonzero_p): Likewise.
        (get_value_range): Return NULL if VRP is not running.
...


-- 
           Summary: Ada gnatlib a-textio.o ICE because of too much RAM,
                    tree-vrp?
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code, build
          Severity: normal
          Priority: P3
         Component: ada
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: laurent at guerby dot net


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

[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp

[ebotcazou at gcc dot gnu dot org]

-- 

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

[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp

[schwab at suse dot de]

------- 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

[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp

[laurent at guerby dot net]

------- 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

[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp

[law at redhat dot com]

------- 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

[Bug ada/26348] ICE compiling a-textio.adb at -O1 -ftree-vrp

[danglin at gcc dot gnu dot org]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[pinskia at gcc dot gnu dot org]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[law at redhat dot com]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[law at redhat dot com]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[law at redhat dot com]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[laurent at guerby dot net]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[pinskia at gcc dot gnu dot org]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[law at redhat dot com]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[rguenth at gcc dot gnu dot org]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[law at redhat dot com]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[ebotcazou at gcc dot gnu dot org]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[law at redhat dot com]

------- 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

[Bug ada/26348] [4.2 Regression] ICE compiling a-textio.adb at -O1 -ftree-vrp

[pinskia at gcc dot gnu dot org]

------- 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