https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #30)
> On 10/19/20 6:40 PM, bergner at gcc dot gnu.org wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97360
> >
> > --- Comment #28 from Peter Bergner <bergner at gcc dot gnu.org> ---
> > (In reply to Andrew Macleod from comment #25)
> >> Wonder if it was suppose to be something like:
> >>
> >>
> >>     /* Vector pair and vector quad support.  */
> >>     if (TARGET_EXTRA_BUILTINS)
> >>       {
> >> -      tree oi_uns_type = make_unsigned_type (256);
> >> -      vector_pair_type_node = build_distinct_type_copy (oi_uns_type);
> >> +      vector_pair_type_node = make_unsigned_type (256);
> >>         SET_TYPE_MODE (vector_pair_type_node, POImode);
> >>         layout_type (vector_pair_type_node);
> >>         lang_hooks.types.register_builtin_type (vector_pair_type_node,
> >>                                                "__vector_pair");
> >>   
> >> -      tree xi_uns_type = make_unsigned_type (512);
> >> -      vector_quad_type_node = build_distinct_type_copy (xi_uns_type);
> >> +      vector_quad_type_node = make_unsigned_type (512);
> >>         SET_TYPE_MODE (vector_quad_type_node, PXImode);
> >>         layout_type (vector_quad_type_node);
> >>         lang_hooks.types.register_builtin_type (vector_quad_type_node,
> > So this passed bootstrap and regtesting with no regressions.
> >
> > Is this really the correct fix?

Yes.

> >  Don't we want a distinct type compared to the
> > unsigned type returned from make_unsigned_type()?

But make_unsigned_type already returns a distinct type.  It's a low-level
worker unless for example make_nonstandard_integer_type which caches types.

> I actually dont know, Richi might have to comment on that.. Nothing was 
> referring to the original unsigned_type that was created?  Its just 
> orphaned?
> 
> tree
> make_unsigned_type (int precision)
> {
>    tree type = make_node (INTEGER_TYPE);
> 
>    TYPE_PRECISION (type) = precision;
> 
>    fixup_unsigned_type (type);
>    return type;
> }
> 
> 
> All it does is create a new node, then fixup goes and creates the MIN 
> and MAX fields and sets a few other little things.     The only reason 
> we saw the old unsigned type is we were picking it up from the MAX and 
> MIN fields,... which  were set to the original type.
> 
> it sure *seems* like that is a resonable fix.  Its not like that first 
> node is creating a system wide node?
> 
> our type system is a bit, umm, flakey,  but it seems reasonable to me.   
> :-)  And its in the spirit of what his patch was doing...
> 
> What could possibly go wrong? :-) :-)

Nothing.

> Andrew

Reply via email to