Failure to optimize number.cc in gnu troff.

[Jim Hand <jhand at austx dot tandem dot com>]

Hi,
   When I try to compile number.cc in gnu's troff program
(part of the groff package), troff always fails due to an
assertion error.  This is a i586-pc-linux-gnu system and the
failures have happened on every snapshot so far of egcs
and I believe also with the last pgcc snapshot before egcs
was first begun.  Compiling number.cc with "-mpentium"
works, while compiling with "-O -mpentium" or "-O2 -mpentium"
causes the executable to fail with an assertion error
when run.  I tried narrowing down the problem somewhat, but
have been unable to recreate a simple test case that exhibits
the same behavior.  The assertion error when trying to view
any man page is always:

troff: Failed assertion at line 626, file `number.cc'.
groff: troff: Aborted (core dumped)

Here is the stack trace of the dump:

(gdb) where
#0  0x400413e1 in ?? () from /lib/libc.so.6
#1  0x400422b5 in ?? () from /lib/libc.so.6
#2  0x8071a29 in assertion_failed () at reg.cc:28
#3  0x8071808 in scale (n=0, x=-1059102256, y=1) at ../include/assert.h:29
#4  0x8071672 in parse_term (v=0xbffff970, scale_indicator=109,
    parenthesised=0) at number.cc:593
#5  0x80708ea in parse_expr (v=0xbffff970, scale_indicator=109,
    parenthesised=0) at number.cc:227
#6  0x807082a in get_incr_number (res=0xbffff970, si=109 'm') at
    number.cc:194
#7  0x807061d in get_hunits (res=0xbffff990, si=109, prev_value={n = 10})
    at number.cc:120
#8  0x806d2d4 in page_offset () at div.cc:610
#9  0x80619d7 in request::invoke (this=0x8083090) at input.cc:2272
#10 0x8063682 in interpolate_macro (nm={static table = 0x808b628,
      static table_used = 558, static table_size = 2003,
      static block = 0x8094ec1 "", static block_size = 911,
      s = 0x808acd8 "po"}) at input.cc:2864
#11 0x80612e4 in process_input_stack () at input.cc:2068
#12 0x80696ad in process_startup_file () at input.cc:5224
#13 0x806a103 in main (argc=4, argv=0xbffffae4) at input.cc:5503

The code that causes the problem is within the parse_term():

589: case 'n':
590: {
591:   // Convert to hunits so that with -Tascii `n' behaves as in nroff.
592:   hunits en = curenv->get_size()/2;
593:   *v = scale(*v, en.is_zero() ? hresolution : en.to_units(),divisor);
594: }

It appears that the "en" object is being constructed fine,
but by the time scale is called, I think that the "en" object
has been clobbered.  Parse_term() is a pretty long function and
the code segment above occurs pretty far down within it.  I am
not sure if this is related.

Jim Hand
Tandem Computers