egcs-1.1b dbxout.c and non-constant TYPE_{MIN,MAX}_VALUE

[Sergio Gelato]

Greetings to all. And my apologies if this has been
discussed before (but a scan of the last two months
of list traffic did not turn up anything obviously
related).

I've been trying to build egcs-1.1b together with
gnat-3.10p on an i586 with Linux and libc1. Thanks
to the posted patches (and to the addition of
-D__builtin_setjmp=__setjmp -D__builtin_longjump=longjump
on the gnatgcc command line for the first bootstrap
stage; I hope the gentleman who mentioned that
problem over on egcs-patches is reading this)
I've been able to build everything successfully.

HOWEVER, the comparison of stages 2 and 3 turns up
differences in the debug stabs of a number of Ada
object files. These are all describing integer range
types where at least one of the bounds is non-static.
The stored values for the nonconstant bounds are
often different between stage 2 and stage 3. Of
course this is irrelevant to the functioning of the
program, and the debugger is supposed to get the
actual bounds from gnat-generated auxiliary variables.
It is, however, annoying to see the bootstrap fail,
and erroneous to store random bound values in the
debug stabs.

What I think is missing is a check that TYPE_MIN_VALUE
and TYPE_MAX_VALUE are constant expressions. When they
aren't, an appropriate default bound should be inserted
instead of whatever happens to occupy the same bits
in the tree structure as the value of a constant would.
I also think that an appropriate choice would be to
use the corresponding bound from the parent type.
(gcc 2.7.2 seems to have been using -1 as the fall-back
upper bound and 0 as the fall-back lower bound, but
I don't believe that's always the right thing to do.)

Could someone with appropriate knowledge of gcc internals work out a suitable patch for this? If
not, I'll have a stab (:-)) at it myself eventually,
but the result is likely to be suboptimal.

If I understood the source code correctly, the DWARF
and DWARF2 debug formats don't have this problem, as
the possibility of non-constant bounds is already
explicitly considered.


-----== Sent via Deja News, The Discussion Network ==-----
http://www.dejanews.com/  Easy access to 50,000+ discussion forums