Re: [rfc][24/37] Eliminate builtin_type_ macros: Platform-neutral generic integers

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

Joel Brobecker wrote:

> > @@ -197,11 +197,11 @@ print_range_bound (struct type *type, ch
> >           the upper bound of the 0 .. -1 range types to be printed as
> >           a very large unsigned number instead of -1.
> >           To workaround this stabs deficiency, we replace the TYPE by
> > -         builtin_type_long when we detect that the bound is negative,
> > +         builtin_type_int32 when we detect that the bound is negative,
> >           and the type is a TYPE_CODE_INT.  The bound is negative when
> >           'm' is the last character of the number scanned in BOUNDS.  */
> >        if (bounds[*n - 1] == 'm' && TYPE_CODE (type) == TYPE_CODE_INT)
> > -	type = builtin_type_long;
> > +	type = builtin_type_int32;
> >        ada_print_scalar (type, B, stream);
> >        if (bounds[*n] == '_')
> >  	*n += 2;
> 
> I'm slightly concerned about the effect of this change on 64-bit
> platforms. Normally, stabs is a 32bit format so this shouldn't be
> a problem, but Tru64 is a 64-bit platform with stabs, and the
> range values are stored as text in the stabs string. So presumably
> 64-bit range types are possible...  However, I couldn't come up with
> a case where things get degraded. Nor did the testsuite, which does
> also test the case described in the comments), reveal any regression.
> So I guess we should be OK.

OK, thanks for verifying this.

> > Index: gdb-head/gdb/p-typeprint.c
> > ===================================================================
> > --- gdb-head.orig/gdb/p-typeprint.c
> > +++ gdb-head/gdb/p-typeprint.c
> > @@ -756,7 +756,7 @@ pascal_type_print_base (struct type *typ
> >        {
> >  	struct type *target = TYPE_TARGET_TYPE (type);
> >  	if (target == NULL)
> > -	  target = builtin_type_long;
> > +	  target = builtin_type_int32;
> >  	print_type_scalar (target, TYPE_LOW_BOUND (type), stream);
> >  	fputs_filtered ("..", stream);
> >  	print_type_scalar (target, TYPE_HIGH_BOUND (type), stream);
> 
> Just an observation: This part seems erroneous, no? type is a
> TYPE_CODE_RANGE, but there is no underlying TARGET_TYPE? Would
> it make better sense to error-out instead? On platforms using DWARF,
> this should never happen (we complain about the missing base type
> and use an integer type as a substitute). For stabs, things seem
> a little less clear, but it looks like we also always create range
> types with a base type. So maybe this should never happen. Anyway,
> if there is a Fortran maintainer reading this...

I agree that this should never trigger, as create_range_type is
never called with a NULL index_type argument.  (For stabsread.c
it seems it might get called with a builtin_type_error argument
in certain cases, but never NULL.)

The same holds for the copies of this code in m2-typeprint.c and
m2-valprint.c.

However, I simply wanted to preserve the status quo with this patch
set -- those checks can be removed with a follow-on patch.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com